ShuriZma
/
desmume
mirror of https://github.com/TASEmulators/desmume.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

handle powered-off geometry engine more sensibly. involves commit 66b5da1c and issue #31, intended to fix ZX advent. fixes #58.

This commit is contained in:
zeromus 2017-09-15 09:54:54 -05:00
parent d33faecd12
commit 759a039e25
2 changed files with 22 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
desmume/src/MMU.cpp
View File

@ -1772,7 +1772,10 @@ static u32 readreg_POWCNT1(const int size, const u32 adr) {
assert(false);
return 0;
}
static void writereg_POWCNT1(const int size, const u32 adr, const u32 val) {
static void writereg_POWCNT1(const int size, const u32 adr, const u32 val)
{
bool wasGeomEnabled = !!nds.power1.gfx3d_geometry;
switch(size)
{
case 8:
@ -1808,8 +1811,16 @@ static void writereg_POWCNT1(const int size, const u32 adr, const u32 val) {
writereg_POWCNT1(8,adr+1,(val>>8)&0xFF);
break;
}
//do we need to test this?
//gbatek: "When disabled, corresponding Ports become Read-only, corresponding (palette-) memory becomes read-only-zero-filled."
bool isGeomEnabled = !!nds.power1.gfx3d_geometry;
if(wasGeomEnabled && !isGeomEnabled)
{
//kill the geometry data when the power goes off
reconstruct(&gfx3d.state);
}
}
static INLINE void MMU_IPCSync(u8 proc, u32 val)
@ -3233,9 +3244,9 @@ void FASTCALL _MMU_ARM9_write08(u32 adr, u8 val)
if ((adr >= 0x04000008) && (adr <= 0x0400005F)) return;
if (nds.power1.gpuSub == 0)
if ((adr >= 0x04001008) && (adr <= 0x0400105F)) return;
if (nds.power_geometry == 0)
if (nds.power1.gfx3d_geometry == 0)
if ((adr >= 0x04000400) && (adr <= 0x040006FF)) return;
if (nds.power_render == 0)
if (nds.power1.gfx3d_render == 0)
if ((adr >= 0x04000320) && (adr <= 0x040003FF)) return;
if(MMU_new.is_dma(adr)) {
@ -3717,9 +3728,9 @@ void FASTCALL _MMU_ARM9_write16(u32 adr, u16 val)
if ((adr >= 0x04000008) && (adr <= 0x0400005F)) return;
if (nds.power1.gpuSub == 0)
if ((adr >= 0x04001008) && (adr <= 0x0400105F)) return;
if (nds.power_geometry == 0)
if (nds.power1.gfx3d_geometry == 0)
if ((adr >= 0x04000400) && (adr <= 0x040006FF)) return;
if (nds.power_render == 0)
if (nds.power1.gfx3d_render == 0)
if ((adr >= 0x04000320) && (adr <= 0x040003FF)) return;
if(MMU_new.is_dma(adr)) {
@ -4304,9 +4315,9 @@ void FASTCALL _MMU_ARM9_write32(u32 adr, u32 val)
if ((adr >= 0x04000008) && (adr <= 0x0400005F)) return;
if (nds.power1.gpuSub == 0)
if ((adr >= 0x04001008) && (adr <= 0x0400105F)) return;
if (nds.power_geometry == 0)
if (nds.power1.gfx3d_geometry == 0)
if ((adr >= 0x04000400) && (adr <= 0x040006FF)) return;
if (nds.power_render == 0)
if (nds.power1.gfx3d_render == 0)
if ((adr >= 0x04000320) && (adr <= 0x040003FF)) return;
// MightyMax: no need to do several ifs, when only one can happen

18
desmume/src/gfx3d.cpp
View File

@ -2344,19 +2344,9 @@ void gfx3d_VBlankEndSignal(bool skipFrame)
GPU->GetEventHandler()->DidRender3DEnd();
}
//try powering on geometry
if(!nds.power_geometry && nds.power1.gfx3d_geometry)
{
nds.power_geometry = TRUE;
}
else if(nds.power_geometry && !nds.power1.gfx3d_geometry)
{
//kill the geometry data when the power goes off
reconstruct(&gfx3d.state);
nds.power_geometry = FALSE;
}
//try powering on rendering. unclear whether there's anything very special about this
//try powering on rendering for the next frame.
//this is a wild guess. it isnt clear what various timings of powering off and on will affect whether a valid frame renders
//its also part of an old and probably bad guess.
if(!nds.power_render && nds.power1.gfx3d_render)
nds.power_render = TRUE;
else if(nds.power_render && !nds.power1.gfx3d_render)
@ -2368,7 +2358,7 @@ void gfx3d_VBlankEndSignal(bool skipFrame)
//But for that matter, so too could texture data. Do we continually re-render for that?
//Well, we have no evidence that anyone does this. (seems useful for an FMV, maybe)
//But also, for that matter, so too could CAPTURED DATA. Hopefully nobody does this.
//So, for now, we're calling this a hack for the clear iamge only.
//So, for now, we're calling this a hack for the clear image only.
//It will increase CPU load for apparently no purpose in some games which switch between heavy 3d and 2d.. and that also use clear images.. that seems unlikely.
//This could be a candidate for a per-game hack later if it proves unwieldy.
//Logic to determine whether the contents have changed (due to register changes or vram remapping to LCDC) are going to be really messy, but maybe workable if everything else wasn't so messy.