Sonic The Hedgehog 16-bit on Uzebox

[lightfoot256]

Yeah; I recently got the mega drive and Sonic 1 and 2... Actually ended up with 2 copies of each as sombody sent me the wrong catridge, I bought another and then they sent the replacement anyway and told me to keep the original!! heh, I might take the spares to bits to see what's inside :-p.

But yeah; First thing (that I knew about anyway) was how much slower 50Hz PAL is to 60Hz NTSC, I've been playing Sonic in the emulator (at 60Hz) for a long time without realising it was slightly faster than when I used to play as a kid so that was a little strange to get used to and yeah there are tonnes of slow downs even during the boss stages it appears just too much is going on. I can also see lots of graphical errors where they're reaching the max sprites per scan line but again I never noticed it when I was younger :-p.

Took me about an hour and a half to get the last level of Sonic 2 to spend 2 minutes loosing all my lifes and not getting anywhere - I switched on the level select and STILL i wasted another hour trying to defeat that boss, switching to debug mode I hit it first time :-p but seriously that last bit is impossible :-p. Killing the metal sonic is easy as you can cheat a little with the spin dash but I didn't figure out how to defeat the final bit without cheating with debug .

Sonic 1 is easy; I've played that to death; Took me about 30 minutes to complete game without messing with emeralds :-p I like how it sorta taunts you to play again though if you didn't get them all - can't remember what the animation looks like when you win... is he jumping up and down or somthing? Been a long time...

And last but not least, the controllers are RREEAAALLLY uncomfortable, geeez who's idea was that? I can remember when PSX came out and everybody was saying how nice the pad felt in your hand, heh, oh the days :-p.

Not had much chance to work on the Sonic port; I got uzem running under linux and managed to port over my projects from the windows drive and that was about it; Definately loving Ubuntu 9.04; Speedy! :-p

[DaveyPocket]

Recently, I started playing Sonic CD again(it's awesome!), and that(being a CD game for the Sega CD expansion) has lots going on too. It looks tough putting all of that into the small memory of the ATMega644.

I recommend finding a Sega CD(Mega-CD) attachment for your Genesis and grabbing a copy of Sonic CD, or you can find the PC version.

[lightfoot256]

So I've been writing lots of pseudo code to get my ideas for this new video mode down in code without having to worry too much about AVR-specific things - then once I was happy I started breaking the code down into blocks and writing more pseudo assembly to get an idea of the amount of clocks it would require...

So my first attempt involved using palettes to try and compress the tile data in ROM - However, trying to pack 2 pixels into 1 byte introduces 4 "swap" instructions and 8 "and" instructions to get the color index - you then need a further 7 clocks to index into the palette (per pixel), read it's value and then output to my line buffer....

Pulling out the values from flash and organizing into registers:

Code: Select all

			clr		r17						// 1	blank, used for ADC further down

			lpm		r18, Z+					// 3	load 8 pixels into 4 registers
			lpm		r20, Z+					// 3
			lpm		r22, Z+					// 3
			lpm		r24, Z+					// 3
			mov		r19, r18				// 1	copy pixel data next 4 registers for our 8 pixels
			mov		r21, r20				// 1
			mov		r23, r22				// 1
			mov		r25, r24				// 1

			swap	r18						// 1	switch 4 of the registers to get the other pixel
			swap	r20						// 1
			swap	r22						// 1
			swap	r24						// 1

			andi	r18, 0x0F				// 1	ensure we're only looking at 1 pixel per register
			andi	r19, 0x0F				// 1
			andi	r20, 0x0F				// 1
			andi	r21, 0x0F				// 1
			andi	r22, 0x0F				// 1
			andi	r23, 0x0F				// 1
			andi	r24, 0x0F				// 1
			andi	r25, 0x0F				// 1

Indexing the colour in the palette, this would need to be repeated 8 times for each register.

Code: Select all

			mov		Z, palette				// 1	render a pixel via the palette
			add		Z, r18					// 1	offset into palette
			adc		Z, r17					// 1
			ld		r16, Z					// 2	read the colour from the palette
			st		Y+, r16					// 2	write value to buffer

I think the above totals around 84 clocks per tile layer and that's not even taking into account scrolling. I also only have a budget of around 57 clocks to render a tile so already it's way over.

I started thinking about leaving the graphics data in 256-colour form and compressing the tiles another way...

Having 128 tiles, each using 64 bytes (8x8) totals 8k. There are 1024 tile rows (8x1 slats) and obviously 8 rows per tile... however, using my current tile sheet mappy recons this can be reduced to 395 unique tiles and using a lookup for each tile to point to the right slat introduces 512 bytes (64x8) giving a grand total of 4184 bytes or a 49% reduction in size - which is pretty close to 4bpp and should hopefully require less code. I'll have to use a different background tileset that's a lot more static than GHZs running water - or simulate the same effect by swapping out whole tiles.

I did look a little into a tile rendering instruction set similar to PNG compression but the tiles are soooo small it ends up not being worth it - if a tile isn't too complex it can weigh in just under 50% it's original size but as soon as you start using more detail it's way over the original.

[lightfoot256]

Actually... the tile slat index would have to be 2 bytes to index the 395 tiles - which makes it a bit worse.

Tiles then compress with 35% reduction, sonic with 17% reduction and the other sprites only 11% reduction - It still totals 6k of saved space so it's still worth it if the clocks to make it work aren't that high.

[lightfoot256]

Just wanted to mention that I'm still thinking about this project and it's not officially dead . Just getting held up with the video mode requirements and trying to plan it out before I spend time implementing it in avr assembler... still aiming for:

• 120x88 resolution
• 8x8 map and sprite tiles
• 16x12 foreground and background map
• 256 colours
• 32 on screen 8x8 sprite chunks
• 8 sprite chunks per line.
• sprite masking for main character
• sprite based hud (albeit small :-p)

My main goal is to define a system first and get that working; I've been thinking about writing a script to generate the assembly code though as I really can't come to terms with trying to make all of the above cycle accurate. Essentially I'm following the original plan of writing to one buffer while the other is being output to the screen and then switching the buffers once done.

I also started re-drawing the hud, tiles and sprites in the uzebox palette and at the lower resolution so they don't look so sucky and also to see how they look. I was also thinking about having "function" based levels where you have a system that basically runs a function i.e. sin(x)*sin(x/2)*sin(x/4) and generates a series of values and each value of x represents a block in the level -- the levels would be pretty random but you could add extra fields in the function to even it out as you please; then levels can just be composed of a series of bytes to represent the arguments to the function... still needs fleshing out but saves tonnes of memory for maps as you'd just generate the map as you go.

Anyway; enough teasing for the time being... so much to do and so little time

[lightfoot256]

Can you believe it's been over 4 years! Time sure flies...

Anyway; Someone asked me how the Sonic project was going and I decided to start it up again -- this time without writing my own video mode and just making it with with all the wonderful stuff that exists already.

I finally caved and just shrunk sonic to be 2x3 sprites; I care more about completing _something_ now rather than trying to make it look like the original. Guess age makes you wiser and more sensible about your goals.

[uze6666]

Heeeey Chris, really nice to hear from you... Yeah it's hard to believe 4 years goes by so fast! Seeing sonic back on track is very exciting, be sure to let us know any question to help out. For one, you will need the latest emulator since it supports the latest kernel in the trunk plus other goodies like Sd card support. If you get to compile it for Mac, send it to me, I'll add it to the binaries in Svn. The latest mode 3, supports more ram tiles which could come handy.

[Harty123]

Hi Chris

I'm curious about the finished game. Good luck!

-Harty