Sik wrote:
But since Sonic Advance does it just for scrolling then maybe it just keeps track of the distance travelled instead?
Yes, you could have variables for the top, bottom, left and right edges of the camera, counting the number of blocks from the beginning (top left) of the level, as well as the pixel coordinates within the current block, and avoid divisions altogether (in fact, in my own NES scrolling engine I do this with the vertical scroll for drawing the map, to handle the fact that name tables are 30 tiles tall, not a convenient power of 2), but normally you'd also need to read the map in order to test collisions between objects and the level's geometry. I guess you could have block counters for objects as well, but when you consider that you need to check multiple points for collisions, and that objects are spawning all he time, that seems a bit awkward.
Quote:
In Sonic Advance's case, the problem is that 64×64 is too small while 128×128 is too large for the proportions they're using, so using something like 96×96 is pretty much the only option that isn't switching to an alternative method altogether. I guess the GBA is powerful enough to not make it a serious issue though. Also 96 is the sum of 64 + 32 (both powers of two), and is a multiple of the latter, so I guess there's still something they can take advantage of, especially when it crosses the tilemap boundary (since it knows that a 32×32 chunk will not cross one).
Yeah, I can understand why that number makes sense for level layouts, but programatically, it sounds troublesome. You're right though, this is not as bad as I'm making it out to be, it's not like the blocks are 75x83 pixels or something crazy like that!