Opengl Es And Sdl Together?


GP2X_Coder

Member
Joined
May 17, 2006
Messages
220
Age
51
Location
USA
Website
mysite.verizon.net
Is it possible to link / run both OpenGL ES and SDL together ( at the same time ) on Pandora like it can be done on PC with OpenGL and SDL?

Any devs with boards try this yet?
 
GP2X_Coder said:
Is it possible to link / run both OpenGL ES and SDL together ( at the same time ) on Pandora like it can be done on PC with OpenGL and SDL?

It's been previously done: link.
 
Last edited by a moderator:
I was experimenting with this very thing yesterday.
SDL can't do the initialisation of OpenGL ES like it can do with full OpenGL, But you can just do the normal SDL screen initialisation, and then grab the OS native window/screen pointers from SDL and use those to initialise GLES (only about 10 extra lines of code). Then as long as you aren't stupid enough to try and use any of SDL's graphics functions after that, they will coexist quite happily, letting you use GLES for graphics and SDL for events/sound/etc.
 
deathterrapin said:
I was experimenting with this very thing yesterday.
SDL can't do the initialisation of OpenGL ES like it can do with full OpenGL, But you can just do the normal SDL screen initialisation, and then grab the OS native window/screen pointers from SDL and use those to initialise GLES (only about 10 extra lines of code). Then as long as you aren't stupid enough to try and use any of SDL's graphics functions after that, they will coexist quite happily, letting you use GLES for graphics and SDL for events/sound/etc.
That sounds great thanks for the post.
 
Last edited by a moderator:
I have a little question:

If I'm not wrong, Pandora will support Hardware Accelerated OpenGL ES... and OpenGL ES API is a subset of OpenGL API, right? There are a lot of well known game-engines that use OpenGL, so...

It would be possible making a OpenGL implementation that use Hardware Accelerated API for OpenGL ES functions and use a Software implementation for the rest of the OpenGL API? It would be fast enough?
 
David Gutiérrez Palma said:
I have a little question:

If I'm not wrong, Pandora will support Hardware Accelerated OpenGL ES... and OpenGL ES API is a subset of OpenGL API, right? There are a lot of well known game-engines that use OpenGL, so...

It would be possible making a OpenGL implementation that use Hardware Accelerated API for OpenGL ES functions and use a Software implementation for the rest of the OpenGL API? It would be fast enough?
OpenGL ES is a subset of OpenGL, but the things OpenGL ES lacks are the things that games doesn't use and are meant for industrial applications and so..

That's what I've understand..
 
Last edited by a moderator:
efegea said:
OpenGL ES is a subset of OpenGL, but the things OpenGL ES lacks are the things that games doesn't use and are meant for industrial applications and so..
It's nice to hear that. I've been googling and I think I've found some people has already done something similar to my idea:

http://sourceforge.net/projects/dogless/
http://downloads.sourceforge.net/dogless/D...mp;big_mirror=0

http://studierstube.icg.tu-graz.ac.at/klimt/index.php


I've also found other (maybe) interesting links:

http://sourceforge.net/projects/torus-3d/
http://www.manifestgames.com/Mobile/Ogre_P..._WhitePaper.pdf
http://www.gprt.ufpe.br/~grvm/pdfs/Artigos...06_Limaetal.pdf
 
Last edited by a moderator:
David Gutiérrez Palma said:
I have a little question:

If I'm not wrong, Pandora will support Hardware Accelerated OpenGL ES... and OpenGL ES API is a subset of OpenGL API, right? There are a lot of well known game-engines that use OpenGL, so...

It would be possible making a OpenGL implementation that use Hardware Accelerated API for OpenGL ES functions and use a Software implementation for the rest of the OpenGL API? It would be fast enough?

You could probably create a "miniGL" library layered on top of OpenGL ES that implements some of the features removed for ES. However, as soon as you'd have to keep around large memory buffers to implement a feature required by an engine, or actually have to do software rendering, it would be pointless. In that case porting the engine to OpenGL ES would be a much better idea.

efegea said:
OpenGL ES is a subset of OpenGL, but the things OpenGL ES lacks are the things that games doesn't use and are meant for industrial applications and so..

That is correct for most of the missing features but not for all of them.
 
Last edited by a moderator:
Back
Top