So yeah, seeing as if I probably won't be working extensively on it, I put a Ristar disassembly I made for the DAC samples onto the SVN. Read the readme.txt and go crazy =P EDIT Some Nemesis(?) art pointers, if anyone wants to confirm/label: http://ristar-cluster.info/php-pages/index2.html
That's the thing I'm unsure of; if you search for TODO you'll see some jumps haven't been fully resolved yet; and besides I might have missed some jumps, or IDA might have accidentlly misinterpreted something as a function (happened to me with Chaotix a lot), etc. Plus with Ristar IDA accidentally marks some data (such as Nemesis data) as offsets. I want to hold off an ASM conversion until the code is analyzed fully, but yes raw split+text ASM would help. Also I'd prefer waiting until someone gets a command line Star compressor/decompressor working too, just so splits/builds/hacks go easier =P
Code (Text): ROM:00005050; =============== S U B R O U T I N E ======================================= ROM:00005050 ROM:00005050; a0 = OST pointer ROM:00005050 ROM:00005050 RenderSprite: ; CODE XREF: MainRenderSprites:loc_5010p ROM:00005050 ; sub_548F0:loc_54958p ROM:00005050 btst #0,2(a0) ROM:00005056 bne.s locret_5060 ROM:00005058 btst #1,2(a0) ROM:0000505E beq.s loc_5062 ROM:00005060 ROM:00005060 locret_5060: ; CODE XREF: RenderSprite+6j ROM:00005060 rts ROM:00005062; --------------------------------------------------------------------------- ROM:00005062 ROM:00005062 loc_5062: ; CODE XREF: RenderSprite+Ej ROM:00005062 movea.l 8(a0),a1 ROM:00005066 moveq #0,d0 ROM:00005068 move.b 3(a0),d0 ROM:0000506C add.w d0,d0 ROM:0000506E adda.w (a1,d0.w),a1 ROM:00005072 moveq #0,d1 ROM:00005074 move.b (a1)+,d1 ROM:00005076 bmi.s locret_50D6 ROM:00005078 move.b (a1)+,4(a0) ROM:0000507C move.w $2A(a0),d2 ROM:00005080 move.w $28(a0),d3 ROM:00005084 btst #6,2(a0) ROM:0000508A bne.s loc_50E4 ROM:0000508C ROM:0000508C loc_508C: ; CODE XREF: RenderSprite+82j ROM:0000508C move.b (a1)+,d0 ROM:0000508E ext.w d0 ROM:00005090 add.w d2,d0 ROM:00005092 move.w d0,(a2)+ ROM:00005094 move.b (a1)+,(a2)+ ROM:00005096 move.b d6,(a2)+ ROM:00005098 move.w (a1)+,d0 ROM:0000509A add.w $E(a0),d0 ROM:0000509E btst #4,2(a0) ROM:000050A4 bne.s loc_50AA ROM:000050A6 ori.w #$8000,d0 ROM:000050AA ROM:000050AA loc_50AA: ; CODE XREF: RenderSprite+54j ROM:000050AA move.w d0,(a2)+ ROM:000050AC move.b (a1)+,d0 ROM:000050AE tst.b 2(a0) ROM:000050B2 bpl.s loc_50BC ROM:000050B4 bchg #3,-2(a2) ROM:000050BA move.b (a1),d0 ROM:000050BC ROM:000050BC loc_50BC: ; CODE XREF: RenderSprite+62j ROM:000050BC addq.l #1,a1 ROM:000050BE ext.w d0 ROM:000050C0 add.w d3,d0 ROM:000050C2 andi.w #$1FF,d0 ROM:000050C6 beq.s loc_50D8 ROM:000050C8 ROM:000050C8 loc_50C8: ; CODE XREF: RenderSprite+8Ej ROM:000050C8 ; RenderSprite+92j ROM:000050C8 move.w d0,(a2)+ ROM:000050CA addq.b #1,d6 ROM:000050CC cmpi.w #$50,d6; 'P' ROM:000050D0 bhi.s locret_50D6 ROM:000050D2 dbf d1,loc_508C ROM:000050D6 ROM:000050D6 locret_50D6: ; CODE XREF: RenderSprite+26j ROM:000050D6 ; RenderSprite+80j ROM:000050D6 rts ROM:000050D8; --------------------------------------------------------------------------- ROM:000050D8 ROM:000050D8 loc_50D8: ; CODE XREF: RenderSprite+76j ROM:000050D8 btst #5,2(a0) ROM:000050DE bne.s loc_50C8 ROM:000050E0 addq.w #1,d0 ROM:000050E2 bra.s loc_50C8 ROM:000050E4; --------------------------------------------------------------------------- ROM:000050E4 ROM:000050E4 loc_50E4: ; CODE XREF: RenderSprite+3Aj ROM:000050E4 ; RenderSprite+EAj ROM:000050E4 move.b (a1)+,d0 ROM:000050E6 ext.w d0 ROM:000050E8 neg.w d0 ROM:000050EA moveq #3,d4 ROM:000050EC and.b (a1),d4 ROM:000050EE addq.b #1,d4 ROM:000050F0 lsl.w #3,d4 ROM:000050F2 sub.w d4,d0 ROM:000050F4 add.w d2,d0 ROM:000050F6 move.w d0,(a2)+ ROM:000050F8 move.b (a1)+,(a2)+ ROM:000050FA move.b d6,(a2)+ ROM:000050FC move.w (a1)+,d0 ROM:000050FE add.w $E(a0),d0 ROM:00005102 ori.w #$1000,d0 ROM:00005106 btst #4,2(a0) ROM:0000510C bne.s loc_5112 ROM:0000510E ori.w #$8000,d0 ROM:00005112 ROM:00005112 loc_5112: ; CODE XREF: RenderSprite+BCj ROM:00005112 move.w d0,(a2)+ ROM:00005114 move.b (a1)+,d0 ROM:00005116 tst.b 2(a0) ROM:0000511A bpl.s loc_5124 ROM:0000511C bchg #3,-2(a2) ROM:00005122 move.b (a1),d0 ROM:00005124 ROM:00005124 loc_5124: ; CODE XREF: RenderSprite+CAj ROM:00005124 addq.l #1,a1 ROM:00005126 ext.w d0 ROM:00005128 add.w d3,d0 ROM:0000512A andi.w #$1FF,d0 ROM:0000512E beq.s loc_5140 ROM:00005130 ROM:00005130 loc_5130: ; CODE XREF: RenderSprite+F6j ROM:00005130 ; RenderSprite+FAj ROM:00005130 move.w d0,(a2)+ ROM:00005132 addq.b #1,d6 ROM:00005134 cmpi.w #$50,d6; 'P' ROM:00005138 bhi.s locret_513E ROM:0000513A dbf d1,loc_50E4 ROM:0000513E ROM:0000513E locret_513E: ; CODE XREF: RenderSprite+E8j ROM:0000513E rts ROM:00005140; --------------------------------------------------------------------------- ROM:00005140 ROM:00005140 loc_5140: ; CODE XREF: RenderSprite+DEj ROM:00005140 btst #5,2(a0) ROM:00005146 bne.s loc_5130 ROM:00005148 addq.w #1,d0 ROM:0000514A bra.s loc_5130 ROM:0000514A; End of function RenderSprite Does anyone know if the sprite mappings read by this routine are the same format as in S1/2/3K/Crackers? I get odd results loading a mapping in all four formats in SonMapEd, and both this and the Sonic 1 code are just confusing.
The code isn't confusing at all if you know how the Sprite Attribute Table works, and if you don't there's always genvdp.txt. Anyway, the mappings data starts off with an offset table which is identical to the one in Sonic 1. The format of each frame's mapping data is NN ?? (YY SS AAAA XX XX'). NN is the number of sprites in the frame - 1, so the bytes in brackets are repeated NN + 1 times. I have no idea what ?? is but it's moved to byte 4 of the object's status table. YY is the Y offset, SS is the sprite size, AAAA is the art tile, XX is the X offset and XX' is the X offset in case the object is X-flipped (it doesn't need to be stored separately, it can be calculated, but I'm assuming it was done for speed reasons). For comparison, Sonic 1 is NN (YY SS AAAA XX), except NN is the number of sprites in the frame instead of the number of sprites -1. Also, RenderSprite is an inaccurate name since a mapping frame can consist of multiple sprites. RenderMappingFrame or RenderFrame or even RenderObject would be better.