GP2X Working Around Firmware 2.0.0 Flickering Issue


Epicenter

Well-Known Member
Joined
Oct 9, 2005
Messages
2,068
Age
39
Location
USA
Website
www.epicgaming.us or http
I've noted at least 2 programs, DrMDx and GnuBoy2x, experience an odd flickering issue. DrMDx in the menu, most obviously. This only occurs in Firmware 2.0.0 and reportedly some very old version I never used. Well, it wasn't long before I noticed something odd in a game engine I am developing.

When the game is allowed to draw to the screen at >56 FPS on my GP2X ('Second' Edition) or HydraLancer's First Edition at >30 FPS, there is black flickering on the display. When slowed, it vanishes! This seems very similar to that of emulator menus like DrMDx's animating one that seems to just run as fast as it can-- and might exceed the max framerate the LCD can operate at.

What exactly was changed? Some alteration to the display driver for the LCD controller in the Linux OS included with FW2.0.0? An alteration to the kernel?

My question is, what workaround was used to get rid of this flickering issue? I'd like to run this engine at a 'standard' 60 FPS without this obnoxious flickering. Thanks for any advice anyone can offer.
 
Epicenter posted on May 22 2006 at 09:05 PM said:
I've noted at least 2 programs, DrMDx and GnuBoy2x, experience an odd flickering issue. DrMDx in the menu, most obviously. This only occurs in Firmware 2.0.0 and reportedly some very old version I never used. Well, it wasn't long before I noticed something odd in a game engine I am developing.

When the game is allowed to draw to the screen at >56 FPS on my GP2X ('Second' Edition) or HydraLancer's First Edition at >30 FPS, there is black flickering on the display. When slowed, it vanishes! This seems very similar to that of emulator menus like DrMDx's animating one that seems to just run as fast as it can-- and might exceed the max framerate the LCD can operate at.

What exactly was changed? Some alteration to the display driver for the LCD controller in the Linux OS included with FW2.0.0? An alteration to the kernel?

My question is, what workaround was used to get rid of this flickering issue? I'd like to run this engine at a 'standard' 60 FPS without this obnoxious flickering. Thanks for any advice anyone can offer.
The "polarity" of the internal signal representing the vsync pulse changed, so code that waits for the vsync pulse before flipping may not work correctly any more. If you are accessing the hardware registers directly you can fix the code (there has been a thread or two about it before, I can post some code if you need it). If you are using a library such as SDL you'll need a new version of the library.
 
Last edited by a moderator:
@Epicenter: I fixed DrMD by removing the VSYNC code and quad buffering the menu instead. Are you using Rlyeh's SDK? or SDL? I'm using hacked version Rlyeh's SDK, which I changed to allow quad buffering in 16bit mode. I could apply the changes to Rlyeh's original code for you if your interested, just let me know.
 
is there a fix yet for sdl ? i mean is there a new compiled libary somewhere with the fix. i thought there wasn't any just yet.
 
I am using Paeryn's latest (I know of) SDL Library with hardware acceleration, as I have been. I utilize SDL_DOUBLEBUF (Double buffering) so yes, it should be waiting on the vertical refresh to draw to the display. I assume there is no fix in the SDL Library just yet.. I have PM'ed Paeryn about it, I hope he can give me a hand. What is this code to use as a workaround, and would it be at all compatible with an SDL application? I imagine it involves drawing directly to a framebuffer in some capacity.

Thanks for the help. (Sorry I didn't post this in the Developers' Corner, place seems a bit barren most of the time.)
 
Reesy posted on May 23 2006 at 09:10 AM said:
@Epicenter: I fixed DrMD by removing the VSYNC code and quad buffering the menu instead. Are you using Rlyeh's SDK? or SDL? I'm using hacked version Rlyeh's SDK, which I changed to allow quad buffering in 16bit mode. I could apply the changes to Rlyeh's original code for you if your interested, just let me know.

what code did you change to get the buffering working well and not flickering? currently working on something and blitting an image (stored in a gp2x_rect) on top of another is causing the top one to flicker which is annoying...
 
Last edited by a moderator:
xafier posted on May 27 2006 at 02:56 PM said:
Reesy posted on May 23 2006 at 09:10 AM said:
@Epicenter: I fixed DrMD by removing the VSYNC code and quad buffering the menu instead. Are you using Rlyeh's SDK? or SDL? I'm using hacked version Rlyeh's SDK, which I changed to allow quad buffering in 16bit mode. I could apply the changes to Rlyeh's original code for you if your interested, just let me know.

what code did you change to get the buffering working well and not flickering? currently working on something and blitting an image (stored in a gp2x_rect) on top of another is causing the top one to flicker which is annoying...

Well the normal code only double buffers, this causes a problem when not waiting for vblank before switching frame buffers. The flickering you see if the framebuffer being updated. Triple or quadruple buffering fixes this, I changed Rlyeh's code to allow quad buffering while in 16bit mode.
 
Last edited by a moderator:
Back
Top