Managed to read Star Fox SNES ROM using VL-Tone guides. I need more info.

[Stef]

Hey Dyson,

I'm still working on that
In fact i already have the high poly arwing in .obj format so i could use it but i prefer to be able to directly rip all data from the rom or SFXEdit as it does give extra info as description / name which is cool
All decompilation informations are valuables and the high poly arwing informations you posted are very interesting !
Normally having -1 followed by 0 in facegroup means you reached the end of facegroup definition, but i guess we should have more facegroup from the high poly arwing.

I'm currently writing a tool to decompile ans show all Starfox object data from the rom as it's really painful to do it manually. I'm experiencing issues with some unknown tag (as $1C vertex list which correspond to animated vertex). I guess i will just ignore them and try to only parse valid data. As soon the tool will be ready i will probably post it here

[dyson132]

That sounds awesome Stef!

I've learnt more about roms just from this thread alone so thank you but I think I've reach the limit of what I can dig up. If I think of something else I'll post it but I think you've had much more progress than I ever could.
Since you know more about the use of the color palette I'll try ripping the openGL color table from SFXEdit myself since I'd want to use something like that.

If I could leave you with some questions just so I know stuff:
-What tools have you been using to the hack the rom? Any particular procedure?
-What programming language are you using for the decompiling tool?
-Did you already crack the color palettes method? How about the color changing ones and are they dependant on ztimer as the animations are?


In case anybody is curious, here is a portion of the Hex colors tables to RGB Values found inside SFXedit 0.93.exe. There are at least 40 (?) references to TXT files, each with long strings of the following parsed and easily readable. I'm sure one can extrapolate the RGB values from the color tables (see Mattrizzle's post). Notice at the begginning there are rgb values and in the second half there are Hex combinations:

Code Select Expand

[rgb( 235, 251, 251 ), rgb( 170, 251, 251 ), rgb( 235, 251, 251 ), rgb( 105, 219, 251 ), rgb( 235, 251, 251 ), rgb( 170, 251, 251 ), rgb( 235, 251, 251 ), rgb( 97, 138, 251 )], [rgb( 235, 251, 251 ), rgb( 251, 170, 105 ), rgb( 235, 251, 251 ), rgb( 251, 211, 146 )], [rgb( 235, 251, 251 ), rgb( 195, 219, 235 ), rgb( 154, 178, 195 ), rgb( 113, 130, 154 ), rgb( 73, 97, 113 ), rgb( 24, 48, 73 ), rgb( 24, 48, 73 ), rgb( 24, 48, 73 )], "1B,40", "1F,40", [rgb( 251, 211, 146 ), rgb( 170, 8, 65 )], ["A0,40", "A1,40", "A2,40", "A3,40", "A4,40", "A4,40", "A5,40", "A5,40"], ["0C,40", "0D,40", "0E,40", "0D,40"], "AA,40", "DF,40", "DF,40", ["19,40", "1A,40", "1C,40", "19,40", "1A,40", "1C,40", "19,40", "1A,40"], ["0A,40", "0B,40", "0F,40", "0B,40"], "A9,40", ["3D,46", "3C,46", "3B,46", "3B,46", "3A,46", "3A,46", "39,46", "39,46"], ["1D,40", "1E,40", "1D,40", "1E,40", "1D,40", "1E,40", "1D,40", "1E,40"], "00,40", ["CC,40", "CD,40", "CC,40", "CE,40"], ["15,40", "16,40", "17,40", "16,40"], "D0,46", "D0,46", ["C7,40", "C9,40", "C8,40", "C9,40"], ["CB,40", "13,40"], "D4,44", "D4,45", "D5,44", "D5,45", "B4,40", ["3B,46", "3C,46"], "07,40", "02,3B", "46,3C", [], rgb( 97, 138, 251 ), rgb( 97, 149, 162 ), rgb( 48, 109, 235 ), [],

[Zoinkity]

STXT is an indicator in the macromedia bytecode.  The length of the text is at +0xC, and text starts 0x14 from there.  For instance, within STXT block at 0x9031A4, 0x251 bytes of text:

Code Select Expand

mtllib cube.mtl

    shadow_obj cube.obj

    v 0.000000 2.000000 2.000000
    v 0.000000 0.000000 2.000000
    v 2.000000 0.000000 2.000000
    v 2.000000 2.000000 2.000000
    v 0.000000 2.000000 0.000000
    v 0.000000 0.000000 0.000000
    v 2.000000 0.000000 0.000000
    v 2.000000 2.000000 0.000000
  # 8 vertices

    g front
    usemtl red
    f 1 2 3 4
    g back
    usemtl blue
    f 8 7 6 5
    g right
    usemtl green
    f 4 3 7 8
    g top
    usemtl gold
    f 5 1 4 8
    g left
    usemtl orange
    f 5 6 2 1
    g bottom
    usemtl purple
    f 2 6 7 3
    # 6 elements


Should be pretty easy to automate with a script, but you'd wind up with every string used, possibly also some source code and comments.

[dyson132]

@Zoinkity
Interesting. I was curious about the STXT strings and since they looked exactly like formated text I just thought they were plain TXT files.
Anyways, I believe Shockwave is very much dead and I tried finding somthing like you mention or maybe a Shockwave Director decompiler but I had no luck with it. SFXedit 0.93.exe isn't even encrypted.

[Stef]

That sounds awesome Stef!

I've learnt more about roms just from this thread alone so thank you but I think I've reach the limit of what I can dig up. If I think of something else I'll post it but I think you've had much more progress than I ever could.

We are already made nice progress but i think there is still a lot to discover
I continue my work on the object ripper tool, making slow progress, i hope to have something ready soon !

Since you know more about the use of the color palette I'll try ripping the openGL color table from SFXEdit myself since I'd want to use something like that.

I guess the palette used in SFX Edit are more suited for what i intend to do, in my case i want to conserve the exact same look and so use the original palette

If I could leave you with some questions just so I know stuff:
-What tools have you been using to the hack the rom? Any particular procedure?

Honestly I'm not used to rom hacking... I just use a hexa editor and try to understand how stuff are encoded by making relation between different values

-What programming language are you using for the decompiling tool?

I'm using java as it is a language i'm used to (use it professionally) and it's better than C to design GUI.

-Did you already crack the color palettes method? How about the color changing ones and are they dependant on ztimer as the animations are?

Yeah i got almost all the palette encoding, right now i'm only working with the main sub palette (the one refered by 13 83 in object header). I almost got all informations from this post :
http://acmlm.kafuka.org/archive2/thread.php?id=6876

I've to admit i had to reread it ten of times before understand the whole ^^
Here's a share with all my palettes rip and some informations about palette decoding :

https://www.dropbox.com/sh/kyvjzvnj1q4fqwh/PS12A3Xjd8/dev/sfx

Actually you find the color info in face data (from the face group data).
The color byte value permit to find the color type from the main palette you have here :

Rom address : $18413

From this palette you will read 2 bytes indicating color/texture references.
First byte value generally give color type and the second give color index.

Color type value :

00-09 refer to lighted colors palette.
The type also give the color index here (same value for each byte). The final color is obtained from color index and the light index.
Light index is calculated with the cross product of face normal and light vector (which is fixed for each level).
You can find the whole light palette color here (10 colors * 10 light level * 4 depth sub palette) :

Rom address :  $19000

3E XX refer to 32 solid colors palette.
Second byte is the color index (00 to 1F).
Whole palette here (32 colors * 4 depth sub palette * 4/5 context sub palette) :

Rom address : $18D8A

3F XX refer direct color.
Each X is from the standard StarFox 4-bit palette to form the checkerboard pattern

8X XX refer to animated color/texture palette.
XXX is anim data offset (18XXX$+200$ in ROM).
First byte of animated data is the number of frames then the color data is in this same format as explained above (i.e. 3F XX for direct color).

Note than you always obtain a byte as final color : XX, each X being 4 bits and representing 1 of the 16 colors from the master palette here :


Well i think my post is a total mess, try to use VL-Tone topic as references as i believe he explained far better than i did here.
You can use my images to help

[dyson132]

Well i think my post is a total mess, try to use VL-Tone topic as references as i believe he explained far better than i did here.
You can use my images to help

I read his documents far too much times and even though I understood how they could work I never would have been able to integrate everything, between errors in the documents and no knowledge of hex I was going to get nowhere.
One question though, do you happen to know the light vector for Corneria Level 1? or how to find any? I will use that and rip the original Arwing as Hex values into my c++/openGL application just to make sure I've done it correctly.

I've been trying to find someone interested in the topic for at least three years, may I ask what got you interested in this?
I'll try and work on my palette conversión tools.
Thank you very much for all the information and I do look forward to your progress.

Small edit->
I didn't know I could share links with dropbox! Here is the parsed High poly model I had made with some guess work and stuff:
https://www.dropbox.com/s/g0y8gaworrkvo6v/Airwing_Big_high_poly.txt

The type also give the color index here (same value for each byte). The final color is obtained from color index and the light index.
Light index is calculated with the cross product of face normal and light vector (which is fixed for each level).

Cross product between two vectors would be a vector and I think you mentioned it as an index, are you sure it is not the dot product? Dot actually worked very well by interpolating values between the two extremes of a color palette. Here is a picture of what I obtained with a lightVector(1,1,0), shadows seem to be mirrored horizontally but that is not a problem. I also used just one color palete to make it work and I'll add the other colors now.
https://www.dropbox.com/sh/t24ll7lzsgbuzxh/ha_gY9hAox#f:Test%201.png

The only doubt I have left is that if light vector is fixed per stage and normal vectors per face are also fixed then the rotation of the object has to be taken into account at some point.
(I like openGL, I know a whole lot more about it than hex and rom hacking. )


news!
Converted the table in the simplest way and made it use linear interpolation, added a light vector that I could change with the mouse and it does work nicely. Of course, I'd rather do it correctly when I see what you've figured out but I think I've come very close. The screen capture doesn't show but the red circle and line are a visual reference related with the light vector and the shadows of the Arwing appear dynamically as it rotates.
https://www.dropbox.com/s/3cm44gg2rpe5ub5/Test%202.png
Also, the color changing triangle I think is dependant on the zTimer so I had to fake it but at least with the colors from the direct Hex values.
Anyways, I know it works, I can do more in the future. Thanks for all the info!

news 2!
Thought you might like to see a video which was only possible with the progress in this thread. When the shadows instantly change it is because I changes the light vector to some other position:
https://vimeo.com/59810080
It is really fascinating how they managed to design this, the game has no lighting (in the traditional 3D accelerated sense) and it is all mostly tricks that work perfectly together using the least amount of memory and processing available. This was one of the reasons I wanted to see how to do this.

[Stef]

I read his documents far too much times and even though I understood how they could work I never would have been able to integrate everything, between errors in the documents and no knowledge of hex I was going to get nowhere.

I understand your feeling, i also had bad headache with that post... it took me a lot of time to understand the whole thing.

One question though, do you happen to know the light vector for Corneria Level 1? or how to find any? I will use that and rip the original Arwing as Hex values into my c++/openGL application just to make sure I've done it correctly.

I got it just by watching the original game :p
In Corneria 1 you can see light coming from left, i just estimated it

I've been trying to find someone interested in the topic for at least three years, may I ask what got you interested in this?

Well i was searching informations about Starfox, how to extract the object from rom for instance and i finally found that topic which was the most recent one discussing about it and pointing exactly what i was looking for
Your project seems really similar to mine : you want to reproduce game very close to the original one.

I didn't know I could share links with dropbox! Here is the parsed High poly model I had made with some guess work and stuff:
https://www.dropbox.com/s/g0y8gaworrkvo6v/Airwing_Big_high_poly.txt

Hey thanks ! Looks like you gone a bit far when you extracted your face data but all data extracted looks correct when i compare to my object extractor. I made some progress on it, you can download it here if you want to test :

https://dl.dropbox.com/u/93332624/dev/sfx/sfxObjReader.jar

You should open the rom first (the headered version one which we were using previously).
Then you should open "extra" from this file (it gives object name) :
https://dl.dropbox.com/u/93332624/dev/sfx/objects_extras.txt

As the tool is wrote in java you should have a JRE installed on your system to execute it.

Cross product between two vectors would be a vector and I think you mentioned it as an index, are you sure it is not the dot product?

Sorry you are right, i was meaning dot product :p
Negative value mean back faced face (not visible), positive value gives you light factor, just multiply it by 10 to have light index

Dot actually worked very well by interpolating values between the two extremes of a color palette. Here is a picture of what I obtained with a lightVector(1,1,0), shadows seem to be mirrored horizontally but that is not a problem. I also used just one color palete to make it work and I'll add the other colors now.
https://www.dropbox.com/sh/t24ll7lzsgbuzxh/ha_gY9hAox#f:Test%201.png

The only doubt I have left is that if light vector is fixed per stage and normal vectors per face are also fixed then the rotation of the object has to be taken into account at some point.
(I like openGL, I know a whole lot more about it than hex and rom hacking. )

Glad you got it working
If you look at the arwing face color, you will notice that only a few of the face are actually affected by light... i guess that is to minimize light calculation on the SFX as it requires dot product for each face.
To calculate light on a face you have 2 methods :
- apply object transformation to the face normal vector then compute cross product with light vector.
  This method require you to transform each normal vector which is time consuming so you should prefer the second one.
- apply object inverse transformation on the light vector then compute cross product with face normal vector.
This method is better as you only transform the light vector

Also, the color changing triangle I think is dependant on the zTimer so I had to fake it but at least with the colors from the direct Hex values.
Anyways, I know it works, I can do more in the future. Thanks for all the info!

Actually the blinking triangle is a animated color (the 8XXX format).
XXX is the offset containing color animation data (see VL tone post for more information about exact rom address) :
XXX+0: number of frame for animation (4 or 8 for instance)
XXX+1: color frame 0 (color is encoded as previously : 00XX-09XX = light color, 3EXX = solid, 3FXX = direct...)
XXX+3: color frame 1
XXX+5: color frame 2
...

So at each frame you take the next color until you reach the maximum frame then back to color frame 0

news 2!
Thought you might like to see a video which was only possible with the progress in this thread. When the shadows instantly change it is because I changes the light vector to some other position:
https://vimeo.com/59810080

Nice video ! looks really promising
I would like to show something similar but right now I'm not far enough for any interest :-/

It is really fascinating how they managed to design this, the game has no lighting (in the traditional 3D accelerated sense) and it is all mostly tricks that work perfectly together using the least amount of memory and processing available. This was one of the reasons I wanted to see how to do this.

True, the BSPTree structure is really neat and pretty advanced for that period, all the code and structure were heavily optimized both for SuperFX and SNES hardware. I still do not understand how the object shadows are rendered, i guess they used smart tricks for that !

[dyson132]

Hey thanks ! Looks like you gone a bit far when you extracted your face data but all data extracted looks correct when i compare to my object extractor. I made some progress on it, you can download it here if you want to test :

https://dl.dropbox.com/u/93332624/dev/sfx/sfxObjReader.jar

You should open the rom first (the headered version one which we were using previously).
Then you should open "extra" from this file (it gives object name) :
https://dl.dropbox.com/u/93332624/dev/sfx/objects_extras.txt

AWESOME! Yeah I can understand now that I went right past the last hex values of the Airwing_Big_high_poly. xD
This is great! I can verify a lot of stuff now, I'll try and add some functionality to my app and make a video or something. I've been programming it with openFrameworks which uses c++ and openGL. I'm not an expert programmer but I want to learn more.
You mentioned the animated color, do 3d animated object work in a similar way and did you manage to determine what separates those memory blocks?
Also, I know VL-Tone's Arwing doc says that a the faces info stops at FF00 and that sometimes stops with nothing, how did you know when to stop reading for each model?

If you look at the arwing face color, you will notice that only a few of the face are actually affected by light... i guess that is to minimize light calculation on the SFX as it requires dot product for each face.

I think this has the added benefit of maybe simulating different light absorption materials. I guess wings should be very shiny and reflective more than the blue parts, as well as those parts in which parts of a model "emit" light.

Thank you for the extra info, I will try to add stuff as I go, I might go slower now that I'm following you since you are the one making the real hacking progress

True, the BSPTree structure is really neat and pretty advanced for that period, all the code and structure were heavily optimized both for SuperFX and SNES hardware. I still do not understand how the object shadows are rendered, i guess they used smart tricks for that !

In case you are curious I've also seen it used in Doom but the engine has been opensource for years and is already ported to openGL.
http://doom.wikia.com/wiki/Doom_rendering_engine#Node_building
In my particular case in which I use openGL I don't need to use the BSP tree since openGL can be set to determine the position of each triangle using glEnable(GL_DEPTH_TEST), but I would still like to replicate the palette behaviour with checkerboard pattern. It can be replicated very quickly using masks and FBOs, but I won't do this soon.

¿Do you plan on continuing with the hack? Anything I can do to help?

[Stef]

You mentioned the animated color, do 3d animated object work in a similar way and did you manage to determine what separates those memory blocks?

I know animated objects use a special type ($1C) for vertex list but i don't understand yet how things are encoded, it is something i have to work on

Also, I know VL-Tone's Arwing doc says that a the faces info stops at FF00 and that sometimes stops with nothing, how did you know when to stop reading for each model?

Honestly i assumed he was wrong here as without end delimiter the game itself would not be able to parse data correctly.
Right now, on my 249 objects i always found the "FF" end delimiter I assume FE is correct too but i never meet it so FF seems the correct end delimiter.

I think this has the added benefit of maybe simulating different light absorption materials. I guess wings should be very shiny and reflective more than the blue parts, as well as those parts in which parts of a model "emit" light.

True, still when you look at the original game, there are parts which are not lighted parts and look weird as their base color seems to be "prelighted"  for the level :



Here you can see that the top of the arwing is correctly lighted as light come from West.

But if you look at this image :



You can see the top color of arwing is fixed and now look weird as only half of the bottom is "lighted" when we expect both.

Thank you for the extra info, I will try to add stuff as I go, I might go slower now that I'm following you since you are the one making the real hacking progress

Actually your information about the real address of vertex data helped a lot, i couldn't figure the address encoding without it
And there is still so much to do, about level data for instance, we can probably try to understand them better

In case you are curious I've also seen it used in Doom but the engine has been opensource for years and is already ported to openGL.
http://doom.wikia.com/wiki/Doom_rendering_engine#Node_building

Yeah i know used BSPTree but it was only for fast map rendering, the way Starfox used it for 3D object decomposition (convex object) and rendering is really clever

In my particular case in which I use openGL I don't need to use the BSP tree since openGL can be set to determine the position of each triangle using glEnable(GL_DEPTH_TEST), but I would still like to replicate the palette behaviour with checkerboard pattern. It can be replicated very quickly using masks and FBOs, but I won't do this soon.

In your case you indeed really don't need the BSPtree info as OpenGL give simpler (and better) ways to handle depth rendering
The checkerboard will be a bit more tricky to handle !
In my case i want to replicate starfox with a software render engine (4 bpp bitmap based) so i can use the whole original starfox engine easily

¿Do you plan on continuing with the hack? Anything I can do to help?

Yeah i plan to continue to work on it, I will keep the thread updated with my progress
After object i plan to work on level data, we won't be able to use them "as it is", at least for the ASM block that won't be useful in our case :p
Ii would be nice if we can have a complete description of 1 level data as corneria 1. That would be a good start to figure of the rest !

[dyson132]

You can see the top color of arwing is fixed and now look weird as only half of the bottom is "lighted" when we expect both.

I did see this, I specially noticed it while rotating the Arwing because I have complete freedom on every axis so I would get odd shading on some angles. I think this is just how it was optimized and programmed.

In my case i want to replicate starfox with a software render engine (4 bpp bitmap based) so i can use the whole original starfox engine easily

GREAT! I'd want to see that!
I'm now importing the ROM directly into my c++ app to replicate part of your Obj Reader. I'll post something later in case I make progress.
I've also been playing around with WebGL and using that would be very interesting.

Yeah i plan to continue to work on it, I will keep the thread updated with my progress
After object i plan to work on level data, we won't be able to use them "as it is", at least for the ASM block that won't be useful in our case :p
Ii would be nice if we can have a complete description of 1 level data as corneria 1. That would be a good start to figure of the rest !

I'll finish this app and see what more info I can dig up or guess. The Star Fox object decoder made in Shockwave flash has the complete Corneria 1 stage decoded but I don't know if it can be disassembled or decompiled.
I will also be reading the thread and adding anything I can.
Thanks Again!

[Stef]

GREAT! I'd want to see that!
I'm now importing the ROM directly into my c++ app to replicate part of your Obj Reader. I'll post something later in case I make progress.
I've also been playing around with WebGL and using that would be very interesting.

I hope to be able to show something but i think it won't happen that soon unfortunately :-/
By the way,do you want the sources of the object decoder ? There is not much in it but as you use C++ you can translate java code quickly if you want...

I'll finish this app and see what more info I can dig up or guess. The Star Fox object decoder made in Shockwave flash has the complete Corneria 1 stage decoded but I don't know if it can be disassembled or decompiled.
I will also be reading the thread and adding anything I can.
Thanks Again!

Hehe, i think i will need to read the level data part a lot of time to understand it
Can i ask you something about the 3D ? you seems more used than me to that
Do you know how we have to handle camera view and arwing transformation ?

I try to do it this way :
World view is located depending arwing XY position.
I also apply do Z rotation depending the arwing X movement to make world rotating a bit as the original.
Then i try to get the arwing in the world at correct position but because of Z rotation the arwing goes up and down as background. I know i should apply an inverse translation before doing rotation on the arwing but i can't get that part correct and it's a bit confuse in my minds ^^

[dyson132]

By the way,do you want the sources of the object decoder ? There is not much in it but as you use C++ you can translate java code quickly if you want...

YES PLEASE! I've just about structured the file information in c++ but I have an offset for the faces data. You had posted a formula for the faces before but I don't arrive where I should.
I was using VL-Tone's tutorial and your formula but intead of arriving at $8F3ED where I know the face values begin, I arrive at 8F396 with the posted formula.
I'd like very much to read the source code, I guess a PM with the link or email should work.
I've already made a different c++ application that read the whole rom and uses what we know, with the correct face formula I could have all the models in openGL in a short while, without colors of course.

Do you know how we have to handle camera view and arwing transformation ?

I try to do it this way :
World view is located depending arwing XY position.
I also apply do Z rotation depending the arwing X movement to make world rotating a bit as the original.
Then i try to get the arwing in the world at correct position but because of Z rotation the arwing goes up and down as background. I know i should apply an inverse translation before doing rotation on the arwing but i can't get that part correct and it's a bit confuse in my minds ^^

I'm not quite sure I understand what is wrong and I don't know how much you know so I'll comment on what I've done in openGL.
I've used a very normal viewport.
I pushMatrix and translate to the center of the screen.
I  add a rotate value that will rotate that ship
I draw lines or triangles on screen using the ROM coordenates with a scaled value of 10.
Then I popMatrix.

Also in order to calculate the correct light index for the triangles I HAVE to use the rotation values. I rotated the normals in my first demo and it looks right but I think I'm wrong.

I can also send you my source after I'm done with the intial model. The gl portions are not hard to read.

[Stef]

YES PLEASE! I've just about structured the file information in c++ but I have an offset for the faces data. You had posted a formula for the faces before but I don't arrive where I should.
I was using VL-Tone's tutorial and your formula but intead of arriving at $8F3ED where I know the face values begin, I arrive at 8F396 with the posted formula.
I'd like very much to read the source code, I guess a PM with the link or email should work.
I've already made a different c++ application that read the whole rom and uses what we know, with the correct face formula I could have all the models in openGL in a short while, without colors of course.

Here it is :
https://dl.dropbox.com/u/93332624/dev/sfx/StarFoxDecoder.zip

I don't mind posting them public :p

I'm not quite sure I understand what is wrong and I don't know how much you know so I'll comment on what I've done in openGL.
I've used a very normal viewport.
I pushMatrix and translate to the center of the screen.
I  add a rotate value that will rotate that ship
I draw lines or triangles on screen using the ROM coordenates with a scaled value of 10.
Then I popMatrix.

Also in order to calculate the correct light index for the triangles I HAVE to use the rotation values. I rotated the normals in my first demo and it looks right but I think I'm wrong.

Thanks for taking the time to explain ! I finally fixed the problem and turned to be very simple
It was just a problem about the transformation order (i made translation then rotation instead of the contrary :p).
Problems coming from the world objects, having the arwing alone was ok

[dyson132]

@Stef
Thank you!
BRB


Progress!
I've implemented most of the simpler tags, this is the High Poly Arwing directly from the ROM, only thing odd is that I had to use the same color palette for everything until I finish this. (clicking the image seems to resize it, I don't know).



Definitely works!
I made it skip some tags that I don't know so I can see a few models perfectly like this one, the "fish" and a few powerups. So cool.


@Stef
I think I'll have to replicate the behaviour of your Object Decoder because I started the c++ code with no information about the correct tags. Your code is very clean and well structured.
I will however have less time now that I am really back at work. ¬¬

[Stef]

Wow nice, objects looks perfect ! I'm impatient to test that too
As you probably saw in my code, there are still unknown tags...
I sorted some as the 16 bits X flip vertex type list and bsptree empty node but still some unknown remains, i hope to fix them quickly ! Good luck with your project

[dyson132]

Wow nice, objects looks perfect ! I'm impatient to test that too

I made this using openFrameworks: http://www.openframeworks.cc/
Do you plan on trying it out? Try to get it to compile any demo project and I can post the project file (even if the source code is a bit messy). I have OSX too so I could port the project very quickly.
Installation instructions are not complicated.

I sorted some as the 16 bits X flip vertex type list and bsptree empty node but still some unknown remains, i hope to fix them quickly ! Good luck with your project

About that, 16 bits in this case means that I need 2 of the values that I would normally use?

Question 2: objects_extras.txt has some values that when I calculate the address I get negative values, does this happen to you?

[Stef]

I made this using openFrameworks: http://www.openframeworks.cc/
Do you plan on trying it out? Try to get it to compile any demo project and I can post the project file (even if the source code is a bit messy). I have OSX too so I could port the project very quickly.

It looks interesting and quite simple to use but i prefer to stand on java for multi plateform project as i'm used to that =)
Is OF available on all systems (osx, win, linux) ?

About that, 16 bits in this case means that I need 2 of the values that I would normally use?

Just that coordinate are encoded on 2 bytes, you have to take care of that when you parse your vertex data.

Question 2: objects_extras.txt has some values that when I calculate the address I get negative values, does this happen to you?

objects_extras.txt just contains object id and name, nothing more.
The object id is used to get the object header address (just by subtracting $7E00). Normally you cannot have any negative value. Take attention about the id value you may need to reverse byte order as i copied them directly from SFX exe

[dyson132]

It looks interesting and quite simple to use but i prefer to stand on java for multi plateform project as i'm used to that =)
Is OF available on all systems (osx, win, linux) ?

Yes it is. I work programming interactive installations and such and it is openGL so it is has gpu acceleration. Some guys like to add scientific libs to make some graphics. Also, using shaders in openGL is great! There is also Cinder which is osx and windows only.
http://libcinder.org/
There is also Processig is java but with a similar purpose, Processing.js is Webgl.

objects_extras.txt just contains object id and name, nothing more.
The object id is used to get the object header address (just by subtracting $7E00). Normally you cannot have any negative value. Take attention about the id value you may need to reverse byte order as i copied them directly from SFX exe

I get that but for example, in your objReader the first value in the list ACA1 has address 0, vertex and face 0 too. What happens there?
I think I'm going to have to reprogram my app. I ported part of your code that does the vertex parsing and that works really great but I have a problem with my face parsing (haven't tried porting yours), the Arwing works correctly but other models say, for example, 4 vertex when I know they have 3. sometimes I get 2. That is why I think in the captures I posted I get missing triangles.
This is going to take me a bit, I'll be back in a few days in case nothing happens.

[Stef]

Yes it is. I work programming interactive installations and such and it is openGL so it is has gpu acceleration. Some guys like to add scientific libs to make some graphics. Also, using shaders in openGL is great! There is also Cinder which is osx and windows only.
http://libcinder.org/
There is also Processig is java but with a similar purpose, Processing.js is Webgl.

I did know http://www.openprocessing.org/ which looks very similar to your lib, very nice to do graphical stuff very easily and quickly
But in case of the starfox remake i prefer hard implementation by hand X'D

I get that but for example, in your objReader the first value in the list ACA1 has address 0, vertex and face 0 too. What happens there?

Indeed, i just assume 0 as address means no data I also discovered there is only 249 objects and not 250, the last one was returned wrong address because of that. But all others objects are correctly parsed.
But i think i miss a lot of object, if you compare to SFXEdit, you will see it contains many more objects that i can parse, i don't know where to find the others objects...

I think I'm going to have to reprogram my app. I ported part of your code that does the vertex parsing and that works really great but I have a problem with my face parsing (haven't tried porting yours), the Arwing works correctly but other models say, for example, 4 vertex when I know they have 3. sometimes I get 2. That is why I think in the captures I posted I get missing triangles.
This is going to take me a bit, I'll be back in a few days in case nothing happens.

I think there is something wrong somewhere in your parser, a very minor bug can cause you to go to hell, that is the problem when parsing data :p

[dyson132]

Indeed, i just assume 0 as address means no data I also discovered there is only 249 objects and not 250, the last one was returned wrong address because of that. But all others objects are correctly parsed.
But i think i miss a lot of object, if you compare to SFXEdit, you will see it contains many more objects that i can parse, i don't know where to find the others objects...

I think there are some other banks, but that is why I ripped SFXedit 0.93.exe's complete Header address list. I think it is your same list.

Also, you mention that there are 250 objects but your objects_extras.txt  has over 550 address, even if some of them point to negative addresses.
When you open the rom using your Obj Reader you get only 249 entries.
I believe that you've only read one list of addresses for headers from the rom prior to reading the list but there is another set of addresses.

I rewrote my program and even though some entries are non existant it does read all 550 and I've already drawn correctly all of their vertex points (only missing faces ). Maybe I can see all 550 headers correctly because my programming is sloppy, specially in hex and I didn't make my code check to see if a model exists in a list inside the ROM.

Another question: I am close to rewritting everything with most ideas from your own code but running the models on openGL with light and everything. For what system would you want me to compile first?

news!
IT WORKS!
Rewrote it from scratch with the ideas and tags from Stef's java source. Here is the result:
https://vimeo.com/59966574
Not ALL models work but the standard normal ones work perfectly without crashing the program. Also, the normal Arwing is the only one with colors for each face, this because I haven't implemented the colors directly from the rom yet
The last Obj. in the video is the Base at the beginning of Corneria !!! And of course, the real application runs at 60fps or more.

@Stef
You might be interested in these screen captures. I noticed that many faces replicate and some correspond either to an animated part or color. You will notice this "glitch" in many models in the video but it is there for a reason.
In the second part you will notices there are 4 vert. on a surface, they are the 4 corners of a texture. It is the same "building" that appears with a SF crest texture that you had uploaded before, surely there is another tag there.


Extra comments:
- The parrot, at arround 1:00 in the video, used to have wings as mirrored vertex  so I'm guessing that one should have a different reference too which I will look for. I can see that each wing had 7 vertices with 4 faces.
- I verified that the Jukebox has a texture in that place where it has that glitch but that texture also shifts to one side.
- Also I think noticed what we had commented on before, that some faces are "pre-shadowed".