I decided to rewrite my older VB6 "Poing" game, which is now showing it's age. In particular, I wanted to design this new version from the ground up to prevent the various issues I had working on the original. Some of the most prevalent bugs from the original were all caused by the fact that everything was being drawn to the same surface. For example, since a ball might be a few pixels inside of a block before it get's ejected by the collision detection, that ball would then erase it's last position, which was inside the block. this would leave a "hole" in said block. I hacked around this by making the block redraw after a few frames, but at it's core that's what it was- a hack. and things only went downhill from there.
In this version I decided to try to make it so the image was built from a set of composited images; in this case, I've got several layers- the background, the blocks, and the balls. The Paddle and the particles are drawn last onto the target "Graphics" object.
The advantage of this method is that if something on a surface hasn't changed- for example, if the blocks are all the same as they were in the previous frame- there is no need to make any changes at all to that surface, and I can skip an entire drawing loop. The image itself is composited onto the picturebox Graphics object in the Paint routine, which is invoked by the game loop to redraw each frame. It pretty much follows the logic "has anything on this layer changed? If so, redraw the layer (by clearing and redrawing it's contents)" otherwise, ignore and keep it the same" and then painting each layer on top of each other on the resulting image.
The nice thing about this technique is that I no longer have to worry about "erasing" stuff explicitly- in the first version, balls, for example, were responsible for deleting their previous position. This caused a few graphical anomalies all over the place, what with the white background ball being drawn to erase the previous location sometimes not quite exactly fitting over the previously drawn image, causing some balls to leave a trail of errant pixels behind them. I had to resort to a LOT of dirty hacks to get that working, and the end result is pretty much that I've precluded that version from really ever using any large amount of non-ball related animation.
This new version however can have any number of items animated, even blocks can be animated (I've got a few derived classes which implement blocks that bounce around, for example). With this new architecture I can create any number of interesting combinations, such as blocks that, when hit, start moving away from the block that hit them, and so forth.
This alpha goes quite heavy on the particle effects. the intent is that particle effects will be more "candy coating" then anything game-altering, that way I can disable their rendering via an option for slower PCs that can't keep up with the particles.
Which brings me to my worry-point- performance. C# is not something that get's high-praise for it's performance, and although it works beautifully here (note the FPS in the 200-250 range most of the video) I'm dread to try running it on anything slower. Let's hope I am pleasantly surprised.
