GLES 1.1 <-> OpenGL 3.4 equivalent names/functions?

[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, 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]

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 :-SOn 5 August 2011 18:01, William Dyce <@William_Dyce> wrote:

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

[Vittorio_Giovara]

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.
VittorioOn Fri, Aug 5, 2011 at 10:01 AM, William Dyce wrote:

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

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[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
tutorialhttp://www.developer.nokia.com/Community/Wiki/Introduction_to_OpenGL_ES_1.0I
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

WilliamOn 5 August 2011 18:39, Vittorio G. <vitto.giova at yahoo.it> wrote:

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

On Fri, Aug 5, 2011 at 10:01 AM, William Dyce <@William_Dyce> wrote:

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

---

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

[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 -

es_cm_spec_1.1.pdf

• ScottOn Fri, Aug 5, 2011 at 4:53 PM, William Dyce wrote:

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
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

On 5 August 2011 18:39, Vittorio G. <vitto.giova at yahoo.it> wrote:

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

On Fri, Aug 5, 2011 at 10:01 AM, William Dyce wrote:

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

---

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

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[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.

WilliamOn 5 August 2011 19:08, Scott Percival wrote:

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

On Fri, Aug 5, 2011 at 4:53 PM, William Dyce <@William_Dyce> wrote:

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
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

On 5 August 2011 18:39, Vittorio G. <vitto.giova at yahoo.it> wrote:

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

On Fri, Aug 5, 2011 at 10:01 AM, William Dyce <@William_Dyce> wrote:

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

---

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

---

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

[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);*

On 5 August 2011 19:11, William Dyce <@William_Dyce> wrote:

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

On 5 August 2011 19:08, Scott Percival wrote:

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

On Fri, Aug 5, 2011 at 4:53 PM, William Dyce <@William_Dyce> wrote:

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
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

On 5 August 2011 18:39, Vittorio G. <vitto.giova at yahoo.it> wrote:

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

On Fri, Aug 5, 2011 at 10:01 AM, William Dyce <@William_Dyce> wrote:

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

---

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

---

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

[Brian_Barnes]

Vittorio G wrote:

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]

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.On Fri, Aug 5, 2011 at 3:02 PM, Brian Barnes wrote:

Vittorio G wrote:

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
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Patrick_Baggett]

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.)On Fri, Aug 5, 2011 at 4:36 AM, William Dyce wrote:

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);*

On 5 August 2011 19:11, William Dyce wrote:

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

On 5 August 2011 19:08, Scott Percival wrote:

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

On Fri, Aug 5, 2011 at 4:53 PM, William Dyce wrote:

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
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

On 5 August 2011 18:39, Vittorio G. <vitto.giova at yahoo.it> wrote:

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

On Fri, Aug 5, 2011 at 10:01 AM, William Dyce wrote:

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

---

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

---

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

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Scott_Smith]

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: wilbefast@gmail.com (William Dyce)
To: SDL Development List
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]

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]

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?

WilliamOn 6 August 2011 01:50, RodrigoCard wrote:

**
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.

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

-------------- next part --------------
A non-text attachment was scrubbed…
Name: image.png
Type: image/png
Size: 395 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20110806/6a7cb37c/attachment.png

[William_Dyce]

Same problem, possibly:
http://stackoverflow.com/questions/3476348/how-to-use-textures-in-android-ndk-with-opengl-es-2-0On 6 August 2011 14:17, William Dyce <@William_Dyce> wrote:

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

On 6 August 2011 01:50, RodrigoCard wrote:

**
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.

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[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
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,

JohnOn Fri, Aug 5, 2011 at 11:46 PM, William Dyce wrote:

Same problem, possibly:
http://stackoverflow.com/questions/3476348/how-to-use-textures-in-android-ndk-with-opengl-es-2-0

On 6 August 2011 14:17, William Dyce wrote:

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

On 6 August 2011 01:50, RodrigoCard wrote:

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.

---

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

[William_Dyce]

Well that works for Desktop Linux, thanks John. Android is still drawing me
the white square though :-/On 6 August 2011 15:46, John Magnotti <john.magnotti at gmail.com> wrote:

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

On Fri, Aug 5, 2011 at 11:46 PM, William Dyce <@William_Dyce> wrote:

Same problem, possibly:

http://stackoverflow.com/questions/3476348/how-to-use-textures-in-android-ndk-with-opengl-es-2-0

On 6 August 2011 14:17, William Dyce <@William_Dyce> wrote:

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

On 6 August 2011 01:50, RodrigoCard wrote:

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.

---

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

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[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 black” into Google and you get
all kinds of stuff:
http://www.gamedev.net/topic/511985-texture-appearing-black/

OpenGL textures appear just black

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

WilliamOn 6 August 2011 00:03, Paulo Pinto wrote:

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.

On Fri, Aug 5, 2011 at 3:02 PM, Brian Barnes wrote:

Vittorio G wrote:

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
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://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

[William_Dyce]

Got it working

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

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

On 6 August 2011 15:58, William Dyce <@William_Dyce> wrote:

Well that works for Desktop Linux, thanks John. Android is still drawing me
the white square though :-/

On 6 August 2011 15:46, John Magnotti <john.magnotti at gmail.com> wrote:

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

On Fri, Aug 5, 2011 at 11:46 PM, William Dyce <@William_Dyce> wrote:

Same problem, possibly:

http://stackoverflow.com/questions/3476348/how-to-use-textures-in-android-ndk-with-opengl-es-2-0

On 6 August 2011 14:17, William Dyce <@William_Dyce> wrote:

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

On 6 August 2011 01:50, RodrigoCard wrote:

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.

---

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

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[icculus]

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

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.

[Scott_Smith]

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/On 08/06/2011 11:01 AM, William Dyce wrote:

Got it working

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

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

On 6 August 2011 15:58, William Dyce <wilbefast at gmail.com <mailto:wilbefast at gmail.com>> wrote:

Well that works for Desktop Linux, thanks John. Android is still
drawing me the white square though :-/


On 6 August 2011 15:46, John Magnotti <john.magnotti at gmail.com <mailto:john.magnotti at gmail.com>> wrote:

    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

    On Fri, Aug 5, 2011 at 11:46 PM, William Dyce <wilbefast at gmail.com <mailto:wilbefast at gmail.com>> wrote:
    > Same problem, possibly:
    >
    http://stackoverflow.com/questions/3476348/how-to-use-textures-in-android-ndk-with-opengl-es-2-0
    >
    > On 6 August 2011 14:17, William Dyce <wilbefast at gmail.com <mailto:wilbefast at gmail.com>> wrote:
    >>
    >> 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
    >>
    >>
    >> On 6 August 2011 01:50, RodrigoCard <cuecax at gmail.com <mailto:cuecax at gmail.com>> wrote:
    >>>
    >>> 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.
    >>> _______________________________________________
    >>> SDL mailing list
    >>> SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
    >>> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
    >>>
    >>
    >
    >
    > _______________________________________________
    > SDL mailing list
    > SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
    > http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
    >
    >
    _______________________________________________
    SDL mailing list
    SDL at lists.libsdl.org <mailto: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