I want everybody to know that I'm still on this and doing some coding despite the fact that I have some kind of a nasty cold.
I don't know if I'm doing something wrong but the code is getting more and more complicated (It's often hard to predict what could stop working properly if I add feature X). Maybe it was an overkill to add all this engines (particle, sprite) and making it so modular... Or maybe this is my workflow. I didn't design the architecure beforehand. Instead I'm trying to keep things flexible in case I need to add something and I constantly refactor and refine the code so it meets my needs for the moment.
Also this game is pretty hard to debug, because a lot of things happen on the screen very fast. It's almost impossible in some cases to knowingly reproduce bugs.
I think it would be easier if I could enclose all the brick mechanics in a relatively simple, finite set of rules. For ex. if they could be implemented using a rigid body physics engine. But the mechanics doesn't fully resemble real-world physics. They are highly custom so I need to hand-craft code for almost every possible situation.
As far as catching memory allocation bugs is concerned - consider this scenario:
- A piece of code registers a sprite as a particle. Accidentaly this sprite isn't allocated.
- In the next iteration (frame) game crashes in the particle-processing loop on null pointer dereference.
So all I know in that situation is that I have a particle that is assigned to a nonexistent sprite. But which piece of code added that particle? Obviously debugging data gives me nothing. I have to go through every piece of code that seems even a bit suspicious.
Or this:
- A piece of codes registers sprite as a particle X, telling particle engine to destroy it on animation end.
- Another piece of code registers the same sprite as particle Y, telling particle engine to destory it on fade out.
- Whatever comes first - the fadeout or the animation end - the sprite and the appropriate particle X or Y are destroyed.
But the second particle assigned to this sprite (which is now freed) is still processed in the particle engine which causes in the best scenario:
* that a freed block of memory is accessed
In the worst
* that this not allocated block of memory is written to causing data corruption
In the latter case the behaviour of the program (especially the crashes) become undefined. It is not certain that it will crash in the very moment of writing to the freed block. For example it can crash on any malloc, free, realloc if internal data (linked lists) of libc memory routines were overwritten. If this happens - the origin of the error is virtually untraceable with standard debugger. This is where valgrind comes into play - it will tell you exactly which piece of code caused the invalid write.
Once (not in this project) I had a situation where the program was randomly overwritting a loop's index or boundary variable when inside that very loop (without crashing!). That was crazy, I thought that there is a bug in the kernel at first, because restarting the system sometimes caused the undefined behaviour to stop.
One more, consider this trivial scenario: Many pointers are pointing to the same memory block. A piece of codes frees its pointer and sets it to NULL. But the other pointers still have the same value. So how do we know that it is no longer valid? There's no viable solution in C that I know of. The only way is to keep track of what is happening and don't try to access it if you know it's invalid. And minimize your pointer duplication...
I thought that this stories might be a bit interesting to someone who didn't have much experience with pointer hell. If you want, I have more of them.
Ok, so contrary to the impression you might've had after reading this my code may be not brilliant but it is pretty tight and quite well-thought in general. Such bugs are inevitable to some extent. And of course more refactoring is coming before anyone sees the code!
I'll post some videos when I fix some bugs and finish "advancing to the next level". "level advancing" is the moment when you dig through the "level interconnecting layer" and land on new, shiny 100 rows of bricks.
