Well, at heart Retro-Sonic has always been "the Sonic game I've always wanted to make myself", which I suppose is what makes it a fan game... I'm making 12 levels, my own special stage etc. But after doing the first C++ engine for Retro-Sonic, I realised a lot of people wanted to make levels for it so with the new engine I've put in more effort to create better editing tools (the RSDK) so people could also create their own levels. Then the fact that all the tile mappings formats and object placement/level design format info from the Megadrive games was available from the hacking community led me to think: "Hey, since I have similar kinds of formats why not make converters to import this data into Retro-Sonic" As it stands now the following things can be converted from a savestate/rom -8x8 tile gfx, 16x16 mappings: Retro-Sonic uses 16x16 base tiles so the 16x16 tile mappings are rasterized into a bmp file, which is then compressed. - 128x128 or 256x256 mappings: are converted into 128x128 mappings (I use 3 bytes because I have extra tile properties that can't fit into 2) -Level Design: nuff said, it's the easiest data to port -Collision Data: a decent conversion is possible, although some touching up in the editor is required sometimes. -Ring Placement -Object Placement, you must specify what objects in the Megadrive games correspond with what objects in Retro-Sonic are used when converting. In terms of scrolling, line based parallax/deformation is possible so pretty much any zone's background can be recreated (not converted from a savestate though) Now considering I'm going to have multiplayer mode via lan or netplay, the level importing options are useful if people wanted to play against each other in say Green Hill. So I guess overall, I'm looking at this from both perspectives: This is a game that I've wanted to create with my own ideas and everything, but after this there's much more I can do with this engine. On another note: I'm pretty sure the method I use for programming loop-de-loops etc, by coincidence is very similar to how it's done in the actual games: The idea is what I like to call "Track Gripping" where the player sticks to the collision height maps according to where the collision sensor points are. From observation, it looks like there is 2 or 3 collision sensors that do this for the ground. The game checks to see which sensor is the highest and sets the player's y position around that. This is a fast method, but encounters problems when the change in height is greater than a 45 degree angle (it looks un-natural). So the game switches to wall gripping, using the sensor points in a different position. Then when you go above 135 degrees, the gripping mode changes again to roof gripping. Now this could be wrong, but I have some proof that this might be the system that is used in the actual games (not just Retro-Sonic): Take a look at this bug from Sonic 1. The yellow lines indicate where 2 collision sensors would exist. In the left picture both sensors have detected a collision. The right sensor has a higher collision than the left, therefore the collision height from the right sensor is chosen by the game. Now in screen 2, the right sensor has gone off collidable ground. Since the left sensor is the only one detecting a collision, it's height *must* be chosen. This causes Sonic to move down into the ground. The solution? Make slopes that always have at least a bit of flat ground after them. This is one of the few spots in the game where you can see this. Another level is Casino Night I think. Soo yeah... enough rambling, I'm sure Dr Ivo and LOst probably even know the asm collision code used.