Basic Questions & Answers thread NEWBIES: Start here!
Posted 03 October 2015 - 07:11 PM
Remapping it to use less tiles is also a possibility.
This, and another tip that means more work but that it will worth it. If you 'break' the sprites, you can create additional blank tiles so you can decrease the amount of tiles loaded even futher. I will post the same example since this is one case that really show the benefit of it.
Of course that this means editing the art file, but in frames like this one you can load up to 4 tiles less than without breaking it. It also means a more complex mapping, but if you're using SonMapEd, you have no excuse to not do it. I do have to say that I don't know how optimized the S3 sprites are, but at least in S1 you can save a lot of space with this.
I will also stop being an asshole and accept that I need help with some issue with porting the bloody DMA Queue. You'll see, Im using the GitHub disassembly since Im a newbie and I need all things labeled and tagged and split into a lot of individual files (2005 one's 3MB sonic.asm file lags like hell in my netbook) and I wanted (still want) to port Green Snake's multi-character guide from the old disam format to the GH one, and after some help I have all done... except the DMA Queue. So, I started porting that, and I can not make Sonic appear at all. Im sure that the problem is here, but I don't know what to do. Here's the thing:
Once you've finished, go to "loc_CD4", "loc_DAE", "loc_EEE", and loc_FAE"
Once you've finished, go to "loc_CD4", "loc_DAE", "loc_EEE", and loc_FAE". Replace this piece of code.
tst.b ($FFFFF767).w beq.s loc_D50 lea ($C00004).l,a5 move.l #$94019370,(a5) move.l #$96E49500,(a5) move.w #$977F,(a5) move.w #$7000,(a5) move.w #$83,($FFFFF640).w move.w ($FFFFF640).w,(a5) move.b #0,($FFFFF767).w
jsr (ProcessDMAQueue).lMy disam doesn't have this, but after comparing them side by side, I figured out that it would be this part:
Once you've finished, go to "VBla_08/@waterbelow", "VBla_0A", "VBla_0C/@waterbelow", and "VBla_16"
Replace this piece of code.
tst.b (f_sonframechg).w ; has Sonic's sprite changed? beq.s @nochg ; if not, branch writeVRAM v_sgfx_buffer,$2E0,vram_sonic ; load new Sonic gfx move.b #0,(f_sonframechg).w
The WriteVRAM macro is this:
writeVRAM: macro lea (vdp_control_port).l,a5 move.l #$94000000+(((\2>>1)&$FF00)<<8)+$9300+((\2>>1)&$FF),(a5) move.l #$96000000+(((\1>>1)&$FF00)<<8)+$9500+((\1>>1)&$FF),(a5) move.w #$9700+((((\1>>1)&$FF0000)>>16)&$7F),(a5) move.w #$4000+(\3&$3FFF),(a5) move.w #$80+((\3&$C000)>>14),(v_vdp_buffer2).w move.w (v_vdp_buffer2).w,(a5) endm
The guide says that if you build and you see Sonic, you deserve a cookie. well, Sonic does NOT appear therefore I have NO COOKIE!
Also, while I see that the macro HAS TO BE the thing that I have to replace because it's too bloody similar, I have no idea what those >((())$%$· things are.
Can someone explain to me what am I doing wrong, please? I have this thing pending since I joined the comunity (yes, I am THAT dumb).
This post has been edited by rata: 03 October 2015 - 07:13 PM