🔒 Locked

Encapsulating GLUT within a Class

Started by Doggan Feb 22, 2005 at 12:01 PM 4 replies 900+ views

Original Post

Feb 22, 2005 at 12:01 PM

For a school project, we're forced to use GLUT for our window initialization, mouse/keyboard capture, main loop, etc. I'm not really a fan of glut, as I'd prefer to roll my own functions, but that's beside the point. I've used glut often in the past, but just for small projects to test various things out. This, however, is a fairly large project. What I want to do is encapsulate my entire application in some CApp class, where I can store everything (window dimensions, title, meshes, etc), instead of having globals floating around. The problem is when I want the display/reshape functions to be part of the CApp class. Obviously, when I register these methods in main() with glutDisplayFunc(), it needs a static reference to the function. This means I have to declare my display function as static. This works, but now the problem is that I'm not allowed to call any non-static methods or variables within a static function. This turns into an ugly cycle where I'd be declaring everything as static. Another solution was to do something like this:

CApp g_app;

void display()
{
    g_app.display();
}

int main()
{
    ...
    glutDisplayFunc( display );
}

Then CApp::display() wouldn't have to be static. This method works but seems a little hackish. /shrug. Does anyone have an idea on how to go about this in a cleaner way? If there are no other ideas I will settle for the 2nd method. ;) Thanks for reading. :)

Drew_Benton

Feb 22, 2005 at 2:48 PM

Rather than try encapsulating a C-style library with C++, use the class instead of making everything into a class. With that said, I believe your second method is the best approach in my opinion. It's not that is is hackish, it's just what happens when you mix the two languages [lol]. That's really the best thing I can offer, I can't think of anything else to add, but if there is something you are wondering, feel free to ask.

_ Drew

Ready4Dis

Feb 22, 2005 at 3:01 PM

Just because you're forced to use GLUT for windows initialization, does that mean your forced to use it's interface functions? You could possibly just use glut to set the video mode, and still handle all the messages, and function calls from a main loop, which can be right inside of your class... it all depends on how much of glut you are required to use really.

Drew_Benton

Feb 22, 2005 at 3:04 PM

Quote:
Original post by Ready4Dis
Just because you're forced to use GLUT for windows initialization, does that mean your forced to use it's interface functions? You could possibly just use glut to set the video mode, and still handle all the messages, and function calls from a main loop, which can be right inside of your class... it all depends on how much of glut you are required to use really.

Well I think the point of them using GLUT is so that they will not have to meddle with all of the core components of making a project. GLUT provides functionality of using the keyboard/mouse, handeling events, as well as a whole other bunch of thngs that makes life eaiser. If you do not use the interface functions, you will have to add your own, which I could deem darn near impossible. You can't use windows messages and you can't use direct input without jumping through hoops. I could be wrong though, but just a thought on that idea.

Ready4Dis

Feb 22, 2005 at 3:20 PM

Well, you can use windows messages, you just have to write a new wndproc and assign it to your window. This is kinda defeating *part* of the purpose of GLUT, but you can still use glut to set your window ;). I would probably just write the single function to call your classes method, it'll be the simplest method, although a bit ugly, very simple to implement, and very simple to follow the code.

--- Edit ---
One additional, semi-sloppy method:

define class, Display() static. Then in your header make an extern reference to your global class:

extern CApp g_app;

Then in your implementation, whenever you have to call another class method, you could call it by g_app.Method(), rather than just Method(). This would mean no statics besides the Display method (or whatever other functions you need glut to call), but it's a bit hackish, probably more so than just using a seperate function as a mediator ;).

--- Edit Edit ---
Or, if you're feeling really ambitions, you could write a .dll that has a class interface with virtual functions, which use a function to call said virtual functions, then in your application, you simply need the .lib and a header file, and you can then overload the virtual functions with your own, and it'll look really clean, and be reuseable, and all the ugly will be hidden (at the cost of some function overhead of course, which is normally minimal for something called only once per frame).

[Edited by - Ready4Dis on February 22, 2005 3:20:45 PM]

Doggan

Feb 22, 2005 at 7:23 PM

Eh.. thanks for all the suggestions. I think Drew hit it straight on with his first post. This is what happens when you try to mix 2 languages. I'm just going with my original 2nd option. I would rather have the couple semi-ugly functions, as we're not necessarily graded on style, than spend a lot of extra time dealing with Win32 message handling and such. If I wanted to do that, I'd work on my Engine ;P The reason for the original post was more of a curiosity of mine, instead of the need for a perfect solution.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.