Makes multi-pixel sprites a possibility. This is the base for the snake game (on snake_mru branch). Some things that may not be quite right: I've called the full collection of pixels that the sprite occupies pixels. That name is a little jarring to me, because the sprite isn't mean to know that it lives in a pixelated world...
Also, there's the inherent choice to base the "pixels" on an absolute frame, rather than relative to a location. This makes it much easier for the snake game, whose growth depends on where it actually is. But for static sprites (in terms of their relative shape), it would be easier to define a "region" of pixels relative to a single location which itself moves. I don't know how to get the best of both worlds.
Another downside here is that I've had to change several pieces of code that check for co-location so that they go through a list of pixels and do the check, which is just a bit more computationally intense. But it's probably fine.
Makes multi-pixel sprites a possibility. This is the base for the snake game (on
snake_mrubranch). Some things that may not be quite right: I've called the full collection of pixels that the sprite occupiespixels. That name is a little jarring to me, because the sprite isn't mean to know that it lives in a pixelated world...Also, there's the inherent choice to base the "pixels" on an absolute frame, rather than relative to a location. This makes it much easier for the snake game, whose growth depends on where it actually is. But for static sprites (in terms of their relative shape), it would be easier to define a "region" of pixels relative to a single location which itself moves. I don't know how to get the best of both worlds.
Another downside here is that I've had to change several pieces of code that check for co-location so that they go through a list of pixels and do the check, which is just a bit more computationally intense. But it's probably fine.