Author Topic: How to properly initialize SDL?  (Read 2855 times)

pinkeen

  • Guest
How to properly initialize SDL?
« on: July 03, 2010, 02:39:28 am »
I wrote a simple SDL app to test performance of alpha-channeled blits, but when I first run it, it segfaults. The second time i run it (without reboot) sdl init fails with "Unable to open a console terminal"? What am I doing wrong. I tried initializing the screen with 16bits, 24bits, fullscreen, no fulscreen...

Or maybe the doublebuffering isn't supported? But double buffering can be done in pure software so I don't see the point...

Code is here:
http://pastebin.com/mivu3AAJ

UPdATE:

Okay, it was the double buffering. I turned it off and used SDL_UpdateRect instead of SDL_Flip and it runs fine. And there's no tearing... Is there some kind of simulated vsync?

Now I see why we don't need doublebuffering - SDL_UpdateRect pumps the data to the screen, you don't draw directly on the screen.

But when I switched to HWSURFACE images were distorted, flickering and stuff, why is that?

And what's the best way to directly access the video memory? cause I'd like to write a custom sw blitter (for my game creation framework) with all the goodnes of rotation, scaling, blending and stuff?

« Last Edit: July 03, 2010, 03:03:18 am by pinkeen »

Marisa-Chan

  • Posts: 12
Re: How to properly initialize SDL?
« Reply #1 on: July 03, 2010, 05:33:44 am »
SDL_Flip work's fine for me.
Try this code http://pastebin.com/yxdPLMQv
Only SWSURFACE, because all operations makes by CPU - GPU co-processor not present in dingoo.

mth

  • Posts: 317
Re: How to properly initialize SDL?
« Reply #2 on: July 21, 2010, 03:09:18 pm »
There are a number of different buffers between your program and the screen:
- in-memory surface of SDL when using a software surface
- the Linux frame buffer
- the GRAM of the ILI chip
You get tearing when the copy from one buffer to the next is not synchronized.

The design of A320 PCB does not allow reading of ILI registers, which makes it impossible to synchronize the transfer from the frame buffer to GRAM. Well, impossible is a big word, but the obvious solution doesn't work and so far no-one found a non-obvious solution. So, tearing is unavoidable here.

You control when SDL copies its in-memory buffer into the frame buffer by using SDL_Flip() or SDL_UpdateRect(). So here you can avoid tearing when using a software surface.

If you use a hardware surface, the in-memory surface does not exist and you write directly into the Linux frame buffer from your program. This means that changes you make to the picture can become visible at any moment. So if you paint in layers, it's possible the lower layer will be made visible before the upper layer is painted, resulting in flickering. If you paint in one go, there is no problem though and you gain some speed by not using an intermediate buffer and an extra copy step.

There is a bug in the SLCD driver in the 2.6.24 kernel that makes weird things (crashes, hangs etc) happen when using a hardware surface with double buffering. In OpenDingux this bug does not exist. Older versions of OpenDingux do not support double buffering, but recent versions do. The upload to GRAM is not synchronized yet to the page flip, so there might be glitches, but this is something that I plan to fix soonish. Even right now, the extra performance might be worth the occasional glitch.