SDL 2.0 on Pi?

[mlepage]

Is anyone going to be porting SDL 2.0 to Raspberry Pi?

It's near release, as the developers are basically only fixing release critical bugs now, so it would be a perfect time to get started.

[Joe Schmoe]

Can you tell us what sorts of advantages it would bring?

All I know about SDL is that it is used for DosBox and for QEMU. What else does it do?

[portets]

It's used in almost every major open source game project to provide an easy way for programmers to display 2d and 3d video, audio, input handling, loading of images/fonts.

SDL 2.0 brings easy to use hardware accelerated rendering of 2d material, which was more complicated before. I've heard SDL 2.0 is faster in a lot of other ways too, with many, many other various improvements. It also features better input handling and a unified force-feedback API.

I'm sure I'm missing a lot of new features here.

[Joe Schmoe]

Sounds good.

[JPDefault]

Hiya!
SDL 2.0 compiles on Raspbian with minimal modifications, I tried it a few days ago (took about 2-3 hours to compile).
The problem is that your SDL 1.2 applications will run slower on 2.0 unless you rewrite them using the new features (e.g. use SDL_Texture instead of SDL_Surface).

[crazysam]

Isn't pygame essentially an interface for SDL?
That means someone has some sweet binaries that they're not sharing

[ghans]

Is is SDL usable without hardware acceleration on the Pi ? This was a problem
for many people who ported apps , which itself are potable because of
SDL.


ghans

[gordon@drogon.net]

Is is SDL usable without hardware acceleration on the Pi ? This was a problem
for many people who ported apps , which itself are potable because of
SDL.


ghans

SDL is very usable on the Pi, but the standard interfaces aren't acellerated. However for my application, it ported by me simply typing 'make' and worked right away. Yes, it's a little slower than on my desktop, but tht's mostly due to the ARM processor being slower - my application is poking pixels for the most part - although the sprite handler would benefit from some sort of hardwar "blitter" type acelleration as done on some of the early 2D graphics cards...

-Gordon

[jethrogb]

I've got SDL 2.0 working with hardware acceleration without X. "patch" at http://jbeekman.nl/pub/sdl2_video_rpi.tbz . This is mostly the pandora code with modifications to make it work on the RPi. This is a huge hack, but it works. Events don't work, I'm not sure if I will be implementing those.

Besides SDL dependencies, you might also want to apt-get install mercurial build-essential .

To download, configure, build and install SDL:

Code: Select all

hg clone http://hg.libsdl.org/SDL
cd SDL
./autogen.sh
wget http://jbeekman.nl/pub/sdl2_video_rpi.tbz
tar xvjf sdl2_video_rpi.tbz
mkdir build
cd build
export CFLAGS="-I/opt/vc/include/ -I/opt/vc/include/interface/vcos/pthreads"
export LDFLAGS="-L/opt/vc/lib/"
../configure --prefix=`pwd`/install --without-x --disable-video-x11 --disable-x11-shared --disable-video-x11-xcursor --disable-video-x11-xinerama --disable-video-x11-xinput --disable-video-x11-xrandr --disable-video-x11-scrnsaver --disable-video-x11-xshape --disable-video-x11-vm --disable-video-opengl --disable-video-directfb --enable-video-opengles --enable-video-dummy
make
make install
# The binaries and includes are now located in SDL/build/install

SDL_image:

Code: Select all

hg clone http://hg.libsdl.org/SDL_image
cd SDL_image
./autogen.sh
mkdir build
cd build
../configure --prefix=`pwd`/../../SDL/build/install
make
make install
# The binaries and includes are now located in SDL/build/install

SDL_ttf (does not have hardware accelerated drawing):

Code: Select all

hg clone http://hg.libsdl.org/SDL_ttf
cd SDL_ttf
./autogen.sh
mkdir build
cd build
../configure --prefix=`pwd`/../../SDL/build/install --without-x
make
make install
# The binaries and includes are now located in SDL/build/install

You can change the prefix to /usr/local if you want to pollute your system. If you don't, it's probably easier to link statically.

[Vanfanel]

Awesome work, jethrogb!!
Accelerated X-less SDL is probably the best thing that could happen to the Raspberry Pi.

But I have some questions:

-If events are not working, how is input supposed to work?
-What do you mean by accelerated exactly? Image scaling, blitting, both? What backend did you use in the Pi's side?

Thanks!

[jethrogb]

Re: the events, assuming you are running this from a terminal, you can still use the terminal for input however you see fit. For example:

Code: Select all

#include <unistd.h>
#include <termios.h>
#include <fcntl.h>

int main ()
{
    struct termios old_terminal_settings, new_terminal_settings;

    //Disable line buffering, read STDIN char by char
    tcgetattr(0, &old_terminal_settings);
    memcpy(&new_terminal_settings, &old_terminal_settings, sizeof(struct termios));
    new_terminal_settings.c_lflag &= ~(ICANON|ECHO);
    new_terminal_settings.c_cc[VTIME] = 0;
    new_terminal_settings.c_cc[VMIN] = 1;
    tcsetattr(0, TCSANOW, &new_terminal_settings);
    fcntl(STDIN_FILENO, F_SETFL, fcntl(STDIN_FILENO, F_GETFL, 0) | O_NONBLOCK);

    //SDL init here

    while (!feof(stdin))
    {
        char ch;
        
        //SDL main loop here

        if (EOF!=(ch=getchar()))
        {
            //interpret ch here
        }
        else
        {
            //should check for errno==EAGAIN here, other errors might indicate real EOF
        }
    }

    tcsetattr(0, TCSANOW, &old_terminal_settings);

    //SDL finish here

    return 0;
}

It should also be possible to interpret mouse input from the terminal, but I'm not sure how. I think ncurses can do this (edit: yes, with gpm). Of course, this means you can't port existing software easily, but hey, it's a start.

Re: the acceleration. See http://www.raspberrypi.org/phpBB3/viewt ... 12#p148212 for SDL 2.0 HW acceleration features. SDL 2 supports OpenGL ES 2.0 for rendering out of the box. You turn surfaces into textures and render those (like blitting), see SDL 2.0 MigrationGuide and SDL_RenderCopyEx. There are other hardware accelerated functions, see SDL Wiki Category Render.

Edit: wow, links are invisible in this theme. Underlined for your convenience.

[Vortex code]

I have created a video and posted it on youtube showing how to download and setup SDL 2.0 for the raspberry pi on youtube.

Here is the link and please subscribe and share!

http://youtu.be/Yo7hO7GZ-ug

[bloodline]

I've got SDL 2.0 working with hardware acceleration without X. "patch" at http://jbeekman.nl/pub/sdl2_video_rpi.tbz . This is mostly the pandora code with modifications to make it work on the RPi. This is a huge hack, but it works. Events don't work, I'm not sure if I will be implementing those.

Thanks to your post, I can build SDL2.0 apps now, but I'm getting intriguing graphics corruption.

All SDL_RenderDraw* functions show the console framebuffer through... not sure if I'm doing something wrong here?

-Edit it seems as though there is some kind of blend mode active with the console frame buffer... I have tried to change it but to no avail.

[bloodline]

Ok, The blending modes seem to be messed up (or I don't under stand them properly).

To stop the Console/X11 framebuffer showing through you need to set this:

Code: Select all

SDL_SetRenderDrawBlendMode(renderer, SDL_BLENDMODE_BLEND);

Where renderer is the pointer to your renderer...

I'm now experimenting with the Texture blending modes to see what works correctly with these...

[bloodline]

The texture blend mode also needs to be set to blend, if you don't set the blend mode or set it to none, the console/X11 frame buffer shows through.

Also, I am only able to get 40fps (with very occasional little jumps up to my monitor's refresh rate) and this is with VSync on. Which looks jerky, not fluid at all

-Edit- Turning VSync off gets me 46 FPS... My monitor refresh is 60Hz so it really doesn't look nice

[jwzumwalt]

I just successfully got SDL2 up and running.
My instructions are located at http://www.raspberrypi.org/phpBB3/viewt ... 91&t=56756