Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 2 of 2 FirstFirst 12
Results 11 to 17 of 17

Thread: New XML-based API Registry released

  1. #11
    Administrator Contributor
    Join Date
    Jan 2002
    Location
    Mt. View, CA
    Posts
    97
    You seem to assume all enums are bitfields to be ANDed together where in the original specs you could easily see they were separate, had specific values and were not all enumerations, i.e. some are constants of a type to be ANDed.
    I'm not sure what you mean by this. Enums that are bitmask values are tagged as such, e.g.

    <enums namespace="GL" group="AttribMask" type="bitmask">
    <enum value="0x00000001" name="GL_CURRENT_BIT"/>
    ...

    You're correct on the other two points. OpenGL is explicitly defined as a C API and the XML registry reflects that now, while the .spec files pretended that wasn't the case - which resulted in a lot of pain for me, slow updates, and a fair number of errors creeping in over the years resulting from the typemap system. There is some discussion upthread about ways to help accomodate the differences if you want to mechanically translate the API to other language bindings, but it is true that you'll have to do some things differently than with the .spec files, and do some additional type translation work. Hopefully the benefits of a well-defined XML schema, more accurate description of the relationship between features and GL versions/profiles, ES support, and much more frequent updates will balance that out for most people.
    Jon Leech
    Khronos API Registrar
    ARB Ecosystem TSG Chair
    GL/EGL/GLES Spec Editor
    ...and suchlike

  2. #12
    Newbie Newbie
    Join Date
    Aug 2013
    Posts
    2
    Would you be able to use a typemap like the old specs did?



    This would make it far easier for folks that are trying to generate loaders for other languages that don't follow the C declaration syntax.

    Anyway, thanks so much for your work, you have made our lives much easier.

  3. #13
    Newbie Newbie
    Join Date
    Aug 2013
    Posts
    1
    As the (currently sole) maintainer of the Delphi (and Free Pascal) OpenGL headers over at delphigl.com I must admit that I'm pretty happy with the release of the XML-based API files. It only took me two weekends to write a converter that automatically creates a complete Delphi / Free Pascal OpenGL header with the click of one single button, and just half an hour ago I even got an OpenGL 4.x template working with that generated header

    So from now one I don't have to do a diff with the C-headers to check what's changed and merge that manually into our headers anymore. Instead I now just download the latest XML definition, click a button and it's done. The only thing I'm currently struggling a bit with are type mappings, cause there are some differences between data types and their declarations between Delphi (Free Pascal) and C, and I also want the new header to be compatible to our old ones.

    But I'd say the new XML definitions are a step in the right direction, especially for generating headers / wrappers for other languages.

  4. #14
    Newbie Newbie
    Join Date
    Nov 2011
    Posts
    1
    Great to have a documented and up to date spec in xml format. But while writing a parser for it I stumbled on the point of the use of C-syntax for both types and functions.

    Using C inside the spec is understandable from the point that OpenGL is a C API. Though parsing it to use it for something else than generating a C-like header it is a pain. Parsing the current format thus requires not only a xml-parser but also a parser for the C parts. Thus making the spec far more complicated to parse than a simple xml file. Assuming it is parsed the processable cases need to be distinguished. Simple cases like "typedef int <name>GLint</name>" can probably be handled by a translator, while complex cases like the "inttypes" cannot.

    I think these problems all stem from allowing arbitrary C, while only a small part is needed for almost everything. Apart from "inttypes", "GLhandleARB" and the C-specific headers all types can be easily expressed without needing C. Furthermore I think that the same holds for the function parameters and prototypes.

    Using xml for the standard case would have several advantages. The parsing would be easier, it would be clear what types are present and make C-specific types stand out from the normal ones. Overall this would make writing a parser for the spec format and using it a whole lot easier.

  5. #15
    Newbie Newbie
    Join Date
    Sep 2013
    Posts
    1
    Hi Jon,
    it's really great the you've switched to the xml file, there were too many strange things in the old format. As I am working on wrapper for .NET (OpenGL4NET), I've started to go through your new format to rewrite the wrapper generator and I have these comments/questions right now:

    1. Someone already wrote, that it would be great to have some more generic way of typemaps. This C declaration makes the process quite difficult as there are various kind of declarations (simple typedefs, callbacks etc.).
    2. In some commands (e.g. glBufferStorage) there is no ptype (I know you've stated that ptype is optional, but again for people working on non-C implementation, this is a complication).
    3. In the old format, there was a nice hint for parameters in/out value/array. I understand that for C language it does not make a big difference but for other languages this could help to create more language dependent calls. Furthermore having * directly in the <param> element makes the DOM somehow weird.
    4. Just a small problem - having <return> tag instead of using <ptype> inside <proto> will again improve the quality of xml, and make it easier for other languages.

    Please, would it be possible to make the .xml specification more C-independent.

    Thank you

  6. #16
    Newbie Newbie
    Join Date
    Aug 2013
    Posts
    2
    Ok, here's our loader generator for Rust based on the XML registry: https://github.com/bjz/gl-rs

  7. #17
    Newbie Newbie
    Join Date
    Feb 2014
    Posts
    1
    I always wanted to have a nice overview of which OpenGL functions or enums are supported in which OpenGL version. Something like the tables that are available for GLSL commands in the reference pages. However, I haven't found one ... so I've made my own

    Using the XML registry as the base with Lucene and a simple Web-Frontend and API on top I've created: index.gl

    Its still Beta but it works well, I think. The sourcecode is available at github too (can't post the link due to number of URLs restriction in a single post limit - but the link is at the bottom of the main website).

    Maybe this will be helpful for others as well.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •