Sonic speed ?

Ask anything your want about Megadrive/Genesis programming.

Moderator: BigEvilCorporation

Post Reply
KanedaFr
Administrateur
Posts: 1128
Joined: Tue Aug 29, 2006 10:56 am
Contact:

Sonic speed ?

Post by KanedaFr » Wed Aug 13, 2014 4:08 pm

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

neologix
Very interested
Posts: 122
Joined: Mon May 07, 2007 5:19 pm
Location: New York, NY, USA
Contact:

Post by neologix » Wed Aug 13, 2014 6:38 pm

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. :D

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

Mask of Destiny
Very interested
Posts: 591
Joined: Thu Nov 30, 2006 6:30 am

Post by Mask of Destiny » Wed Aug 13, 2014 6:53 pm

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.

sega16
Very interested
Posts: 251
Joined: Sat Jan 29, 2011 3:16 pm
Location: U.S.A.

Post by sega16 » Wed Aug 13, 2014 9:32 pm

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

r57shell
Very interested
Posts: 478
Joined: Sun Dec 23, 2012 1:30 pm
Location: Russia
Contact:

Post by r57shell » Thu Aug 14, 2014 2:42 pm

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

djcouchycouch
Very interested
Posts: 683
Joined: Sat Feb 18, 2012 2:44 am

Post by djcouchycouch » Thu Aug 14, 2014 4:05 pm

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?

Mask of Destiny
Very interested
Posts: 591
Joined: Thu Nov 30, 2006 6:30 am

Post by Mask of Destiny » Thu Aug 14, 2014 5:24 pm

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.

Gigasoft
Very interested
Posts: 89
Joined: Fri Jan 01, 2010 2:24 am

Post by Gigasoft » Sat Aug 16, 2014 8:23 am

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.

Post Reply