#40453 - Ultima2876 - Mon Apr 18, 2005 11:44 pm
I've got a problem with my hblank routine. I'm trying to tilt a sprite like this:
http://img39.echo.cx/img39/9305/11tn.jpg
It works absolutely fine in emulators. But when I try it on hardware, it does this:
http://img39.echo.cx/img39/9711/23zn.jpg
It uses the REG_VCOUNT register to apply some pre-calculated settings to the scanline in question, using this code (in the hblank):
To reproduce the problem so that it happened on emulator (and subsequently fixed it on hardware), I did this:
Is REG_VCOUNT different on hardware or something? or could it be something else (emulator bug of some kind)? As you can see, there's no other sprites on those scanlines, so I highly doubt its a speed issue.
It does this in Boycott Advance, VisualBoy Advance and No$GBA...
And now for another related question - how could I fix this so that it looks right both on hardware and emulator? I've tried using various little "hacks" to make the game detect whether its running on emulator, but these don't work for all emulators (the main problematic one being VBA 1.8.0 Beta, which seems to have fixed all of these emulation "gaps"). So surely there's some small thing I'm missing?
More code is available if needed.
Thanks very much to anyone who can help.
http://img39.echo.cx/img39/9305/11tn.jpg
It works absolutely fine in emulators. But when I try it on hardware, it does this:
http://img39.echo.cx/img39/9711/23zn.jpg
It uses the REG_VCOUNT register to apply some pre-calculated settings to the scanline in question, using this code (in the hblank):
Code: |
CODE_IN_IWRAM void hblank_tilt(void)
{ ((u16*)0x070003E2)[0] = hsetting[REG_VCOUNT]; ((u16*)0x070003EA)[0] = hsetting1[REG_VCOUNT]; ((u16*)0x070003F2)[0] = hsetting2[REG_VCOUNT]; } |
To reproduce the problem so that it happened on emulator (and subsequently fixed it on hardware), I did this:
Code: |
CODE_IN_IWRAM void hblank_tilt(void)
{ ((u16*)0x070003E2)[0] = hsetting[REG_VCOUNT - 1]; ((u16*)0x070003EA)[0] = hsetting1[REG_VCOUNT - 1]; ((u16*)0x070003F2)[0] = hsetting2[REG_VCOUNT - 1]; } |
Is REG_VCOUNT different on hardware or something? or could it be something else (emulator bug of some kind)? As you can see, there's no other sprites on those scanlines, so I highly doubt its a speed issue.
It does this in Boycott Advance, VisualBoy Advance and No$GBA...
And now for another related question - how could I fix this so that it looks right both on hardware and emulator? I've tried using various little "hacks" to make the game detect whether its running on emulator, but these don't work for all emulators (the main problematic one being VBA 1.8.0 Beta, which seems to have fixed all of these emulation "gaps"). So surely there's some small thing I'm missing?
More code is available if needed.
Thanks very much to anyone who can help.