This time I've changed the library to handle windows/contexts. I switched from using GLUT to GLFW. It's a bit better, and it handles keyboard input as well. With GLUT you didn't have full control of the main-loop. GLFW has more freedom in this sense. GLFW is multi-platform, like GLUT.
I then made a game-state management system. This means that I can now create "rooms" that are separate .cpp-files. To change state, I simply call a function that'll handle cleanup, initializing and loading new states. It even has loading-screen that displays between states.Here are one thousand hamsters in a circle.
Here's a video of them spinning around fancily.http://mordi.ziphoid.com/data/stuff/Showing_First_OpenGL_App3.webmNext, I will add FreeType to load and draw fonts. After that, I'll need to add some form of input-handling. These will probably take several days to add, just like all the other features of this little game engine have.
I could not control my amusement when I read "here are one thousand hamsters in a circle."
Hamster circle jerk.
In most cases, if you are hard coding rooms, you're doing it wrong. You should usually build a trigger system to handle everything in a separate editor, with provisions for room or object specific scripts. Even when building a game-specific engine you should be hardcoding as little as possible.
Rob: I have a base class that all levels inherit from. To change state I just need to pass in a parameter, and it'll handle everything from there.
To create a new state, I create a class that inherits from said base-class. Then, to activate this state when the game is running, I call "ChangeState(new StateClassNameHere());".Usually how I do it is have three states. Menu, Editor and Game, where editor and game loads level-files. This has worked well in the past. I've usually only made multiplayer-focused games without any sort of scripting.