Pure OpenGL bindings
sedillard
section. There is a simple glut example that uses pure-ffi for the
rendering callback. I've only tested it on my Ubuntu system. You
should see a rainbow triangle on a white background. Please try it out
on other systems. You'll have to edit the files (first line) to point
to the correct GL, GLU and glut dlls for your system.
Issues:
Right now I've got all the functions in namespaces GL, GLU and GLUT.
Albert, you mentioned that we might perform the "extern" declarations
in an eval, so that if the function does not exist in the dll, it
fails silently. I can't figure out how to get this to work with
namespaces.
namespace GL;
eval "extern void glBegin(int) = Begin;";
This puts 'Begin' in the default namespace. I'd rather not have to
declare these all as public, as that nearly doubles the size of the
file. So currently, you get a bunch of noise on your stdout when you
load the bindings.
Albert Graef
> I can't figure out how to get this to work with
> namespaces.
>
> namespace GL;
> eval "extern void glBegin(int) = Begin;";
What about:
eval "namespace GL; extern void glBegin(int) = Begin;";
Also, to speed that up, you might want to eval all such declarations in
one go.
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.G...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
sedillard
On Jan 30, 7:07 pm, Albert Graef <Dr.Gr...@t-online.de> wrote:
> sedillard wrote:
> > I can't figure out how to get this to work with
> > namespaces.
>
> > namespace GL;
> > eval "extern void glBegin(int) = Begin;";
>
> What about:
>
> eval "namespace GL; extern void glBegin(int) = Begin;";
>
> Also, to speed that up, you might want to eval all such declarations in
> one go.
>
scanner uses REJECT
Albert Graef
> Fails with: input buffer overflow, can't enlarge buffer because
> scanner uses REJECT
Can you please post the exact code that causes this?
Albert Graef
> sedillard wrote:
>> Fails with: input buffer overflow, can't enlarge buffer because
>> scanner uses REJECT
>
> Can you please post the exact code that causes this?
Ok, I guess it's just the string getting too long for the flex-generated
scanner to handle. In that case you'll have to split it up in smaller
chunks for now. I'll have to enlarge the buffer size, or rework the flex
grammar so that huge strings can be handled.
sedillard
On Jan 30, 9:04 pm, Albert Graef <Dr.Gr...@t-online.de> wrote:
> > Can you please post the exact code that causes this?
>
> Ok, I guess it's just the string getting too long for the flex-generated
> scanner to handle. In that case you'll have to split it up in smaller
> chunks for now. I'll have to enlarge the buffer size, or rework the flex
> grammar so that huge strings can be handled.
>
I've changed the generator so that it breaks the bindings up into
smaller files. The core OpenGL 2.1 API goes into GL.pure. This should
be supported by most vendors who aren't actively trying to anger their
customers. The more esoteric extensions go into e.g. GL_ARB.pure,
GL_NV.pure, etc. So you only pull in what you need. This makes loading
times much faster. It still echoes the function-not-found error to
stdout, but only if you specifically pull in the esoteric extensions.
I'd appreciate it if someone who is using open-source drivers (nv,
mesa, etc) could check to see if GL.pure loads without error.
Scott
Albert Graef
> This is starting to get a little ridiculous :)
Well, sorry, but it's a limitation in flex that I didn't know about
until now. I didn't write flex, you know. ;-)
Your simple_glut_example.pure works fine over here. Cool, now I can
start porting my OpenGL examples from Q. :)
BTW, 'do void' isn't really the way to sequence commands in Pure.
There's the sequence operator $$ for that:
display _ =
GL::Clear (GL::DEPTH_BUFFER_BIT or GL::COLOR_BUFFER_BIT) $$
GL::Begin GL::TRIANGLES $$
GL::Color3f 1.0 0.0 0.0 $$
GL::Vertex2d 0.0 0.0 $$
GL::Color3f 0.0 1.0 0.0 $$
GL::Vertex2d 1.0 0.0 $$
GL::Color3f 0.0 0.0 1.0 $$
GL::Vertex2d 1.0 1.0 $$
GL::End $$
GLUT::SwapBuffers;
Or, if you prefer a more conventional syntax, you can also use a 'when'
clause, like this:
display _ = ()
when
GL::Clear (GL::DEPTH_BUFFER_BIT or GL::COLOR_BUFFER_BIT);
GL::Begin GL::TRIANGLES;
GL::Color3f 1.0 0.0 0.0;
GL::Vertex2d 0.0 0.0;
GL::Color3f 0.0 1.0 0.0;
GL::Vertex2d 1.0 0.0;
GL::Color3f 0.0 0.0 1.0;
GL::Vertex2d 1.0 1.0;
GL::End;
GLUT::SwapBuffers;
end;
> It still echoes the function-not-found error to
> stdout, but only if you specifically pull in the esoteric extensions.
Or you just do
eval "using GL_ARB;";
etc. to silence the error messages. I like the idea with the separate
files for the various extensions.
> I'd appreciate it if someone who is using open-source drivers (nv,
> mesa, etc) could check to see if GL.pure loads without error.
I can only test with the proprietary ATI driver here. 'using GL;'
reports a single undefined symbol:
GL.pure, line 1431: external symbol 'glBlendEquationSeparate' cannot be
found
Can someone else test with the open source drivers please?
Anyway, it shouldn't be a big deal to write a Pure script which checks
the availability of each routine and comments out those which aren't
available on the target system. I'll have a look at that asap.
There's another issue with libfreeglut I noticed. If I only have the
libfreeglut package installed (not the corresponding -devel package)
then there is no libfreeglut.so, only libfreeglut.so.x.y, so 'using
"lib:libglut";' gives an error. The libfreeglut.so is in the -devel
package. This is on openSUSE, but the packaging policies of other
distros are similar AFAICT.
This isn't a big deal for developers who are prepared to install the
-devel packages they need, but it might be an issue for end users who
just run some Pure script without actually knowing what's going on. It
would be preferable to fix this in the interpreter, so that it looks for
versioned dlls. Unfortunately, the treatment of dll versioning is
platform-dependent (and might even be done in an ad-hoc fashion), so
it's not really feasible to do that.
I don't really have a neat solution for that. Any suggestions?
Great piece of work, Scott. :) Many thanks!
Albert
Libor
I have searched the svn tree but failed to find it.
sedillard
> Where can I find the "files section" with this OpenGL stuff?
> I have searched the svn tree but failed to find it.
It's not in the svn repository, its part of this Google group. I'll
leave it to Albert to decide whether or not to put this in svn.
Scott
sedillard
On Jan 31, 4:42 am, Albert Graef <Dr.Gr...@t-online.de> wrote:
> GL.pure, line 1431: external symbol 'glBlendEquationSeparate' cannot be
> found
same error for glBlendEquationSeparateEXT. They are the same function,
but it has been promoted to OpenGL proper as of version 2.0. I assume
that your drivers support 2.0 or greater, because otherwise you would
get many more such errors for all the other 2.0 functions. If AMD
shipped non-compliant drivers, I should probably be able to find some
news of this, but I cannot. So I'm inclined to think that this is a
problem with the Pure/LLVM dll mechanism.
Scott
Albert Graef
> It's not in the svn repository, its part of this Google group. I'll
> leave it to Albert to decide whether or not to put this in svn.
I just started working on it. I have some examples from Q that I can
port, and of course I need to put together a Makefile which installs
stuff in the proper location. When that is done, I'll check it in so
that you can review the package. Ok?
Albert Graef
> On Jan 31, 4:42 am, Albert Graef <Dr.Gr...@t-online.de> wrote:
>> GL.pure, line 1431: external symbol 'glBlendEquationSeparate' cannot be
>> found
>
> That's really strange. Try loading GL_EXT.pure and see if you get the
> same error for glBlendEquationSeparateEXT.
Yup, same error.
> I assume
> that your drivers support 2.0 or greater, because otherwise you would
> get many more such errors for all the other 2.0 functions.
fglrxinfo reports:
display: :0.0 screen: 0
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: ATI Radeon HD 3850
OpenGL version string: 2.1.8304 Release
The driver is version 8.12 which I installed some 2-3 weeks ago, so it's
a pretty recent version. I could try version 9.1 which has just been
released a few days ago, but I'm not too eager to break a working
system. ;-)
> If AMD shipped non-compliant drivers, I should probably be able to find some
> news of this, but I cannot. So I'm inclined to think that this is a
> problem with the Pure/LLVM dll mechanism.
No, it's not:
> using "lib:libdl";
> extern void *dlopen(char *filename, int flag);
> extern void *dlsym(void *handle, char *symbol);
> let h = dlopen "/usr/X11R6/lib64/libGL.so" 1;
> dlsym h "glEnable";
#<pointer 0x7fb84469b5f0>
> dlsym h "glBlendEquationSeparate";
#<pointer 0>
If dlopen can't find it, it's not in there.
Maybe it's just the Linux driver, I'll check on Windows later today.
Cheers,
Jiri Spitz
>
> I'd appreciate it if someone who is using open-source drivers (nv,
> mesa, etc) could check to see if GL.pure loads without error.
>
>
proprietary nvidia drivers.
Jiri
Albert Graef
> Maybe it's just the Linux driver, I'll check on Windows later today.
On Windows it's even worse, missing GL and GLU calls galore, I've
attached a list to this mail. That is with the latest ATI driver (9.1).
I checked some of these against the exports list of opengl32.dll and
glu32.dll (as obtained with impdef), and they really aren't there. So it
seems I'll have to add some configury to comment out the missing stuff
after all.
Other than that, after adding freeglut.dll and changing the dll names,
the modules load up fine, and the GLUT operations seem to work ok.
However, each and every GL operation segfaults when called. I still have
to debug this. The OpenGL diagnostic software I have seems to run fine,
so this seems to be an issue with the LLVM call interface, I will try
ffi instead.
BTW, are the GL_* enumerants guaranteed to be the same for every
platform/implementation?
If anyone else wants to give it a whirl on Windows, I can post my
freeglut.dll here (the ones I found on the web didn't work), just let me
know.
sedillard
posted more or less the same thing on the other thread
http://groups.google.com/group/pure-lang/t/76aec328214e0527
Let's continue this there.
Scott
Albert Graef
> Other than that, after adding freeglut.dll and changing the dll names,
> the modules load up fine, and the GLUT operations seem to work ok.
> However, each and every GL operation segfaults when called. I still have
> to debug this. The OpenGL diagnostic software I have seems to run fine,
> so this seems to be an issue with the LLVM call interface, I will try
> ffi instead.
Calling the same functions through ffi works fine. It seems that in
certain situations the LLVM JIT has trouble calling functions in some
Windows dlls. I had to work around a similar issue with pd-pure.
Albert Graef
> Albert Graef wrote:
>> sedillard wrote:
>>> Fails with: input buffer overflow, can't enlarge buffer because
>>> scanner uses REJECT
>> Can you please post the exact code that causes this?
>
> Ok, I guess it's just the string getting too long for the flex-generated
> scanner to handle. In that case you'll have to split it up in smaller
> chunks for now. I'll have to enlarge the buffer size, or rework the flex
> grammar so that huge strings can be handled.
Fixed as of r846.