Discussion:
GLES 1.1 <-> OpenGL 3.4 equivalent names/functions?
(too old to reply)
William Dyce
2011-08-05 08:01:57 UTC
Permalink
Hi guys,

I know this is a bit off topic since it's an OpenGL question, albeit OpenGL
within SDL (not that this makes any differences). It is also the result of
using GLES1.1 with SDL for Android, and most people developing SDL are
pretty OpenGL savvy. Feel free to flame me though if you object to this
hyjacking :-S

So: I'm using OpenGL 3.4 for Desktop machines and GLES 1.1 for mobiles, and
a few function names have changed, making compilation a bit tricky. For
instance, the android version wants *"glOrthof*" rather than
*"glOrtho"*(with no f). I'm thinking I might just use the preprocessor
to fix the
problem, for instance I could include for Android compilations:

*#define glOrtho(a,b,c,d,e,f) glOrthof(a,b,c,d,e,f)*

Trouble is I'm having a huge amount of trouble finding all the necessary
correspondences. Other names I need to "wrap" for the sake of compatibility
(because they don't appear in version 1.1) are:

- *GL_BGR*
- *GL_BGRA*
- *GL_QUADS*
- *glBegin*
- *glTexCoord2i*
- *glVertex3f*
- *glEnd*

Any idea what the equivalents might be, if there are any? Most resources
online seem to focus on later version of openGL :-/

Thanks,

William
William Dyce
2011-08-05 08:26:42 UTC
Permalink
Hang on, I just found this:
http://www.developer.nokia.com/Community/Wiki/Introduction_to_OpenGL_ES_1.0

Apparently GLES doesn't allow higher-level functions like glBegin() and
glEnd(), so I'll have to do everything the hard way :-S
Post by William Dyce
Hi guys,
I know this is a bit off topic since it's an OpenGL question, albeit OpenGL
within SDL (not that this makes any differences). It is also the result of
using GLES1.1 with SDL for Android, and most people developing SDL are
pretty OpenGL savvy. Feel free to flame me though if you object to this
hyjacking :-S
So: I'm using OpenGL 3.4 for Desktop machines and GLES 1.1 for mobiles, and
a few function names have changed, making compilation a bit tricky. For
instance, the android version wants *"glOrthof*" rather than *"glOrtho"*(with no f). I'm thinking I might just use the preprocessor to fix the
*#define glOrtho(a,b,c,d,e,f) glOrthof(a,b,c,d,e,f)*
Trouble is I'm having a huge amount of trouble finding all the necessary
correspondences. Other names I need to "wrap" for the sake of compatibility
- *GL_BGR*
- *GL_BGRA*
- *GL_QUADS*
- *glBegin*
- *glTexCoord2i*
- *glVertex3f*
- *glEnd*
Any idea what the equivalents might be, if there are any? Most resources
online seem to focus on later version of openGL :-/
Thanks,
William
Vittorio G.
2011-08-05 08:39:45 UTC
Permalink
Hi William,
using opengl and opengles is rather tricky but the end result is that
you'ra going to achieve a higher performance when running opengles
compatible code on desktop.
That being said, you need to change your opengl design a little, as
some the functions you listed are *not* present in opengles or are not
portable or are plainly discouraged. In opengl es you simply can't use
any glBegin / glEnd section at all, but rather you have to drive the
video card using vertex arrays (even better if they are buffered) and
then change the video card state.
As for GL_QUADS it was deprecated because a quad is just a pair of
triangles, so if you want to draw a square surface you'll need to draw
two triangles (this is a more efficient operation for embedded gpus).
Finally GL_BGR and GL_BGRA are simply two values that aren't really
present in gl-es headers and you'll need to use GL_BGR_EXT or supply
your own macro if you really want to use the bgr colorspace; they are
0x80e0 and 0x80e1 respectively.
One final note that doesn't come up from your topic is that you should
try to avoid using 3 color components functions (like glcolor3f) but
their 4 color components counterparts, which adds the alpha value. I'm
not sure this required by the specifications but will make your code
more portable anyways.


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?


Hope this helps.
Vittorio
Post by William Dyce
Hi guys,
I know this is a bit off topic since it's an OpenGL question, albeit OpenGL
within SDL (not that this makes any differences). It is also the result of
using GLES1.1 with SDL for Android, and most people developing SDL are
pretty OpenGL savvy. Feel free to flame me though if you object to this
hyjacking :-S
So: I'm using OpenGL 3.4 for Desktop machines and GLES 1.1 for mobiles, and
a few function names have changed, making compilation a bit tricky. For
instance, the android version wants "glOrthof" rather than "glOrtho" (with
no f). I'm thinking I might just use the preprocessor to fix the problem,
#define glOrtho(a,b,c,d,e,f) glOrthof(a,b,c,d,e,f)
Trouble is I'm having a huge amount of trouble finding all the necessary
correspondences. Other names I need to "wrap" for the sake of compatibility
GL_BGR
GL_BGRA
GL_QUADS
glBegin
glTexCoord2i
glVertex3f
glEnd
Any idea what the equivalents might be, if there are any? Most resources
online seem to focus on later version of openGL :-/
Thanks,
William
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
William Dyce
2011-08-05 08:53:10 UTC
Permalink
That's for the info Vittorio. I'd only included GL_BGR and _BGRA following a
tutorial: I've never used images encoded other than RGB or RGBA myself. I
might not bother. As for GL_QUADS, the
tutorial<http://www.developer.nokia.com/Community/Wiki/Introduction_to_OpenGL_ES_1.0>I
linked uses them but it appears that they're not supported for me. I'm
trying to draw a nice textures quad like so:

*glBegin(GL_QUADS);
glTexCoord2i(0, 0); glVertex3f(-16, -16, 0 ); // Top-left vertex
glTexCoord2i(1, 0); glVertex3f(16, -16, 0 ); // Bottom-left vertex
glTexCoord2i(1, 1); glVertex3f(16, 16, 0 ); // Bottom-right vertex
glTexCoord2i(0, 1); glVertex3f(-16, 16, 0); // Top-right vertex
glEnd();*

But I guess it's not going to be so simple in ES. Still, interesting to dig
a little deeper into all this :)

William
Post by Vittorio G.
Hi William,
using opengl and opengles is rather tricky but the end result is that
you'ra going to achieve a higher performance when running opengles
compatible code on desktop.
That being said, you need to change your opengl design a little, as
some the functions you listed are *not* present in opengles or are not
portable or are plainly discouraged. In opengl es you simply can't use
any glBegin / glEnd section at all, but rather you have to drive the
video card using vertex arrays (even better if they are buffered) and
then change the video card state.
As for GL_QUADS it was deprecated because a quad is just a pair of
triangles, so if you want to draw a square surface you'll need to draw
two triangles (this is a more efficient operation for embedded gpus).
Finally GL_BGR and GL_BGRA are simply two values that aren't really
present in gl-es headers and you'll need to use GL_BGR_EXT or supply
your own macro if you really want to use the bgr colorspace; they are
0x80e0 and 0x80e1 respectively.
One final note that doesn't come up from your topic is that you should
try to avoid using 3 color components functions (like glcolor3f) but
their 4 color components counterparts, which adds the alpha value. I'm
not sure this required by the specifications but will make your code
more portable anyways.
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?
Hope this helps.
Vittorio
Post by William Dyce
Hi guys,
I know this is a bit off topic since it's an OpenGL question, albeit
OpenGL
Post by William Dyce
within SDL (not that this makes any differences). It is also the result
of
Post by William Dyce
using GLES1.1 with SDL for Android, and most people developing SDL are
pretty OpenGL savvy. Feel free to flame me though if you object to this
hyjacking :-S
So: I'm using OpenGL 3.4 for Desktop machines and GLES 1.1 for mobiles,
and
Post by William Dyce
a few function names have changed, making compilation a bit tricky. For
instance, the android version wants "glOrthof" rather than "glOrtho"
(with
Post by William Dyce
no f). I'm thinking I might just use the preprocessor to fix the problem,
#define glOrtho(a,b,c,d,e,f) glOrthof(a,b,c,d,e,f)
Trouble is I'm having a huge amount of trouble finding all the necessary
correspondences. Other names I need to "wrap" for the sake of
compatibility
Post by William Dyce
GL_BGR
GL_BGRA
GL_QUADS
glBegin
glTexCoord2i
glVertex3f
glEnd
Any idea what the equivalents might be, if there are any? Most resources
online seem to focus on later version of openGL :-/
Thanks,
William
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Scott Percival
2011-08-05 09:08:24 UTC
Permalink
Also it's worth pointing out that your original desktop application
wouldn't be using OpenGL 3.4; partly because it doesn't exist yet, but
mostly because Khronos tried their darndest to kill off the fixed
pipeline in GL 3.1. What you're targeting is more OpenGL 1.5.

At a bare minimum, you're going to have to convert to buffers for your
geometry - so no glBegin, glEnd, or glVertex3f sadly. A good place to
start would be to look for an Android tutorial targeting GL ES 1.1.
Also the GL ES difference spec is a good reference if you get stuck -
http://www.khronos.org/registry/gles/specs/1.1/es_cm_spec_1.1.12.pdf

- Scott
Post by William Dyce
That's for the info Vittorio. I'd only included GL_BGR and _BGRA following a
tutorial: I've never used images encoded other than RGB or RGBA myself. I
might not bother. As for GL_QUADS, the tutorial I linked uses them but it
appears that they're not supported for me. I'm trying to draw a nice
glBegin(GL_QUADS);
    glTexCoord2i(0, 0); glVertex3f(-16, -16, 0 ); // Top-left vertex
    glTexCoord2i(1, 0); glVertex3f(16, -16, 0 ); // Bottom-left vertex
    glTexCoord2i(1, 1); glVertex3f(16, 16, 0 ); // Bottom-right vertex
    glTexCoord2i(0, 1); glVertex3f(-16, 16, 0); // Top-right vertex
glEnd();
But I guess it's not going to be so simple in ES. Still, interesting to dig
a little deeper into all this :)
William
Post by Vittorio G.
Hi William,
using opengl and opengles is rather tricky but the end result is that
you'ra going to achieve a higher performance when running opengles
compatible code on desktop.
That being said, you need to change your opengl design a little, as
some the functions you listed are *not* present in opengles or are not
portable or are plainly discouraged. In opengl es you simply can't use
any glBegin / glEnd section at all, but rather you have to drive the
video card using vertex arrays (even better if they are buffered) and
then change the video card state.
As for  GL_QUADS  it was deprecated because a quad is just a pair of
triangles, so if you want to draw a square surface you'll need to draw
two triangles (this is a more efficient operation for embedded gpus).
Finally GL_BGR and GL_BGRA are simply two values that aren't really
present in gl-es headers and you'll need to use GL_BGR_EXT or supply
your own macro if you really want to use the bgr colorspace; they are
0x80e0 and 0x80e1 respectively.
One final note that doesn't come up from your topic is that you should
try to avoid using 3 color components functions (like glcolor3f) but
their 4 color components counterparts, which adds the alpha value. I'm
not sure this required by the specifications but will make your code
more portable anyways.
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?
Hope this helps.
Vittorio
Post by William Dyce
Hi guys,
I know this is a bit off topic since it's an OpenGL question, albeit OpenGL
within SDL (not that this makes any differences). It is also the result of
using GLES1.1 with SDL for Android, and most people developing SDL are
pretty OpenGL savvy. Feel free to flame me though if you object to this
hyjacking :-S
So: I'm using OpenGL 3.4 for Desktop machines and GLES 1.1 for mobiles, and
a few function names have changed, making compilation a bit tricky. For
instance, the android version wants "glOrthof" rather than "glOrtho" (with
no f). I'm thinking I might just use the preprocessor to fix the problem,
#define glOrtho(a,b,c,d,e,f) glOrthof(a,b,c,d,e,f)
Trouble is I'm having a huge amount of trouble finding all the necessary
correspondences. Other names I need to "wrap" for the sake of compatibility
GL_BGR
GL_BGRA
GL_QUADS
glBegin
glTexCoord2i
glVertex3f
glEnd
Any idea what the equivalents might be, if there are any? Most resources
online seem to focus on later version of openGL :-/
Thanks,
William
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
William Dyce
2011-08-05 09:11:11 UTC
Permalink
Found 3.4 in another tutorial - that's a bit distressing :-S

You might be right Scott: now that I've read a bit more about this stuff I
reckon it's probably a better idea to do everything low-level and compatible
throughout. Hopefully the different platforms won't diverge too much from
eachother this way.

William
Post by Scott Percival
Also it's worth pointing out that your original desktop application
wouldn't be using OpenGL 3.4; partly because it doesn't exist yet, but
mostly because Khronos tried their darndest to kill off the fixed
pipeline in GL 3.1. What you're targeting is more OpenGL 1.5.
At a bare minimum, you're going to have to convert to buffers for your
geometry - so no glBegin, glEnd, or glVertex3f sadly. A good place to
start would be to look for an Android tutorial targeting GL ES 1.1.
Also the GL ES difference spec is a good reference if you get stuck -
http://www.khronos.org/registry/gles/specs/1.1/es_cm_spec_1.1.12.pdf
- Scott
Post by William Dyce
That's for the info Vittorio. I'd only included GL_BGR and _BGRA
following a
Post by William Dyce
tutorial: I've never used images encoded other than RGB or RGBA myself. I
might not bother. As for GL_QUADS, the tutorial I linked uses them but it
appears that they're not supported for me. I'm trying to draw a nice
glBegin(GL_QUADS);
glTexCoord2i(0, 0); glVertex3f(-16, -16, 0 ); // Top-left vertex
glTexCoord2i(1, 0); glVertex3f(16, -16, 0 ); // Bottom-left vertex
glTexCoord2i(1, 1); glVertex3f(16, 16, 0 ); // Bottom-right vertex
glTexCoord2i(0, 1); glVertex3f(-16, 16, 0); // Top-right vertex
glEnd();
But I guess it's not going to be so simple in ES. Still, interesting to
dig
Post by William Dyce
a little deeper into all this :)
William
Post by Vittorio G.
Hi William,
using opengl and opengles is rather tricky but the end result is that
you'ra going to achieve a higher performance when running opengles
compatible code on desktop.
That being said, you need to change your opengl design a little, as
some the functions you listed are *not* present in opengles or are not
portable or are plainly discouraged. In opengl es you simply can't use
any glBegin / glEnd section at all, but rather you have to drive the
video card using vertex arrays (even better if they are buffered) and
then change the video card state.
As for GL_QUADS it was deprecated because a quad is just a pair of
triangles, so if you want to draw a square surface you'll need to draw
two triangles (this is a more efficient operation for embedded gpus).
Finally GL_BGR and GL_BGRA are simply two values that aren't really
present in gl-es headers and you'll need to use GL_BGR_EXT or supply
your own macro if you really want to use the bgr colorspace; they are
0x80e0 and 0x80e1 respectively.
One final note that doesn't come up from your topic is that you should
try to avoid using 3 color components functions (like glcolor3f) but
their 4 color components counterparts, which adds the alpha value. I'm
not sure this required by the specifications but will make your code
more portable anyways.
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?
Hope this helps.
Vittorio
Post by William Dyce
Hi guys,
I know this is a bit off topic since it's an OpenGL question, albeit OpenGL
within SDL (not that this makes any differences). It is also the
result
Post by William Dyce
Post by Vittorio G.
Post by William Dyce
of
using GLES1.1 with SDL for Android, and most people developing SDL are
pretty OpenGL savvy. Feel free to flame me though if you object to
this
Post by William Dyce
Post by Vittorio G.
Post by William Dyce
hyjacking :-S
So: I'm using OpenGL 3.4 for Desktop machines and GLES 1.1 for
mobiles,
Post by William Dyce
Post by Vittorio G.
Post by William Dyce
and
a few function names have changed, making compilation a bit tricky.
For
Post by William Dyce
Post by Vittorio G.
Post by William Dyce
instance, the android version wants "glOrthof" rather than "glOrtho" (with
no f). I'm thinking I might just use the preprocessor to fix the problem,
#define glOrtho(a,b,c,d,e,f) glOrthof(a,b,c,d,e,f)
Trouble is I'm having a huge amount of trouble finding all the
necessary
Post by William Dyce
Post by Vittorio G.
Post by William Dyce
correspondences. Other names I need to "wrap" for the sake of compatibility
GL_BGR
GL_BGRA
GL_QUADS
glBegin
glTexCoord2i
glVertex3f
glEnd
Any idea what the equivalents might be, if there are any? Most
resources
Post by William Dyce
Post by Vittorio G.
Post by William Dyce
online seem to focus on later version of openGL :-/
Thanks,
William
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
William Dyce
2011-08-05 09:36:45 UTC
Permalink
Right, need to convert the GL_QUADS here into a GL_TRIANGLES. Perhaps 2
different calls, drawing the top-right and bottom-left corners?
*
glBindTexture(GL_TEXTURE_2D, image);

GLfloat box[] = {-16,-16,0, 16,-16,0, 16,16,0, -16,16,0};
GLfloat tex[] = {0,0, 1,0, 1,1, 0,1};

glEnableClientState(GL_VERTEX_ARRAY);
glEnableClientState(GL_TEXTURE_COORD_ARRAY);
glVertexPointer(3, GL_FLOAT, 0, box);
glTexCoordPointer(2, GL_FLOAT, 0, tex);
glDrawArrays(GL_QUADS, 0, 4);

glDisableClientState(GL_VERTEX_ARRAY);
glDisableClientState(GL_TEXTURE_COORD_ARRAY);*
Post by William Dyce
Found 3.4 in another tutorial - that's a bit distressing :-S
You might be right Scott: now that I've read a bit more about this stuff I
reckon it's probably a better idea to do everything low-level and compatible
throughout. Hopefully the different platforms won't diverge too much from
eachother this way.
William
Post by Scott Percival
Also it's worth pointing out that your original desktop application
wouldn't be using OpenGL 3.4; partly because it doesn't exist yet, but
mostly because Khronos tried their darndest to kill off the fixed
pipeline in GL 3.1. What you're targeting is more OpenGL 1.5.
At a bare minimum, you're going to have to convert to buffers for your
geometry - so no glBegin, glEnd, or glVertex3f sadly. A good place to
start would be to look for an Android tutorial targeting GL ES 1.1.
Also the GL ES difference spec is a good reference if you get stuck -
http://www.khronos.org/registry/gles/specs/1.1/es_cm_spec_1.1.12.pdf
- Scott
Post by William Dyce
That's for the info Vittorio. I'd only included GL_BGR and _BGRA
following a
Post by William Dyce
tutorial: I've never used images encoded other than RGB or RGBA myself.
I
Post by William Dyce
might not bother. As for GL_QUADS, the tutorial I linked uses them but
it
Post by William Dyce
appears that they're not supported for me. I'm trying to draw a nice
glBegin(GL_QUADS);
glTexCoord2i(0, 0); glVertex3f(-16, -16, 0 ); // Top-left vertex
glTexCoord2i(1, 0); glVertex3f(16, -16, 0 ); // Bottom-left vertex
glTexCoord2i(1, 1); glVertex3f(16, 16, 0 ); // Bottom-right vertex
glTexCoord2i(0, 1); glVertex3f(-16, 16, 0); // Top-right vertex
glEnd();
But I guess it's not going to be so simple in ES. Still, interesting to
dig
Post by William Dyce
a little deeper into all this :)
William
Post by Vittorio G.
Hi William,
using opengl and opengles is rather tricky but the end result is that
you'ra going to achieve a higher performance when running opengles
compatible code on desktop.
That being said, you need to change your opengl design a little, as
some the functions you listed are *not* present in opengles or are not
portable or are plainly discouraged. In opengl es you simply can't use
any glBegin / glEnd section at all, but rather you have to drive the
video card using vertex arrays (even better if they are buffered) and
then change the video card state.
As for GL_QUADS it was deprecated because a quad is just a pair of
triangles, so if you want to draw a square surface you'll need to draw
two triangles (this is a more efficient operation for embedded gpus).
Finally GL_BGR and GL_BGRA are simply two values that aren't really
present in gl-es headers and you'll need to use GL_BGR_EXT or supply
your own macro if you really want to use the bgr colorspace; they are
0x80e0 and 0x80e1 respectively.
One final note that doesn't come up from your topic is that you should
try to avoid using 3 color components functions (like glcolor3f) but
their 4 color components counterparts, which adds the alpha value. I'm
not sure this required by the specifications but will make your code
more portable anyways.
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?
Hope this helps.
Vittorio
Post by William Dyce
Hi guys,
I know this is a bit off topic since it's an OpenGL question, albeit OpenGL
within SDL (not that this makes any differences). It is also the
result
Post by William Dyce
Post by Vittorio G.
Post by William Dyce
of
using GLES1.1 with SDL for Android, and most people developing SDL
are
Post by William Dyce
Post by Vittorio G.
Post by William Dyce
pretty OpenGL savvy. Feel free to flame me though if you object to
this
Post by William Dyce
Post by Vittorio G.
Post by William Dyce
hyjacking :-S
So: I'm using OpenGL 3.4 for Desktop machines and GLES 1.1 for
mobiles,
Post by William Dyce
Post by Vittorio G.
Post by William Dyce
and
a few function names have changed, making compilation a bit tricky.
For
Post by William Dyce
Post by Vittorio G.
Post by William Dyce
instance, the android version wants "glOrthof" rather than "glOrtho" (with
no f). I'm thinking I might just use the preprocessor to fix the problem,
#define glOrtho(a,b,c,d,e,f) glOrthof(a,b,c,d,e,f)
Trouble is I'm having a huge amount of trouble finding all the
necessary
Post by William Dyce
Post by Vittorio G.
Post by William Dyce
correspondences. Other names I need to "wrap" for the sake of compatibility
GL_BGR
GL_BGRA
GL_QUADS
glBegin
glTexCoord2i
glVertex3f
glEnd
Any idea what the equivalents might be, if there are any? Most
resources
Post by William Dyce
Post by Vittorio G.
Post by William Dyce
online seem to focus on later version of openGL :-/
Thanks,
William
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Patrick Baggett
2011-08-05 14:44:45 UTC
Permalink
Use GL_TRIANGLE_STRIP instead of GL_QUADS in the example below. For the case
of n = 4 verts (2 tris) the data is identical (save, perhaps, winding/vertex
order, but that will be immediately obvious -- either it looks like a square
with a triangle cut out of the top or it disappears, either way, it is fix
once and done forever.)
Post by William Dyce
Right, need to convert the GL_QUADS here into a GL_TRIANGLES. Perhaps 2
different calls, drawing the top-right and bottom-left corners?
*
glBindTexture(GL_TEXTURE_2D, image);
GLfloat box[] = {-16,-16,0, 16,-16,0, 16,16,0, -16,16,0};
GLfloat tex[] = {0,0, 1,0, 1,1, 0,1};
glEnableClientState(GL_VERTEX_ARRAY);
glEnableClientState(GL_TEXTURE_COORD_ARRAY);
glVertexPointer(3, GL_FLOAT, 0, box);
glTexCoordPointer(2, GL_FLOAT, 0, tex);
glDrawArrays(GL_QUADS, 0, 4);
glDisableClientState(GL_VERTEX_ARRAY);
glDisableClientState(GL_TEXTURE_COORD_ARRAY);*
Post by William Dyce
Found 3.4 in another tutorial - that's a bit distressing :-S
You might be right Scott: now that I've read a bit more about this stuff I
reckon it's probably a better idea to do everything low-level and compatible
throughout. Hopefully the different platforms won't diverge too much from
eachother this way.
William
Post by Scott Percival
Also it's worth pointing out that your original desktop application
wouldn't be using OpenGL 3.4; partly because it doesn't exist yet, but
mostly because Khronos tried their darndest to kill off the fixed
pipeline in GL 3.1. What you're targeting is more OpenGL 1.5.
At a bare minimum, you're going to have to convert to buffers for your
geometry - so no glBegin, glEnd, or glVertex3f sadly. A good place to
start would be to look for an Android tutorial targeting GL ES 1.1.
Also the GL ES difference spec is a good reference if you get stuck -
http://www.khronos.org/registry/gles/specs/1.1/es_cm_spec_1.1.12.pdf
- Scott
Post by William Dyce
That's for the info Vittorio. I'd only included GL_BGR and _BGRA
following a
Post by William Dyce
tutorial: I've never used images encoded other than RGB or RGBA myself.
I
Post by William Dyce
might not bother. As for GL_QUADS, the tutorial I linked uses them but
it
Post by William Dyce
appears that they're not supported for me. I'm trying to draw a nice
glBegin(GL_QUADS);
glTexCoord2i(0, 0); glVertex3f(-16, -16, 0 ); // Top-left vertex
glTexCoord2i(1, 0); glVertex3f(16, -16, 0 ); // Bottom-left vertex
glTexCoord2i(1, 1); glVertex3f(16, 16, 0 ); // Bottom-right vertex
glTexCoord2i(0, 1); glVertex3f(-16, 16, 0); // Top-right vertex
glEnd();
But I guess it's not going to be so simple in ES. Still, interesting to
dig
Post by William Dyce
a little deeper into all this :)
William
Post by Vittorio G.
Hi William,
using opengl and opengles is rather tricky but the end result is that
you'ra going to achieve a higher performance when running opengles
compatible code on desktop.
That being said, you need to change your opengl design a little, as
some the functions you listed are *not* present in opengles or are not
portable or are plainly discouraged. In opengl es you simply can't use
any glBegin / glEnd section at all, but rather you have to drive the
video card using vertex arrays (even better if they are buffered) and
then change the video card state.
As for GL_QUADS it was deprecated because a quad is just a pair of
triangles, so if you want to draw a square surface you'll need to draw
two triangles (this is a more efficient operation for embedded gpus).
Finally GL_BGR and GL_BGRA are simply two values that aren't really
present in gl-es headers and you'll need to use GL_BGR_EXT or supply
your own macro if you really want to use the bgr colorspace; they are
0x80e0 and 0x80e1 respectively.
One final note that doesn't come up from your topic is that you should
try to avoid using 3 color components functions (like glcolor3f) but
their 4 color components counterparts, which adds the alpha value. I'm
not sure this required by the specifications but will make your code
more portable anyways.
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?
Hope this helps.
Vittorio
Post by William Dyce
Hi guys,
I know this is a bit off topic since it's an OpenGL question, albeit OpenGL
within SDL (not that this makes any differences). It is also the
result
Post by William Dyce
Post by Vittorio G.
Post by William Dyce
of
using GLES1.1 with SDL for Android, and most people developing SDL
are
Post by William Dyce
Post by Vittorio G.
Post by William Dyce
pretty OpenGL savvy. Feel free to flame me though if you object to
this
Post by William Dyce
Post by Vittorio G.
Post by William Dyce
hyjacking :-S
So: I'm using OpenGL 3.4 for Desktop machines and GLES 1.1 for
mobiles,
Post by William Dyce
Post by Vittorio G.
Post by William Dyce
and
a few function names have changed, making compilation a bit tricky.
For
Post by William Dyce
Post by Vittorio G.
Post by William Dyce
instance, the android version wants "glOrthof" rather than "glOrtho" (with
no f). I'm thinking I might just use the preprocessor to fix the problem,
#define glOrtho(a,b,c,d,e,f) glOrthof(a,b,c,d,e,f)
Trouble is I'm having a huge amount of trouble finding all the
necessary
Post by William Dyce
Post by Vittorio G.
Post by William Dyce
correspondences. Other names I need to "wrap" for the sake of compatibility
GL_BGR
GL_BGRA
GL_QUADS
glBegin
glTexCoord2i
glVertex3f
glEnd
Any idea what the equivalents might be, if there are any? Most
resources
Post by William Dyce
Post by Vittorio G.
Post by William Dyce
online seem to focus on later version of openGL :-/
Thanks,
William
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Brian Barnes
2011-08-05 13:02:21 UTC
Permalink
Post by Vittorio G.
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
Paulo Pinto
2011-08-05 14:03:08 UTC
Permalink
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.
Post by Vittorio G.
I'm throwing in my own opengles questions hoping that someone will be
Post by Vittorio G.
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>
William Dyce
2011-08-06 13:36:46 UTC
Permalink
I 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 black" into Google and you get
all kinds of stuff:
http://www.gamedev.net/topic/511985-texture-appearing-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

I'm confident that there's a solution to this - I'll share if I find it ;)

William
Post by Paulo Pinto
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.
Post by Vittorio G.
I'm throwing in my own opengles questions hoping that someone will be
Post by Vittorio G.
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>
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Forest Hale
2011-08-07 04:04:07 UTC
Permalink
I 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.
I 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
http://www.gamedev.net/topic/511985-texture-appearing-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
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>
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
--
LordHavoc
Author of DarkPlaces Quake1 engine - 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
William Dyce
2011-08-09 00:43:20 UTC
Permalink
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 Hale
I 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 Dyce
I 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>
Brian Barnes
2011-08-05 13:04:38 UTC
Permalink
umh speaking of offsets on ios, is it just me or the superview in
landscape-only mode cuts almost half of the screen from receiving
touch events? At least when you rotate the view you can sorta see a
black glitch that corresponds exactly to the area that is unsensitive
to the touches...
Did anybody else notice this?
I haven't had that problem. And I'm having second thoughts about the 20
pixel off problem because it's 20 pixels off on the X direction when in
landscape, so that either throws out the "top above the finger" bit or
something is not right somewhere.

dim3 on iOS is coming right along, so I'll be a good test bed for all
this stuff, and if you want to see what I'm doing, the code is open
source and free.

[>] Brian
Vittorio G.
2011-08-05 14:53:49 UTC
Permalink
No i was talking about another issue, the one that is addressed here:
http://forums.libsdl.org/viewtopic.php?t=7212&highlight=touch
Not sure what's wrong with that patch, but i hope a proper fix will be
pushed soon.

Cheers,
Vittorio
umh speaking of offsets on ios, is it just me or the superview in
landscape-only mode cuts almost half of the screen from receiving
touch events? At least when you rotate the view you can sorta see a
black glitch that corresponds exactly to the area that is unsensitive
to the touches...
Did anybody else notice this?
I haven't had that problem.  And I'm having second thoughts about the 20
pixel off problem because it's 20 pixels off on the X direction when in
landscape, so that either throws out the "top above the finger" bit or
something is not right somewhere.
dim3 on iOS is coming right along, so I'll be a good test bed for all this
stuff, and if you want to see what I'm doing, the code is open source and
free.
[>] Brian
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Scott Smith
2011-08-05 15:26:04 UTC
Permalink
Others have given you code to convert to your immediate mode quad to vertex
arrays. But here is some more info i think might help.

The first thing that is off from you think you using opengl 3.X, which you
really arnt. Opengl-ES 1.X is equivalent to Opengl 1.3. Opengl-ES 2.0 is closer
to Opengl 3.0. Anything >= 2.0 introduced the programmable pipeline. Anything <
2.0 is fixed pipline. So the point is your driver vendor may say its 3.X, but
really your targeting API specified for 1.X.
You can target OpenGL 1.3 and if you do not use any special API it will work on
ES variants. I assume from this point on that you plan to use the fixed pipline.
Here a list of ES 1.1 API that is use as a reference
http://www.khronos.org/opengles/documentation/opengles1_0/html/

Never use immediate mode (glBegin/glEnd) unless you want something quick for
debugging/testing.There are ways to use this API on ES hardware but it requires
using software wrappers that other developers have written. But dont go there if
you dont need to.

Use vertex arrays (add VBO/IBO's for boost in performance, all these do is allow
you to load your vertex data onto the GPU memory and update the vertex data as
little as possible. So if you had a static mesh, you load it into the vbo/ibo
and the data is in the GPU memory and it doesnt need to be updated from that
point on, since it is static. In my project I coded both paths where i can use
vertex arrays directly or through VBO's.
Good reference for vertex arrays:
http://www.songho.ca/opengl/gl_vertexarray.html
VBO/IBO's: http://www.songho.ca/opengl/gl_vbo.html

Keep your texture data simple, GL_RGB or GL_RGBA

In my personal project im currently working on, I went through roughly this
process. Learn the obj format for vertex data, Organize the obj data into
vertices (position/texcoords/color/normals) for vertex arrays (i use
glDrawArrays with GL_TRIANGLES). Add vbo's/ibos'. Learn how matrices can be used
to scale, rotate, translate the object. Add texturing to the obj format and into
the render routines. Learn how matrices can be used to set the projection and
modelview matrices for camera effects. This is the current method i use for
static models, things would need to change for dynamic vertex data.

One word on matrices, i dont use the opengl API, other than glLoadMatrix. I use
math library CML: http://cmldev.net/. It has worked really well for me, and i
suggest using it or something like it as the matrix API is deprecated with the
programmable pipline.





________________________________
From: William Dyce <***@gmail.com>
To: SDL Development List <***@lists.libsdl.org>
Sent: Fri, August 5, 2011 4:01:57 AM
Subject: [SDL] GLES 1.1 <-> OpenGL 3.4 equivalent names/functions?

Any idea what the equivalents might be, if there are any? Most resources online
seem to focus on later version of openGL :-/

Thanks,

William
RodrigoCard
2011-08-05 15:50:03 UTC
Permalink
About glBegin/End

you can change this:

glBegin(GL_TRIANGLES);
glVertex3f(1,0,0);
glVertex3f(0,1,0);
glVertex3f(-1,0,0);
glEnd();

with this:

GLfloat vertices[] = {1,0,0, 0,1,0, -1,0,0};
glEnableClientState(GL_VERTEX_ARRAY);
glVertexPointer(3, GL_FLOAT, 0, vertices);
glDrawArrays(GL_TRIANGLES, 0, 3);
glDisableClientState(GL_VERTEX_ARRAY);

a brief explanation is avaible here:
http://pandorawiki.org/OpenGL_ES_1.1_Tutorial

see ya.
William Dyce
2011-08-06 04:17:53 UTC
Permalink
I've rewritten my draw calls so they're GLES1.1 compatible, though I still
have to cheat for the glOrtho/glOrthof problem. Here's my minimal code:
http://pastebin.com/0aZc4pk4
This code assumes you have a file "image.png" in a "data/" folder: use the
data.sh script provided with the Android port to push it to the device. I'll
try to attach the one I use to this message.

The problem is the exact same problem I was having using the high-level SDL
Renderer stuff: the image draws Linux, but instead of blitting with
transparency I get a white background around the image. On the Android (both
HW and emulated) *I only get the white box, with no image at all*.

I'd hoped that dropping to a lower level might solve the problem, but
there's nothing to this code and it still doesn't want to play ball. I'm
completely at a loss now :-( Does anybody have any idea why this might be
happening?

William
Post by RodrigoCard
**
About glBegin/End
glBegin(GL_TRIANGLES);
glVertex3f(1,0,0);
glVertex3f(0,1,0);
glVertex3f(-1,0,0);
glEnd();
GLfloat vertices[] = {1,0,0, 0,1,0, -1,0,0};
glEnableClientState(GL_VERTEX_ARRAY);
glVertexPointer(3, GL_FLOAT, 0, vertices);
glDrawArrays(GL_TRIANGLES, 0, 3);
glDisableClientState(GL_VERTEX_ARRAY);
http://pandorawiki.org/OpenGL_ES_1.1_Tutorial
see ya.
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
William Dyce
2011-08-06 04:46:42 UTC
Permalink
Same problem, possibly:
http://stackoverflow.com/questions/3476348/how-to-use-textures-in-android-ndk-with-opengl-es-2-0
Post by William Dyce
I've rewritten my draw calls so they're GLES1.1 compatible, though I still
http://pastebin.com/0aZc4pk4
This code assumes you have a file "image.png" in a "data/" folder: use the
data.sh script provided with the Android port to push it to the device. I'll
try to attach the one I use to this message.
The problem is the exact same problem I was having using the high-level SDL
Renderer stuff: the image draws Linux, but instead of blitting with
transparency I get a white background around the image. On the Android (both
HW and emulated) *I only get the white box, with no image at all*.
I'd hoped that dropping to a lower level might solve the problem, but
there's nothing to this code and it still doesn't want to play ball. I'm
completely at a loss now :-( Does anybody have any idea why this might be
happening?
William
Post by RodrigoCard
**
About glBegin/End
glBegin(GL_TRIANGLES);
glVertex3f(1,0,0);
glVertex3f(0,1,0);
glVertex3f(-1,0,0);
glEnd();
GLfloat vertices[] = {1,0,0, 0,1,0, -1,0,0};
glEnableClientState(GL_VERTEX_ARRAY);
glVertexPointer(3, GL_FLOAT, 0, vertices);
glDrawArrays(GL_TRIANGLES, 0, 3);
glDisableClientState(GL_VERTEX_ARRAY);
http://pandorawiki.org/OpenGL_ES_1.1_Tutorial
see ya.
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
John Magnotti
2011-08-06 05:46:52 UTC
Permalink
I haven't done anything with opengl-es, but when I've used
transparency in opengl I've always specified the blending function to
use. something like:

glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);


for more details:
http://www.khronos.org/opengles/documentation/opengles1_0/html/glBlendFunc.html

hope that helps,

John
Post by William Dyce
http://stackoverflow.com/questions/3476348/how-to-use-textures-in-android-ndk-with-opengl-es-2-0
Post by William Dyce
I've rewritten my draw calls so they're GLES1.1 compatible, though I still
http://pastebin.com/0aZc4pk4
This code assumes you have a file "image.png" in a "data/" folder: use the
data.sh script provided with the Android port to push it to the device. I'll
try to attach the one I use to this message.
The problem is the exact same problem I was having using the high-level
SDL Renderer stuff: the image draws Linux, but instead of blitting with
transparency I get a white background around the image. On the Android (both
HW and emulated) I only get the white box, with no image at all.
I'd hoped that dropping to a lower level might solve the problem, but
there's nothing to this code and it still doesn't want to play ball. I'm
completely at a loss now :-( Does anybody have any idea why this might be
happening?
William
Post by RodrigoCard
About glBegin/End
glBegin(GL_TRIANGLES);
glVertex3f(1,0,0);
glVertex3f(0,1,0);
glVertex3f(-1,0,0);
glEnd();
GLfloat vertices[] = {1,0,0, 0,1,0, -1,0,0};
glEnableClientState(GL_VERTEX_ARRAY);
glVertexPointer(3, GL_FLOAT, 0, vertices);
glDrawArrays(GL_TRIANGLES, 0, 3);
glDisableClientState(GL_VERTEX_ARRAY);
http://pandorawiki.org/OpenGL_ES_1.1_Tutorial
see ya.
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
William Dyce
2011-08-06 05:58:15 UTC
Permalink
Well that works for Desktop Linux, thanks John. Android is still drawing me
the white square though :-/
Post by John Magnotti
I haven't done anything with opengl-es, but when I've used
transparency in opengl I've always specified the blending function to
glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
http://www.khronos.org/opengles/documentation/opengles1_0/html/glBlendFunc.html
hope that helps,
John
http://stackoverflow.com/questions/3476348/how-to-use-textures-in-android-ndk-with-opengl-es-2-0
Post by William Dyce
Post by William Dyce
I've rewritten my draw calls so they're GLES1.1 compatible, though I
still
Post by William Dyce
Post by William Dyce
http://pastebin.com/0aZc4pk4
This code assumes you have a file "image.png" in a "data/" folder: use
the
Post by William Dyce
Post by William Dyce
data.sh script provided with the Android port to push it to the device.
I'll
Post by William Dyce
Post by William Dyce
try to attach the one I use to this message.
The problem is the exact same problem I was having using the high-level
SDL Renderer stuff: the image draws Linux, but instead of blitting with
transparency I get a white background around the image. On the Android
(both
Post by William Dyce
Post by William Dyce
HW and emulated) I only get the white box, with no image at all.
I'd hoped that dropping to a lower level might solve the problem, but
there's nothing to this code and it still doesn't want to play ball. I'm
completely at a loss now :-( Does anybody have any idea why this might
be
Post by William Dyce
Post by William Dyce
happening?
William
Post by RodrigoCard
About glBegin/End
glBegin(GL_TRIANGLES);
glVertex3f(1,0,0);
glVertex3f(0,1,0);
glVertex3f(-1,0,0);
glEnd();
GLfloat vertices[] = {1,0,0, 0,1,0, -1,0,0};
glEnableClientState(GL_VERTEX_ARRAY);
glVertexPointer(3, GL_FLOAT, 0, vertices);
glDrawArrays(GL_TRIANGLES, 0, 3);
glDisableClientState(GL_VERTEX_ARRAY);
http://pandorawiki.org/OpenGL_ES_1.1_Tutorial
see ya.
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
William Dyce
2011-08-06 15:01:56 UTC
Permalink
Got it working :D

I'd been playing around with glGetError(), which I probably should have been
doing ages ago (what a silly cuss). The following line:

* glTexImage2D(GL_TEXTURE_2D, 0, n_colours, surface->w, surface->h, 0,
format, GL_UNSIGNED_BYTE, surface->pixels);*

Generated a *GL_INVALID_OPERATION* error, which means... well, it could mean
many different things. The two things I'm not sure about are *
GL_UNSIGNED_BYTE* (I think this is just the format SDL loads images with
though) and the what that we use *GL_RGB/GL_RGBA* for the *format* and the
number of colours (*3 or 4* respectively) for the *internal format*. I
wasn't convinced that the (3==GL_RGB && 4==GL_RGBA) was true so I tested it.
As a matter of fact:
*GL_RGB = 6407 != 3*
*GL_RGBA = 6408 != 4*

I decided to put the enum in both places rather than using the n_of_colours
for the internal format. Now the Android is happily drawing the texture :D

The moral to the story: don't be a silly cuss, don't blindly copy-paste
things off the internet and use glGetError() liberally to begin with!
*
*William*

*
Post by William Dyce
Well that works for Desktop Linux, thanks John. Android is still drawing me
the white square though :-/
Post by John Magnotti
I haven't done anything with opengl-es, but when I've used
transparency in opengl I've always specified the blending function to
glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
http://www.khronos.org/opengles/documentation/opengles1_0/html/glBlendFunc.html
hope that helps,
John
http://stackoverflow.com/questions/3476348/how-to-use-textures-in-android-ndk-with-opengl-es-2-0
Post by William Dyce
Post by William Dyce
I've rewritten my draw calls so they're GLES1.1 compatible, though I
still
Post by William Dyce
Post by William Dyce
http://pastebin.com/0aZc4pk4
This code assumes you have a file "image.png" in a "data/" folder: use
the
Post by William Dyce
Post by William Dyce
data.sh script provided with the Android port to push it to the device.
I'll
Post by William Dyce
Post by William Dyce
try to attach the one I use to this message.
The problem is the exact same problem I was having using the high-level
SDL Renderer stuff: the image draws Linux, but instead of blitting with
transparency I get a white background around the image. On the Android
(both
Post by William Dyce
Post by William Dyce
HW and emulated) I only get the white box, with no image at all.
I'd hoped that dropping to a lower level might solve the problem, but
there's nothing to this code and it still doesn't want to play ball.
I'm
Post by William Dyce
Post by William Dyce
completely at a loss now :-( Does anybody have any idea why this might
be
Post by William Dyce
Post by William Dyce
happening?
William
Post by RodrigoCard
About glBegin/End
glBegin(GL_TRIANGLES);
glVertex3f(1,0,0);
glVertex3f(0,1,0);
glVertex3f(-1,0,0);
glEnd();
GLfloat vertices[] = {1,0,0, 0,1,0, -1,0,0};
glEnableClientState(GL_VERTEX_ARRAY);
glVertexPointer(3, GL_FLOAT, 0, vertices);
glDrawArrays(GL_TRIANGLES, 0, 3);
glDisableClientState(GL_VERTEX_ARRAY);
http://pandorawiki.org/OpenGL_ES_1.1_Tutorial
see ya.
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Ryan C. Gordon
2011-08-06 18:51:39 UTC
Permalink
format_. I wasn't convinced that the (3==GL_RGB && 4==GL_RGBA) was true
*GL_RGB = 6407 != 3*
*GL_RGBA = 6408 != 4*
Legacy OpenGL allows you to specify 3 or 4 (presumably for backwards
compatibility with IrixGL or something) and have it map to GL_RGB and
GL_RGBA, respectively. I wouldn't be surprised if GLES got rid of that.

--ryan.
Forest Hale
2011-08-07 04:09:42 UTC
Permalink
The rule with GLES is: internalformat == format.

There is *absolutely no* conversion capability in GLES2, you must do any pixel conversions yourself before upload.

This includes the removal of the legacy 1-4 types, you must use GL_ALPHA, GL_LUMINANCE_ALPHA, GL_RGB, GL_RGBA, and then be sure to use the correct type parameter (such as GL_UNSIGNED_BYTE).

GL_UNSIGNED_BYTE is correct for 888 (GL_RGB/GL_BGR) and 8888 formats (GL_RGBA/GL_BGRA).

GL_BGR and GL_BGRA are extensions on GLES and I don't really recommend relying on them.

Aside from GL_UNSIGNED_BYTE you may find types like GL_UNSIGNED_SHORT_5_5_5_1 to be of some use for faster rendering and memory savings, but I'm going by memory on these as it's been a long time since
I tried them (but was successful back then).
format_. I wasn't convinced that the (3==GL_RGB && 4==GL_RGBA) was true
*GL_RGB = 6407 != 3*
*GL_RGBA = 6408 != 4*
Legacy OpenGL allows you to specify 3 or 4 (presumably for backwards compatibility with IrixGL or something) and have it map to GL_RGB and GL_RGBA, respectively. I wouldn't be surprised if GLES got
rid of that.
--ryan.
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
--
LordHavoc
Author of DarkPlaces Quake1 engine - 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
William Dyce
2011-08-07 04:34:16 UTC
Permalink
Scott: thanks, I'll check it out :)

Forest: yeah, I'm using the following switch for 1-4 colours, then I plonk
the same format value in both places:

*switch(n_colours) {*
* case 1: format = GL_LUMINANCE; break;*
* case 2: **format = **GL_LUMINANCE_ALPHA; break;*
* case 3: **format = **GL_RGB; break;*
* case 4: **format = **GL_RGBA; break;*
* default: return EXIT_FAILURE;*
*}*
*
*
I think that's about right* -* I'm not bothering with BGR or BRGA. I wonder
if I can figure out what was going wrong with the SDL_Renderer code now: I
had a similar problem, though it seemed to occur during rendering (it
depended on the draw order) rather than during the loading of the image.
It's one of the reasons I started using GLES directly (see
here<http://wilbefast.com/2011/08/06/sdlglesandroid-we-need-to-go-deeper/>).
But that would assume that I'm better with GLES than the guys who wrote the
Android port, which I very much doubt <:P
Still, I'd like to do more than just point out errors, and maybe and
ignoramus like myself it's just what's need to see a problem trained eyes
have overlooked.

William

PS - Forest, you worked on Nexuiz? Wow! I just keep meeting all these
awesome people around here, I'm very humbled :)
Post by Forest Hale
The rule with GLES is: internalformat == format.
There is *absolutely no* conversion capability in GLES2, you must do any
pixel conversions yourself before upload.
This includes the removal of the legacy 1-4 types, you must use GL_ALPHA,
GL_LUMINANCE_ALPHA, GL_RGB, GL_RGBA, and then be sure to use the correct
type parameter (such as GL_UNSIGNED_BYTE).
GL_UNSIGNED_BYTE is correct for 888 (GL_RGB/GL_BGR) and 8888 formats (GL_RGBA/GL_BGRA).
GL_BGR and GL_BGRA are extensions on GLES and I don't really recommend relying on them.
Aside from GL_UNSIGNED_BYTE you may find types like
GL_UNSIGNED_SHORT_5_5_5_1 to be of some use for faster rendering and memory
savings, but I'm going by memory on these as it's been a long time since I
tried them (but was successful back then).
format_. I wasn't convinced that the (3==GL_RGB && 4==GL_RGBA) was true
Post by William Dyce
*GL_RGB = 6407 != 3*
*GL_RGBA = 6408 != 4*
Legacy OpenGL allows you to specify 3 or 4 (presumably for backwards
compatibility with IrixGL or something) and have it map to GL_RGB and
GL_RGBA, respectively. I wouldn't be surprised if GLES got
rid of that.
--ryan.
______________________________**_________________
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>
Scott
2011-08-06 21:33:54 UTC
Permalink
Yeah that 3/4 bytes can get you, i have to make sure i check for those
when i work on ports.

By the way I saw your comment about things like glOrtho/glOrthof, yout
define is about all you can do. There a couple functions they did that with.

Also i see your using GLU, if you want there is a glu-es
http://code.google.com/p/glues/
Post by William Dyce
Got it working :D
I'd been playing around with glGetError(), which I probably should
* glTexImage2D(GL_TEXTURE_2D, 0, n_colours, surface->w, surface->h, 0,
format, GL_UNSIGNED_BYTE, surface->pixels);*
Generated a *GL_INVALID_OPERATION* error, which means... well, it
could mean many different things. The two things I'm not sure about
are *GL_UNSIGNED_BYTE* (I think this is just the format SDL loads
images with though) and the what that we use *GL_RGB/GL_RGBA* for the
format and the number of colours (*3 or 4* respectively) for the
internal format . I wasn't convinced that the (3==GL_RGB &&
*GL_RGB = 6407 != 3*
*GL_RGBA = 6408 != 4*
I decided to put the enum in both places rather than using the
n_of_colours for the internal format. Now the Android is happily
drawing the texture :D
The moral to the story: don't be a silly cuss, don't blindly
copy-paste things off the internet and use glGetError() liberally to
begin with!
*
*William*
*
Well that works for Desktop Linux, thanks John. Android is still
drawing me the white square though :-/
I haven't done anything with opengl-es, but when I've used
transparency in opengl I've always specified the blending function to
glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
http://www.khronos.org/opengles/documentation/opengles1_0/html/glBlendFunc.html
hope that helps,
John
On Fri, Aug 5, 2011 at 11:46 PM, William Dyce
http://stackoverflow.com/questions/3476348/how-to-use-textures-in-android-ndk-with-opengl-es-2-0
Post by William Dyce
Post by William Dyce
I've rewritten my draw calls so they're GLES1.1 compatible,
though I still
Post by William Dyce
Post by William Dyce
have to cheat for the glOrtho/glOrthof problem. Here's my
http://pastebin.com/0aZc4pk4
This code assumes you have a file "image.png" in a "data/"
folder: use the
Post by William Dyce
Post by William Dyce
data.sh script provided with the Android port to push it to
the device. I'll
Post by William Dyce
Post by William Dyce
try to attach the one I use to this message.
The problem is the exact same problem I was having using
the high-level
Post by William Dyce
Post by William Dyce
SDL Renderer stuff: the image draws Linux, but instead of
blitting with
Post by William Dyce
Post by William Dyce
transparency I get a white background around the image. On
the Android (both
Post by William Dyce
Post by William Dyce
HW and emulated) I only get the white box, with no image at
all.
Post by William Dyce
Post by William Dyce
I'd hoped that dropping to a lower level might solve the
problem, but
Post by William Dyce
Post by William Dyce
there's nothing to this code and it still doesn't want to
play ball. I'm
Post by William Dyce
Post by William Dyce
completely at a loss now :-( Does anybody have any idea why
this might be
Post by William Dyce
Post by William Dyce
happening?
William
Post by RodrigoCard
About glBegin/End
glBegin(GL_TRIANGLES);
glVertex3f(1,0,0);
glVertex3f(0,1,0);
glVertex3f(-1,0,0);
glEnd();
GLfloat vertices[] = {1,0,0, 0,1,0, -1,0,0};
glEnableClientState(GL_VERTEX_ARRAY);
glVertexPointer(3, GL_FLOAT, 0, vertices);
glDrawArrays(GL_TRIANGLES, 0, 3);
glDisableClientState(GL_VERTEX_ARRAY);
http://pandorawiki.org/OpenGL_ES_1.1_Tutorial
see ya.
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Beoran
2011-08-09 06:07:27 UTC
Permalink
Advantages to doing everything at once (fewer calls?) + triangle strip rather than triangles or triangle fan?
Sorry to but in here but according to wikipedia (http://en.wikipedia.org/wiki/Triangle_strip):

A triangle strip is a series of connected triangles, sharing vertices, allowing for faster rendering and more efficient memory usage for computer graphics. They are optimized on most graphics cards, making them the most efficient way of describing an object. There are two primary reasons to use triangle strips:
1) Triangle strips increase code efficiency. After the first triangle is defined using three vertices, each new triangle can be defined by only one additional vertex, sharing the last two vertices defined for the previous triangle.
2) Triangle strips reduce the amount of data needed to create a series of triangles. The number of vertices stored in memory is reduced from 3N to N+2, where N is the number of triangles to be drawn. This allows for less use of disk space, as well as making them faster to load into RAM.

Both points should certainly make a difference if you're drawing plenty of rectangles using triangle strips. (Like, say, with a tile map).
William Dyce
2011-08-09 15:46:52 UTC
Permalink
Good point :-/ Yeah, for quads without GL_QUADS triangle-strip should be a
no-brainer shouldn't it. Thanks for the info by the way: it interests me to
know the relative complexity of these operations, even if it's just for
curiosity sake. I'm quite enjoying OpenGL believe it or not ;)
Post by William Dyce
**
Advantages to doing everything at once (fewer calls?) + triangle strip
rather than triangles or triangle fan?
Sorry to but in here but according to wikipedia (
A triangle strip is a series of connected triangles, sharing vertices,
allowing for faster rendering and more efficient memory usage for computer
graphics. They are optimized on most graphics cards, making them the most
efficient way of describing an object. There are two primary reasons to use
1) Triangle strips increase code efficiency. After the first triangle is
defined using three vertices, each new triangle can be defined by only one
additional vertex, sharing the last two vertices defined for the previous
triangle.
2) Triangle strips reduce the amount of data needed to create a series of
triangles. The number of vertices stored in memory is reduced from 3N to
N+2, where N is the number of triangles to be drawn. This allows for less
use of disk space, as well as making them faster to load into RAM.
Both points should certainly make a difference if you're drawing plenty of
rectangles using triangle strips. (Like, say, with a tile map).
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Scott Smith
2011-08-09 16:20:37 UTC
Permalink
The other benefit is that ES doesnt support quads, so going with triangles,
strips, fans makes you compatible across the most if not all opengl versions.




________________________________
From: William Dyce <***@gmail.com>
To: ***@lists.libsdl.org
Sent: Tue, August 9, 2011 11:46:52 AM
Subject: Re: [SDL] GLES 1.1 <-> OpenGL 3.4 equivalent names/functions?

Good point :-/ Yeah, for quads without GL_QUADS triangle-strip should be a
no-brainer shouldn't it. Thanks for the info by the way: it interests me to know
the relative complexity of these operations, even if it's just for curiosity
sake. I'm quite enjoying OpenGL believe it or not ;)
Advantages to doing everything at once (fewer calls?) + triangle strip rather
than triangles or triangle fan?
Sorry to but in here but according to wikipedia
A triangle strip is a series of connected triangles, sharing vertices, allowing
for faster rendering and more efficient memory usage for computer graphics. They
are optimized on most graphics cards, making them the most efficient way of
1) Triangle strips increase code efficiency. After the first triangle is defined
using three vertices, each new triangle can be defined by only one additional
vertex, sharing the last two vertices defined for the previous triangle.
2) Triangle strips reduce the amount of data needed to create a series of
triangles. The number of vertices stored in memory is reduced from 3N to N+2,
where N is the number of triangles to be drawn. This allows for less use of disk
space, as well as making them faster to load into RAM.
Both points should certainly make a difference if you're drawing plenty of
rectangles using triangle strips. (Like, say, with a tile map).
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Loading...