Inertia's picture

ES 2.0 Discussion

To keep the issues regarding cleanup of OpenGL ES 2.0 free from offtopic discussions, here's a new topic for that purpose.

Some things I've observed while doing the cleanup:

  1. GL_TOKEN_EXT is interpreted as Gltokenext, not GLTokenExt. This makes reading it alot harder and I recommend fixing this before doing anything else.
  2. [In, Out] is next to every parameter. This should not be a problem, but it's just wrong. :P
  3. 98.721942% of the ES functions only accept [In] flow of data.
  4. Only Get***() functions and ReadPixels() do actually return data by parameters, most functions will return int;.
  5. The generator does not recognize ubyte *GetString() correctly.
  6. Inconsistency: In OpenGL you don't have to GL.Enable(Texture2D) when using GLSL. The EnableCap enum is either missing the TextureCubeMap token, or the Texture2D token is misplaced there. (could not find confirmation of either)

So far so good, the ES bindings look much better than the initial GL ones :)


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture
  1. My mistake, I applied the transformation twice: GL_TOKEN_EXT -> GLTokenExt -> Gltokenext. I'll have to recreate the xml files.
  2. Known issue, low priority.
  3. As above. (my calculations are closer to 98.657412% though :P)
  4. The [Out] attribute is only necessary with arrays that are filled by unmanaged code (e.g. GetFloat(foo, float_array);)
  5. Hm, generator issue. It transforms byte[] -> string, but not ubyte[] -> string. I'll fix that.
  6. Either a leftover from ES 1.1 or a misplaced token. We'll have to check with AMD's ES emulator, once EGL starts working.

The nice thing is that these fixes apply to all bindings equally. In a short while, we'll be able to run OpenAL/OpenCL through the generator and get a completely consistent API. Future updates will be easier to perform, too.

Inertia's picture

2,3 & 4. IMO it's good practice to set these attributes correctly even if it's only a single element. The observation was that very few functions will return data through parameters and it would even be possible to set all attributes to [In] and fix the remaining functions (less than a dozen) by hand.
6. I'm rather sure we can safely remove it, since the spec never tells that Texture2D must be enabled to use samplers in GLSL it is most likely redundant.

I doubt there will be much movement regarding OpenAL soon, the only significant development in the past years was the step from stereo to surround (becoming affordable for consumers). The generator is definitely a great thing for a young and volatile API like CL.

the Fiddler's picture

Issue #1 is fixed now.

#5 is proving more difficult to crack.

Regarding OpenAL, word of mouth has it that Creative is working on OpenAL 2.0 along with major game developers (Epic and others). However, there's nothing to prove or disprove this rumor.

Even if it stays at 1.1 forever, running it through the generator would allow us to add automatic error checking. However, that's more of a wishlist item, rather than a priority.

Edit: Issue #5 now fixed and committed to rev. 1966.