empathicqubit/Mesen-X
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

PPU: Tweaked sprite evaluation code to simulate another hardware glitch seen in the oam_flicker_test_reenable test

Browse source 
When rendering is enabled/disabled around scanlines 128-136, a single 8 pixel sliver of a sprite appears on the following scanline, due to the previously discovered bug where disabling rendering increments the oam address pointer by 1
This commit is contained in:
Sour 2020-05-01 20:06:56 -04:00
parent 8d5399a692
commit 77b4289299
1 changed files with 10 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

11
Core/PPU.cpp
View file

@ -1065,7 +1065,10 @@ void PPU::ProcessSpriteEvaluation()
_sprite0Added = true;
}
if(_spriteAddrL == 4) {
//Note: Using "(_secondaryOAMAddr & 0x03) == 0" instead of "_spriteAddrL == 0" is required
//to replicate a hardware bug noticed in oam_flicker_test_reenable when disabling & re-enabling
//rendering on a single scanline
if((_secondaryOAMAddr & 0x03) == 0) {
//Done copying all 4 bytes
_spriteInRange = false;
_spriteAddrL = 0;
@ -1373,6 +1376,12 @@ void PPU::UpdateState()
// if rendering is disabled on an odd cycle, the increment will wait until the next odd cycle (at which point it will be incremented by 1)
//In practice, there is no way to see the difference, so we just increment by 1 at the end of the next cycle after rendering was disabled
_state.SpriteRamAddr++;
//Also corrupt H/L to replicate a bug found in oam_flicker_test_reenable when rendering is disabled around scanlines 128-136
//Reenabling the causes the OAM evaluation to restart misaligned, and ends up generating a single sprite that's offset by 1
//such that it's Y=tile index, index = attributes, attributes = x, and X = the next sprite's Y value
_spriteAddrH = (_state.SpriteRamAddr >> 2) & 0x3F;
_spriteAddrL = _state.SpriteRamAddr & 0x03;
}
}