Re: [ooc-compiler] New OpenGL bindings available

[Stewart G. <sgr...@ii...>]

Hi Frank,

[...]

> On that note I would recommend using the C naming convention for the 
> the
> modules/header files, which is lowercase. Not that it matters that 
> much when
> porting; the most efficient way of doing it is with search/replace 
> which
> doesn't care (much) about case in identifiers.

The default behaviour is to use the header file name as the module 
name. Therefore, if you do:
   #include <OpenGL/gl.h>
the module will be called "gl.Mod". I tried to use an "Oberon-ish" 
convention by capitalising the first letter of the module name. 
Actually, you can call the module whatever you want by using the 
OutputName module attribute:
   MODULE "gl" {
     OutputName = "Gl";
     StripPrefix = "gl", "GL_", "GL";
   }
The StripPrefix attribute removes the specified prefixes from symbols 
in the defined module.

>> The new version is a complete rewrite of the old tool. The C front end
>> is missing some features that are in version 1 (eg. support for 
>> calling
>> conventions, record alignment) but the overall structure is cleaner 
>> and
>> more flexible. For example, the processor can now split an API into
>> component modules, and there are user-definable rules for controlling
>> the mapping from C to Oberon-2 where the original definitions are
>> ambiguous (eg. for pointers in procedure parameter lists). Once all of
>> the core features are in (and properly documented) I plan to add
>> support for some C++ constructs such as references, classes, and
>> namespaces.
>
> Kewl. At some point I'll build it and see how it copes with gl/glx.h.

Don't know much about that file, but I think it should work OK.

> I'm working my way through the 3rd edition of "OpenGL Superbible", 
> porting
> selected examples[1]. I can confirm that examples using GLUT timer 
> functions
> instead of the idle function don't have the same CPU impact.

Good to hear.

> One issue I've encountered is with the *ub variants of OpenGL 
> functions,
> specifically glColor3ub(). The parameters are of type Gl.ubyte which is
> aliased to CHAR. This means that a call like:
>
>   glColor3ub (255, 255, 0);
>
> has to be converted to:
>
>   Gl.Color3ub (CHR (255), CHR (255), CHR (0));
>
> Unfortunately this sort of abuse of the Oberon type system is 
> inevitable as
> long as the Oberon languages fail to properly[2] support unsigned 
> integer
> types.

Yes, this is a major pain in the neck. You could use SHORTINT instead 
of CHAR, but that doesn't really help since any integer in the range 
128..255 is not a legal SHORTINT constant. You would have to convert it 
to the equivalent negative number, which really does not help the 
readability of your code. From this standpoint, I think the CHR 
approach is probably better. OOC version 1 previously allowed large 
positive constants to be passed as integer arguments, but version 2 is 
more strict. Another option is to use Gl.Color3s, which is probably not 
much different in terms of performance. Fortunately, the API allows 
pretty much any integer size to be used - most APIs are not this 
flexible.

> [1] I would put the ported examples on my web server, but they don't 
> have a
> licence that permits distribution of derived works. They don't appear 
> to
> have a licence at all so by default copyright law prevents 
> distribution of
> derived works. 10 years ago I wouldn't have bothered about it but
> $cientology, RIAA and MPAA have between them made me far more cautious 
> these
> days.

Perhaps you could contact the author or the publisher to obtain 
permission. Suggest that it improves the examples by making them usable 
to more developers. People are usually OK about this sort of thing so 
long as appropriate credit is given.

There is some nice OpenGL tutorial code by Neon-Helium Productions:
   http://nehe.gamedev.net
That has been translated to at least a dozen languages, so it might be 
a good choice if you just want to try some stuff and see how it works. 
Of course, the book examples are in sync with the text so they're 
probably much more useful for the learning process.

Cheers,
   Stewart