Re: [ooc-compiler] New OpenGL bindings available

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

Hi Frank,

>> Under OSX, you can just do:
>>   oo2c -r . --make Test2
>>   bin/Test2
>
> This worked under Debian GNU/Linux (testing), after...
>
>> in the extracted directory. For other operating systems, you will have
>> to adapt the LINK directives in the interface files.
>
> Gl.Mod: MODULE Gl [ INTERFACE "C"; LINK LIB "GL" END ];
> Glu.Mod: MODULE Glu [ INTERFACE "C"; LINK LIB "GLU" END ];
> Glut.Mod: MODULE Glut [ INTERFACE "C"; LINK LIB "glut" END ];

Thanks for confirming that. I think every platform (Linux, Mac, 
Windows) uses different names for these libraries.

>> Also there (under "misc"), is the original source used by the
>> translator to generate the output modules. Unfortunately there's no
>> documentation yet for this tool but if you're interested this will 
>> give
>> you an idea how it works.
>
> I'd be interested to have the source code for the translator. The most
> recent version of H2O I can find is h2o-20020204.tar.gz, which I 
> gather is
> not the version used to generate these interfaces.

The source code is in the ooc2 CVS repository (under src/H2O). Its not 
stable yet, so is not built as a standard tool. Once you've checked out 
and configured the compiler source, you should be able to build the 
translator by doing:
   oo2c --config oo2crc-install.xml -Mv TestH2O
Alternatively, you can do "make test" under tests/h2o.

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.

>> Feedback is welcome, although I can't necessarily help with any
>> problems at the moment.
>
> Running bin/Test2 consumed 100% of CPU to rotate a simple wireframe 
> object.
> This was a bit surprising on an Athlon 1700+ but I gather this is a
> "feature" of the freeglut implementation of libglut.

The test just uses a Glut.IdleFunc procedure to update the state and 
refresh the display. There's no "throttling" in there, so it may well 
do this depending on how GLUT is implemented. A better way to do it 
would be to use a Glut timer to limit the frame rate.

Thanks for the feedback. Glad to hear it works for someone else too ;-)

Cheers,
   Stewart