[SDL] Surface vs Texture - optimal usage

neoaggelos at gmail.com neoaggelos at gmail.com
Tue Oct 15 06:40:50 PDT 2013


There are three OpenGL backends because of the three major OpenGL 'versions': desktop OpenGL, OpenGL ES and OpenGL ES 2.

Currently, I strongly believe that none of those should be removed. 
- Desktop OpenGL is required for desktop systems.
- OpenGL ES 2 is the standard backend for Android and iOS.
- OpenGL ES exists to support older hardware, which do not support OpenGL ES 2. And yes, the transition from GL ES1 to GL ES2 is impossible for older hardware. If you search the internet, you will see that both are used actively (okay, OpenGL ES 2 is getting more and more popular, but you get the point).

For the next two or three years, keeping OpenGL ES 1 is required to be compatible with an audience as wide as possible. If it were removed, then, amongst other things, the minimum supported  iOS version would become 5.0, completely dropping support for pre-Lion systems.


On 15 Οκτ 2013, at 8:27 π.μ., "T. Joseph Carter" <tjcarter at spiritsubstance.com> wrote:

> I really like that SDL's render API can provide a stepping stone to OpenGL for 2D game developers.  It also makes a lot of old 2D SDL extension libraries available for use in OpenGL-using programs.
> 
> There's some gotchas there, however.  The notable one I have found is that if you're using the fixed function pipeline, you need to push the modelview matrix (and consequently the matrix mode) before you start drawing in 3D and pop it when you're done.  There may be other things that need preserving, but that's the one that stuck out at me.
> 
> If you even have a fixed function pipeline available to use, it's a good bet SDL's using it in its renderer.  Obviously it has to on GLESv1, but it also does so on the desktop (which means you're running in compatibility mode on the newest OpenGL versions—possibly a less optimized path going forward).
> 
> Preserving the modelview matrix is no biggie, but if there are more such major issues out there, it could quickly raise the learning curve.
> 
> (And I'm still not convinced 3 OpenGL render backends are actually necessary.  I get two—one for fixed function and one programmable, but it seems like the OpenGL ES versions ought to run fine using SDL's OpenGL abstraction.  Nothing in the render API needs anything GLES doesn't provide…)
> 
> Joseph
> 
> 
> On Mon, Oct 14, 2013 at 11:39:52AM -0400, Ryan C. Gordon wrote:
>> 
>>> What might seem like a boon in less-work-now will turn into a
>>> disappointing rewrite when you come to the polish step.
>> 
>> It depends on what you're doing. The intention for the Render API was two goals:
>> 
>> - Provide a reasonable path for modernizing 2D games (specifically: SDL 1.2 games). If one moves to the Render API, out of the box you get faster rendering, scaling, Steam Overlay support, Direct3D on Windows, GLES on iOS, etc.
>> 
>> - Make simple games simple to write. If all you want to do is write a Super Mario clone--which itself is a stretch goal when you're starting out--then you're going to drown if you work with OpenGL directly. I like that you can knock out a simple game really quickly with the Render API.
>> 
>> But you are right: you are absolutely going to hit limits quickly if you have larger rendering ambitions. That's sort of by design: the API meets its design goals without added complications, and we didn't want to build a full API that abstracts every other 3D API...for those cases, we made it easy to use the existing APIs themselves.
>> 
>> --ryan.
>> 
>> 
>> _______________________________________________
>> SDL mailing list
>> SDL at lists.libsdl.org
>> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
> _______________________________________________
> SDL mailing list
> SDL at lists.libsdl.org
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org



More information about the SDL mailing list