GP32 Double-buffer Help

[Pirotic]

Hiya, having some problems getting rid of the flicker on a few of my GP32 projects - and having to cap the framerate down to amend it, even with double buffering i get these horrible white flickering stripes down the right of the screen..

did a quick forum search to no avail, so if anybody has any advice - cheers!

 

[trooper]

I am in know way a coder (Unless you call writing a master mind game in Sam Coupe basic coding. :lol Have you tried triple buffering. I heard someone mention this a couple of days ago, On here.

Trooper

 

[Pirotic]

to be honest with you, i have no idea how/why tripple buffering even exists

i think it doesn't like the fact both buffers are at different memory address's and jumping between them is causing some sort of corruption (i may be totally wrong).

im using MiniGP32 dev kit

 

[Daz_Genetic]

Triple buffering exists for the very reason you mention. It works the same as double buffering except you have three video buffers and you then move your pointer between the three. Though you shouldn't need this unless you are updating the screen in a different thread. If your code is linear, double buffering is all you require because the screen buffer won't change until you have drawn everything and you update the pointer.

There is probably some other reason why you are getting corruption. Are you sure you are drawing to the offscreen buffer and not the one being displayed. It's a pretty easy mistake.

 

[Pirotic]

just double checked, and my nflips are correct - its drawing to two GPDRAWSURFACE's which are flipped correctly, so its always adding graphics to the unshown surface then flipping at the end of the operation.

i can reduce the flickering by getting rid of the buffer clearing but its not perfect, it tends to flicker the most when it isnt having to draw very much - when a scene is tied down with alot of sprites the flicker vanishs, almost like its updating too fast, so i cap the frame-rate but it still only reduces the problem.

strange,

 

[Saotome]

there was something very similar a few days ago. here
actually i think its the same problem, so it should help
(the solution is in the very last post - you dont have to go through the whole thread)

 

[MojoJojo]

I suspect this may be down to that pesky Samsung Writeback bug, which has been discussed many times on this board. It's most common symptom is crackly sound, but it can cause LCD flickering too.

Are you usign the SDK rectFill functions a lot ? They cause this bug to manifest.

 

[Pirotic]

hiya, i'll try to find some of the older posts -

removed all the rectfill commands, and it does seem to have helped a little, also adding triple buffering as we speak so hopefully i can raise the FPS slightly without tearing.

also thanks for that link, sadly im using my own customized version of the miniGP32 SDK and therefore cannot use that vblank code

Update: finished adding triple buffering, works a charm now - no tearing at all even with an unlocked framerate, problem solved thanks

 

[Robster]

Hey there - good to know that you've fixed the problem Pirotic

I do go on a bit around here about triple buffering, because the thing is that it works and it isn't actually any harder than double-buffering.

Would you be prepared to show us your flipping code, as a demonstration of how straightforward it is?

 

[Pirotic]

lol, my flipping code is 3 lines..

something like

nflip++;
if ((nflip + 1) > BUFFER_COUNT) nflip = 0;
showscreen(nflip);

whenever it creates/clears the buffers it takes the BUFFER_COUNT value into account, so changing to triple buffers was just a case of changing it from 2 to 3,

i used to just do that nflip = &01 thingy which would just toggle it between 0 and I, dunno if its possible to use that to go thru 3 tho

 

[Saotome]

how about this:

nflip = (nflip+1) % 3; //or nflip = (nflip+1) % BUFFER_COUNT;
showscreen(nflip);

one line saved :lol:
but actualy i think it would be slower (a division is slower than a compare&branch (not realy sure)). but it doesnt really matter since its only done once a frame

 

[Pirotic]

hehe thanks, i tend to try to use as little lines as possible, but seeing as the flip is in its own little subroutine out of the way i'll stick with my rather long-winded method (as it'll probably be fractionally quicker).

but thanks all the same, i'll remember how to do that (< new to C)

 

[Robster]

Cheers Pirotic, that's what I was after

by the way, if we're talking about micro-optimisations then avoid %, it's a very slow way of doing it.

And instead of

if ((nflip + 1) > BUFFER_COUNT) nflip = 0;

you can just do

if (nflip >= BUFFER_COUNT) nflip = 0;

which is definitely about 0.000001% faster

 

[Oankali]

Hi Pirotic.
I know that you have resolved your fickering problem but I have something that could interest you.
In my games I never had flickering problems until one day I tryed other clock speeds in Animings to see the diference.
Some clock speeds were absolutly smooth, while others made my screen flicker only on the right side of the screen.
Do you still have your old sources with double buffering? Can you try changing the clock speed and see what happens?
Actually my games works at 40mhz.

 

[Oankali]

By the way, if you say that you tend to use as little line as possible, you can change your code:

nflip++;
if ((nflip + 1) > BUFFER_COUNT) nflip = 0;
showscreen(nflip);

by this one (sol 1):

if (++nflip >= BUFFER_COUNT) nflip = 0;
showscreen(nflip);

or even this one (sol 2):

showscreen(nflip = (++nflip >= BUFFER_COUNT ? 0 : nflip));

Here are some tricks you can do with C, but my prefered solution is sol 1, more readable than sol 2.

 

[Pirotic]

neat code - thanks! thats 0.1% of my source-code fully optimized now

also i noticed that changing the clock speeds affected the flickering, but due to my projects requiring a rather high frame-rate the lower speeds made the game unplayable.