So many improvements!

Originally my intention was to make the graphics look pixely and low-resolution, akin to Arkanoid or 90s PC demos or the like.  But the more I played with the vector-art visuals the more I liked them (and also that fits with the intended aesthetic of a bunch of the other games in the album), so I decided to increase the game resolution to 1280x720. Which required changing a lot of parameters around but part of that led me to a more stable approach for placing bricks. So that's a win.

As part of doing that I also finally switched from an unwieldy pile-of-if-elses to using an event queue that allows me to easily duplicate events and do a few other things nicely. At some point I'll [game name] that out so that the other games can use it too, since it's a model that several of the tracks will be able to make use of.

I also noticed a lot of framerate judder, and so I threw on a simple profiler.  It turns out that even though the new physics system has a fast-fail path, it was still taking a HUGE amount of time; about half of my CPU time was going to getting the polygon of the paddle and its AABB! So I did a few things to speed that up:

• Used a simple bounding box test as the first pass
• Only compute the polygon and AABB if that first test passes
• Also memoize the polygon (which allows it to be shared between the physics and render passes)

While I was at it I realized this would be a highly bogus problem for bricks and entities and so on, so I extended the Actor API to make all of that a lot simpler to add. (Not all Actors will benefit from the bounding circle test but the ones that do benefit greatly.) If I ever get Actors with more complex shapes I might move the collision detection into them so that they can do more interesting fast-fails but I don't anticipate a need for that right now.

Anyway, now physics takes only a tiny sliver of my CPU time, even when there's a crapton of actors on the screen! So this is good. I was worried I might have to implement a collision quadtree or some other sort of spatial partitioning but I don't think that'll be necessary now (and I suspect the overhead of a quadtree would be more than the cost of the naive bounding-circle test).

Oh, and now there's a new type of ball: the SUPERBALL.

For the next update I hope to get more block spawn patterns and maybe some non-brick actors in. Or maybe I'll focus on visual effects. Or something! There are so many things I want to do, and while it's unrealistic to think I'll get all of them done for the game jam I definitely want to try to do as much as I can.