View previous topic :: View next topic |
Author |
Message |
Bradley Smith
Joined: 20 Jun 2006 Posts: 60
|
Posted: Fri Sep 08, 2006 6:52 pm Post subject: DerelictGLUT |
|
|
I have created a Derelict binding for GLUT. If you wish to integrate it into the Derelict project, you may download it from http://www.baysmith.com/DerelictGLUT.zip
Warning: it has not been tested on Linux.
Although SDL is more useful, I have found a GLUT binding handy for converting some demos to D. |
|
Back to top |
|
|
JoeCoder
Joined: 29 Oct 2005 Posts: 294
|
Posted: Fri Sep 08, 2006 7:52 pm Post subject: |
|
|
Awesome. I don't have time to try it out now, but the professor in my graphics class has us using glut for all the homeworks so this will come in quite handy.
I usually use SDL. |
|
Back to top |
|
|
aldacron
Joined: 05 May 2004 Posts: 1322 Location: Seoul, South Korea
|
Posted: Sat Sep 09, 2006 2:41 am Post subject: |
|
|
Thanks for the info, but I don't think I want to include it in the trunk. Mark Kilgard abandoned GLUT some time ago, and Nate Robins has not released a new Win32 version since 2001. So unless anyone else has released updates since, GLUT is a dead API. That doesn't really matter from the perspective of features, but it's a big deal in terms of maintenance. I remember when I first used GLUT in the late 90s there were some sporadic issues with fullscreen apps, among other things. Whether they have been fixed or not, I don't know. But I don't want the Derelict crew to wind up bugfixing the GLUT source as part of maintaining Derelict. I also don't see GLUT being as useful as SDL or GLFW.
As for ease of porting, it's trivial to convert GLUT code to use SDL, GLFW, Win32, or any other framework. The important bits lie in the render loop, not in how the application is structured.
I'm not trying to belittle your work, I just don't think it belongs in Derelict. I'll happily add a link to the Derelict home page and on my blog, though. _________________ The One With D | The One With Aldacron | D Bits |
|
Back to top |
|
|
jpelcis
Joined: 09 Mar 2006 Posts: 40
|
Posted: Sat Sep 09, 2006 12:15 pm Post subject: |
|
|
It's not completely dead. The freeglut project has created a new implementation of GLUT with a few features that are unique to it. The extra features can be freely taken from my port of GLUT. They're the things in the Code: | version (FREEGLUT_EXTRAS) |
|
|
Back to top |
|
|
JoeCoder
Joined: 29 Oct 2005 Posts: 294
|
Posted: Thu Sep 28, 2006 1:16 pm Post subject: |
|
|
I can't get it to work.
Code: | import derelict.opengl.gl;
import derelict.opengl.glu;
import derelict.opengl.glut;
void main(char[][] args)
{
DerelictGL.load();
DerelictGLU.load();
DerelictGLUT.load();
int l = args.length;
//glutInitD(args);
} |
Uncommenting glutInitD() causes an access violation. DMD 0.167. Any ideas? Anyone have example code that does work?
[Edit]
I tried building opengl, glu, glut, and util as part of my project instead of running Derelict's buildme script and then importing derelict's files. glutInitD doesn't fail any more, but now any other glut function I call does. |
|
Back to top |
|
|
aldacron
Joined: 05 May 2004 Posts: 1322 Location: Seoul, South Korea
|
Posted: Thu Sep 28, 2006 9:06 pm Post subject: |
|
|
Looking at the source and comparing to the C header, I'm thinking it's a calling convention problem. In glutfuncs.d, all of the function definitions follow an extern(C): statement. On Windows, the GLUT header declares the functions as __stdcall. In D, this is extern(Windows). So line 11 in glutfuncs.d needs to be changed thusly:
Code: |
version(Windows)
extern(Windows):
else
extern(C):
|
Using an incorrect calling convention can definitely cause issues.
Another thing to think about is the location of the loadGLUT function. Because the two extern statements use a colon instead of braces, I would imagine that loadGLUT is also being affected by whichever one is active instead of having D linkage. There's no way to change the externs to use braces without copying all of the typedefs again for each linkage type. So although I don't think this is causing a problem, it's still probably a good idea to move the loadGLUT function to a location becore the version statements to ensure that it gets D linkage.
I do the same thing with DerelictGL and other packages that require __stdcall linkage. All Windows system libraries do, and for some reason I've never understood so do some third-party libraries. So when creating bindings for D you always need to check the header to determine how the functions are declared on Windows and use the appropriate extern statement on the D side. _________________ The One With D | The One With Aldacron | D Bits |
|
Back to top |
|
|
Bradley Smith
Joined: 20 Jun 2006 Posts: 60
|
Posted: Mon Oct 02, 2006 4:48 am Post subject: |
|
|
Yes, the wrong extern was probably the problem. I've repackaged the binding and corrected this. The new code is available from http://www.baysmith.com/d/baysmith.glut.zip. A couple of examples programs are also included.
Since this won't be an official derelict binding, I've moved the glut module from derelict.opengl.glut to baysmith.glut. Your import statements will need to be changed.
On the extern issue, you may find that you need to experiment with the extern(Windows) and extern(C) functions. The accumaa.d example crashes if extern(Windows) is used, but only after using the GLUT menu. Changing it to extern(C) eliminates the crashing. I do not understand why. |
|
Back to top |
|
|
JoeCoder
Joined: 29 Oct 2005 Posts: 294
|
Posted: Tue Oct 03, 2006 11:35 am Post subject: |
|
|
Thanks, and everything seems to work now.
A suggestion, but what if Derelict kept an optional collection of add-on packages, perhaps available as a separate download. Glut and PhysFS immediately come to mind. These would be unsupported and maintained only by the community, but at least then they could easily be found by anyone looking for them. |
|
Back to top |
|
|
aldacron
Joined: 05 May 2004 Posts: 1322 Location: Seoul, South Korea
|
Posted: Tue Oct 03, 2006 5:00 pm Post subject: |
|
|
JoeCoder wrote: | Thanks, and everything seems to work now.
A suggestion, but what if Derelict kept an optional collection of add-on packages, perhaps available as a separate download. Glut and PhysFS immediately come to mind. These would be unsupported and maintained only by the community, but at least then they could easily be found by anyone looking for them. |
Feel free to add a section to the wiki, linking to any homegrown stuff you want. That way, the community can maintain the links and I don't have to worry about it _________________ The One With D | The One With Aldacron | D Bits |
|
Back to top |
|
|
|