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
1
On the same idea than the SF2 patch : http://www.romhacking.net/forum/index.php/topic,18561.0.html
I patched the Super Street Fighter 2 game (megadrive) to fix the sound driver and improve the SFX quality :)
You can find the IPS patch here (for the US version of the game) :
https://dl.dropboxusercontent.com/u/93332624/dev/megadrive/ssf2/SSF2_mod.ips

2
Thanks, i guess this is exactly what i was looking for =)

August 28, 2014, 02:13:52 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
Wonderful ! 2 clicks to create the patch !

https://dl.dropboxusercontent.com/u/93332624/dev/megadrive/sf2/sf2_audio_driver_patch.ips

I guess there is a better place to submit it :)

3
Oh yeah but to be honest i am definitely not a rom hacker guy, is there any tools which allow to generate the IPS patch by comparing 2 roms ? I guess there is but i'm somehow novice to that (i modified the rom with hexa editor).

4
Hi folks,

I also posted it on other forum but it might be better placed it after all :)

I guess everyone know this famous game and its reputation for having scratchy voices. One of my crazy projects i had in mind was to rewrite the Z80 PCM sound driver for this game to improve the voices output as the Megadrive is perfectly able of playing them well, it just requires good programming... something that Capcom never (wanted to) achieved on the Sega Megadrive.

Some days ago i finally decided to get a shoot in that project and i started by disassembling the Z80 driver. I don't know if it has already be made before but i did not found any informations about it...
Anyway i was very surprised by the size of the driver, it's very simple and short (code size = 358 bytes).
So for those who are curious you can see the source code of SF2 Z80 driver at the end of this post.
I commented, equated and modified it a bit (replaced some JR (PC+2) by 3 NOP) to make it more readable.
I even fixed a bug in the driver ! Because of it the channel 2 can miss one sample from time to time, not very important but still it shows how developer was lazy about it. Also the code is definitely not optimized, of course it do not use buffering but even worse, it uses lazy and slow memory access for many thing and never take advantage of SP register.
The loop is 749 cycles length (i do not count special case of new command) which mean the sample rate is about 4.8 Khz.
That is really bad, one of the first driver i wrote (which was not using any buffering) was able to play 2 channels at 14 Khz.

It took me about 3h to reverse engineer the driver, that was the easy part ;) Now what i need to do is to mimic this driver but replacing it by something safe against DMA. I will use the same method i used in my bad apple demo. The idea is to buffer sample from ROM in Z80 ram during the active period and use them to read sample during DMA which should occurs in VBlank period. Problem is that SF2 is extending VBlank a bit and i don't know if DMA is effectly used before the VInt occurs. If that is the case i will have to "count" to find the correct period where i need to stop ROM accesses... Then i will need to patch some 68k code, i guess they disable Z80 during DMA which we should avoid for instance, same for IO access (but not as important).

Ok, that was my initial message to introduce the project and you can find more technical details on Sega-16 forum :
http://www.sega-16.com/forum/showthread.php?28108-Street-Fighter-2-new-Z80-PCM-sound-driver-project

Now the patch is done, i had some hard time in fixing a stupid bug but finally i come with a 100% working version.

Here is the last version of patched rom :
https://dl.dropboxusercontent.com/u/93332624/dev/megadrive/sf2/sf2_mod_v7.bin

And here a video comparing before and after the patch (sorry for the awful quality of the video) :
https://www.youtube.com/watch?v=-iE5GJNkOqs


August 27, 2014, 05:30:43 am - (Auto Merged - Double Posts are not allowed before 7 days.)
Code: [Select]
; BC = bank register

COUNTER     EQU     $1FF0           ; 16 bits counter
COMM_CH0    EQU     $1FFE           ; FF = done, < 80 = SFX ID to play
COMM_CH1    EQU     $1FFF           ; FF = done, < 80 = SFX ID to play

FM_ACCESS   EQU     $1FFD           ; indicate that Z80 is accessing DAC register (00 = ok, 2A = DAC access)

CH0_PRIO    EQU     $1FE0           ; channel 0 priority
CH0_LEN     EQU     $1FE1           ; channel 0 length (2 bytes: LH)
CH0_ADDR    EQU     $1FE3           ; channel 0 address (3 bytes: LMH)

CH1_PRIO    EQU     $1FE8           ; channel 1 priority
CH1_LEN     EQU     $1FE9           ; channel 1 length (2 bytes: LH)
CH1_ADDR    EQU     $1FEB           ; channel 1 address (3 bytes: LMH)

            ORG     $0000

init
            DI                      ; disable ints
            IM      $01             ; set int mode 1
            LD      SP, $1000       ; setup stack

            ld      A,0xff
            ld      (COMM_CH0),a        ; clear command ch 0
            ld      (COMM_CH1),a        ; clear command ch 1

            ld      hl,(0x1001)         ; load empty sample param
            ld      (CH0_ADDR),hl
            ld      (CH1_ADDR),hl
            ld      a,(0x1003)
            ld      (CH0_ADDR+2),a
            ld      (CH1_ADDR+2),a
            ld      bc,0x6000           ; init BC

loop
            ld      hl,(COUNTER)
            inc     hl                  ; inc counter
            ld      (COUNTER),hl        ;                                       =38

do_com0
            ld      a,(COMM_CH0)
            or      a                   ; read command channel 0
            jp      m,do_com1           ; if (a & 0x80) goto do_com1            =27

            ld      l,a                 ; A = SFX ID
            ld      h,0x00
            add     hl,hl
            add     hl,hl
            add     hl,hl
            ex      de,hl
            ld      ix,0x1000
            add     ix,de               ; IX = SFX DATA ADDR                    =+77

            ld      a,(CH0_PRIO)
            ld      e,a                 ; E = old prio
            ld      a,(ix+0)            ; A = new prio                          =+36

            cp      e                   ; if (new_prio > old_prio)
            jr      c,com0_done         ; {                                     =+11/16

            ld      (CH0_PRIO),a        ;   load prio
            ld      l,(ix+4)
            ld      h,(ix+5)
            ld      (CH0_LEN),hl        ;   load lenght
            ld      l,(ix+1)
            ld      h,(ix+2)
            ld      (CH0_ADDR),hl       ;   load address
            ld      a,(ix+3)
            ld      (CH0_ADDR+2),a      ; }                                     =+153

com0_done
            ld      a,0xff
            ld      (COMM_CH0),a        ; command channel 0 done                =+20

do_com1
            ld      a,(COMM_CH1)
            or      a                   ; read command channel 1
            jp      m,set_bank0         ; if (a & 0x80) goto set_bank0          =27

            ld      l,a                 ; A = SFX ID
            ld      h,0x00
            add     hl,hl
            add     hl,hl
            add     hl,hl
            ex      de,hl
            ld      ix,0x1000
            add     ix,de               ; IX = SFX DATA ADDR                    =+77

            ld      a,(CH1_PRIO)
            ld      e,a                 ; E = old prio
            ld      a,(ix+0)            ; A = new prio                          =+36

            cp      e                   ; if (new_prio > old_prio)
            jr      c,com1_done         ; {                                     =+11/16

            ld      (CH1_PRIO),a        ;   load prio
            ld      l,(ix+4)
            ld      h,(ix+5)
            ld      (CH1_LEN),hl        ;   load lenght
            ld      l,(ix+1)
            ld      h,(ix+2)
            ld      (CH1_ADDR),hl       ;   load address
            ld      a,(ix+3)
            ld      (CH1_ADDR+2),a      ; }                                     =+153

com1_done
            ld      a,0xff
            ld      (COMM_CH1),a        ; command channel 1 done                =+20

set_bank0
            ld      hl,(CH0_ADDR)       ; HL = sample 0 addr (ML)
            ld      a,h
            rlca
            ld      (bc),a              ; bank = addr bit 15                    =31

            ld      a,(CH0_ADDR+2)      ; A = sample 0 addr (H)
            ld      (bc),a              ; bank = addr bit 16
            rrca
            ld      (bc),a
            rrca
            ld      (bc),a
            rrca
            ld      (bc),a
            rrca
            ld      (bc),a
            rrca
            ld      (bc),a
            rrca
            ld      (bc),a
            rrca
            ld      (bc),a              ; bank = addr bit 23                    =97

read0
            set     7,h                 ; HL = sample ch0 addr banked
            ld      a,(hl)
            ex      af,af'              ; A' = sample ch0                       =19

set_bank1
            ld      hl,(CH1_ADDR)       ; HL = sample 1 addr (ML)
            ld      a,h
            rlca
            ld      (bc),a              ; bank = addr bit 15                    =31

            ld      a,(CH1_ADDR+2)      ; A = sample 1 addr (H)
            ld      (bc),a              ; bank = addr bit 16
            rrca
            ld      (bc),a
            rrca
            ld      (bc),a
            rrca
            ld      (bc),a
            rrca
            ld      (bc),a
            rrca
            ld      (bc),a
            rrca
            ld      (bc),a
            rrca
            ld      (bc),a              ; bank = addr bit 23                    =97

read1
            set     7,h                 ; HL = sample ch1 addr banked           =8

            ld      de,FM_ACCESS
            ld      a,0x2a
            ld      (de),a              ; indicate Z80 is accessing YM DAC register
            ld      (0x4000),a          ; prepare DAC write                     =37

mix
            ex      af,af'              ; A = sample ch0 (7 bits)
            add     a,(hl)              ; A = mixed sample (8 bits)
            rra                         ; A = mixed sample (7 bits)
            ld      (0x4001),a          ; write sample to DAC                   =28

            xor     a
            ld      (de),a              ; Z80 release YM access                 =11

update0
            ld      hl,(CH0_LEN)        ; HL = ch0.len
            ld      a,h
            or      l                   ; if (ch0.len == 0)
            jr      z,play_fixed0       ;   goto play_fixed0                    =31

            dec     hl
            ld      (CH0_LEN),hl        ; ch0.len--
            ld      a,h
            or      l                   ; if (ch0.len == 0)
            jr      z,play_done0        ;   goto play_done0                     =37

            ld      hl,CH0_ADDR
            inc     (hl)                ; ch0.addr.l++
            jr      nz,play_done0_1                                             =28

            ld      hl,(CH0_ADDR+1)
            inc     hl                  ; ch0.addr.mh++
            ld      (CH0_ADDR+1),hl
            jp      update1             ; goto update1                          =48

play_fixed0
            ld      a,0x05
play_f0_wait
            dec     a
            jr      nz,play_f0_wait                                             =+87+5

            nop                         ; waste some cycles
            jr      update1             ; goto update_ch1                       =+16

play_done0
            xor     a
            ld      (CH0_PRIO),a        ; no more playing ch0
            nop
            nop
            nop
            nop
            nop
            nop
            nop
            nop
            jr      update1             ; waste some cycles                     =+61+5

play_done0_1
            ld      a,0x00
            nop
            nop
            nop
            nop
            nop
            nop
            nop
            nop
            nop                         ; waste some cycles                     =+43+5

update1
            ld      hl,(CH1_LEN)        ; HL = ch1.len
            ld      a,h
            or      l                   ; if (ch1.len == 0)
            jr      z,play_fixed1       ;   goto play_fixed1                    =31

            dec     hl
            ld      (CH1_LEN),hl        ; ch1.len--
            ld      a,h
            or      l                   ; if (ch1.len == 0)
            jr      z,play_done1        ;   goto play_done1                     =37

            ld      hl,CH1_ADDR
            inc     (hl)                ; ch1.addr.l++
            jr      nz,play_done0_1                                             =28

            ld      hl,(CH1_ADDR+1)
            inc     hl                  ; ch1.addr.mh++
            ld      (CH1_ADDR+1),hl
            jp      next                ; goto next                             =48
; note that in the original driver it was jumping to 'update1' instead
; that is probably a copy/paste bug and lead to some missed sample

play_fixed1
            ld      a,0x05
play_f1_wait
            dec     a
            jr      nz,play_f1_wait                                             =+87+5

            nop                         ; waste some cycles
            jr      next                ; goto next                             =+16

play_done1
            xor     a
            ld      (CH1_PRIO),a        ; no more playing ch1
            nop
            nop
            nop
            nop
            nop
            nop
            nop
            nop
            jr      next                ; waste some cycles                     =+61+5

play_done1_1
            ld      a,0x00
            nop
            nop
            nop
            nop
            nop
            nop
            nop
            nop
            nop                         ; waste some cycles                     =+43+5

next
            jp loop                                                             =10

                                        ; total cycles per loop = 749 ~ 4.8 Khz

            BLOCK   $1000-$

; SFX DATA
; --------
; format : PP AA AA AA LL LL 00 00
; PP = priority
; AA = address (LMH)
; LL = length (LH)
;
; 001000    00 00 00 28 52 05 00 00         SFX 0
;           00 52 05 28 e7 0d 00 00         SFX 1
; 001010    00 39 13 28 b9 05 00 00         .....
;           00 f2 18 28 ca 05 00 00
; 001020    00 bc 1e 28 d1 06 00 00 00 8d 25 28 97 05 00 00
; 001030    00 24 2b 28 c8 05 00 00 00 ec 30 28 fe 06 00 00
; ...
; 0013f0    ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
;
; NOT USED
; 001400    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
; ...

; VARIABLES
; 001fe0    00 00 00 00 00 28 00 00 00 00 00 00 00 28 00 00
; 001ff0    53 30 00 00 00 00 00 00 00 00 00 00 00 00 ff ff

5
To be honest the HUD is a part we did not explored at all but i guess you can just exam the rom to find the HUD graphics data and replace it by transparent graphics data so you won't have to even patch code.

6
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

7
Hey Dyson,

I don't know if you are still around but i wanted to post some news... My laptop never appeared as i expected but anyway my motivation never gone at least ;) Lately i spent sometime in improving the 3D rendering part on the megadrive. I improved a bit the performance, not a big boost over the previous version to be honest but still a bit faster. Now i need to get hands back in the starfox format itself, i just read the whole topic and i am ready to spent sometime in figuring the last unknowns in the header format :) I will keep the topic updated with my future findings...

8
Yep, just unlucky this time... but as i said i have the motivation to get it back which is the most important :)
Glad to hear you're still around !


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

9
Hi,

Back to bring some news, not good ones unfortunately.
I had to fly some days ago for my job and unfortunately the air company lost one of my baggage on return, the baggage which contained my laptop actually... Usually i always keep my laptop as hand baggage and never put it to the check in but i didn't had choice this time. Even if the company told me they can still find the baggage i don't really trust them and assume it's already 100% lost. Worst than laptop itself is data loss... i lost about 7 months of data, work... I'm trying to recover as much i can from internet, forum, dropbox or whatever but i know i lost many stuff.
Right now i try to get back my starfox remake project, hopefully i had some backup sitting somewhere, unfortunately these backups are quite old (really older than the one i posted 1 month ago) but well, it can be redone.
Really glad that we discussed here as i could restore my starfox object decoder from archives i posted =)

10
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

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

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.

12
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

The good point of doing it on PC is that you're not limited in term of CPU resource, so you can really replicate game using most of the original data ! In my case i have to convert them in a more friendly format for the megadrive as i cannot waste any CPU resource in weird decoding code :p

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

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


13
Yeah i realized that was posted elsewhere now, i'm glad to see how it was generally received :) funny to see it induced some nintendo vs sega fans wars too :p
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
Then when that will be done i will probably work on optimization.
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 !


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

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

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

Cool ! I don't know if he actually follows our progression but i hope he is, its help would be very valuable :)

15
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?

I started to write the 3D engine a long time ago and i improved it so it can be fast enough to allow Starfox style game on a stock megadrive.
Also i started with my own models, i got the arwing one from the deconstruction page and i did other object by hand but they weren't that great. Also i did not wanted to show it until it has something interesting to show ;)
The good point is that megadrive share a lot of identical constraint / feature with the SNES (as the 4bpp color) so it is a nice target to attempt a "port". The difficult part is that i don't have the SuperFX to help, hopefully a stock megadrive has much more power than a stock SNES (thanks to the true 16 bits architecture) so even without SuperFX we can put some polygon up :)
The lack of a bitmap mode does not help either here but i can live with that (need software tile buffer to bitmap buffer conversion).

Quote
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 get that i somehow simulated a board to store level data, i use a sort of ztimer the same way the original Starfox does. When timer goes to 0 i simply read from the board next object until i read a new Ztimer value. For the moment i made a test level by putting random objects here and there with some movements for the big walker for instance. It's nice to see them animated as the original :)

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

Unfortunately i can say the scale is the only parameter i am certain, the size / object bounds looks weird and as i say above, i do not see how use them neither yet.
All that values still need a lot of research ;)

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

Glad to hear that, so the objects are corrects at least ;)

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

We can post him a link here if he is interested :)

16
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

Actually SFXEdit already have the level editor, except it is done in hexa decimal edition form but you can actually already edit / modify Starfox level through the application :)
Map out the rom is a nice idea, it is the easiest way then to read / decode and understand the rom for someone else it but that would require much much time to do it ! Right now we already have many informations but you are right, they need to be compiled and set in a good form so we can easily read them. And as far i know there is no ready to go solution for that... except taking notepad and writing all by hands :p

By the way, here is the format of the object header as i now understand it :

Code: [Select]
$00: vertex address offset (2 bytes, low byte first)
$02: bank number (1 byte)
$03: face address offset (2 bytes, low byte first)
$05: Z position ?? (2 bytes, low byte first)
$07: scale, used as left shift operator: value <<= scale  (1 byte)
$08: unknown address, collision infos ?? (2 bytes, low byte first)
$0A: size X (2 bytes, low byte first)
$0C: size Y (2 bytes, low byte first)
$0E: size Z (2 bytes, low byte first)
$10: Z distance / alignment ? (2 bytes, low byte first)
$12: palette address (2 bytes, low byte first)
$14: id1
$16: id2
$18: id3
$1A: id4

Bank number = 0 is a special value meaning there is no vertex nor face data attached to this object.

To compute final vertex and face data address in the rom we have to use this formula :
((bank number - 1) * $8000) + address offset   (add $200 for headered rom)

Example of low poly arwing model header :
vertex address = ($10 * $8000) + $F173 = $8F173  ($8F373 on headered rom)
face address = (($10 * $8000) + $F196 = $8F196  ($8F396 on headered rom)

There are many informations I'm not sure about :
$05: Z distance ?? (2 bytes, low byte first)
$08: unknown address, collision infos ?? (2 bytes, low byte first)
$10: Z position / alignment ? (2 bytes, low byte first)

$05 seems to be something as Z distance of object but i'm really not sure, the filed is rarely set which make it even more difficult to figure.
$08 field is rarely set too but when it is done, it seems to be a 16 bit address... Note that field is almost time use of Arwing object or some big boss / base object.
$10 is almost time very close to the value set in $0E (size z) but not always the same, a bit more or a bit less... can't really figure what it is.

About the size fields, they give the final object size after scale factor have been applied. Once again I am not sure about them but i believe the size information could be use as a bounding box and Z position could be a sort of bounding box shift compared to object center. Just some suppositions...

Here is the last version of my object decoder tool :
https://www.dropbox.com/s/bem8k66w8syj80q/sfxObjReader.jar?dl=0

Red object : not correctly decoded
Green object : animated
Blue object : position field set

As you may see, the SFX Object decoder do not exactly use the same header decoding as the one explained above, it is just because i tried several test cases and i still don't have figured the real meaning of these fields.

Here is a preview of my project, just a small demo:
https://www.dropbox.com/s/macxo0841djlo5a/sfx_gen.zip?dl=0

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

Edit: fixed dropbox links

17
Just saw your messages ! Awesome VL Tones contacted you, well done :)
I downloaded the zip file he sent but looks like that is all we already have on different topic / forum / archive we explored.
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) :)

18
If there is any comment about it I would have to say this: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.)

Actually i saw the following different cases by looking in model vertices :
Code: [Select]
Fixed
Animated
Fixed

----

Fixed
Animated

---

Animated

So maybe you are right, you can't have vertices definition starting with animated then having fixed following.
At least my code parser allow it just in case :)



Quote
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 didn't yet tested displaying models, i will may experience some troubles too when i will try it ^^

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

Of course :)
You have to handle the game logic yourself :
- control the arwing ship from user input
- level navigation (Z coordinate decrement on all scene objects)
- handle collision between objects (arwing shoot, arwing, ennemy, scene objects)
- a lot more...

The level data only give events so it make some enemies, scene objects, boss, cutscene... to appears.
But then all the game logic handle them and a lot of the logic itself is hidden in "behavior" object of level data.
We actually have to reproduce the original game logic to make all that working...  Level data is just here to help is constructing the level but not for the game logic itself which we have to build on our own.

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

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?

I do now a bit about SNES programming but not that much, it could help in reverse engineering rom data but not in reproducing the game itself. All the rom can bring us is data and only data (object model, level data...). All the game logic code has to be redone and that is just game programming skill, nothing else.
We could try to read the base game code but there is no point in doing it, we can try to replicate it just by testing and comparing original game and remake :)
About level data, we can just use what SFXEdit give us, it actually contains all what we want =) Did you read the SFXEdit documentation ? it gives nice informations about how interpret level data :)

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

semi colon separate the address and the value :
$77EEFF:EE

means : set value $EE at address $77EEFF

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


Actually i think these subpalette are used only depending the Z depth of your object in the scene :)
The farther is your object, the more dark it is.

Quote
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

Thanks for sharing ! I will try them asap :)
By the way, i am still working on objects. I try to understand what are the informations contained in the object header and i have to admit that i had some hard time with that.
For the moment i only isolated the scaling parameter, some others data seems to be related to the object size or many bounds but i'm not yet sure about that.

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

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

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

You can have fixed part before and after animated part, you can also have only animated part.

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

Exactly, that allow reuse of same vertices for another frame, the simplest example can be a growing then decreasing bloc. You can use vertices of the growing frames for the decrease part of animation :)

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

There are still some unknown about palette, i think some data in the object header define "object type" or something like that which may help in palette interpretation as maybe bounding box informations as well.

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

Yeah i noticed that, this is because Starfox use polygon clockwise order to define if it's visible or not, so if a face is always visible (as part of arwing wing) then you should define 2 polygon in reverse order to get it always displayed.

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

You can try my last version of my object decoder, invalid object (missing data or cannot be parsed correctly) are displayed in red, that might help you to know if your object is correct or not :
https://dl.dropbox.com/u/93332624/dev/sfx/sfxObjReader.jar

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

Nowhere :D
I did not yet started anything about it as i meet some troubles with my program, it turns out i got memory corruption when i try to import all generated objects... This is not due to the exported itself ;)


Quote
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

It looks really smooth ! Your interpolation code works perfectly :)
I will fit with standard animation as anyway i won't have smooth frame rate on my final program. It does run on a much more limited system and interpolation would waste even more my limited CPU resource !

Quote
Stef, how should I post the source code? :D
In a way it is it is permanently on the web.

Actually you can post it in whatever form you want on FileShare or whatever, of course it would be best to choose a reliable share site so it can stay available for a long time. Honestly i'm not sure that a lot of guys will use it, we are probably the only ones interested in doing a remake of the original game ^^


Quote
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

Yeah i already read that topic, some part are interesting but i think the best is still to use that SFXEdit tool and the attached documentation :) There is many interesting thing to get from it, at least we can somehow reproduce them by reading how level are arranged even f we don't use direct level data !

20
Quote
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?

Usually you just find vertex data of other frame :)

A typical animated vertex list data will look like this :

Code: [Select]
04           // normal vertex
XX           // vertex number
XX XX XX    // vertex data
XX XX XX
...
1C          // animated vertex
XX          // number of frame
XX XX     // offset for animated vertex frame 1
XX XX     // offset for animated vertex frame 2
XX XX     // offset for animated vertex frame 2
....          // offset for animated vertex frame x

// frame 0 animated vertex data
XX          // vertex type
XX          // vertex number
XX XX XX   // vertex data
XX XX XX
...
20          // jump
XX XX      // 16 bit offset where to jump to reach end of vertex data
// frame 1 animated vertex data
XX          // vertex type
XX          // vertex number
XX XX XX   // vertex data
XX XX XX
...
20          // jump
XX XX      // 16 bit offset where to jump to reach end of vertex data
// frame 2 animated vertex data
XX          // vertex type
XX          // vertex number
XX XX XX   // vertex data
XX XX XX
...
20          // jump
XX XX      // 16 bit offset where to jump to reach end of vertex data
// frame 3 animated vertex data
...

So there is no waste in vertex data :)
The way i parsed the animated vertex in my tool permit to entirely rebuild the vertex list for each frame but in the rom only the variable part are redefined (it's why we have a jump tag so we can always attach to the same last vertices).

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

It does work for me, does it still fail for you ?

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

It does, as the animated color, animated object use a different vertex base at each frame :)

Pages: [1] 2 3