Menu
▾
▴
#722 quick press of A button cause screen flickering in game
using svn2848 & GI Joe - rise of the cobra, there is a long intro with text display from each character.
If you press A button when the text finish typing onto the screen, there is no flickering.
If you quick press A button to make text appear instantly, the top screen will flickerfor each quick press of the A button on the gamepad.
Another input issue ?
By the way, GI Joe will crash emu when it is about to go in-game.
Discussion
Anonymous
still the same for r2934
During the intro, if you quick press A button to get text to appear instantly instead of appearing by letter, the top screen will flicker and image is affected (see right image at the point of quick press and left image when all text has appeared).
If you let the text appear by itself, no flickering or image glitch.
Tested on clean r3042 with frameskip 0 @fps60.
In other games, you can quick press A to make text appear instantly and no such glitch.
my theory is that this is caused by the game misbehaving and swapping texture banks during the beginning of 3d drawing time. on the hardware this may manifest as a much smaller glitch, maybe in the first scanline only, or maybe as an invisibly tiny glitch. in desmume, since ALL rendering happens at that very moment, if the textures banks aren't given to 3d (given to cpu for uploading the finished text) then the entire frame will render untextured. This is the first time I have seen this behavior so it is worth keeping this around as remind.
To prove this you can change
if(nds.VCount==214)
to
if(nds.VCount==215)
in ndssystem.cpp which will fix the game.
I believe we have a one-off error in our entire scanline counting system. This may also account for glitches in scanline 0 of some games (nsmb does it sometimes)
Thanks zeromus.
You are right. tested and it works.
I will wait for the official fix before closing this issue.
Ehm...that fix is added to the code? On SVN3417 is the same problem.
I have changed my mind. I think this is just due to excessively tight timing, and an over-reaction due to an emulation quirk (if the textures arent ready at vcount=214 then the whole frame is blown). On real HW, only a few scanlines would get blown if textures arent ready at vcount=214. Now, the game has until vcount=262, which will fix this game as of r3422; I used to feel like this was an unacceptable hack, but I no longer do.
fixed in r3422.