Sonic and Sega Retro Message Board: TapamN - Viewing Profile - Sonic and Sega Retro Message Board

Heh. I actually made a floor editor like that about three or four years ago, written in VB6. It even read in the graphics the same way. The biggest difference was that you had a palette of tiles on the right rather than using a spinbox, and a menu bar for selecting the MAP/PLY files and saving.

It's in the (awesome) credit sequence, near the end.

I've already got Metal Sonic's sprites.

Edit: These are from the PC version. I see a few Sonic sprites in your's that I didn't get (frozen Sonic), but I think all of the Metal Sonic and Special Stage sprites are in there.

This may sound rather odd bringing this up so suddenly, but I happened to be thinking about how a framebuffer would be done on the Genesis earlier today... Except I was trying to figure out how one would do a linear framebuffer instead of formating it into tiles (as a glance at the VRAM shows this demo does).

I'm not too sure how well this would work though, but... my algorithm is as follows:

First, set the top left most cell to display the first 8 horizontal pixels of the linear framebuffer. Only the first 8x1 pixels of the framebuffer are linear at this point; the pixel data that should be to the right is one line below it because of the tiling.

On the cell to the right of the previous one, place the same tile. But now, one would use the vertical scroll to scroll that cell up one line. This places what was below the previous tile to the right of it, how a linear framebuffer would have. Meaning now there's a 16x1 area of linear framebuffer.

Repeat that across the line switching tiles every 8 cells.

Erm... that seems like it would be hard to understand... Er... imagine a tile map were the first row has it's first 8 columns set to the same tile. Now use the VDP's vertical scrolling to scroll each column up X pixels, where X is it's column mod 8. (I.e. column 0 is scrolled up 0 pixels, column 1 is scrolled up by 1 pixel, column 2 is scrolled up by 2 pixels. Column 8 would be scrolled up by 0 pixels, and col. 9 is 1 pixel up.) Now the first 64 pixels on the first row of pixels would display they tile they are set to linearly. Three more times across the first row of the tile map to have 256 pixels of linearly accessable framebuffer.

That still sounds messy... Ah, I just make a picture.
 framebuffer.gif (1.79K)
Number of downloads: 42
The top left block is the first 64 pixels of the linear framebuffer shown as a tile. The first row of color is how the tile should be arranged in the tile map, without vertical scrolling. The second, diagonal line shows the tile map with vertical cell scrolling. The bottom line shows how the first 64 pixels of the line are; the "tile" has been turned in a small, 64x1 linear framebuffer.

The problem is getting more than one line to display properly.

By placing the tiles on a 32 tile by 128 tile name table (256 pixels by 1024 pixels) and then scrolling the map up one tile each h.blank, it would be possible to have the top 256x128 pixels of the screen represented by a linear framebuffer using one name table. With the second table, the rest of the screen could be displayed.

One problem with this is RAM: there's not enough VRAM to double buffer. Two framebuffers are 256*224/2*2=57344 bytes, and two 128*32 tile name tables are 8192*2=16384 bytes... totaling 72 kB. Dropping one name table to 32*96, the minimum required (96+128=224), just drops 2 kB off the requirements. It might be possible to use one name table and DMA in the data for the second name table, bringing the whole thing down to 64 kB. There are still a few other problems... Is it possible to completely disable sprites, or would the sprite pointer be forced to point to FB or name table data? DMAing in more of the name table and setting aside some as a scratch might work...

He might have just changed his mind. He could have decided that the speed increase wasn't worth the extra code size. There's a 460 byte difference between Sonic 1 and STB's object executing code, as well as a 482 byte difference between PS2 and STB. Both of these games are far more complex than STB and would benefit from any easily saved ROM space.

(Also, has anyone disassembled Phantasy Star 1? Even if it's on a different CPU, it'd still be interesting to see how much crossed the 8 bit barrier.)