FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

DerelictGLUT

 
Post new topic   Reply to topic     Forum Index -> Derelict
View previous topic :: View next topic  
Author Message
Bradley Smith



Joined: 20 Jun 2006
Posts: 60

PostPosted: Fri Sep 08, 2006 6:52 pm    Post subject: DerelictGLUT Reply with quote

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
View user's profile Send private message
JoeCoder



Joined: 29 Oct 2005
Posts: 294

PostPosted: Fri Sep 08, 2006 7:52 pm    Post subject: Reply with quote

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
View user's profile Send private message
aldacron



Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea

PostPosted: Sat Sep 09, 2006 2:41 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
jpelcis



Joined: 09 Mar 2006
Posts: 40

PostPosted: Sat Sep 09, 2006 12:15 pm    Post subject: Reply with quote

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
View user's profile Send private message
JoeCoder



Joined: 29 Oct 2005
Posts: 294

PostPosted: Thu Sep 28, 2006 1:16 pm    Post subject: Reply with quote

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
View user's profile Send private message
aldacron



Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea

PostPosted: Thu Sep 28, 2006 9:06 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
Bradley Smith



Joined: 20 Jun 2006
Posts: 60

PostPosted: Mon Oct 02, 2006 4:48 am    Post subject: Reply with quote

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
View user's profile Send private message
JoeCoder



Joined: 29 Oct 2005
Posts: 294

PostPosted: Tue Oct 03, 2006 11:35 am    Post subject: Reply with quote

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
View user's profile Send private message
aldacron



Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea

PostPosted: Tue Oct 03, 2006 5:00 pm    Post subject: Reply with quote

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 Smile
_________________
The One With D | The One With Aldacron | D Bits
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> Derelict All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group