Sonic 1 CDSS Edition

The Sonic CD special stages have always had a distinctive roll in the series and with that, it was unique. One of the things we achieve in “Sonic hacking” is proving the impossible with concepts in action. Today, I am going to show you one of those concepts:


Sonic 1 CDSS Edition - (Sonic CD special stage in Sonic 1)


Download


Collect 50 rings, and jump into the stars floating above the lampposts.


http://www.youtube.com/watch?v=EFefE3r8mQA


Firstly, a special thanks to Zone-Zero for the special stage map rips, it saved me a lot of time.


I’ve known for a while that the Mega Drive has certain limited capabilities on the hardware side of things, though any programmer will tell you that if you know the hardware well enough, you can cheat any machine into achieving the impossible by software, so I set out the task of recreating Sonic CD’s special stages onto the Mega Drive with the only modifications being software.


17th June 2012


The first revision was a predictable failure, I had attempted to take individual tiles and stretching them one by one into a buffer space, and later DMA flush them off, the time consumption and the quality was very terrible. One of the issues was that it wouldn’t stretch on the Y axis, only the X.


19th June 2012


The second revision was a test; I used a trick that “old skool” game programmers used to use, altering the plane’s vertical scroll position during H-blank intervals, it was successful, but that was no surprise (I had done this before), the issue I ran into later on though, was that the VDP’s address/mode would change to VSRAM write mode every H-blank line occurrence, and flushing the art out to VRAM in a single frame was a no go, the only way around that would have been to store the VDP’s current mode and restore it every H-blank, though that would require counting while writing, and frankly that takes up further processing time.


28th June 2012


The third revision had nothing to do with stretching, scaling or rotation of any kind, it was more of a setup, a preparation if you will, I wrote up a quick tool to convert a bitmap image of Selbi’s splash screen into a 400x400 (hex) pixel tile, with this I would have the art in scan lines rather than having to navigate my way through the silly 8x8 tile format, it did however mean having the data uncompressed on the ROM as there weren’t enough RAM space for a 100000 byte tile image (and there never will be if I’m sticking to software only). Surely enough I managed to display the image, but the processing time required to flush it off and write it into the buffer correctly became problematic.


29th June 2012


For the fourth revision, I rewrote the way it sent art to VRAM, instead of writing it to a buffer and then transferring it off, I wrote the art directly to the VDP port quad pixel by quad pixel, in general this would be assumed as slower, but due to having the tiles setup mapped in order vertically, and having the VDP’s auto increment mode set to a singular tile’s X line worth, I would only ever need to set the VDP address/mode twice through the entire drawing routine, it was tricky, but it enabled me to bypass the 8x8 tile system to a further degree, and it proved to be much faster.


Following this I proceeded to apply the rotation algorithm, it wasn’t working too well, it left the image line rotating correctly, but the pixels weren’t rotating the same way, I later realised that the X and Y increment values needed two sine waves, each one being loaded into a dedicated integer space so that the decimal place (floating point) space would not clash with each other.


30th June 2012


The fifth revision had the two sine waves applied, an alpha for scanning along horizontally 1 pixel, and a beta for scanning along vertically (horizontally 400 pixels), I had also changed the tile mapping format, made it a little more flexible and allowing me to change the number of tiles to be mapped/drawn from centre screen down and outwards (hence, if I wanted to, at the cost of less art I could increase speed with the change of a simple value).


1st July 2012


The sixth revision I replaced Selbi’s art with one of Sonic CD’s stage map art, Selbi’s art was a good enough example for the rotation test, but due to its small size I could not tell if the entire 400x400 image was being displayed or not. Sonic CD’s stage art is 800x800 pixels, my engine could only read 400x400, but it occurred to me that my engine had no restrictions at this point, and that moving outside the art space would cause it to continue down the ROM, moving out on X caused it to move onto the next scan line (thus seeming as though it were wrapping), while moving out on Y caused it to read further down (and up) the ROM.


In simple terms it means the Y size of the image would only be as limited as the ROM size itself, I was able to fit in half of the stage size (400x800), I cleaned up the controls a little, and had a simple displaying/rotating Sonic CD special stage level rendering in real time, and was able to move about in it like a real game, however, it was still from a bird’s eye view.


2nd July 2012


The seventh revision was tricky; I honestly thought this would have been a lot easier than the rotation, I was wrong, my many attempts to somehow incur the illusion of distance failed, or well, they half failed. The day wasn’t a complete waste though, thanks to OrdosAlpha who had brought up something I had completely forgotten about, the screen display mode selection, the Mega Drive’s VDP can display two different widths of tiles, one being 28 tiles horizontally, the other being 20 tiles horizontally, but stretched evenly, by using 20 instead of 28, it would mean needing to draw less tiles for display, thus freeing up a bit more processing time (2 frames worth to be the exact).


I had also changed the plate size from 400x??? to 800x??? I set the X size as 800 fixed which gives it enough space, and as for the Y, it’s limited only to the ROM’s size.


3rd July 2012


The eighth revision was close, I tried altering the angle while loading a new X/Y Alpha/Beta positions each V line draw, this caused the sides to bend similar to that of a camera with fish eye perspective, unfortunately this isn’t the perspective I’m looking for, but it’s still an interesting point of view. It’s back to the drawing board.


16th July 2012


I did initially finish this revision a lot sooner, but put it to rest for a while due to it being inaccurate to the perspective I was looking for, not to mention to huge lag, the issue I’ve found is that the X sizing keeps “bending” when I don’t want it to, and the Y sizing I do want “bending” but it appears to be bending to opposite direction, the ninth revision was a failure, but not in vain, at least now I can look away from this method and progress harder.


17th July 2012


For the tenth revision, I had worked out how to bend the Y sizing in reverse, originally I was trying a method of taking a certain value with a quotient and divisor, adding it to a memory space, then adding that to another memory space, and then adding that to the current Y position, what I should have been doing is taking a certain value with a quotient and divisor, adding it a memory space, then adding that to the current Y position, but then, adding a fraction OF the core’s quotient/divisor value onto itself, that is where I had went wrong the first time around.


The eleventh revision has the method applied with the alpha/beta sine waves; the perspective is good enough for my liking, though I now need to eradicate the lag.


21st July 2012


For the twelfth revision, it had occurred to me that the calculations for the perspective, couldn’t be optimised any further, 14 frames for every redraw is below unacceptable for playability, I was discussing this on IRC as was recommended to use more look up tables, generally speaking, the idea did cross my mind to start with, my reason for not going with that method was down to ROM space, I had calculated that having a table of positions for each angle of each pixel in each tile would be (20 X tiles, 0E Y tiles):

• 20 x 0E = 1C0 x (8 x 8) = 7000 (pixels) / 4 (pixels per byte squared) = 1C00 x 4 (long-word) = 7000 x 100 (angles) = 700000 bytes (7 decimal Mega Bytes).

7 Mega Bytes is simply too much, one of the rules I said I would follow is keeping the ROM within 4 Mega Bytes, that way it will be compatible with emulators that don’t emulate bank switching (at all or correctly), the plate itself is big enough as is, the last thing I wanted to do was use 7 times more.

Though compromising and taking some minor shortcuts made it a little more bearable, by that I mean:

• 7000 x (100 / 4) (angles) = 1C0000 bytes (1.75 decimal Mega Bytes).

And by performing another minor software calculation (negation), I was about to cut down on half the angle size data, and reverse the positions for the other half angles:

• 7000 x ((100 / 4) / 2) (angles) = E0000 bytes (0.875 decimal Mega Bytes).

It still proves to be a lot of memory just for a lot of insignificant pixels, but acceptable enough to build a ROM under 4 Mega Bytes.

I wrote a tool to create these tables ready, but I only applied rotation alone, not the perspective, I rewrote the software to read from these tables and apply directly with little to no calculations required, and for the test, it proved to take about 4 frames to draw, this is by far the best results yet, once the perspective is pre-calculated onto the tables, it will mean that the processing time will never change, i.e. it will still take 4 frames to draw even with the perspective placed in.

22nd July 2012

Still on revision twelve, I placed in perspective towards my tool, getting the right perspective was a real challenge, it seems the one closest to Sonic CD’s didn’t work out very well, due to the pixels being x2 the size, I got confirmation from a few individuals in IRC, after producing four different ROMs with four different perspectives.

Y = Vertical tile count, X = Horizontal tile count, V = VRAM starting point, YD1 = Vertical stretch Division of sine wave, YD2 = Vertical stretch Division of current division, XD1 = Horizontal stretch Division of sine wave, XD2 = Horizontal stretch Division of current division

• X = 20 Y = 0A V = 09000000 YD1 = 01 YD2 = 06 XD1 = 20 XD2 = 07
  
• X = 20 Y = 0D V = 07800000 YD1 = 01 YD2 = 0C XD1 = 40 XD2 = 10
  
• X = 20 Y = 0D V = 07800000 YD1 = 02 YD2 = 08 XD1 = 40 XD2 = 10
  
• X = 20 Y = 0C V = 08000000 YD1 = 02 YD2 = 06 XD1 = 30 XD2 = 0C

The second one was preferred for perspective by multiple individuals. With that settled, I started getting in the BG design from the second stage, due to the positioning, I had to lower the vertical tile amount, but that’s not much of a problem considering the processing time I had saved from it.


26th July 2012


For the thirteenth revision, there wasn’t a lot of work related to the 3D rendering element of the stage, this revision was more for the growth of the other specific gimmicks of the level, including objects, collision and floor actions, HUD display, and the overall playability, all being recreated to near replicate Sonic CD’s playability. There have, however, been a few modifications to make the stage less frustrating than Sonic CD’s, but done without ruining what makes it a Sonic CD special stage.


With that in mind, a new map was made. Using graphics of the original stage, a new (compact) version was made to fit within the 800x400 range I had been limited to.


27th July 2012


I altered the algorithm for revision fourteen, to dump the art data to RAM, and then DMA transfer the data directly afterwards, though it seems that sending the art directly to VRAM manually is much quicker for this particular situation, the DMA method took an extra frame to perform correctly.


Hence, I have reverted back to using the old method.


28th July 2012


A few bug fixes for the fifteenth revision, nothing much, I’m getting tired now and wish to move onto more interesting things, I feel that the minor work such as displaying rings when hitting spikes and losing them, or the sparkles around the emerald when it comes on screen are unnecessary for a proof of concept hack, after all, the main concept has already been proven, as a deduction, my work here is finished.


I did want to replace the music, but I had run out of time for the contest, and I’m no miracle worker.

 

Just one word....


Incredible

 

It doesn't change the fact that I absolutely despise the CD special stages, but it surely shows off your skills and knowledge of the Mega Drive once again. Amazing work!

 

0:00:43, how lucky is that?


Anyway, great work. It is possible for the Megadrive! Love to see the improvements in the future. How you do these things are beyond me.

 

Another one of your gems to try out? I can't wait ^_^ !

 

Wow this is very cool I always thought that this is possible and you have proved it! It is so cool to play the special stages just like sonic cd it makes the real game feel inferior to the special stages. I have always really liked the sonic CD special stages and wished sega would have made a whole game with the same effect that did happen on the sega dreamcast (sonic jam and sonic r do not count) but back then it was much cooler to play with sonic in a 3D space than it was on the dreamcast because all games were in 3D.

 

Amazing like always MJ! It's amazing what you can do with Sonic 1, with the Mega Drive in general! See nothing is "impossible" unless if you set your mind to it, and have great skills. :V I just had a feeling that's what you've been working on, I saw your old signature. xP I eagerly await what else you have in store for us.

 

This is VERY cool.


It's amazing what you can do with the system. Projects with this level of complexity require not only skills but also effort and time spending (I'm pretty sure you started this significantly before 17th June, given the time consumption you mention on the post. And it went on until 28th July o_o)


For the record, these special stages are one of the very few things I like about Sonic CD. It's very nice what you've done so far to recreate them

 

Indeed it is OrdosAlpha. MarkeyJester, I have found sort of an oversight for the layout of GHZ in general. It doesn't matter if he has entered the special stage or not Here is the screenshot:





Now in GHZ's background, the layout is deformed for some odd reason, I' m not entirely sure if anyone has spotted this.

 

Strictly speaking, I haven't changed anything that would cause the original game to damage like that, either way I don't care too much about the original game, it is just a POC hack after all, thanks though.

 

Well I just needed to know if you spotted this, anyway thanks.

 

Overall a great hack, Markey ; it's just a shame that I still suck at the Sonic CD special stages , as shown in my Youtube upload (FlickF).

 

So since you have to aspects of collecting emeralds or time stones now, What other abilities were you planning on adding if you're capable of collecting both sets? I know it;s nit-picky, but It sort of seems like a let down to work hard to collect that many gems in game without some special power or something.

 

It's a proof of concept, he's not making a full blown hack out of this. What you see is what you get, I very much doubt he'll be putting any more time into this hack.

 

Congratulations MarkeyJester for such great work. You worked hard on this and you have an excellent result with it, I'm very impressed with your talent to find the way to do everything that you have in mind.


Another point, although I know this is a concept, but the fact you said you didn't touch nothing of the original game I have to say that I noticed that if you select the SPECIAL STAGE in the level select screen (yes, the original S1 special stage), there are no rings, well, there are not "visual" rings lol

 

I know it's proof of concept. And I'm not so sure if he is still fixing the last little bits with this, but I wan't to get the answer from him.

 

I know it's only a concept, and it's in it's early stages, but just in-case. When you get rings from the UFO, then run into the spike traps on the floor, you don't see the rings scatter.

 

I like you Stephen, you actually read the first post before asking questions or making notes. I wish a lot more people on this forum did the same.

 

Allow me to quote the opening post, or more specifically, the relevant part of it.

Pay particular attention to the part that I have underlined and highlighted in bold. His work is finished, nothing else to add. He's not going to fix a broken background, add special abilities for collecting emeralds in this method, or any other suggestion you're going to inevitably come out with. If you are aware it's a proof of concept, then I shouldn't have to explain this, unless of course you're unfamiliar with what one actually is. He has proven that SCD special stages can be made on the MD / Genesis, and therefore he has proven the concept. Adding other irrelevant stuff does nothing whatsoever to prove the concept.