Everybody,
After 3 months of hacking and testing it is here: my contribution for the newLisp contest. :-)
GL and GLU were already available, now also a binding with GLUT is finished. Signals, callbacks, window creation, menus etc., all functions from the original GLUT library can be used with the greatest programming language on this planet: newLisp. Works both with Linux and Windows.
Also included is the good old MUI, an OpenGL-based userinterface.
You can find the binding including demo programs and screenshots here:
http://www.turtle.dds.nl/gl4newlisp/
Enjoy!
Peter
Hi Peter,
Very nice work.
Run fine for me under WIN XP.
But under WIN2K I get:
bitfont + gldemo crashes newLISP.exe
spin + solar do not start, return to newlisp prompt
simpledraw, simpleanim,mui_test + steam works OK
By the way:
Is the contest opened?
Who will be the judge?
Hi HPW,
Strange you have problems with Win2K, since I developed the DLL in Win2k... but I exprienced the same thing with WinME. Could you try to compile a newlisp.exe without the '-O3' optimization flag and let me know your results? (On my Win2000 I can use the standard newlisp.exe though.)
The idea of the contest was launced by Norman, the judge will be newLisp users who can vote for a submitted contribution.
Peter
Correction:
bitfont + gldemo + spin crashes newLISP.exe (-O3 flag)
spin + solar do start/crash (I had them copied into the wrong path)
bitfont + gldemo + spin works newLISP.exe (-Os flag)
Peter,
Left light seems not to work in steam.lsp
Any chance to use PLIB with your stuff?
http://plib.sourceforge.net/index.html
Would offer a more abstract scene graph and a different GL-user-interface.
Do not know if it runs on windows.
http://plib.sourceforge.net/requirements.html
Another Correction:
bitfont + gldemo + spin crashes also on WIN XP newLISP.exe (-O3 flag)
(I had tested the first time with a -Os compiled/packed newLISP.exe 68K)
The left light in 'steam.lsp' indeed does not work, neither in the compiled version of 'steam.c'. This is a bug in the original program.
Apparently it makes sense in which way the newLisp.exe binary is compiled. I suspect the '-O3' optimization flag does strange things with pointers and memory allocation. My freeglut DLL was compiled without any optimization flag.
In Win2000 on my laptop I have no problems with the standard newLisp binary though. I run Service Pack 4. Unfortunately I do not have access to WinXP right now.
I will look into PLIB, but it is unknown to me so far. Didn't 'tuxracer' use it?
Peter
>Didn't 'tuxracer' use it?
On their web-site are some Tux-programms mentioned (Tux,TuxKart,tuxFleet)
I have test to pack freeglut.dll with UPX. Still works with 80KB size.
Cool! The smaller the better.
PLIB is C++ based, so porting PLIB to newLisp becomes difficult. Because of the name-mangling of methods and classes, all exported routines must be renamed and for each method an individual C export must be defined. A lot of work.
Peter
>A lot of work.
I was only looking for a more abstract way to 3D content.
They have put in a lot of work in loaders for popular 3D formats
and have provide other cool functions.
IVRS for TK was a similar approach. But it is not very activly under development.
http://www.alh.net/newlisp/phpbb/viewtopic.php?t=160&highlight=ivrs
The nice things with it is, that you have mouse-over and click events/callbacks for 3D-Objects.
On the other side, there is a ongoing discussion for the windows platform about the best 3D enviroment. (OpenGL vs. DirectX) Since MS has announcent that vista will only emulate OpenGL on DirectX, it has not become easier to decide for the supported platform. And one has to wait what Nvidia and ATI will do on this.
Aha ok, about that Microsoft decision, I did not know. However, Linux is my primary platform, though it always improves my code if I port it to Win32. We'll see what happens with Vista then.
Hi HPW,
I thought to have found a possible cause for the crashes on other Windows platforms. Looking through the Win32 makefiles of freeGLUT which are intended to be used with VisualC, I saw the /MT flag, which means multithreading.
My GLUT DLL is compiled with MinGW using the '-mthreads' flag. But from the newLisp Makefile I see that newLisp is not compiled in a thread-safe way. That could explain the improper functioning on some Windows platforms, since thread errors may sometimes occur, and sometimes not. But it doesn't solve the issue.
I also found why my demos worked on my Win2000 install: I was still using a fresh install newLisp 8.6.1. When I install 8.7 the same demos crash on my machine also.
So, again I tend to think something has happened in the newLisp source, after which some stuff got broken. Keep you informed.
Peter
Problem (appears to be) solved.
The common thing in the GLUT demos which crash, is that they share an IdleFunc. Each of the demos crash in registering the Idle Function. So what happens there which is so special that the '-O3' optimization can't swallow? The registering of the Idle function happens in the 'freeglut.lsp' context, which in fact calls a C-function in the freeglut DLL. However, this C-function requires an argument (which is not used at all), but the newLisp context did not pass this argument.
So I removed the argument from the C-function header, recompiled the DLL and it runs on my Win2000 machine now *with* newLisp 8.7.0 optimized with '-O3'.
This was really a headache, since the way the problem showed itself was very inconsistent. The 'steam.lsp' demo does register an idle func and worked. GDB could not debug the memory used by newLisp and freeglut. And it never occured in Linux since the newLisp binary is compiled in Linux without any optimization. Why it worked for me in the first place with newLisp 8.6.1 is a riddle to me, and why it worked with WinXP also is something I don't understand. Anyway.
Could you please download the new DLL and try again:
http://www.turtle.dds.nl/gl4newlisp/freeglut.dll
Please let me know the results.
Peter
Peter,
Tested on my home WIN/XP everything works fine with the new DLL.
Tests on WIN2K when I back in office tomorrow.
Also everything is working on my WIN2K now.
Hi HPW,
Good news. Though I still don't understand why the '-O3' optimization delivers these problems.
Thanks a lot!
Peter
If the 'C' function in the GLUT dll reqired an argument, an argument has to be passed. The fact that it did not crash under certain optimization settings was pure luck.
This DLL is a great entry into Norman's contest. I will try it out when I am home again and have access to a windows machine. I have been trying to get OpenGL+GLUT going on Mac OSX, but no luck yet. All OSX OpenGL/GLUT stuff is tuned/documented with XCODE (the Apple development system) in mind. I wonder if anybody else here uses Mac OSX and got the OpenGL/GLUT working using normal GNU tools.
Lutz
Thanks!
The port will work in Linux and Win32, however, I do not have access to a MacOSX machine at all, so unfortunately I cannot port it myself....
Peter
The GLUT binding has been improved.
- Added support for mousewheel and joystick (Win32+Linux)
- Rewrote the callback registering functions
- Fixed potential bugs when using more than 8 windows
- Fixed bug with the 'gluLookAt' function
- More programs from the OpenGL website were ported
Download here:
http://www.turtle.dds.nl/gl4newlisp/index.html
The affected files are the SO/DLL, the 'freeglut.lsp' context, and 'GLU.lsp'.
Peter
Maybe this is also interesting:
http://www.openscenegraph.org/
A release 1.0 is out.
The demos are cool.
They have a LUA binding. (Maybe a newLISP-binding is possible?)
Looks good!
Quote
Maybe a newLISP-binding is possible?
Hmm... The website states:
Quote
Written entirely in Standard C++
It will be hard to import (mangled) names from classes and methods, if not impossible. So if a binding must be created, probably it will be on C-level entirely by adding new statements to newLisp. :-(
Peter