Almost Done, Still One Little Issue

[deps]

Hello fellow GP2X developers!

It's near a release for my little project. Here's a pretty picture of it:



Still got one little problem. Sometimes the screen flickers. Must be when I call SDL_Flip but I'm not certain. It does this at irregular intervals, sometimes not at all. Haven't seen this on other games on my GP2X.

Is this a known bug in the devkit? Anyone else seen it?

 

[Blah]

Perhaps updating the whole screen every frame is too much for the '2x to handle...I guess you could try updating each sprite individually only when needed.

Show me your graphics code. Which devkit are you using?

 

[deps]

The graphics code? Might be a bit much to post here.
It all boils down to me blitting a Surface onto another, and then flipping that one using SDL_Flip(). Will do some more testing and code reading before I release it. Just wondered if someone else have had this little problem.

I'm using whatever devkit that comes with the Code::Block devkit bundle someone here is making.

 

[fawny]

Are you using SDL_HWSURFACE in the SDL_SetVideoMode call? If so try SDL_SWSURFACE. I have read that the hardware surface is always used in this implementation of SDL, either way, but have found that using SDL_HWSURFACE results in flicker while SDL_SWSURFACE does not.

 

[Squidge]

Flicker is normally caused by changing the contents of the display whilst the LCD is trying to display it. The solution is usually to only change the contents of the display whilst the LCD is doing nothing. So you draw everything to an invisible surface, and then blit it to the frame buffer on the vblank interval.

 

[fawny]

He is doing that. Surely SDL_Flip() should handle the vblank.

QUOTE
blitting a Surface onto another, and then flipping that one using SDL_Flip()


Just from observation, I am no techno-wizard, asking for SDL_HWSURFACE appears to ignore the vblank. I too am using yaustar's code::blocks setup. I don't know if that is the latest SDL release - perhaps there is something dodgy in that version ?

SDL_SWSURFACE does not flicker but is there a cost to performance ?

Are we missing some extra step that needs to be performed for SDL_HWSURFACE to work ?

 

[zacaj]

Would locking the surface help?

 

[Sphinxter]

My guess is you are using the graphic primitives of SDL to draw where you should be using SDL_gfx.
http://www.ferzkopp.net/joomla/content/view/19/14/

 

[yaustar]

I vaguely remember that problem, I think I had to call SDL_GP2X_WaitForBlitter(); after each blit to fix it. The problem is this function disappeared during an update of the SDL libraries which was annoying. I never did find the actual solution.

 

[Sphinxter]

In the first cut of fishball drawing the zoomed out ocean view entirely with SDL rectangles had me afraid of triggering seizures in the players.

 

[deps]

QUOTE
Are you using SDL_HWSURFACE in the SDL_SetVideoMode call?

Yes, I am. I can try to switch to SWSURFACE and see if I can spot a difference. But the flicker is not showing up every single time, so it might take a long time before I know if it helped.

QUOTE
Would locking the surface help?

Haven't tried it. Can give it a go tonight.

QUOTE
My guess is you are using the graphic primitives of SDL to draw where you should be using SDL_gfx.

I'm using some putpixel/getpixel code I found online, but only on surfaces that never touch the screen. The original code used an Allegro BITMAP* instead of an array to store the map. Don't ask me why, I didn't write it.
But if they are the root of the problem, wouldn't the screen flicker all the time and not, like now, once in 20-30 runs and just for a fraction of a second?

QUOTE
I vaguely remember that problem, I think I had to call SDL_GP2X_WaitForBlitter(); after each blit to fix it.

A bummer it disappeared. Might have been useful.