SpritesMind.Net

Hi there,

I'm not into the Sonic scene so is there someone here which can point me to technical info about the speed of Sonic ?

I mean, how did they manage to get hscroll so fast, w/o flick and with to many tile collide detection (like for the loop!) ?

I dislike my hscroll so I'm looking for better way to handle it....

Regards

Try the Sonic Physics Guide at Sonic Retro. I haven't looked at it in a couple of months, but it might have info on scrolling planes.

ValleyBell might have some first-hand info as well, so maybe look for him too?

This guide on Sonic Retro seems pretty good. The Solid Tiles section seems to cover the basics of collision detection.

That doesn't cover how the tilemap is updated or how new tiles are loaded though. Is that part of what you're looking for? I assume they just use a 64x64 tilemap (or maybe 128x32 since you scroll horizontally more than you do vertically) and then updates a portion of the offscreen tilemap as you move. I believe the Sonic games have a sort of two-level map for level data so that levels are constructed of larger blocks of tiles. I also seem to remember that there are certain trigger points in a level for loading new tiles.

EDIT: Seems neologix beat me to the punch.

Yes levels are constructed using smaller blocks and larger chunks. In the sonic games levels are constructed like this tiles->blocks->chunks->chunk layout. In all sonic games blocks are 2x2 tiles large. In sonic 2 and 3 chunks are 8x8 blocks in size however sonic 1 uses chunks that have the size of 16x16 blocks. Blocks are stored just like the VDP stores tilemap data. Chunks also store some collision data and if the blocks are flipped. I would like to point out that the disassembles for sonic are quite good see https://github.com/sonicretro

to scroll background fast, best way is update one column (in each background without DMA), and one row (with DMA)
Collision: make collision tests with few picks (check some data at certain points, don't use loops).

r57shell wrote:to scroll background fast, best way is update one column (in each background without DMA), and one row (with DMA).

That's interesting! Why isn't using DMA for columns better? Can't you use auto inc?

djcouchycouch wrote:

r57shell wrote:to scroll background fast, best way is update one column (in each background without DMA), and one row (with DMA).

That's interesting! Why isn't using DMA for columns better? Can't you use auto inc?

You only get adjustable auto increment on the VRAM side. If you're tilemap is laid out on the 68K side like it is in VRAM, entries for a column won't be sequential on the 68K side.

And why would it be laid out like that? Usually your levels are made out of larger tiles, and you only generate rows and columns of VRAM tiles when needed. Otherwise you run out of space fast. In the rare event that you do have a tilemap in ROM or RAM, it's probably still better to get the column data ready beforehand so that you can quickly DMA it during V-Blank, depending on how much other data you need to write.