Wow, it's been a long time since I've worked on this project. I've been very busy with school and work. Since I work with computers and other technical stuff for school and my job anyway, it's hard to stay motivated to work on technical side projects. Sometimes you just need some art or literature or music. Anyway, I've made some biggish updates - the engine can now display text strings. This feature isn't in its final form, but it's close. I think the only thing missing in the text department is to handle multi-line strings in an elegant manner. Text is handled using freeGLUT's built-in glutBitmapString(), and everything is wrapped into its own text-display routine so I'll only have to modify one function if I want more complicated behaviour in later versions.
The next big change is that the framerate should be much smoother now. I set a desired movement rate, and based on feedback about how long it took to draw the previous frame, the movement distance for the current frame is adjusted. A maximum movement distance is set just in case the previous frame took an unusually long time to draw. This helps prevent clipping. I'm using the sys/time.h header for timing. Since this is a quick fix, I didn't read up too much about the timing utility, so there's a check in the code to make sure the distance is never negative (apparently getting negative time differences could maybe be a thing depending on how the system clock synchronizes itself with networks or something).
No screenshots (I'm lazy and it's spring break woooooo), but here's the zip of all the .cpp files. Also, here's a source file from November 15 - I made some update or other but didn't get around to writing about it. It's outdated, but I want to record its existence for the sake of way-too-late-to-remember-what-it-does documentation.
Altered the movement system so that the player can move diagonally if two direction keys are held down at the same time. This causes a small bug if the player tries to walk into another sprite. Typically the other sprite will push back the player in the opposite of whatever direction they're heading when there's a collision. The other sprite can tell which way they're heading by looking at the facing property, which also determines how the player's sprite is drawn. Now that the player can move diagonally, I'll probably have to update the functions that depend on the facing property. No big deal, but it's not a very important bug and I'm not motivated to handle it right now. Also, I cleaned up the code by placing all class definitions in their own file. All updated files are in the following zip file:
Yesterday I did some work on implementing the game as a big state-machine. It seems to be working so far - state is currently changed by hitting an object in the "transporter" class that'll flag the state change. I ended up making new state initialization a separate function from the body of the state so that it is easier to see where in the code the new state is set up. The next task I want to tackle is moving all of the class definitions into their own file to clean up the code a bit. I think eventually each state or "scene" will get it's own file: easier to stay organized that way.
Game files:
I think I'm pretty well set for now in terms of the engine being able to handle a single scene or location. What I'd like to start working on is making it so the engine can handle multiple scenes and the transitions between them. I'm thinking the entire engine will run as a state machine, where the current state determines which map is rendered. Transitions will probably be triggered by the user sprite coming into contact with an invisible object at the edge of a map that, when hit, changes the state so that the next map is loaded. Specifically, I think that each state will have only one function that handles the rendering and manages all of the scene's variables and objects (such as sprites). I might end up using some globally-initialized sprites that can be re-initialized upon first entering a state to avoid having to have every sprite from every state stored globally. It'll save memory this way. Anyway, each of these state function should have a parameter or static variable to indicate the first time the function is called so those sprites and whatnot can be initialized. Man, if only C++ supported static classes :/ .
Boring update, but it'll help me remember my ideas.
I'm working on a 2D game engine for an exploration/puzzle game inspired by Myst. The engine is based on OpenCV and OpenGL and is still in the very early stages. The screenshot below shows a test scene: the bird is controlled with WASD and if you can reach the sprite in the center of the star it'll spin around. Very exciting stuff. All files are in the zip after the screenshot. This test was run under Ubuntu.