Here's the puzzle test thing.

Here's MatchUp. It's been sat on my hard drive for a few weeks now so I figured I'd better put it out there just so I've got someothing to show for my time spent. It's a puzzle game I created to test out my game framework I've been working on. Tried it on as many computers as I could get my hands on but if it does have trouble running on your machine then please leave a comment with a brief explanation and if possible an error code. Alternatively you could leave me a comment to let me know what you think. It ain't groundbreaking but it works and means I can now move on to making proper games. The first of which I've already started but that a story for another post.

MatchUp

Double points if you match the combo with the required multiple on the right side of the screen. The rest is pretty straightforward. Bigger combos mean more points. Bonus 10000 points for clearing the board. Leftover time is converted into points at end of game.

Remember that puzzle game I mentioned?

Well it's nearly finished. Only 4 weeks overdue. Things never do run as smoothly as expected, especially when life gets in the way. In any case the match 3 puzzle test program is virtually finished. I will be updating in just a few days to post a link to the finished article.

Currently...

Well now that I've got a half decent framework up a running I've just started to build a test project. Nothing special, just a simple match 3 game to make sure the framework is useable. So far so good. I'll post a link to the finished project once I'm done. Hopefully won't take long. Famous last words.

The other thing

While working on my sprite editor I've also been working on a more consistent framework for my projects. Whereas my previous isometric engine utilised OpenGL, it was kind of thrown together with little thought for what was where with the best intentions of sorting it out later. Instead of going through the laborious process of untangling a big mess of code I decided to start from scratch and, armed with the knowledge garnered from writing my isometric engine, I was able to decide on what was needed and what was completely unnecessary. With the new framework I've separated all aspects of the basic structure into clearly defined units.

I have a utilities unit which contains the main Game class. The game class is used for storing common objects that all games would contain;

log file (Class)
quit flag
title
framerate timer (Class)
pause flag

The Utils unit also houses some commonly used functions. All subsequent units have access to the Utils unit.

The Graphics unit houses the Screen class and the Sprite and SpriteManager classes. This is the only place where direct OpenGL calls should be made.

The Input unit is used for interfacing with the mouse and keyboard. I am using SDL for input but all SDL calls are contained here and there is no reason to directly call SDL outside of this unit.

Here's a screenshot of a very simple program written to test the framework. It is approx 200 lines of code in the main program since most of the work is done behind the scenes in the framework or encoded into the sprites using my sprite editor.


(Oh yeah, I borrowed the sprites from the Internets)
Download it here.
Use arrow keys to move one of the guys and be sure to click and hold for flames galore.

My sprite editor

Since my last post I've been creating a sprite editor which allows me to load a sprite sheet and section it off into frames. I can then also anchor points so that animations are drawn smoothly and trigger frames so that when I use the animation in the game I can look out for these triggers and generate an event based on the trigger value. For instance a zero would be a null trigger since the default for all frames is a zero. However a trigger value of one might be the shoot trigger. In which case I could generate bullets whenever this trigger frame is drawn. Instead of having the bullets generated at the beginning of the shoot animation I could have them generated at the exact frame where the gun recoils. Another example would be the jump animation. Let's say we've got a Prince Of Persia-esque character walking along then the player hits the jump button and this begins the jump animation. Now in this version there's a few frames of pre jump action where the character compresses his body then explodes into the jump. It would seem a bit odd to have the character jumping the instant this animation starts so instead I add a trigger frame at frame 4 and the animation is much more convincing. Now this could all be hard coded but the problem with hard coding things like this is that it's much more effort and should the need arise to change the animation then the code would need editing and recompiling, also the code tends to look like crap when there's special case stuff like that dotted all over the place.

Boring boring tools

After working on the isometric engine for so long and hitting countless dead ends and brick walls I'm currently taking a break from all that by building some tools for use with the engine. I'm currently working on my sprite editor which will allow me to import a bitmap image, split it into frames, add anchor points to each frame and then save it in my hand rolled sprite format. Alongside that I'm just learning a bit more about OpenGL vertex arrays and seeing if I can utilise them to increase my ever dwindling framerate. Did check out display list but they seem unsuitable what I'm doing not only because they are now deprecated and probably won't be supported at all much longer but also because they only seem to be useful for static stuff. Might be handy for a UI overlay but aside from that I can't find much good for them. I'll try and post a bit more from now on too.

A minor victory

Apologies for the delay between posts. Had to move flat and so programming took a bit of a backseat. After trying to squash the draw error using various methods I've finally made some progress using masking. I can now redraw the entire area occupied by a sprite correctly with any overlapping objects drawn either behind or in front without any issues. As a result I can also implement a dirty rect system for redrawing objects. The plan is to create a grid of rectangle. When anything moves a flag is switched on the relevant grid locations and all objects that are within those sections are redrawn. Should save a lot of time when it comes to drawing any scene. Current concerns lie with scrolling. If the user scrolls the scene then everything will need redrawing and since the camera will probably lock onto the player this means full redraw with every movement. I'm sure there's a way of shifting the colour buffer so that the OpenGL moves the ready drawn scene and the only redraw will be things coming into view. Right now I've got other stuff to worry about.