I've just been pillaging the SDL code-base looking at how you've implemented
source and destination rectangles for RenderCopy. I notice the code for
drawing texture subsections in SDL_render_gles.c and SDL_render_gl.c is
quite different. For OpenGL SDL uses the glBegin and glEnd tags rather than
using the same code everywhere, which is what I've been trying to do. Any
advantages to doing things this way? I remember being told a moment ago that
doing things the bare-bones "GLES way" with arrays of vertices was actually
more efficient (if less straightforward).
For subsections GLES_RenderCopy uses GL_TEXTURE_CROP_RECT_OES (part of
GLES/glext) which is not available for GL as far as I can tell. Is there any
way I might implement source rectangles in a unified way? Destination is not
so important, but to use sprite-sheets and textures atlases I need to be
able to grab a specific subsection of a texture to draw.
As always your collective graphics-programming expertise would be most
appreciated :)
Also SDL's code:
* vertices[0] = minx;
vertices[1] = miny;
vertices[2] = maxx;
vertices[3] = miny;
vertices[4] = minx;
vertices[5] = maxy;
vertices[6] = maxx;
vertices[7] = maxy;
texCoords[0] = minu;
texCoords[1] = minv;
texCoords[2] = maxu;
texCoords[3] = minv;
texCoords[4] = minu;
texCoords[5] = maxv;
texCoords[6] = maxu;
texCoords[7] = maxv;
glVertexPointer(2, GL_SHORT, 0, vertices);
glTexCoordPointer(2, GL_FLOAT, 0, texCoords);
glDrawArrays(GL_TRIANGLE_STRIP, 0, 4);*
My code:
* glVertexPointer(3, GL_FLOAT, 0, polygon);
glTexCoordPointer(2, GL_FLOAT, 0, skin);*
* // Top-left triangle
polygon = {-size.x/2,-size.y/2,0, size.x/2,-size.y/2,0,
size.x/2,size.y/2,0}; ///FIXME
skin = {0,0, 1,0, 1,1}; ///FIXME
glDrawArrays(GL_TRIANGLES, 0, 3);
// Bottom-right triangle
polygon = {-size.x/2,-size.y/2,0, -size.x/2,size.y/2,0,
size.x/2,size.y/2,0}; ///FIXME
skin = {0,0, 0,1, 1,1}; ///FIXME
glDrawArrays(GL_TRIANGLES, 0, 3);*
Advantages to doing everything at once (fewer calls?) + triangle strip
rather than triangles or triangle fan? Possible GL_SHORT makes more sense
for separating subsections that GL_FLOAT. I like being legible but
efficiency is the main aim here... I'll get rid of those array
initialisations - I don't like all the warnings I keep getting about them.
William
Post by Forest HaleI don't know about the SDL renderer for 2D games with regards to GLES2, but
SDL GLES2 works fine here after I fixed the CreateContext line in
SDLActivity.java to specify an appropriate list of attributes (requesting
the version I want).
Granted I've only tested on Tegra hardware here, but it works fine.
Post by William DyceI don't think the SDL port currently supports ES 2.0 at the moment. The
higher Android OS versions wouldn't display anything until I forced GLES 1.1
to be used instead: apparently as of Android 2.2
it's all GLES2 unless you specify otherwise.
I've stripped out all the calls GL-only now - apparently it should be more
efficient this way anyway (for desktop computers I mean). Android's still
not keep on texturing my polygons though: guessing
I'm still using something that doesn't work properly in the embedded
version. Other people have had similar issues - just type "android texture
http://www.gamedev.net/topic/**511985-texture-appearing-**black/<http://www.gamedev.net/topic/511985-texture-appearing-black/>
http://stackoverflow.com/**questions/4124708/opengl-**
textures-appear-just-black<http://stackoverflow.com/questions/4124708/opengl-textures-appear-just-black>
http://stackoverflow.com/**questions/6068903/**gldrawtexfoes-draws-black-
**texture-on-phone-and-correct-**in-emulator<http://stackoverflow.com/questions/6068903/gldrawtexfoes-draws-black-texture-on-phone-and-correct-in-emulator>
I'm confident that there's a solution to this - I'll share if I find it ;)
William
You really should drop glBegin/glEnd calls, specially if you plan to
move later on to OpenGL ES 2.0 devices, which don't support this
type of calls any longer.
I'm throwing in my own opengles questions hoping that someone will be
able to reply: from the documentation you can always found two
versions for every function, one is with floats and one is with fixed
integers (like glorthof and glorthox). A consensus on this subject
seems to be lacking, so which flavor gives the best performance on a
modern mobile gpu? -f or -x?
I can't speak for Andriod, but every iOS device (forever) has had a
FPU, so do NOT use fixed, it'll just slow it down. Stick with floats
(especially for vertex data.)
The next question is -- unsigned bytes for color data or floats?
That's something I'm about to try, so I can answer that question later. I
suspect unsigned bytes will be much faster (as
memory bandwidth is your big concern here.)
As for Williams question, I'd do a rewrite on my non-OpenGL ES
desktop application first -- go to VBOs for everything, first, and eliminate
all the glBegin/glEnd pairs. Make sure all your VBO
indexes fit in unsigned shorts (no unsigned int indexes in OpenGL
ES). You're going to want to do that before you even attempt a OpenGL ES
port.
[>] Brian
______________________________**___________________
SDL mailing list
http://lists.libsdl.org/__**listinfo.cgi/sdl-libsdl.org<http://lists.libsdl.org/__listinfo.cgi/sdl-libsdl.org><
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.org<http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org>
______________________________**_________________
SDL mailing list
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.org<http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org>
______________________________**_________________
SDL mailing list
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.org<http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org>
--
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/**
darkplaces <http://icculus.org/twilight/darkplaces>
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged
demo." - James Klass
"A game is a series of interesting choices." - Sid Meier
______________________________**_________________
SDL mailing list
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.org<http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org>