Pandora Sdl 1.3, Glu And Nehe Opengl Tutorials For The Pandora

[Cpasjuste]

Hello there !

After a lot of work, i finally successfully writed an OpenGL ES pandora driver for the upcoming SDL 1.3 library.

The pandora video driver allow to use SDL 1.3 with OpenGL ES support under the framebuffer, but for now i didn't writed the input event part, so we need to add our own control system. This will be added to the pandora video driver soon, i bet before the official pandora release.

I also added OpenGL ES support for the x11 video driver, so we can use SDL 1.3 with OpenGL ES support under X, with input event working and all that crap. So it mean that this one is fully functionnal.

I contacted Sam, the author of the SDL library, this one confirmed me that we can dynamically link our application against SDL 1.3 for FREE, and that we can add this shared library for free in our Pandora firmware image. This mean that you can already start coding application under the SDL 1.3 library, it will be free for the pandora.

Note that all this work is done on the SVN library, but this one seems to be almost done for a release so it may not change a lot.

Here is the SDL 1.3 repository with Pandora support : http://github.com/Cpasjuste/SDL-13/tree


In the same time, i ported GLU library to the pandora, based on the "Mike Gorchak" QNX port (http://embedded.org.ua/opengles/lessons.html) so i was able to compile his Nehe OpenGL tutorials ports.
Here is the GLU repository with Pandora support, which need SDL 1.3 : http://github.com/Cpasjuste/GLU/tree

And here is the Nehe OpenGL tutorial compiled for the pandora (with sources) : http://mydedibox.fr/_stuff/sdl13_nehe.zip

If you want some screenshot of the tutorials, you can found them here : http://embedded.org.ua/opengles/lessons.html
All of them have been ported with success on the pandora.

See you !!!

 

[MWeston]

Wow, nice work!!

 

[Pickle]

Cpasjuste, this is great.

How is 1.3 different. In previous 1.2.X build opengl and software context's seem to separate, is this still the case with 1.3? Basically does any of the opengles power the normal software modes? Could normal SDL apps linked to 1.3 see any increase in speed?

I guess I need to find some documentation on 1.3 to get up to speed.

 

[Cpasjuste]

In fact SDL 13 have some new functions for rendering. When we use the 13 calls, all the blitting are done with openGL ES for us, and software for other platform. So when using the SDL 13 engine, yes we have a lot of power. Old SDL 1.2 calls (SDL_Blitsurface ..) are still here but use software rendering like the 1.2 one.

Having SDL 13 mean that we have a great openGL ES powered 2D library, and that all future application using the sdl 13 engine will be openGL ES accelerated on the pandora. Also the 1.3 engine is already working on the iphone, so people can easly develop application for the iphone and the pandora in the same time.

I was actually writing a 2D opengl Es library for the pandora, i will move it to SDL 1.3.

 

[Pickle]

are still here but use software rendering like the 1.2 one.

Having SDL 13 mean that we have a great openGL ES powered 2D library, and that all future application using the sdl 13 engine will be openGL ES accelerated on the pandora.

Yeah thats what I thought, very awesome!

 

[Cpasjuste]

I think porting SDL 1.2 2D applications to 1.3 should be very easy, i will try soon to see.

Also, you remember our problem of poor framerate under X with openGL ES ? I asked powerVr team about that, and they are already aware of this problem. It should be fixed in june with the EVM ! So for now SDL 13 under X is slower than under the framebuffer but should be fixed in june.

 

[Pickle]

I think porting SDL 1.2 2D applications to 1.3 should be very easy, i will try soon to see.

Also, you remember our problem of poor framerate under X with openGL ES ? I asked powerVr team about that, and they are already aware of this problem. It should be fixed in june with the EVM ! So for now SDL 13 under X is slower than under the framebuffer but should be fixed in june.

Great im glad they are on the problem.

 

[dockthepod]

Very cool. Is there a changelist somewhere for 1.2->1.3? I'm failing to find anything.

 

[senorgomez]

Noob question but whatever. This includes Open GL ES 2.0 not 1.x?


EDIT: P.S. Very exciting thread, I am about to start my own project (uni semester is over)

And to add, this is exactly what I (and other amateur developers) need, thanks a lot!

 

[lulzfish]

Not sure, but since the Pandora supports both and SDL programs don't really use GLSL, it shouldn't matter.

 

[Cpasjuste]

It use openGL ES 1.1.

If people want to start a project with SDL 1.3 for the pandora, you can compile the openGL desktop version of it, and use it on your desktop, As soon as you don't use any openGL call that are not provided with openGL ES, your project will run fine on the pandor. I'm actually working on a library that come on top of SDL 1.3, that should add some easy wrapper for rotation, scaling, TTF font rendering etc. I will try to release a premilary version very soon, maybe in the next week, so people can start coding !

 

[Yod4z]

I have heard that the SGX on the OMAP is not good at 2D things, is this right?

 

[JayFoxRox]

Can't be I think. Because if you look at OpenGL ES 2.0 you see that you have to do vertex transformation in the vertexshader. Not transforming it results in a 2D Primitive, transforming it results in a 3D primitive. In theory drawing the 2D Primitive should be faster because you don't have to multiple by a matrix. The only thing which could be the limiting factor here is that most 2D objects cover more screen and require more work in the fragmentshader (but then again, you can skip lighting) and bandwidth

 

[Adventus]

QUOTE
I have heard that the SGX on the OMAP is not good at 2D things, is this right?
A TBDR doesn't really gain you anything without a zbuffer because the fragment shader will still run on nonvisible fragments. Its still much quicker than software, you just don't get the zero overdraw advantage. If your billboarding and batching your primitives it should work fine.

In SuperLumenal i do all my transforms as a 2D matrix + displacement vector. Saves a lot over a full 4D matrix or 3d + displacement.... 8 vs 28 / 18 operations.

 

[Michoko]

Amazing work! Hardware accelerated SDL is just what we needed !

 

[benjymous]

Ok, so my current engine uses SDL1.2 to manage the creation of the OGL window, I use SDL_Image to load PNG images (then convert them into the OGL format myself), and old fashioned "newbie" glBegin/glEnd calls to draw textured blended quads.

If I switch to SDL1.3, do I just use it's internal "draw quad" functionality, and get all the GLES stuff handled for me? Will I still need to use SDL_Image for the png loading?

Also, can someone point me at a set of ready built Win32 binaries for SDL1.3? Last time I looked I could only find source repositories, that I got in a muddle trying to get to build!

 

[Cpasjuste]

, and old fashioned "newbie" glBegin/glEnd calls to draw textured blended quads.

If I switch to SDL1.3, do I just use it's internal "draw quad" functionality, and get all the GLES stuff handled for me? Will I still need to use SDL_Image for the png loading?

Also, can someone point me at a set of ready built Win32 binaries for SDL1.3? Last time I looked I could only find source repositories, that I got in a muddle trying to get to build!

Yes that is, you can use internal SDL 1.3 functions to render your textured blended quads. You still need SDL_image to load png.

Here is some sample exemple code on how it work :

Initialise the screen and the GL context/renderer :
CODE
SDL_Init(SDL_INIT_VIDEO);

windowID = SDL_CreateWindow("GLES2D",
SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, 800, 480,
SDL_WINDOW_RESIZABLE | SDL_WINDOW_OPENGL | SDL_WINDOW_SHOWN | SDL_WINDOW_FULLSCREEN );

SDL_CreateRenderer(windowID, -1, 0 );


Load a texture :
CODE
SDL_Surface *bmp_surface;

bmp_surface = IMG_Load( filename );

textureID = SDL_CreateTextureFromSurface( SDL_PIXELFORMAT_ABGR8888, bmp_surface);
SDL_SetTextureBlendMode( textureID, SDL_BLENDMODE_BLEND );

SDL_FreeSurface(bmp_surface);


Finally, render the texture :
CODE
SDL_RenderCopy( textureID, NULL, NULL );
SDL_RenderPresent();


Like you see, very easy.
I'm actually writing a cross platform 2D library based on sdl13, that should support linux desktop with openGL, i will try to make it windows compatible.

 

[Awakening]

I'm short on time here so I'll be brief. I'm learning SDL right now (when I have the time over) and this is great news! I also like the iPhone support of 1.3.

One question (don't know how well this works in 1.2): Can I scale and rotate my 2D sprites in hardware and get nice results without learning OGL?

 

[Cpasjuste]

: Can I scale and rotate my 2D sprites in hardware and get nice results without learning OGL?

Yes you can !

 

[Awakening]

Great! Thanks