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

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

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

William

On 6 August 2011 00:03, Paulo Pinto <pjmlp at progtools.org <mailto:pjmlp at progtools.org>> 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 <ggadwa at charter.net <mailto:ggadwa at charter.net>> 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 <mailto:SDL at lists.libsdl.org>
    http://lists.libsdl.org/__listinfo.cgi/sdl-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


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

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).On 08/06/2011 11:51 AM, Ryan C. Gordon wrote:

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.


SDL mailing list
SDL at lists.libsdl.org
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

Scott: thanks, I’ll check it out :slight_smile:

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
herehttp://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 :slight_smile:

On 7 August 2011 14:09, Forest Hale wrote:

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

On 08/06/2011 11:51 AM, Ryan C. Gordon wrote:

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.

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


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

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

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.

WilliamOn 7 August 2011 14:04, Forest Hale wrote:

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.

On 08/06/2011 06:36 AM, William Dyce wrote:

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://www.gamedev.net/topic/511985-texture-appearing-black/
http://stackoverflow.com/questions/4124708/opengl-
textures-appear-just-blackhttp://stackoverflow.com/questions/4124708/opengl-textures-appear-just-black
http://stackoverflow.com/**questions/6068903/**gldrawtexfoes-draws-black-
**texture-on-phone-and-correct-**in-emulatorhttp://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 :wink:

William

On 6 August 2011 00:03, Paulo Pinto <pjmlp at progtools.org <mailto: pjmlp at progtools.org>> 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 <ggadwa at charter.net<mailto: ggadwa at charter.net>> 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 <mailto:SDL at lists.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.orghttp://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.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.orghttp://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
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

wilbefast wrote:

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

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 ;)On 9 August 2011 16:07, Beoran wrote:

**

wilbefast wrote:

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


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

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: wilbefast@gmail.com (William Dyce)
To: sdl at 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 :wink:

On 9 August 2011 16:07, Beoran wrote:

wilbefast wrote:

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


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