We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 2042

Summary: OpenGL ES renderer tries to load OES functions unconditionally [patch]
Product: SDL Reporter: Gabriel Jacobo <gabomdq>
Component: renderAssignee: Gabriel Jacobo <gabomdq>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2    
Version: HG 2.0   
Hardware: x86_64   
OS: Linux   
Attachments: Dont fail if OES functions dont load

Description Gabriel Jacobo 2013-08-15 13:26:20 UTC 
Created attachment 1288 [details]
Dont fail if OES functions dont load

The OpenGL ES renderer tries to load OES functions and fails if they are not available. This is not the right behaviour as the renderer is capable of functioning without them (the Linux Nvidia binaries provide a GL ES context but these OES functions are not available). This becomes a problem with the common EGL code patch (bug #2037).

It also advertised SDL_RENDERER_TARGETTEXTURE despite the GL_OES_framebuffer_object extension not being present.
Comment 1 Sam Lantinga 2013-08-16 10:15:08 UTC 
The patch seems reasonable as far as it goes.  Are the OES functions only used in the streaming texture codepath?  Should they be checked for NULL at any point?

Target textures aren't an optional feature in the API at this point.  If there's no way to support them in the NVIDIA codepath we need to figure out an alternative.
Comment 2 Gabriel Jacobo 2013-08-16 10:20:19 UTC 
The rest of the OES functions are protected correctly by an extension check (AFAICT). We could add null checks but it would be redundant.

Target textures work fine with OpenGL ES2 with nVidia binaries, I think they just winged it with the ES 1.x support :)
Comment 3 Gabriel Jacobo 2013-08-16 12:39:42 UTC 
http://hg.libsdl.org/SDL/rev/303214c66577