Progress on the Match Three game
Having a week off work has let me work on this game a bit more. I’ve put in about eight hours and it is now correctly dropping.
I’d never programmed one of these before so my first version used a board of pieces plus a secondary array for holding “transitions”. A transition was a struct that held information about two pieces being swapped and the current coordinates of each piece. It seemed to be quite messy code and was quite buggy with pieces on top of other pieces.
So I then switched to a system where each board cell had a pointer to a struct for a piece (held in an array). If the piece wasn’t moving the program calculated its pixel coordinates from the board coordinates and drew it there. If it was moving, it would no longer have board coordinates and would use the pixel coordinates to draw it.
That was better but then I thought why not just have the board just be a 2D array of structs with one struct for each piece.
This is the struct for each piece.
struct Cell {
int piece;
int moving;
int scEndX, scEndY;
float scCurrentX, scCurrentY;
float velY, velX;
int bdEndX;
int bdEndY;
int angle;
int lock; //1 = locked. Display padlock
int size; // used when killing to diminish size
};
SDL2 does rotation very nicely; you don’t need to pre-render shapes just call SDL_RenderCopyEx instead of SDL_RenderCopy and specify the angle and one or two other parameters. When a piece is removed, it animates for about a half-second, rotating and shrinking in place. That’s the purpose of the angle and size fields.
If the lock value is 1 then the piece stays in place and won’t drop. You have to remove the lock by forming a line that includes the locked piece. When the line is removed, all locked pieces in the line remain but without the lock.
So far the game is currently about 800 lines of code. There’s no game level structure, high-score table, sounds, bonus pieces or even a basic piece matching algorithm. I’ve been testing by just randomly removing three vertical or horizontal pieces and then having unlocked pieces above fall down.
This 3rd version does not suffer from the Mexican-wave problem that the first and second version had. Sometimes when a column of pieces moved down, instead of all pieces moving together they moved one-by-one. New pieces get added in when the top row piece finishes dropping away.
So now on with the book and the next part of the game.
So after yesterday’s post I also installed Code::Blocks on Ubuntu 20.04 LTS, the recent six monthly Ubuntu release. Guess what, it’s a much newer version of Code::Blocks that looks slightly different and does include SDL2. Although the demo program it creates is C++ not C (That coloured bar picture is the demo). I haven’t used it enough to see what’s different between this and version 16.01.

When I first started on the asteroids game, I did it as a set of tutorials on About.com. That was around 2011/2012 and back then I used SDL 1 which was all about surfaces not textures. When I picked up 
So my demo program runs fine when I run it from the terminal. It creates a SDL Window and blits lots of numbers, but if I try to start it in the debugger, it gets to this function and fails in the SDL_CreateWindowAndRenderer.
What makes possible all of the fast graphics in SDL2 is really one instruction.
Back in 2012/2013 I was writing the C/C++/C# column for About.com and I was doing games tutorials with SDL. This is an Empire type game, much like the Z80 game I mentioned in yesterday’s post except coded in C and with hexagons instead of squares.
Part of the reason is SDL which is a wonderful library and whose potential I have barely touched. I used to be an 8-bit games developer back in the 1980s, writing games for CBM-64, ZX Spectrum, MSX and Amstrad CPC-464.