#165883 - strat - Sun Jan 11, 2009 11:00 am
Is it possible to modify a sprite immediately after the last scanline it's drawn and place it on the next scanline? The game I'm working on has the characters using three vertically arranged sprites.
Actually, I've been fumbling around with this. Should this do anything?
(in the interrupt handler)
if (REG_IF & IRQ_VBLANK) {
REG_IF = IRQ_VBLANK;
REG_IFBIOS = IRQ_VBLANK;
scanline = 0;
sprite0.ycoord = 0;
update_oam();
}
if (REG_IF & IRQ_HBLANK) {
REG_IF = IRQ_HBLANK;
scanline++;
if (scanline == 32)
sprite0.ycoord = 32;
update_oam();
}
#165890 - Dwedit - Sun Jan 11, 2009 5:02 pm
You can do it as long as you set the "HBlank Interval Free" bit in REG_DISPCNT. You will not be able to draw as many sprites on the scanline with that flag set, but you will be able to re-use sprites.
Also, try to use VCOUNT interrupts instead of HBLANK interrupts to compare scanlines to a specific number.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#165894 - strat - Sun Jan 11, 2009 8:40 pm
Using VCount now. Any idea why the sprite would cut off as the screen moves around, and why resetting its position during vblank and writing to oam doesn't work?
#165899 - strat - Mon Jan 12, 2009 8:09 am
hnn...here's what I've got now:
-one sprite changing position on two vcounts in one frame
-on vblank, the sprite should reset but it doesn't show up at the top
-however, scrolling to the edge of the map causes the situation to reverse. Now the sprite will show up at the top but not where the vcount handler sets it
#165905 - Miked0801 - Mon Jan 12, 2009 7:38 pm
Sounds like you are running both fat VBlanks and Fat HBlanks. If you're gonna be doing low level trickery like this, you need to be very, very concise with your code.
From your 2nd bullet point, if your sprite isn't showing up at the top, you've either got a fat vblank so that the position isn't being set in time, you you a math error.
Scrolling to the edge means your system is probably working less hard to show the map therefore it has time to properly display the VBlank version, but the HBlank could be getting overrun by something else. Try putting your HBlank sprites at least 1/2 way down the screen to make sure your VBlank code isn't clobbering it.
Another possibility is you have another interrupt running (or a very large DMA xfer) that is locking the CPU out from interrupts.
HBlank DMAs are probably a better way to modify sprite stuff per scanline - setup and modifiy a position table in VBlank and let it move your sprites around.
#165917 - strat - Tue Jan 13, 2009 12:58 am
I realized the screenblock updating routine was using too many cycles, and that's what cut off the sprite resetting. Putting the code in internal ram was enough for the moment.
#166595 - strat - Wed Feb 11, 2009 4:08 am
I went back to working on this and decided to report something that has a really obvious work-around but still pretty quirky.
In the HBlank handler, setting the sprite's new pos 1 scanline above where it's to be displayed will display it at the new position and not cut it off at the last position. This also works on no$. However, it cuts off the sprite on VBA.
Likewise, setting the sprite's new pos 2 scanlines above will display on GBA with no cutoff but on no$ there's a cutoff of one scanline.
Is it a quirk with the emulators or could it have something to do with the efficiency of the code?
In the meantime, #if is my friend here.
#166609 - Miked0801 - Wed Feb 11, 2009 8:02 pm
If it works on target and not emulator, you've found an emulator bug :P
#166612 - strat - Wed Feb 11, 2009 10:17 pm
Surprised no one's found it before.
Although I still wonder if it's something on my end, because this would've had to show up in commercial games.
Last edited by strat on Wed Feb 11, 2009 10:19 pm; edited 1 time in total
#166613 - Dwedit - Wed Feb 11, 2009 10:18 pm
Not as surprised, few people do sprite multiplexing.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#166643 - Miked0801 - Thu Feb 12, 2009 6:24 pm
Yep - 3D hardware has so many advantages in most cases that there's little need to resort to hblank trickery (as much).
#167042 - Ruben - Fri Feb 27, 2009 3:59 pm
Slightly old post.. but thought I'd post this:
Yeah, for some reason, VBA is off by one scanline compared to No$... I'm not sure about hardware, but I would think it works like No$.
Like.. for waiting for my routines to reach the topmost scanline, I'd usually go "while(REG_VCOUNT != 227)" but that screws up on VBA, cos it seems to not write the correct scanline there cos, if I remember right, REG_VCOUNT is off by 1 scanline.