News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Stef

Pages: 1 [2] 3
21
Great! Do you happen to have a list of valid objects? How have you determined that an object is or isn't valid?
Because it turns out, when I added the textures my program would crash (very probably bad coding by myself)

Actually invalid objects are the ones which are unamed and usually not interesting so they should not give any problems from this side.

Quote
I'll see if I can dig up something but I don't see anything but the info VL-Tone had posted on that old forum. The big problem I see here is that now it is more about the timing of the game (ztimer?). I think faking that value would be easy but it would be more accurate to actually emulate the SuperFX. Whats worse is colision detection, where is that? is it just bounding box?

I guess emulating ztimer is really easy, we just need a counter to decrement... bounding box is indeed another thing i would like to figure ! I guess it is bounding box but i would to find theirs definition :)

Quote
Anyways, the lack of documentation and proper programming/ROM hacking knowledge (from me) is making this very frustrating so I will not be working too much on this anymore. I will however be reading up and since I have to learn more c++  for work so I will eventually be remaking the code.

...but I won't leave the thread, I would like very much to see your progress and new codes! :D
I won't disappear, I am easily reachable since I've posted this Star Fox thing in a few places, they all point to a usable email account.

And how can I post my source code? someone could very well continue! I made it using openframeworks of_v0073_win_cb_release.

I also posted the info and request for help in this thread here: http://www.smwcentral.net/?p=viewthread&t=62544

I understand and honestly it is a bit the same for me... now i need to advance my own implementation :)
Having almost all the objects is already a good start.
Of course it would be nice to get bounding boxes and more informations on level data but i need to work on my stuff else it will never progress !

Quote
Here is something I captured from the latest version I made. This is the version that crashed on some models (not sure if it was only in the corrupt ones).
Also notice, I've managed to let the textures pixelate even on high resolutions, I wanted textures with aliasing. :P


Look really nice with the pixelated texture, more "authentic" :D

Quote
I tried getting the frames one last time and I hit dead end again. I'm not sure I understand the process and how the information is stored. How does one know which vertex is being "animated" (changed) and how does your frame offset work (practicaly).
I changed the examples to two very distinct animations. One is a pillar with variable height over one axis only (easy to draw too) and the other is the Hydra with flapping wings that oddly gives out more info after the "frames". VL-Tone had those frames in the SFXedit 0.93.exe but not in the StarfoxDecoder.dcr , I am thinking they are other kinds of transformations but I am just guessing. Anyways, the Hydra one exceeds the offset assumption. Also, the pillar one only moves 4 vertices of 8, I think it is the easiest example.

You just did some minors mistakes in your decoding.
Here's my updated notes about the objects decoding :
https://dl.dropbox.com/u/93332624/dev/sfx/objects.txt

And also your vertex definition fixed :

Code: [Select]
Vertex Information:
38 ($38) X flip vertex list
02 Two sides
07 00 F6 Side 1 Mirrored [7,0,-10] and [-7,0,-10] accounts for 2 vertex
F9 00 0A Side 2 Mirrored [-7,0, 10] and [7,0, 10] accounts for 2 vertex
1C ($1C) animated vertex list
20 Frame Count $20 means 32 frames (16 more than expected)
3F 00 Frame offset $3F = 63+1 = 64
48 00
51 00
5A 00
63 00
...

// Here begin the Other parts of the model.
38
02
07 F1 F6 [7,-15,-10] and [-7,-15,-10]
07 F1 0A [7,-15, 10] and [-7,-15,-10]
20 // 16 bits offset jump
A3 00 Frame offset $A3 = 163+1 = 164 // Here I got lost

38
02
07 E7 F6
07 E7 0A
20
98 00
38
02
...

2fb9 Plasma Hydra Boss body
Vertex Information:
04 ($04) Type 04 Non Mirrored
04
00 00 EC
00 D8 F6
00 14 1E
00 00 28
38 ($38) X flip vertex list
09 9 Mirrored Vertex
0A 28 E2 Mirrored
19 00 F1 Mirrored
E4 FB F6 Mirrored
FA F6 F6 Mirrored
E2 0A FB Mirrored
F6 14 00 Mirrored
1E 00 0A Mirrored
08 FB 0A Mirrored
F6 0A 0F Mirrored
1C ($1C) animated vertex list
0A Frame Count $0A means 10 frames (Exactly as expected)
13 00 Frame offset $13 = 19+1 = 20
21 00
2F 00
3D 00
4B 00
59 00
67 00
75 00
83 00
91 00
04                    // here is the correct start for first frame vertex
02 // 2 vertex
14 14 EC
EC 14 EC
38                    // mirror x
01                    // 1 vertex
1E 28 28
20                    // jump
8E 00               // next is at offset $8E
...

Hope that help you with the animated data =)

22
Wow, well done dyson ! You get out the texture part :) Look really nice !

So now i think we almost have complete object decoding :D
In my object decoder i still have some invalid objects (about 40 over 550) but i don't really care ;)
I think i will see texture part later as i am using 4bpp bitmap surface and doing software texture mapping with 4bpp surface is a bit tricky ^^

Well now we need to figure a bit more about level decoding ! There is some informations on this so i guess it will be easier.
Almost some parts will need to be "hardcoded" as behavior or stuff like that.

23
After many work i think i finally figured the animated vertex (my first implementation was partially wrong)... I had to change a bit my structure to adapt to it. If you look into the sources you will see that animated data are not as easy to handle than others type, i hope you will understand my code.
Also i fixed some others stuff and tried to parse as many objects i can from the rom, i have now about 550 objects.
There is still some bugs i can't figure... data look wrong in some case: some models should have 32 frames but only vertex data for 20 frames is present...

Here's the last version of my decoder application, sources are included in the jar file.
https://dl.dropbox.com/u/93332624/dev/sfx/sfxObjReader.jar

Quote
I agree of course but I think that is far more complicated for me. I'm basically following your progresss and adding a bit of guesswork.
I also have this idea. Here is an 720p video I made a few hours ago and I will post it in some forums, reddit and maybe others. I'm thinking somebody with more knowledge might want to help.
https://vimeo.com/60089406

The video is really cool, nice object viewer with cool music =)
I don't know if you will find other interested people for that project, honestly that is a really complex and long task to analyze and extract data from rom, specially when we are not used to rom hacking :p

Quote
I did the palettes changeable from the start using the headers. They are displayed by object if they correspond to the following four palettes, 8213, 82ed, 83c1, 85e2. VL-Tone mentioned that there were 9 and I'm guessing the ROM has references to them in plain sight.
I found those four by setting 8213 as a default, then found some models with colors that I didn't remember from the game and checked if their own palettes worked.

I think i will quickly add support to all palettes as it doesn't make a big difference :)
Daytime / nightime / space variation is independent from the palette object information so we can easily change them !

Quote
I am particularly intrigued by the Andross face model because it is VERY fluent compared to some other animations.
Also, If anybody knows the texture addresses and sprite addresses let me know. :P

Unfortunately i did not yet have tried to understand where are the texture address, i know you can get them from palette but i never investigated in that. Honestly texture is not my first preoccupation right now as they are not much used in game.

Quote
183D8 -> D881 (59 values Very short!)
18413 -> 1382 (218 values that make up the 109 that were mentioned before in the thread. This is the most common palette in Star Fox SNES)
184ED -> ed82 (212 values)
185C1 -> c183 (64 values)
18681 -> 8184 (265 values)
1878A -> 8485 (Could never get it to run, crashed my app)

Should not your last palette address be 8A85 instead of 8485 ??

Quote
Also, they are consecutive in the ROM meaning no jumping around. I bet they are all there.

Cool, that make them even simpler to decode =)

24
I guess you got your 552 objects from the SFXEdit app, i still not yet found where others objects are located.
I could use the SFXEdit addr too but i really want to find them from the rom too :)
Thanks for the statistics, that show that, indeed, 1382 is mainly used... i will probably wait to implement the other one :p

It's nice to see the object display in semi wireframe, their method is simple but efficient to display hybrid object :)

25
Wow you progress so quickly, well done !
Unfortunately i have only few time to work on the project right now :-/
I only implemented the "13 82" palette right now, do the others palette are often used ? Just to know if i should also add support for them. In this case i will have to parse palette address from the object header.

About the shadow, i think you are right, they probably use the "shadow" models for that but that mean it almost double all objects transform calculations and rendering !

I'm continue my work on the animated data, i almost figured it out :) I still have some parsing bugs to fix and questions on some point (BSPTree node which do not reference any triangle for instance).
I hope to get that this evening after my job day :)

26
Well i think it's better to have animated objects handled as well so we can have a real object viewer (as the SFXEdit actually) except that data is directly parsed from the rom and we understand how the process is done :)

27
Yeah the objects_extra comes from the SFXEdit application, it is the rip i did just to get object name.
I use it to feed object's name in my object decoder tool :)

Glad you fixed your decoder :) The video looks really nice... and exciting :D
Indeed i saw there are many objects with a face dedicated to animated color or texture (the face color information can indicate a specific texture). There is also many objects having a single face with a texture (used for asteroid level mostly).

Yesterday i made some progress on animated objects decoding, i hope to get them soon  !
I'll post an update of my tool as soon this is done so you can update your code to handle them =)

28
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

Quote
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...

Quote
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. :D

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

29
Quote
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) ?

Quote
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.

Quote
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 ;)

30
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 ;)

31
Quote
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

Quote
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 :)

32
Quote
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...

Quote
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. :D
Thanks Again! :D

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 ^^

33
Quote
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 :)

Quote
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.

Quote
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.

Quote
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 :)

Quote
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 :)

Quote
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. :D

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 :D

Quote
┬┐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 !

34
Quote
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.

Quote
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 ;)

Quote
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? :D

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.

Quote
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.

Quote
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 ;)

Quote
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. :P)

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 :)

Quote
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 :)


Quote
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 :-/

Quote
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. :D

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 !

35
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 !

Quote
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 :)

Quote
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 :)

Quote
-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.

Quote
-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 :)

36
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 :)

37
AWESOME! :D
Congrats!
I noticed there are two High Poly Arwings by the way, so I was kinda confused:But yes I think you are very right. :D

Thanks for your efforts in ripping from SFXEdit ! that definitely helped in figuring it :)
Yeah i saw about the multiple high poly arwing, i guess there is only scale factor difference between them !

Quote
Yes, I've seen this but I wanted to show you that the SFXEdit has a bit more info inside in case you need it.
Is it possible to extract this long strings of text from the exe file? I tried the simplest resource extractor I could find and it didn't work.

Usually resource extractor should do it, did you tried hexa editor do do it ?
I extracted that with a hexa editor (frhed) :

Code: [Select]
15AC
31AC
4DAC Andross Square
69AC Black Hole Sprite
85AC Andross Cube
A1AC
BDAC
D9AC
F5AC
11AD
2DAD Explosion
49AD
65AD
81AD
9DAD
B9AD
D5AD
F1AD
0DAE
29AE
45AE
61AE
7DAE
99AE
B5AE
D1AE
EDAE
09AF
25AF
41AF
5DAF
79AF
95AF
B1AF
CDAF Big Asteroid
E9AF
05B0
21B0
3DB0
59B0
75B0
91B0
ADB0
C9B0 Nova bomb
E5B0 Nova bomb 2
01B1 Explo 2
1DB1 Big Explo 3
39B1 Big Explo
55B1 Big Explo
71B1 Big Explo
8DB1 Big Explo
A9B1 Big Explo
C5B1 Big Explo
E1B1 nothing?
FDB1 nothing?
19B2 nothing?
35B2 <bh:d3>GAME<bh:d3>
51B2 <bh:d3>OVER<bh:d3>
6DB2 Alien pilot
89B2 Sparks
A5B2 Nothing?
C1B2 Flashing antenna
DDB2 Bigger Flashing antenna
F9B2 Bigger Flashing antenna
15B3 Flashing antenna
31B3 White morphing fire
4DB3 Flashing yellow morphing fire
69B3 Flashing blue morphing fire
85B3 Flashing flat blue morphing shot
A1B3 Weird flat asteroid sprite (unused?)
BDB3 Same but bigger
D9B3 Same but even bigger
F5B3 Walker with leg broken
11B4 Walker with leg missing
2DB4 Walker walking
49B4 Growing column
65B4 Bee!
81B4 Weird antenna
9DB4 Antenna top
DAB4 Hexagonal multi-missile head
DAB4 Hexagonal multi-missile head
F6B4
F6B4 Slamming outdoor wall
33B5 Slamming outdoor wall
4FB5 Slamming outdoor wall
6BB5 Flat four pronged enemy
87B5 Pyramid
A3B5 Flat far away ship
DBB5 ??
FCB5 ??
01B6 Caterpillar head
1DB6 Caterpillar part
43B6 Cloaking Ship
7BB6 ??
80B6  Caterpillar part
9CB6 Caterpillar head part
B8B6 Shadow
D4B6 blue red pill
F0B6 mini ship
28B7 mini ship 2
28B7 mini ship 2
44B7 turret
B4B7 Tank track
7CB7 Tank track Corner
98B7 Tank track Corner
B9B7 mine?
D5B7 shaded cone spike
F1B7 Launcher hovercraft
0DB8 Exploding mine part
29B8 Exploding mine part
45B8 ??
45B8 falling column orange
82B8 falling column blue
9EB8 column orange (A3 B8)
BFB8 Mid level ring
DBB8 Magic door! (unused in game)
F7B8 Plasma Hydra Boss arms
13B9 Plasma Hydra Boss arms bulging
2FB9 Plasma Hydra Boss body
4BB9 Plasma Hydra animated claws
7FBA neck/tail for Monarch Dodora Boss
83B9 Monarch Dodora Boss head
9FB9 Monarch Dodora body animation
BBB9 Monarch Dodora Boss tip of tail
D7B9 mini bird
F3B9 Egg
0FBA Egg broken top
2BBA Egg broken bottom
47BA bird boss flapping wing
63BA bird boss flapping wing
84BA Motorist
A0BA Large missile
BCBA dart
D8BA Big blue Bonus Archway
F4BA Bonus vertical doorway
10BB Horiz Arrow sliding door
2CBB Random poly
48BB scramble line part
64BB scramble arches
80BB scramble tunel
9CBB Big walker
B8BB Asteroid flat + enemy
D4BB Weird vent?
F0BB Dancing Insector head
0CBC Dancing Insector Boss leg
28BC Dancing Insector leg
44BC Dancing Insector top
60BC Parrot (Bonus OOTD bird)
7CBC flashing flat blue hexagon
98BC Shadow small high poly arwing
B4BC Small high poly arwing
D0BC Big high poly arwing
ECBC Lava erruption
08BD Slot Machine
24BD Slot Machine Arm
40BD Training Ring (Flashing blue)
5CBD Andross Cube + pyramids
78BD Tower top
94BD Yellow-red flashing shot
B0BD Rock formation (irregular gray shape)
CCBD Four pronged space thing
E8BD Diafragm Door
04BE Rock reverse faces
20BE Rock reverse faces and broken
3CBE Rock Crusher Boss part
58BE Rock Crusher Boss flashing dimple
74BE Rock Crusher Boss rotating part
90BE Spinning Core bumpers
ACBE Electric thing under Spinning Core Boss
C8BE Spinning Core Boss top
E4BE Spinning Core flaps up
00BF Spinning Core flaps down
1CBF Spinning Core flaps parts closed
38BF Spinning Core flaps parts closed
54BF Black lines
70BF lines
8CBF lines
A8BF lines
C4BF lines
E0BF lines
FCBF mess
18C0 Armada Battleship entry
34C0 Atomic Base entry
50C0 Atomic Base entry zoom
6CC0 Weird black/orange button
88C0 Weird portal
A4C0 Weird portal 2
C0C0 Weird portal wire frame
DCC0 Weird portal wire frame 2
F8C0 Flashing yellow stripe
14C1 Black rectangle
30C1 Gray rectangle
4CC1 Black large rectangle
68C1 Gray rectangle
84C1 Gray rectangle smaller
A0C1 Gray rectangle large
BCC1 Inside black tunnel
D8C1 Inside gray tunnel
F4C1 little tower top
10C2 box with flashing top
2CC2 Butterfly
48C2 Attack carrier right launcher
64C2 Attack carrier middle part
80C2 Attack carrier low poly middle
9CC2 Attack carrier left shield
B8C2 A-carrier top left closing
D4C2 A-carrier down left closing
F0C2 A-carrier mini-ships
0CC3 Yellow flying enemy
28C3 Blue flying enemy
44C3 Enemy wing
60C3 wireframe shielded Arwing
7CC3 wireframe Arwing no right wing
98C3 wireframe Arwing no left wing
B4C3 wireframe Arwing no wings
D0C3 Interlocking doors opening
ECC3 Antenna dish
08C4 Antenna base
24C4 Pylone
40C4 Pylone 2
5CC4 Twin flasher/repair enemy
78C4 Twin flasher item
94C4 Nova bomb item
B0C4 Shield item
CCC4 Wing Repair item
E8C4 unused (filled cube shield)
04C5 mine, blue/red
20C5 Repairing Arwing
3CC5 Hexagonal mini Hover tank
58C5 Enemy with some wireframe
74C5 Morphing boss part (round room)
90C5 Atomic Base core opening
ACC5 Atomic Base core opening 2
C8C5 Half monolyte (white)
E4C5 Atomic base targets
00C6 Atomic base electric arcs
1CC6 Atomic Base beaks
38C6 Exploded polys
54C6 Slot flashing button
70C6 Slot disabled button
8CC6 A-Carrier2 rotating heads
A8C6 A-Carrier2 main head
C4C6 A-Carrier2 tank base
E0C6 Armada ship core stand
FCC6 Armada ship core
18C7 Unknown boss or portal part
34C7 A-Carrier2 tank middle
50C7 A-Carrier2 tank right
6CC7 A-Carrier2 tank left
88C7 Phantron transformation/jumping animation
A4C7 Phantron closed
C0C7 Mountain with antennas
DCC7 Manned pod ship
F8C7 Winged fat ship
14C8 Phantron leg
30C8 Phantron leg
4CC8 Wingling tail enemy
68C8 Small Bonus Archway
84C8 Long cannon tank
A0C8 Mothership part
BCC8 Octogonal tunnel blue
D8C8 Rectangle tunnel orange
F4C8 Letter D orange
10C9 Letter D blue
2CC9 Scenery White box
48C9 Scenery small White box
64C9 Scenery White high rise box
80C9 Scenery White high rise box
9CC9 Galactic rider door
B8C9 Base shooting red/blue rings
D4C9 Metal Crusher right
F0C9 Metal Crusher left
0CCA Metal Crusher again
28CA Space Truck
44CA Boss three prong opening top
60CA Boss three prong opening top
7CCA Hexa orange with black top
98CA Atomic base part
B4CA Web
D0CA Yellow flat octogon
ECCA White prism
08CB Vertical Orange white column
24CB Big mountain with entry
40CB Fake flat mountain entry
5CCB Long orange tunnel
78CB Orange/gray tunnel
94CB Professor Hanger
B0CB Vertical opening interlock doors
CCCB Mountain part orange
E8CB Mountain part blue
04CC Mountain part white
20CC Mountain part 2 orange
3CCC Mountain part 2 blue
58CC Mountain part 2 white
74CC Mountain part 3 orange
90CC
ACCC
C8CC Mountain part 4 orange
E4CC
00CD
1CCD Mountain part 5 orange
38CD
54CD
70CD Mountain part 6 orange
8CCD
A8CD
C4CD Helicopter
E0CD Metal Crusher mines
FCCD Mountain part 7 orange
18CE Little mountain blue
34CE Little mountain white
50CE Flying Fish
6CCE Growing green leaf
88CE Blossoming flower
A4CE Water Dragon/Flower part
C0CE Water Dragon head
DCCE Flower/Dragon part?
F8CE Flower part
14CF Flower part
30CF Two sides Blue square
4CCF Small Flower
68CF Big Flower
84CF Flower part?
A0CF Flower part
BCCF Spider Boss head
D8CF Spider Boss leg
F4CF Spider Boss leg 2
10D0 Big vertical Entryway
2CD0 Long Octo Tunnel
48D0 Diafragm Door Blue
64D0 Interlocking Doors
80D0 ?? part
9CD0 Vertical Creature
B8D0 Flashing White thing
D4D0 Flashing White Monolyte
F0D0 Pale Monolyte
0CD1 Andross Face Squares
28D1 Andross Face Squares big
44D1 Andross Face morph
60D1 Andross Face morph 2
7CD1 Prof Hanger part
98D1 Vertical Tunnel Door
B4D1 Tunnel part
D0D1 Tunnel part orange
ECD1 Tunnel part orange
08D2 Tunnel part orange
24D2 Tunnel part
40D2 Tunnel part orange
5CD2 Tunnel twisting part
78D2 Orange Electronic Cube
94D2 Orange Electronic Column
B0D2 Orange Electronic Column
CCD2 nothing?
E8D2 Shadow arwing
04D3 Normal arwing
20D3 Normal arwing
3CD3 Normal arwing
58D3 Shadow arwing no right wing
74D3 Arwing no right wing
90D3 Shadow arwing no left wing
ACD3 Arwing no left wing
C8D3 Shadow arwing no wings
E4D3 Arwing no wings
00D4 Simple White building
1CD4 Buildings (4) one blue high
38D4 Buildings (3) one orange high
54D4 Buildings (4) all high rise
70D4 Building with Fox logo
8CD4 Great Commander Boss
A8D4 Great Commander Head
C4D4 Great Commander Head
E0D4 Great Commander trunk with rotating arms
FCD4 Great Commander base with opening vent
18D5 Great Commander whole, not animated
34D5 Great Commander part
50D5 Great Commander left arm
6CD5 Great Commander right arm
88D5 Opening Great Commander vent
A4D5 Opening Great Commander vent
C0D5 Explosion crater
DCD5 Explosion crater
F8D5 Unused?
14D6 Unused?
30D6 Some horizontal beam
4CD6 Some horizontal beam
68D6 Beveled White box
84D6 Beveled White square
A0D6 Beveled White beam
BCD6 Beveled White beam
D8D6 Beveled White square
F4D6 Beveled White beam
10D7 Rising Gray beam
2CD7 Rising arch
48D7 Arwing Cockpit
64D7 Big low poly arwing
80D7 Big arwing (no wings)
9CD7 Big arwing (no R wings)
B8D7 Big arwing (no L wings)
D4D7 PHANTRON Kicking
F0D7 PHANTRON part
0CD8 Dropped by some boss
28D8 Rotating Artsy thing
44D8 Rotating Artsy thing
60D8 Box thing
7CD8 Square thing
98D8 Box thing
B4D8 Box thing
D0D8 Box thing high
ECD8 Blue beam white ends
08D9 Hexagonal blue beam
24D9 Enemy ship
40D9 Enemy ship half
5CD9 Enemy Cargo ship
78D9 Enemy Cargo ship
94D9 Enemy Cargo ship<bh:09>
B0D9 Enemy Cargo ship<bh:09>Low poly
CCD9 Enemy Cargo ship<bh:09>Low poly
E8D9 Enemy Cargo ship<bh:09>Low poly
04DA Far away ships (flat)
20DA Interlocking doors
3CDA Interlocking corner doors
58DA Interlocking diagonal doors
74DA Interlocking diagonal doors (s)
90DA Enemy flapping wings and tail
ACDA Boss poly part?
C8DA Boss poly part triangle
E4DA Boss poly part triangle
00DB Boss poly part triangle
1CDB Rising orange beam in tunnel
38DB Enemy ship
54DB Growing missile
70DB Main enemy ship (orange)
8CDB Mini walker
A8DB Ringo enemy
C4DB Enemy with rotating wings
E0DB Growing beam with flashing top
FCDB Sliding door in tunnel
18DC Coins
34DC Flashing Slot Maching knob
50DC Slot Machine Fruit texture
6CDC Hexa tower with flashing top
88DC Origami 1
A4DC Paper plane
C0DC Warning beam (yellow/black)
DCDC Tunnel side Textured Blocks
F8DC Road side Textured Blocks
14DD nothing?
30DD Shootable cone
4CDD High rise with flashing corner
68DD Big low poly Arwing (2)
84DD Corneria Base
A0DD Flat long rectangle
BCDD Random polys
F4DD Part some ship (DD08)
F4DD Part some ship (DD08)
10DE Micro Walker
2CDE Nano Walker
48DE Machine Gun ship
64DE Machine Gun ship Part (gun)
80DE Machine Gun ship Part body
9CDE Space missile mines
B8DE Shieldable enemy
D4DE Shielded enemy
F0DE Shielded enemy 2
0CDF Shielded enemy cloaking
28DF Big launcher tank
44DF Libellule
60DF Other smaller Libellule
7CDF Flashing wireframe beam
98DF Flashing beam
B4DF Flashing beam
D0DF Flashing beam
ECDF Flashing beam
08E0 Flashing beam
24E0 Flashing beam
40E0 Flashing beam
5CE0 Flashing beam
78E0 Flashing beam
94E0 Flashing beam
B0E0 Flashing beam
CCE0 Flashing beam
E8E0 Flashing beam
04E1 Flashing beam (wireframe)
20E1 Flashing beam
3CE1 Flashing beam (wireframe)
58E1 Flashing beam
74E1 Flashing beam (wireframe)
90E1 Flashing beam
ACE1 Ship Entryway (with antennas)
C8E1 Ship Entryway part?
E4E1 Space half arch
00E2 Space half arch big
1CE2 Space other half arch big
38E2 Rotating pod enemy orange
54E2 Rotating pod enemy white
70E2 Rotating pod enemy white
8CE2 Rotating pod enemy blue
A8E2 Rotating pod enemy blue
C4E2 Medium Walker
E0E2 Mini Volcano
FCE2 Big Volcano
18E3 Portable hole
34E3 Cool missile
50E3 Mini Vertical Enemy
6CE3 Main enemy 2 (orange)
88E3 Main enemy 3 big wings
A4E3 Small yellow stingray
C0E3 Small blue stingray
DCE3 Big blue stingray
F8E3 Big red stingray
14E4 Crystal in ground
30E4 Crystal in ground (vertical)
4CE4 Flying crystal
68E4 Hovercar (road level)
84E4 Skii Truck  (road level)
A0E4 ??
BCE4 Some Enemy part
D8E4 Energy yellow ring
F4E4 Mini Fish
10E5 Other Machine gun enemy
2CE5 Swimming creature
48E5 White flat stripe
64E5 Flat thing
80E5 White arrow
9CE5 Tunnel with blue doors
B8E5 Orange tunnel
D4E5 Tunnel with blue doors 2
F0E5 Federation friend ship
0CE6 Federation friend ship (half)
28E6 Mothership part 2
44E6 Mothership center part
60E6 Bonus bird
7CE6 Whale
98E6 Rotating solid beam with direction arrows
B4E6 Andross 2 Evil Face
D0E6 UFO
ECE6 Small yellow tank
08E7 Small blue tank
24E7 Weird asteroid
40E7 Tunnel with yellow door
5CE7 Tunnel with yellow door
78E7 Morphing ground thing
94E7 Bonus doors (yellow)
B0E7 Letter <bh:d3>E<bh:d3> orange
CCE7 Letter <bh:d3>E<bh:d3> blue
E8E7 Letter <bh:d3>E<bh:d3> gray
04E8 Letter <bh:d3>T<bh:d3> orange
20E8 Letter <bh:d3>T<bh:d3> blue
3CE8 Letter <bh:d3>T<bh:d3> gray
58E8 Letter <bh:d3>N<bh:d3> orange
74E8 Letter <bh:d3>H<bh:d3> blue
90E8 Letter <bh:d3>H<bh:d3> gray

The SFXEdit program seems to contains a lot of data ! probably have a whole copy of the rom X'D
The offset by 2 is weird, maybe the 2 extras bytes has specific meaning for the vertex list ? for animated objects or something like that.
Need to test that on more objects :)

38
Nice ! You are right, the SFXEdit exe file contains a lot of hardwired informations., your last post helped me in figuring the address decoding, at least i believe i have it correct now :)

We already had correct for object header address :

Object header address = object id - $7E00    (would be $8000 with a headered rom).

For instance low arwing object id is 20D3 (we have all object id from rom starting at location $284B) :
Object header address = $D320 - $7E00 = $5520

If we look at location $5520 in the rom we indeed find the low poly arwing header :
$5520: 73 F1 11 96 F1 00 00 00 AC 00 0E ....

Now from the header we can get the vertex and poly data location.

The first 2 byte represent the address of vertex data :
73 F1 --> $F173

Third byte refer the bank number (i was wrong here) :
$11

4th and 5th byte represent the address of face data :
96 F1 --> $F196

To compute the final address in the rom you have to use this formula :
((bank number - 1) * $8000) + $200 + address.

So that give us the following address for vertex and face :
vertex address = ($10 * $8000) + $200 +  $F173 = $8F373
face address = (($10 * $8000) + $200 + $F196 = $8F396

Let's use the high poly arwing object id now : $B4BC

Object header address = $BCB4 - $7E00 = $3EB4
header $3EB4: 01 E0 0C 42 E0 ....

Vertex data ($B* $8000) + $200 + $E001 = $66201
Face data ($B* $8000) + $200 + $E042 = $66242

Now it seems accurate, i think we can rip all objects from rom now :)

February 12, 2013, 04:55:30 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
About palette there is an interesting post here about how interpret them :

http://acmlm.kafuka.org/archive2/thread.php?id=6876

I figured almost everything about palette from this post, it was a bit but now it works =)

39
xD
AWESOME! I've wanted that info for years now! This is great!
I'll reread your message many times now and be back later when I try everything.

By the way, as I mentioned in my previous comment if you open SFXedit 0.93.exe with a Hex editor o in a text editor you will find the list of 3D models and the Stage locations within in plain text! Also, every one of those 28 bit groups that make up a model. Also the conversion for the color palette is there too, there are a few text files in there that should be ripped but I'm guessing there is a better way than doing it by hand.
This is the part that I just mentioned and the list is for every model in SF SNES
So you cracked it! Congratulations! I am forever in your debt.

Thanks :D
I saw what you posted about these list but don't you have access to them through the application ?
When you go to the object viewer you can see the complete object list at the right with a small description.
And if you select an object you can get the 28 byte header at bottom (but not very readable...).
Also you have the level selection with its name and address visible on level editor screen, just in the left column.
I guess plain texts from the exe are here for that.
About the palette color, i already almost figured how they were encoded and as i want to reuses the exact same rendering as the original (with mesh effect) i need to directly interpret it from the ROM data :)

Quote
Just to play around, as exists in SFXedit 0.93.exeAlso just noticed that SFXEdit has a VrtxPtr and FacePtr which account for your use of two and a half hex values for location vertex and face values. I would have never noticed that.

Yeah i saw that, but never understood how to read the value... As numbers and text overlap it was pretty uncommon too.
In the link you were referring :
http://acmlm.kafuka.org/archive2/thread.php?id=4730&pl=96583

VL-Tone already mentioned that first 5 bytes were probably describing vertex & poly data... i just tried to figure how we could read $8F373 from it X'D

Quote
Verified in the Rom with your correct calculations.
Okay,  I think there is some other offset or something because I cannot find this correct info. I'm doing these calculations manually for the D0BC Big high poly arwing and I'm getting the following:
01 E0 0   -->    0 E0 01    -->    70200+0E001 = 7E201       (Points to something that would have 0 vertex data. Also, there should be a 0C before and after this block or some other separator)
42 E0 C   -->    C E0 42   -->     70200+CE042 = 13E242     (Point anything after EOF)

I'll try and find the correct address from SFXEdit, maybe that could help. :D
Also, do you recommend any good hex calculators for this?

Oh you're right, i should have tested on the high poly arwing...
Well i probably missed something ^^ What is strange is that $70200 really looks as the start of the object data.
I will continue my investigations tonight after my job :)


February 12, 2013, 09:23:05 am - (Auto Merged - Double Posts are not allowed before 7 days.)
Quote from: dyson132
Look at the method that VL-Tone had posted for finding a reference (not 3D model) which never worked for me:It's dependant on the D320 as an offset and he also mentions that he doesn't know why a 28 byte header has values that point to itself (Arwing does):so I'm guessing your function works specifically for 20D3 but not for others, I'll try and figure it out today.

The formula given by VL-Tone just seems wrong to me :

$2E15+$D320-$8000 = $8135

I tested and $8135 definitely do not point to the 28 bytes header.

If you take the object 16 number, you'll notice the smallest object value is 15AC --> $AC15
We also know the start of 28 byte object header is located at $2E15. You immediately see the common part in both address so naturally you can think about doing $AC15 - $2E15 to get the offset : $7E00.

It's easy to see that it work as each object address are spaced by 28 bytes :)

Quote
There is also one thing that I found interesting, you said the 3D models begin at 70200, I can see they do but then I expected to find an object pointer like this one "00 00 0x xx xx" so the address would be "0 00 00" plus your offset but there is no object reference like that one on VL-Tone big list, so there has to be another offset that was already included in your method or I'm completely wrong!

By VL-Tone big list, are you talking about the list inside the SFXEdit exe ?
What is weird is that all data are actually contained in the ROM, if VL-Tone figured all address calculations he don't have to store them in SFXEdit program as it can compute them from the ROM. The only reason for that is he wanted to add specific description to some object / data which are absent from the ROM.
Well, i will look more closely in the rom later tonight and kee you informed of my progresses :)

40
Wow glad to see you are back to your project :)
Actually i'm stuck at the exact same point as you, i try to figure where find the object data from the object id in the rom.
Specially this 20D3 arwing object as we do know what data we can expect at the object address.
I even missed the important thread where VL-tones gave the address formula calculation but seems that is not enough to figure it..
I tried to look at the 28 bytes object header but it is quite hard to read it as some text overwrite the values. Anyway even by getting it right i can barely understand the palette address and object number, others values as vertex and faces pointer doesn't make any sense for me...

February 11, 2013, 06:31:56 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
Ok i figured how to get the 28 bytes header address from the object id :

object id : $20D3 --> $D320 - $7E00 = $5520
and we find at this address :
73 F1 11 96 F1 00 00 00 AC 5D 24 00 0E 00 50 00 50 00 13 82 20 D3 20 D3 20 D3 20 D3

which correspond to the arwing object header.

I found it only by taking the first object id (15AC --> $AC15) and subtracting address of start for header data ($2E15) which make more sense :)

Well now i have to figure address of vertex data :o

February 11, 2013, 07:05:58 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
Figured the object address !

Let take the 5 first bytes in the arwing object header:

73 F1 11 96 F1

We should see these 5 bytes as 2 five digits address :
73 F1 1  and  96 F1 1
Note how the second '1' position should be inverted. I think  they did that to avoid wasting one byte in the header.

The first address is used to find the vertex data :
73 F1 1 --> 1 F1 73
$70200 + $1F173 = $8F373
I have verified that $70200 correspond to the beginning of all object data.

The second address is used to find the face (and BSP tree) data :
96 F1 1 --> 1 F1 96
$70200 + $1F196 = $8F396

That's it ! Now we can rip all SFX models =)

Pages: 1 [2] 3