News: 11 March 2016 - Forum Rules

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

Pages: [1] 2 3
1
Glad to see you around ;) Well i will try to work a bit on the level decoder so i can do fast level data rip for tests, i think that may help me to figure the remaining unknown data. Having Starfox in the Oculus Rift could be really cool but could hurt our eyes X'D

Awesome news! Glad to see you are around here too. xD

One of the first things I tried with the Oculus was the Virtual Boy emulator and played Red Alarm. It was very cool, SNES StarFox might not be a bar idea with this. :D
This is not my video but just in case you are curious: https://www.youtube.com/watch?v=C2_zxss_mAU
:D
I've started learning unity so even if it takes time it might work.

2
I'm still around.  ;D
Oculus Rift got me into the "star fox decoding" mode again but I've made little to no progress for myself.

It is good to know you are still interested! I'll try and find an excuse to decode the rom while at work. xD
It would be awesome to get the starfox rom running in the Oculus Rift, I'll definitely try that.

3
That is horrible!  :banghead:
I hope you get your stuff back soon! :)

I've been away too, progress is down to 0 on the Star Fox decode because I had to learn GLSL and stuff. I don't know when I'll resume it but I haven't left the thread either.

Good luck! :)

4
Hey,

Glad to hear that :)
Unfortunately i did not made any progress as i did not have any free time lately and that is, until April...
So you can consider i am exactly at the same point as i was in the last post :p

Dammit! And I got my head stuck GLSL for work, I should be back to the rom soon.
:)

5
Ok Stef!
My presentations are over, now I can try and do the stuff I said before.

Have you had any progress? just so I don't try to replicate what you have done. :D

6
Thanks :) Honestly not really for the moment, i need to look more closely in these. I think you can try display a sort of bounding box around object using object size and also try to display straight Z line corresponding to object Z center minus the Z distance in header so you can see if this value is reliable as a clipping or collision detection.
Cool. I'll have to do this in a few days though, I have to finish this damn Red Book!

:D
Look VL-Tone answered my questions, I have yet to read them:
http://jul.rustedlogic.net/thread.php?id=15998


I've read it now so I think I'll go into regular rom hacking because I really seem to be missing some tools. :P


I knew I had seen this somewhere. In case anyone wishes to replicate the checkerboard pattern they can start here. Page 63 of the RedBook, glPolygonStipple() . It is supposed to be used as a mask.

Code: [Select]
   glPolygonStipple (halftone);
   glBegin(GL_POLYGON);
    glVertex3f(200,  0,  0);
    glVertex3f(250,  0,  0);
    glVertex3f(250,100,  0);
    glVertex3f( 50,100,  0);
   glEnd();
   glDisable (GL_POLYGON_STIPPLE);


7
Of course you're welcome to test that :D Honestly you are a lot faster than me for that as you already shown ;)

I'll do it. Do you have any more guesses about the Z position /distance and Z clipping / collision test?

8
Well anyway it would have be a shame to stop here now we have dig that far ;)

I first want to be able to use the max data i can from the original rom, the more we can extract, the less we have to reproduce :p

Sure lets continue. I don't have much to offer since I am not as experienced as you are but I can verify stuff very quickly.
Also, since VL-Tone mentioned that he needed an 65c816 dissembler/assembler for level info, my guess is you can completely port the game. :D
I was just playing a Doom 64 port for PC:
http://www.doomworld.com/vb/source-ports/54058-doom64-ex-2-0a-feedback-build-updated-1-25-11/
The guy started out replicating the game from what he saw but ended up making an application that read from the rom data. It works very well. I want to do this with Star Fox. :D


I got new inspirations about some infos present in header :D
I think the Z position /distance stuff are related to the Z clipping / collision test, this is something i need to test !

Great! I need more distractions from work! at least I won't get fired for coding so, do you need help?
I should be able to corrupt the game so much that it shows wireframe 3D cubes where the collision boundaries should be. I know you can do it too but I have the code ready and everything.
:D

9
Thanks :D I hope to finish it too but that is really *a lot* of work so that might become a simple "demo" but who know :)

I guess the problem with stopping now is that you've gotten people's attention.
http://www.nintendoage.com/forum/messageview.cfm?catid=22&threadid=97838&StartRow=1

Oh no, now you have to finish. Blast processing my a**! :P
https://www.youtube.com/watch?v=PNGWykZ0ju0
https://www.youtube.com/watch?v=Bm-ICwWxaAY
Now it is personal.  :banghead:
And you'll have to add SVP chip.  ;D

I propose that in order to prove the Genesis is more powerful than the SNES... lets port Star Fox!
If you are a real fan you should prove it in the best way possible, help us decode the Star Fox SNES rom. :D
There must be really good reverse engineers that are also fanboys. xD

10
A lot of great info in your post. I hope you finish the port. :D

I had already posted the link to this thread and I think he read it since he commented on SuperFX being emulated in SFXEdit. I'll post the header info in case he can give some insight.
I posted the link to your post about your port too, the idea is too good not to mention.

11
I started to work on it a long time ago but i can now display direct object from starfox which is awesome =)
Ah yeah, you need a sega megadrive emulator to test it ;)

Where did this come from? xD
How did you do this a long time ago if you just now have the models?!?! :D
It looks great! How did you make this work?

Everything else sounds great. I think I will wait a bit more to rewrite my code, specially since I am kind of stuck with the stage information. :D
You've had awesome progress! :D

To help you out I'll begin hacking at the rom and using your table as reference for distorting objects.  >:D

:D the only one I did get to work as you mentioned out was the scale one. The collision ones are interesting but I couldn't figure out their inner workings although I know they are collisions since I managed to destroy the ship many times before actually starting the game. I also tried using the two bytes as 4 face index values but I'm still not sure.
The "$05: Z position ?? (2 bytes, low byte first)" seems to be right too because it shifter the position at with the Arwing becomes available.

I also answered a question I had for some time which was why is there a face missing from the the Corneria Base obj. It actually isn't missing, it is loaded as a separate object in order to be correctly drawn on screen using the BSP. See, this rectangle appears in front of the ship which should appear in front of the Corneria Base. This rectangle also appears as a separate object in the SFXEdit.

Do you want me to post the complete header info to VL-Tone or should you?.

12
I downloaded the zip file he sent but looks like that is all we already have on different topic / forum / archive we explored.
I looked over them too, I've left him a question about decompiling this SFXEdit and the Shockwave Object Decoder. Anyway, I am just hoping for solid bits of information like the following which I post here so it is searchable on the internets:
Quote
Note that some of the things that you find in SFXedit might not be used by the program itself and are just some text I pasted in my project for reference.
Also, SFXedit doesn't use/emulate any Super-FX code. It does feature a very simple 65c816 dissembler/assembler because level data sometimes depends on ASM code to branch, but it doesn't actually emulate the code.

I am still looking to find a bit more infos about object and after having spent some time on that i can only make some assumptions...
I figured the scale data but all others infos as object looks weird...
I will describe them later when i will be back at home but i guess VL-Tone can help with that (if he can remember) :)
Great! Awesome and lets just hope! :D
Making a level editor would be awesome but I now see that without deconstructing the logic of the header information in the game it would be impossible to modify a stage size or amount of objects it can hold.
By the way, is it hard or even meaningful to map out a ROM? As in, "$60F58 here is the something that does this". Are there any tools for such a thing? I ask because I wish to make a cleaner document about what we already have. :D

13
Thanks for the information!
I believe you are right on all the comments you posted. For example, the crippled D4D7 Phantron Kicking possibly has static->animated->static vertex information and maybe that is why I am getting crippled animation. I will try this later. :D

Thank you!


Verified the Depth Palette thing. I hadn't noticed it.


I tried decoding some stage information but I got confused between addresses and references. What I guessed is that it is relatively straightforward, having the correct information it could be understood quickly.


@Stef
By now I'm just following your work and in order to be somehow useful I'll start correctly documenting what we already know including methods, conversion with examples and such.

March 05, 2013, 09:41:49 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
HEY!!!!!!!!!!!!!!!!!!!!!!!!
READ PM
http://jul.rustedlogic.net/thread.php?id=15998

14
Thanks you for the answers and info. :D

If there is any comment about it I would have to say this:
You can have fixed part before and after animated part, you can also have only animated part.
I read the vertex data expecting the fixed vertices info to always appear before the animated ones. This is not necessarily true but it was how I started the animation part. Turns out in my case it works and looks correct because the triangle construction in the face section points to certain vertices with values, if the vertices are in different order it wouldn't have animated correctly. So at least in my case the vertex info appears before.
Oddly enough, I was curious what would happen if I flip them, almost all objects are affected except the bipeds ( 9CBB, C4E2  and 11B4 and variations.)

There are some models which seem oddly corrupt, I'll read every line of them to find out more about the error (D4D7 Phantron Kicking, weird fixed vertex distorts the object).

I'll post the code later somewhere you've suggested, and now I can take a bit more time to add features. :D
I'll se if I can recheck stage 1 info.


Cool ! Glad you got it, you implement things really quickly :)

It's a combination between years of waiting for someone able to get more info and having to learn c++ and openGL for work. :P
I also don't want to stop because I don't think I will get many chances to advance in the future.

About the Corneria 1, I think we would be starting this all wrong. In the game, the ship moves using the controller which passes through the SNES chipset and all that which would mean far too many things I don't know (maybe you do). First, I will try to read from the ROM the cinematic before Corneria, that one has a fixed and established set of objects which also happen to be good for measuring the size of the scene (to determine the speed of the ship) nothing weird.
Later I will try the game intro scene which might have 1 bounding box as well as a few laser shots combines with a fixed background.

What do you think?
Hey that brings me to a question, what do you know about SNES programming? I know nothing!


I read a little about the topic and I didn't understand much. I started with the fact that I know that at $6F0F8 in the ROM is the beginning of the Training level info, also I know that according to SFXEdit that level is at $9A6E0D. I tried reading a bit about HiROM and LoROM but no, I don't know anything about this. What I can guess is that in order to read much of the info about the ROM it would be necessary to emulate how memory works in the SNES, otherwise working as I have until now would be enough for me but maybe not for you Stef.
VL-Tone has the list of every address but he also mentions stuff like this:

Quote
At 7E1FF9 and 7E1FFA is a 16-bit pointer for the starting level pointer, you can use a cheat at this adress to start at any level in a more "normal" way.

If I go to address 7E1FF9 in the ROM Hex Edit tells me that I have gone past the End Of File. So how does one get from WRAM(?) over to the ROM file address?
Should I worry about this if I know nothing about real SNES hacking?

He also mentions something like the following. ¿What does the colon symbol mean in these cases?

Quote
A funny example, if you go into Corneria level 2 and activate these two cheats, 7E16FF:BB and 7E1700:01, you'll loop the part where one of your crew member will get attacked by an enemy

And finally, the most important of all questions... how do I go from the Stage Header information to the actual stage information. :S


Here is something I never figured out. How and when do I change between these 4 subpalettes? I thought the light index was supposed to affect the layer of every palette but not the subpalette. I did it for level of palette and it looked ok so I never figured the use of the subpalettes.


Anyways, here are download links:
http://bitshare.com/files/umwcr17c/SNES_Star_Fox_Object_Decoder_ver1.zip.html
http://rapidgator.net/file/81179016/SNES_Star_Fox_Object_Decoder_ver1.zip.html
http://www.4shared.com/zip/41CS6-a8/SNES_Star_Fox_Object_Decoder_v.html              (requires registration)

15
Thanks Stef! Everything worked perfectly! :P
I've rewritten my vertex code so it includes animations and it is reading the rom correctly. I'll have captures later :P
Everything you've said works very well :D
Also the link now works correctly, maybe it was just a dropbox thing.

I am left with two questions: is fixed vertex information always before the animated vertex info?
I was wondering this in order to connect it with the face info correctly.

Also, I still don't get the purpose of stating every offset. Can there be more frames than possible vertex states?
For instance, in the "column" example graph I made, in the second half the offsets decrease, and they all point to frame 1. Would this mean that after certain animation frames have been completed repeat frame 1 a few times?
I'm guessing this would be useful in some models like the "sea squid" thing where it doesn't push in a permanent loop.

Here is the last data of the offsets of "Column" example, they all point to the first frame.
0F 00
0D 00
0B 00
09 00
07 00
05 00
03 00
01 00


--EDIT->
IT'S ALIVE!!!! xD
:D
ANIMATIONS ARE WORKING WITH COLOR PALETTES.
If I were to be missing something its the correct placement of textures! :P
(I'd still like your comment on the thing about the offsets :D)

-edit->
So I think I've gotten most of the objects working. I understand now that some frame offsets are for different interactions like the two sequences inside "9FB9 Monarch Dodora body animation", one for when it walks around and the other for when you hit it. The frames are all in sequence but I'm sure the colision detection points to a certain portion of it.
I also know that there is a special palette ("8590") for "4DAC Andross Square" and "85AC Andross Cube" if used crashed the program (I never saw VL-Tone managing to decode it). This palette points to the big andross face in the texture table and by the way, both of these models are 16 bit coords.
I avoided the 20 interchangeable palettes because I didn't know what to do with them but now I discovered that the "64C2 Attack carrier" in Corneria uses this to determine how the sunset affects the color of the ship, Corneria Level 1 and 2 are by day and Level 3 is with the sunset and this is colored using the interchangeable palettes.

Some faces do have incorrect color setting but I've noticed only one object (70DB Main enemy ship (orange)).

Textures are loaded but I have yet to determine the correct offset algorithm needed to place them correctly but if anyone manages to understand it it will be very easy to put them there since they are already decoded and ready for use.

Some faces are made to have two sides, tha is what makes them have that bad flicker. This also happens with faces with textures because the program thinks a texture is another face. This is easy to fix but I prefer it to be visible since that is where the textures will go.

Even while I had success in loading most models some still appear corrupt for no apparent reason for very few models. I followed the code and it should work.

I will now clean up the code a bit and add a smooth animation setting just to see how it looks. Anyways I believe my work is done with this versión of my app. :D

@Stef
I will try and help with the stage thing. Where on this are you now?

-edit with news!->
Here it is! :D
I have added frame interpolation because I could. I had idea for ages and it works nicely and you can disable it with the keyboard if you want to. :D
https://vimeo.com/60433014
Remember you can download the original video which is 60 fps :P

Stef, how should I post the source code? :D
In a way it is it is permanently on the web.
On a side note, I suppose you've read this thread, it is the more obscure one I could find where VL-Tone explains a bit more about the stage info and how it is used:
http://arwinglanding.net/forum/index.php?PHPSESSID=te5kqmecnhn3j7ltc3ddlrfkv5&topic=1649.0;nowap

16
And also your vertex definition fixed :
Hope that help you with the animated data =)
Awesome! Do you happen to know what happens in between the offset? I think that was what confused me since it looks like a lot of bits with little use? Maybe damage data or more atribute for the same model. What do you think about those?

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

I couldn't download from that link. Is it correct?

Anyways, you've helped me a lot here so I will do a bit more digging so that you can continue your implementation of Star Fox :D
I saw this while searching for stuff:
http://wiki.superfamicom.org/snes/show/Stunt+Race+FX
I think the next step invoves using bsnes and analizing analyzing changes and stuff like that.

Thank you!

-edit->
I got it!
I would only like your opinion about why there are 16 bit jumps and so many offsets with little values to them. It seems like a terrible waste of space. :D

-edit 2->
A few days ago I converted the "frame offset" values from the "49B4 Growing column" and found this. I don't know if it is relevant or anything but I think it might be related to movement on screen. I may be terrible wrong but it might be related with the ztimer.
49B4 Growing column


2FB9 - Plasma Hydra with wings flapping

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

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.
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 think I came across the "shadow" palette while reprogramming mi app and I also think the jukebox enemy is made up of the jukebox plus the three rotating things inside it.
Something bad, I found out the texture placing is just weird and easier to do by hand (like 80 textures with horrible variable offset values) but if you want accuracy in coding I think you will have to read more on the SuperFX.
Decompiling the SFXedit 0.93.exe (that uses the ROM) or the StarfoxDecoder.dcr (that uses ripped models) might be useful but that exceeds my programming knowledge, as does recoding every new discovery (like adding textures to old code).

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

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



@Stef
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.

49B4 Growing column
Code: [Select]
Animation 49B4
About 16 frames
Number 75
Description: Column with a square base and variable height (animation)
---------------------------------
49B4 Growing column
Header Address: 3649
Bank:              c
Vert. Address: 6098b
Face Address:  60a83

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 Frame offset $3F = 63+1 = 64
00 48
00 51
00 5A
00 63
00 6C
00 75
00 7E
00 87
00 90
00 99
00 A2
00 AB
00 B4
00 BD
00 C6
00 1F
00 1D
00 1B
00 19
00 17
00 15
00 13
00 11
00 0F
00 0D
00 0B
00 09
00 07
00 05
00 03
00 01
00 Offset points here, end of some part.


// 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 Frame offset $A3 = 163+1 = 164 // Here I got lost
00
38
02
07 E7 F6
07 E7 0A
20
98 00 38 02 07 DF F6 07 DF 0A
20 8D 00 38 02 07 DA F6 07 DA
0A 20 82 00 38 02 07 D3 F6 07
D3 0A 20 77 00 38 02 07 CC F6
07 CC 0A 20 6C 00 38 02 07 C3
F6 07 C3 0A 20 61 00 38 02 07
BA F6 07 BA 0A 20 56 00 38 02
07 B1 F6 07 B1 0A 20 4B 00 38
02 07 B5 F6 07 B5 0A 20 40 00
38 02 07 BE F6 07

2fb9 Plasma Hydra Boss body

Code: [Select]
Animation 2fb9
About 10 frames
118
Description: Plasma Hydra with wings flapping
---------------------------------
2fb9 Plasma Hydra Boss body
Header Address: 3b2f
Bank:              c
Vert. Address: 62659
Face Address:  62738

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 Frame offset $13 = 19+1 = 20
00 21
00 2F
00 3D
00 4B
00 59
00 67
00 75
00 83
00 91
00 04
02 // Something happens here, its at position 10, The following are 7 transformations?
14
14 EC EC
14 EC 38
01
1E 28
28 20 8E
00 04
02 14 11 EC EC
11 EC 38 01 1E 2F 24 20 7E 00 04 02 14 0D ED EC
0D ED 38 01 1E 34 1F 20 6E 00 04 02 14 0A EF EC
0A EF 38 01 1E 39 19 20 5E 00 04 02 14 09 F0 EC
09 F0 38 01 1E 3B 15 20 4E 00 04 02 12 07 F0 EE
07 F0 38 01 24 37 15 20 3E 00 04 02 10 06 F0 F0
06 F0 38 01 2A 32 15 20 2E 00 04 02 0B 05 F0 F5
05 F0 38 01 32 25 15 20 1E 00 04 02 05 06 F0 FA
06 F0 38 01 36 16 15 20 0E 00 04 02 08 05 F0 F8
05 F0 38 01 35 1E 15 0C 30 20 19 17 0E 0E 17 19
0F 16 18 18 16 0F 0B 0A 00 13 12 01 12 13 0A 0E
0F 00 0F 0E 05 03 13 01 01 12 03 03 14 13 12 15
03 03 15 14 04 05 02 05 14 02 02 15 04 14 15 02
13 14 11 13 11 08 14 0E 0C 0C 08 11 0C 07 08 0C
0E 00 00 0A 08 10 15 12 0B 09 10 10 0D 0F 10 09
0D 09 06 0D 06 00 0F 06 09 0B 3C 28 06 20 00 14
28 0D 27 00 04 44 2E 00 28 0F 9C 00 04 44 A3 00
44 E3 00 28 13 FD 00 04 44 05 01 44 17 01 14 04
06 0E 00 7B E1 12 13 0A 0B FF 14 03 0D 38 00 8A
D1 03 15 14 FF 14 03 04 0C 00 5A 5A 0B 0A 00 03
07 0C 00 A6 5A 0E 0F 00 03 12 12 09 29 88 13 14
11 03 15 0E 7E 0E 09 0C 08 11 03 16 10 6F FA 3D
0C 07 08 04 17 38 13 AC 5D 0C 0E 00 07 04 18 12
13 53 5E 00 0A 08 07 03 19 10 F7 29 88 10 15 12
03 1C 0C 82 0E 09 10 09 0D 03 1D 0E 91 FA 3D 09
06 0D 04 1E 38 ED AC 5D 06 00 0F 0D 04 1F 10 ED
53 5E 06 09 0B 00 FF 14 03 0F

18
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
GREAT! :D Thank you!

Should not your last palette address be 8A85 instead of 8485 ??
Yes I think you are right.
By the way, I just noticed that the D881 palette that I mentioned as the first has whole bunch of XX 3F before which if you include those values makes it palette a fixed color palette and it starts at... 18200! This cannot be random, non of the numbers has been. ;)

I think I will take some time away from this to do some time off my computer! xD
But I will keep trying and reading :D


News from guesswork!
Before I "go" I was curious about finding the textures and I did it! :P
I've been curious about color conversion from SNES->RGB and it turns out that when VL-Tone made his applications he chose not to "correct"(?) the color and keep it as is. The great thing about this is that I opened up photoshop and compared VL-Tone's two texture pages and converted them manually to Hex and looked for the string in the ROM. This worked perfectly! :P
Texture data starts at $90200 and uses EXACTLY the method VL-Tone described:
Quote
As many figured out textures are stored as two 256x256 pages using 4 bits per pixel (they use the same 16 colors palette). The pages are interleaved meaning that for each XY$ byte in hex, X is used for page 1 and Y for page 2.
Here is the proof, and on the right is the use of XX 49 (64x64 Texture Polar Mapping Down Left) and the XX 4A (64x64 Texture Polar Mapping Down Right)




I'll be out of town for a few days but I wanted to show you guys it works. :P
It has artefacts around it because it was resized by openGL byt I plan on fixing that at some point.

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

Thanks for the statistics, that show that, indeed, 1382 is mainly used... i will probably wait to implement the other one :p
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.
Also, at the beginning of the video you will see the High poly in daytime, nighttime and space using the 16 color variants. :P

It's nice to see the object display in semi wireframe, their method is simple but efficient to display hybrid object :)
I think this can be perfectly applied to making modern "retro" games.

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


I checked a bit for some palette addresses I had seen before and I also verified the contents. What was weird about these two is that the colors seemed to be the same so I checked and the values for 13 82 and ed 82 are very similar in content. Here are some other palettes that I think work.

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)


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

20
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.
Lets see, this is what I have:
552 Obj Addresses
 13 Point at negative addresses
375 Objs point to 8213
 35 Objs point to 82ed
 10 Objs point to 83c1
  7 Objs point to 852e (I believe these are animated textures)

Then there are many other adddresses that make little to no sense. Specially since the are too varied. For example:
Code: [Select]
8542 8542 8542 8544 8544 8546 8548 8548 8552 8552 8552 8554 8556 8558 8560 8560

I've chosen to block any address reference that is not the first too that I've mentioned, just in case. I changed them with 8213.

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 !
Thought the same but I think the SuperFX can handle it.

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 :)
I have to work too! xD Good luck!

I've also implemented faces composed of 2 vertices, meaning lines. This makes it way easier to spot the models and guess some stuff about them. Those flashy antennas now glow! It also makes powerups look awesome and for example, there are 4 "Shielded Enemy" starting with B8DE, the wireframe shows me that they are not 4 different enemies but the same one, 3 of it's frames are for when it is cloaking.



Important: Now I'm in search of the texture addresses in case anybody has them! I don't mean the snes sprites, I mean the addresses for the textures which have to be read in a certain way, but if you have the addresses for the sprites I wouldn't mind those either. :P

Pages: [1] 2 3