this game uses software rendered voxels. the game generates a depth buffer and passes it to the clear image hardware for the voxels to make geometry (cars, flags, etc.) rendered with the 3d engine to go in front of and behind. when exiting the main engine, the game does not clear its 3d memory. but it _does_ set a depth buffer of frontmost on every pixel and continue passing it to the clear image hardware during the menu, which should prevent the cars from drawing.
the problem is that the real hardware renders 3d continuously, and changes to this depth buffer (which took effect while the screen was fading) happen immediately; whereas, in desmume, 3d renders only each time a frame is submitted by the 3d hardware. that means, in this case, that it never renders again, once the player enters the menu from in-game.
there are a few ways to fix this. one is to correctly emulate the constant-rendering that the hardware does. this is potentially somewhat costly.
next, the aforementioned approach could be made optional. while it fixes this one game, it isn't worth an option. if we find other games that need it, we may reconsider.
finally, we could detect the condition where flags have changed (even though the geometry has not) and take an opportunity to rerender, if so, each frame. But be careful--texture banks or contents may have changed also, since the geometry quit getting submitted, so all those conditions would have to trigger a re-render. I would prefer not to do this, since it is sort of bug city.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Great explanation. I think the first option is better, you can optimize Desmume for speed in later revisions. I'll check for other games by the same house.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
An interesting error, it appears only with JIT enabled, on 4407: the car is totally invisible and it is "shoot" foward and then the screen sometimes freak out on the ground. Without JIT there is no such problem but the music is completely stuck on the same 2 sec.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Serious regression on SVN 5189, now Desmume doesn't render the monster trucks at all on the top screen, only the desert environment. Tried with and without bios+firmware, tried disabling fog and line hacking but no effect. This problem affect OpenGL 3.2, old OpenGL and Softrasterizer. The problem has appeared between 5134 and 5189.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ATV Quad Frenzy (E) has the same problem (by the same company)
still present in svn 2643
game is playable
Still present on SVN2745. Maybe desmume doesn't flush correctly the memory?
Still present on SVN2840
Still present on SVN2902. Also now the music is corrupted, repeating same sound over and over.
Music is fixed but the original bug is still there on SVN3051
Still there on SVN3085.
still present in svn 3104
still present in svn 3299
Still present on SVN3455. Seems that DesMuMe can flush correctly the top screen from the 3D Data.
Still present on SVN3650
this game uses software rendered voxels. the game generates a depth buffer and passes it to the clear image hardware for the voxels to make geometry (cars, flags, etc.) rendered with the 3d engine to go in front of and behind. when exiting the main engine, the game does not clear its 3d memory. but it _does_ set a depth buffer of frontmost on every pixel and continue passing it to the clear image hardware during the menu, which should prevent the cars from drawing.
the problem is that the real hardware renders 3d continuously, and changes to this depth buffer (which took effect while the screen was fading) happen immediately; whereas, in desmume, 3d renders only each time a frame is submitted by the 3d hardware. that means, in this case, that it never renders again, once the player enters the menu from in-game.
there are a few ways to fix this. one is to correctly emulate the constant-rendering that the hardware does. this is potentially somewhat costly.
next, the aforementioned approach could be made optional. while it fixes this one game, it isn't worth an option. if we find other games that need it, we may reconsider.
finally, we could detect the condition where flags have changed (even though the geometry has not) and take an opportunity to rerender, if so, each frame. But be careful--texture banks or contents may have changed also, since the geometry quit getting submitted, so all those conditions would have to trigger a re-render. I would prefer not to do this, since it is sort of bug city.
Great explanation. I think the first option is better, you can optimize Desmume for speed in later revisions. I'll check for other games by the same house.
Still broken on svn3930
Forgot to say that during the game there is a new debug message :D:
"rasterizer rendering at y=192! oops!"
Same problem on SVN4074.
An interesting error, it appears only with JIT enabled, on 4407: the car is totally invisible and it is "shoot" foward and then the screen sometimes freak out on the ground. Without JIT there is no such problem but the music is completely stuck on the same 2 sec.
Same problem on SVN5040.
Same problem on SVN 5134. Tested also with the OpenGL 3.2 render mode.
Serious regression on SVN 5189, now Desmume doesn't render the monster trucks at all on the top screen, only the desert environment. Tried with and without bios+firmware, tried disabling fog and line hacking but no effect. This problem affect OpenGL 3.2, old OpenGL and Softrasterizer. The problem has appeared between 5134 and 5189.
Now the game is perfect with OpenGL 3.2 but flashes and makes desmume to crash with commit 242ccb2 from Github