Re: [ooc-compiler] New OpenGL bindings available

[Frank C. <fj...@wo...>]

On Mon, Feb 07, 2005 at 09:52:09AM +0800, Stewart Greenhill wrote  :

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

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.

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

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

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.

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.

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

[2] Pet Peeve.

Frank Copeland
-- 
Let's not complicate our relationship by trying to communicate with each other.