gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Hardware > REG_VCOUNT on hardware

#11513 - poslundc - Thu Oct 09, 2003 2:21 am

Does anyone know if REG_VCOUNT behaves differently on hardware than in emulation, in particular relating to the interlaced nature of the screen?

I've been trying to do a simple gradient ("sky") by changing a palette colour from the top of the screen to the bottom of the screen. I'm using HBlank interrupts and REG_VCOUNT to determine what colour to use.

It works fine in emulation, but on hardware the very first scanline flickers for the first 30 pixels or so.

I experimentally set it up so that it wouldn't start changing the background colour until the 10th line. Now the first ten lines flicker alternately (ie. interlaced), and the 11th line behaves the way the first line did before.

Here's the interrupt code:

Code:

skyLevel = gCamera.horizon - REG_VCOUNT + 1;

if ((REG_VCOUNT > 10) && (gCamera.horizon > REG_VCOUNT))
{
   BGPaletteMem[gSkyColourIndex] = gSkyValues[skyLevel];
}


Simple enough, huh? And it behaves as expected in emulation, but on hardware those first ten lines BEFORE it starts actually doing anything mysteriously flicker.

Because the flicker is interlaced I thought it might have something to do with how the GBA processes HBlank interrupts and calculates VCOUNT. Can anyone enlighten me?

Thanks,

Dan.

#11514 - tepples - Thu Oct 09, 2003 4:29 am

poslundc wrote:
Does anyone know if REG_VCOUNT behaves differently on hardware than in emulation, in particular relating to the interlaced nature of the screen?

No, it doesn't. The "interlacing" of the GBA screen isn't real interlacing. The GBA draws all scanlines in all frames, but in order to improve apparent LCD response times, the GBA draws every other scanline at what appears to be half brightness.

Quote:
It works fine in emulation, but on hardware the very first scanline flickers for the first 30 pixels or so.

First thirty pixels? Sounds like you're doing a mid-draw write to the palette. Try loading the first scanline's color during vblank.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#11515 - poslundc - Thu Oct 09, 2003 4:53 am

tepples wrote:
No, it doesn't. The "interlacing" of the GBA screen isn't real interlacing. The GBA draws all scanlines in all frames, but in order to improve apparent LCD response times, the GBA draws every other scanline at what appears to be half brightness.


Yeah, I know, but I'm at a loss to explain what could be causing this, so I'm leaning towards whatever crazy connections I can manufacture between the symptoms.

Quote:
First thirty pixels? Sounds like you're doing a mid-draw write to the palette. Try loading the first scanline's color during vblank.


Sorry, I should've mentioned that's already been taken care of. I'm very puzzled as to why the colour would only change partway through the scanline, since I know my HBlank interrupts are being called properly and aren't taking too long. (I literally commented everything out of the code except for pretty much what was above, so there's no way I'm using up all of my cycles - especially considering I was DMAing rot/scale data in before I commented the stuff out to debug.)

Dan.