Sonic The Hedgehog 16-bit on Uzebox

Use this forum to share and discuss Uzebox games and demos.
lightfoot256
Posts: 119
Joined: Wed Jun 10, 2009 2:53 pm
Location: South Yorkshire, England
Contact:

Re: Sonic The Hedgehog 16-bit on Uzebox

Post by lightfoot256 »

I was thinking today about the lower resolution that I wanted to achieve and I just wanted to throw out some numbers to see if I'm on the right track.

Current video mode 3 uses a 224 pixel video width and something like 200 pixels high. I was planning on dropping this on my sonic game to around 160x100. My main reasoning is that now that everything is 50% of the original it'd make sense to make the screen resolution close to 50% as well to keep scale :-p.

If we're currently using 7 clocks per pixel over 224 pixels, that's 1568 (visible?) clocks per line. Because the vertical resolution is half of the original I can render the same line twice in a row and if I'm going to do that I might as well store the first one in a buffer; so I started thinking about using a buffer entirely. If I buffer up 160 pixels of data before each line (starting 2 lines early in the non visible region), I only have to use 3 clocks (2 to read from buffer and 1 to output) per pixel and space them enough so that they stretch over the original 224 width.

Working this out in numbers, The 224 pixel width has 1568 clocks per line but because I'm doubling lines I could say I have 3136 clocks per line (probably more if I can utilise space in the non visible region); Dividing this into 160 pixels I get 19.6 clocks per pixel so rounding that up to 20 I get a horizontal resolution of 156.8 pixels (I guess you'd only see 0.8th of a pixel :-p). If it only takes 3 clocks to render a pixel from the buffer that's 17 clocks to fill the buffer (per pixel) and if I build one buffer while outputting the other you'd just need to switch buffers every other line (2 real lines).

17 clocks per pixel, or 136 clocks per tile is a huge amount of time to do lots of crazy stuff that's not currently possible; I don't want to speculate but I think you might be able to remove the need for vram riles entirely and do sprites and everything on the fly.

The downside to all of this is that the resolution is much much lower - but I don't care cause it's all relative to the sprite and If it plays okay I don't think you'd ever notice :-p
User avatar
pragma
Posts: 175
Joined: Sat Sep 20, 2008 2:16 am
Location: Washington, DC

Re: Sonic The Hedgehog 16-bit on Uzebox

Post by pragma »

lightfoot256 wrote:The downside to all of this is that the resolution is much much lower - but I don't care cause it's all relative to the sprite and If it plays okay I don't think you'd ever notice :-p
Look at it this way: the original gameboy had a resolution of 160x124. The Uzebox has access to 256 colors on top of that. I'd say that the increased clock count per pixel, and reduced graphics footprint open up a *lot* of potential here.
lightfoot256
Posts: 119
Joined: Wed Jun 10, 2009 2:53 pm
Location: South Yorkshire, England
Contact:

Re: Sonic The Hedgehog 16-bit on Uzebox

Post by lightfoot256 »

Yeah; Once you see the resolution with the sprites and tiles inside it doesn't look as bad as you first think. My new concern - that I never thought about was sonic/sprites being rendered under tiles (i.e. when sonic passes through the last bit of the loop), hopefully I'll have enough clocks to do some sort of masking but I'm still learning so we'll see how it goes.

Anyway, I started hacking away at Mode 1 as it was the most simplest to learn from; I managed to get the 160 pixels and I managed to get alternating buffers working pretty fast; I don't know enough about avr-assembly and the winavr variant so it took me a while to get going (I think I spent an good 30 minutes trying to figure out how to use macros, .endmacro doesn't exist!?!?! so I tried .endm and it worked! ha, only thing is I couldn't get arguments working so I ended up giving up... It also took me forever to realise the "mul" instruction stores the result in r1:r0, I couldn't for the life of me figure out how these two registers were being set until I started reading the instruction set manual line by line.

Anyway; I'm starting to "think" in clocks and assembly now; I've spent most of my life as a C/C++ programmer and never had to care about this stuff so it's a big leap at first but once you get the hang of it its pretty simple. Hopefully progress should be faster.

One thing I did notice, I have 3 16-bit pointers: X,Y and Z... If I'm reading from a buffer using one, writing to one using another, and then using one for reading from vram, what do I use to then read the tile data... are these XYZ registers just names, could I do the following: "ld r16, r24+" and treat r25:r24 as a pointer? Failing that I could always push one of the XYZ and pop at the end.

Chris
User avatar
pragma
Posts: 175
Joined: Sat Sep 20, 2008 2:16 am
Location: Washington, DC

Re: Sonic The Hedgehog 16-bit on Uzebox

Post by pragma »

lightfoot256 wrote: One thing I did notice, I have 3 16-bit pointers: X,Y and Z... If I'm reading from a buffer using one, writing to one using another, and then using one for reading from vram, what do I use to then read the tile data... are these XYZ registers just names, could I do the following: "ld r16, r24+" and treat r25:r24 as a pointer? Failing that I could always push one of the XYZ and pop at the end.
That also threw me off, when I first started doing AVR assembler. X,Y, and Z are just aliases for the upper-most registers: Z = 31:30, Y = 29:28 and X = 27:26. So if you need more than three pointers, or need to read from ROM with more than one pointer (Z is the only one that can access ROM), you need to reload your pointer values or save them somewhere for use later. As you observed, using push/pop works - in fact, it's amazing efficient.
lightfoot256
Posts: 119
Joined: Wed Jun 10, 2009 2:53 pm
Location: South Yorkshire, England
Contact:

Re: Sonic The Hedgehog 16-bit on Uzebox

Post by lightfoot256 »

Not so sure about using push/pop as they take 2 cycles each - I wonder if movw would work better as it only takes 1 cycle if you had enough registers to play with. Bleh; I'm sat with the atmega644 documentation trying to calculate what I can fit into these limited cycles :-D.
lightfoot256
Posts: 119
Joined: Wed Jun 10, 2009 2:53 pm
Location: South Yorkshire, England
Contact:

Re: Sonic The Hedgehog 16-bit on Uzebox

Post by lightfoot256 »

I've not had much time over the last week to do any real work so no progress in code but I've been thinking a lot about squeezing the resolution down even further to get even more clocks per pixel and using palettes and save tonnes of memory in flash.

Using the 224 pixel width as a guide - at 7 clocks per pixel, we have 1568 clocks per line. So using a 120 pixel resolution I get just over 13 clocks per pixel. This means the screen is 15 tiles (using 8x8 tiles) wide and the buffer holds 16 tiles of data for fine scrolling.

Using the line-doubling method and buffering, I can read from the buffer using 3 clocks leaving 10 clocks to write per line but because we're doubling the lines and reading the same data on both, I actually get 20 clocks per pixel (nearly 3x that of the original resolution). I have to interweave the output code every 10 clocks that lasts for 3 clocks and I know I'm going to have an issue here without rolling out the entire line into one method but we'll see how that goes.

Anyway, now that I have a buffer and tonnes more clock cycles, I was going to be really wasteful an run the rendering in 3 stages. First render the far background layer really fast using 4x8 tiles stretched to 8x8, then the forground layer with transparency (and also write to the sprite-masking buffer) and then the sprites using the masking from the foreground layer to allow tiles to appear in front of sprites. From my initial (very very basic) calculations, I can have about 8 sprites on each line and have both backgrounds with scrolling with about 24 clocks to spare!

And the fact that I'm doing everything on the fly means the video data only consumes about 1k of ram! :-p Also compressing the sprites and graphical data into 4bpp means I have loads more room in flash for more levels :-p

It's still all theory and probably weeks away from working but I just thought I'd share my progress; I might try and mock up some screens to see how the new resolution copes; 120 pixels works out at 75% of the original sonic game (relative to the sprite which is now 50% :-p) but maybe I can use some clever camera positioning to give you a better view ahead when running.

Maybe I'm getting too bogged down with the video side of things but it was the video stuff that drew me to this project in the first place so... :-D
User avatar
pragma
Posts: 175
Joined: Sat Sep 20, 2008 2:16 am
Location: Washington, DC

Re: Sonic The Hedgehog 16-bit on Uzebox

Post by pragma »

lightfoot256 wrote:Anyway, now that I have a buffer and tonnes more clock cycles, I was going to be really wasteful an run the rendering in 3 stages. First render the far background layer really fast using 4x8 tiles stretched to 8x8, then the forground layer with transparency (and also write to the sprite-masking buffer) and then the sprites using the masking from the foreground layer to allow tiles to appear in front of sprites. From my initial (very very basic) calculations, I can have about 8 sprites on each line and have both backgrounds with scrolling with about 24 clocks to spare!

[...]
I might try and mock up some screens to see how the new resolution copes; 120 pixels works out at 75% of the original sonic game (relative to the sprite which is now 50% :-p) but maybe I can use some clever camera positioning to give you a better view ahead when running.
Personally, I would love to see that. As proud as I am of the work I've done on my own video mode, I have deep concerns for only getting 4 sprites per line, per frame. If the reduced resolution yields enough detail to be useful, I may wind up going that route myself. Also, the reduced memory footprint has other implications for using data from the SD card... how much SRAM is free with your engine?
Maybe I'm getting too bogged down with the video side of things but it was the video stuff that drew me to this project in the first place so... :-D
Honestly, I realized a long time ago that's probably how Uzebox development is supposed to work. ;)
lightfoot256
Posts: 119
Joined: Wed Jun 10, 2009 2:53 pm
Location: South Yorkshire, England
Contact:

Re: Sonic The Hedgehog 16-bit on Uzebox

Post by lightfoot256 »

pragma wrote: how much SRAM is free with your engine?
Like I said, I've not written any code yet but from my plan I have:

Code: Select all

foreground:		16x12	192 bytes
background:		8x12	 96 bytes
sprite-data:	  32x20   640 bytes
buffers:			2x160	240 bytes 
palettes:		  4x16	 64 bytes
total vram:			  	1232 bytes

total ram:			  	 4096 bytes
remaining:			  	 2864 bytes
I think 32 sprites per screen is "enough" and I assumed they'd use 20 bytes to describe, 16 bytes for a 4x4 sprite, 2 bytes for x and y, 1 byte for width and 1 byte for palette table. I could probably pack the data into smaller bytes but it seems like it'd be a waste of cycles to extract it each time.
rogerlevy
Posts: 7
Joined: Thu Jul 09, 2009 1:45 am

Re: Sonic The Hedgehog 16-bit on Uzebox

Post by rogerlevy »

Your video mode sounds interesting, I hope it's successful because I may want to play with it once I get a uzebox. :)
Cheers
Roger
User avatar
paul
Posts: 457
Joined: Sat May 02, 2009 8:41 am
Location: Brisbane, Australia

Re: Sonic The Hedgehog 16-bit on Uzebox

Post by paul »

I just noticed while playing 2P Sonic 2 on the megadrive that there is a ton of slow down. Especially when someone drops their rings or if there's multiple enemies and platforms. I guess I just didn't consider it when I was a kid.

Can't wait to play the Uzebox version - I bet it has no slowdown whatsoever :D
Post Reply