Hi, everyone,
I port SDL to my two embedded systems (Cirrus’s EP9315 and Samsung’s
S3C2440 with Linux kernel 2.6.20.4).
My game initials SDL with HWSURFACE and DOUBLEBUF, and uses flip() to show
the screen . At top speed the FPS is 60, but the screen flickers
seriously. It does’nt flicker only under the speed of 33FPS.
If the game initials with SWSURFACE, it does’nt flickers.
I have also tried the SDL test program – testsprite. The same situation
occurs in testsprite.
If I run testsprite without any arguments, that is to say testsprite use
swsurface, it is so normal.
But I run it with the argument -hw -flip, the screen will flickers again.
As other says, doublebuff can avoids flickering, I find most puzzling
in this problem.
I have thought about this problem for weeks, but I still have no any ideas.
As other says, doublebuff can avoids flickering, I find most puzzling
in this problem.
Double buffering avoids flickering in system with a proper HWSURFACE and
VSYNC implementation, otherwise your best choice is to stick with a sofware
backbuffer (the default behaviour of SDL with 0 in the flags field).
I don’t know exactly the video driver you are using in your embedded system,
but the stock linux SDL doesn’t support HWSURFACEs and double buffering in
X11 enviroment.–
Bye,
Gabry
When I use SWSURFACE, the flip() costs about 20ms (64048016bit) and it
costs 0~1ms when I uses HWSURFACE.
Does this mean that the game has used HWSURFACE ?
And I ensure that it has enabled DOUBLEBUFF. As if I only draw the
background picture at the first frame, the screen will flickering with the
background picture and a black blackground alternately. If I draw the
background picture at the first and the second frame, the screen won’t
flickering with
the background picture and the black alternately.
Any idea could solve my problems besides using the SWSURFACE? The SURFACE
will drop down my framerate seriously.
Thank you.On Thu, Nov 13, 2008 at 6:36 PM, Gabriele Greco <gabriele.greco at darts.it>wrote:
As other says, doublebuff can avoids flickering, I find most puzzling
in this problem.
Double buffering avoids flickering in system with a proper HWSURFACE and
VSYNC implementation, otherwise your best choice is to stick with a sofware
backbuffer (the default behaviour of SDL with 0 in the flags field).
I don’t know exactly the video driver you are using in your embedded
system, but the stock linux SDL doesn’t support HWSURFACEs and double
buffering in X11 enviroment.
When I use SWSURFACE, the flip() costs about 20ms (64048016bit) and it
costs 0~1ms when I uses HWSURFACE.
In 20ms case the screen is memcpy() from software to hardware memory.
Does this mean that the game has used HWSURFACE ?
In 1ms case it is probably direct access to the framebuffer memory, skipping
software memory in whole.
I can see similar results on another 32bit embedded arch that has 320x240
8bpp. memcpy() of complete 320x240 surface results in ~28-30ms.
Somebody correct my observation if wrong…
And I ensure that it has enabled DOUBLEBUFF. As if I only draw the
background picture at the first frame, the screen will flickering with the
background picture and a black blackground alternately. If I draw the
background picture at the first and the second frame, the screen won’t
flickering with
the background picture and the black alternately.
Any idea could solve my problems besides using the SWSURFACE? The SURFACE
will drop down my framerate seriously.
Since you are using fbdev, see the code in SDL-1.2/src/video/fbcon/SDL_fbvideo.c,
for FB_WaitVBL(), FB_WaitIdle() and FB_FlipHWSurface().
I haven’t seen one fbdev driver that implements FBIOWAITRETRACE, in order to achive
the correct retrace. Though, it should not be hard to implement it, but it is
certainly hardware dependent.
HTH,
Hinko–
Hinko Ko?evar, OSS developer
?ETRTA POT, d.o.o.
Planina 3, 4000 Kranj, SI EU
tel ++386 (0) 4 280 66 03
e-mail @Hinko_Kocevar
http www.cetrtapot.si
Don’t just look at the cost for the flip, also look at the cost for
rendering the whole screen. The problem is that CPU writes to video
memory are slow. So when you have a hardware surface (in video memory)
it is possible that your rendering could become quite slow. While with
a software surface, you draw everything to system memory and only the
final copy accesses the (slow) video ram.
So really you have to balance how much you draw per frame vs the cost
of the flip. That problem doesn’t have an obvious solution…
StephaneOn Thu, Nov 13, 2008 at 15:40, JOE Lai wrote:
Hi, Gabriele,
My embedded system uses framebuffer(fbdev)
When I use SWSURFACE, the flip() costs about 20ms (64048016bit) and it
costs 0~1ms when I uses HWSURFACE.