Mode 1 12x12 trick?

[Ramsis]

(Doesn't the SA-1 also have division registers?)

Earth @Espozo, read your docs, and you'll find that the SNES CPU has built-in hardware multiplication/division, in case you didn't know/care.

[tokumaru]

Yes, the inside of these blocks might use more conventional block sizes, but the program still has to find the outer blocks in the first place, and for that a division would be necessary. I know these systems have hardware division, but it's still significantly slower than bit shifting, right?

[Nicole]

Given the fact that the 65816 can only shift one bit at a time, it's not quite as bad as you might expect.

Division is done by doing one 16-bit store and one 8-bit store, waiting 16 cycles, then reading the result. However, you can also do other things during that wait period, so if you're clever about arranging your code, it's not too bad.

[Sik]

Well, both games have hardware that natively supports division... (Doesn't the SA-1 also have division registers?) It's always possible that they're still checking collisions in with 8x8 or 16x16 blocks in those blocks.

GBA doesn't have division as a CPU instruction, IIRC the division support is in software. But since Sonic Advance does it just for scrolling then maybe it just keeps track of the distance travelled instead?

I find it really odd that games like Kirby's Super Star and Sonic Advance, which rely a lot on scrolling, have works built from blocks whose dimensions are not powers of two, because rendering scrolling playfields and colliding with maps are much simpler tasks when you can mask and/or shift bits. Do these games use actual division to access their level maps?

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).

[tokumaru]

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.

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!