General Engine and Mechanics Advice

Depends whether you want an 'authentic' sonic 1/2/3 experience or you want 360 degree movement.

I had a similar problem before and I now have a good idea of what to do for both but obviously depending on what you want to do.

 

No, I mean like you know how in sonic 1, 2 and 3 when you go round a loop sonic just jumps to the next rotation rather than rotating smoothly? Well it is very similar to that (however that was just sprite limitations, not physics). Now if it DID rotate smoothly round that loop then that is an example of 360 degree movement.

The first uses collision masks in specified tiles - you get the position of sonic's feet and then you know exactly what tile he is in, so you get the correct collision mask and work out a position/rotation from there.

As for the second, basically you'd have to implement a pixel collision detection (which I recommend tiles for too for optimization purposes) and then get the rotation by taking the point of impact and going out to a circle. You can then extend this into a capsule to make it more like sonic than just a moving ball. This one is arguably harder, but has a (IMO) better result.

 

nchavez in Sonic 2,3&K you have 2 collision layers, and the art in general is in 3 layers - Sonic, Behind Sonic and In front of Sonic. Every 128x128 tile has 2 parts, one that is background, one that is foreground. Now, many tiles have one part completely blank. You draw the back part first, then Sonic & Friends, then the front part and thats it.
As for the physics part of the story, each 128x128 piece is made up out of 16x16 collision masks, each having only 1 angle(yes, at first glance thats strange but it actually works fine). So each tile has 64 collision masks per layer. You switch between layers with Collision Plane Switchers. Depending on which way you cross it, it gets you to one plane or another. Different CPS behave differently.
Also each mask has a flag that tells if its completely solid, or if it is letting you pass in a certain direction, like bottom->top, left<-> right.
Relick mentioned 360 because Sonic does move at all 360 angles. In the classics the problem is divided into 90 degree segments. You make the character behave on "flat" ground -45 to +45 degrees, then make it work for the other 3 quadrants by flipping the values, and figuring out how to make the transitions between quadrants. Now, you may want to make the physics one whole continuous 360 thing, like the original team *might* have done if the hardware was right at the time, but you won't achieve an "authentic" Sonic engine.
For the tiles themselves you might want to make first a simple viewer or even editor before getting in the deep with the physics.
Other than how the file formats are in the original games, basically everything you need to know is in the Physics Guide. Trust me, I've been down this road (with C#)

 

http://info.sonicretro.org/Sonic_Physics_Guide

This might be what you're looking for, or at least part of it. It offers no programming advice, but explains some of the nuts and bolts of how a lot of the Genesis games work.

 

The collision masks don't have to be linear, some of them are curved, its just that all of the 16 heights of the mask share the same angle and the physics are processed at it. This is similar to how the art rarely follows the collision layers to the pixel. Even the collision angles do not match the visual ones. If you take a screenshot and measure 27 degrees slope, it'll be actually 22.5 the way the game handles it.
Yes the artists prerendered the walking and running animations for several degrees: 0,45,90 and 135. In a modern engine you can just rotate the sprite however you want in real time.

 

Also, in the original games, each collision mask is actually a set of two - a series of 16 heights, and a series of 16 widths - so Sonic can treat them as either floors/ceilings or walls depending on his angle.

That's my video, of a really old build of my upcoming AeStHete engine. I was still using Game Maker's precise collision checking and pushing the player out of the ground with a while statement at the time.

Linear collision masks work okay (they're what I used for Sonic Fan Remix) but they can only get you so far. Height maps (collision masks, whatever you want to call them) are preferable, especially if you want to emulate classic zones' terrain accurately.

 

Anything that moves in the originals is handled separately from the terrain simply because it is easier and more optimized to do so. They're called objects, and so every frame Sonic checks if he is touching the terrain; if so do this etc; then straight after it checks all the objects whether he has collided with them. These aren't nearly as complicated at implementing as the terrain - it's as simple as checking distances between the two centers of the objects and seeing if the hit box has been crossed; if so destroy the badnik or hurt sonic or whatever. Since they only use hitboxes (height and width from center) rather than full collision masks it saves a lot of computational power, so on the (comparatively) weak genesis it meant more objects could be in the level at once. Obviously not such a problem nowadays, but it is useful to know in order to make sure your engine is optimized.

Unless I'm completely wrong, in which case please correct me :S

 

Sounds good, would be great to see the first engine for the new platform.

However, if you are going to go through the trouble of making it for Windows 8 you may as well just use C# or VisualBasic because it is 100 times easier than managed C++ and I believe it can export straight into Windows RT as well as 8.

 

It might just be me but using managed c++ was so hard after using unmanaged because unmanaged is so simple and makes sense whereas managed does crazy things that don't make sense, and since its so high up in the code hierarchy it's nearly impossible to revert it back to before. With unmanaged, once you get around the fact that there are a lot of extra things you need to remember to do (such as deleting objects) it feels much more powerful than C# or VisualBasic and combined with the power of DirectX you can just about do anything you like (without having to delve into the depths of assembly lol).

Coming from a fairly uninformed standpoint I'd say that anything on Windows 8 will not be geared towards heavy graphics manipulation. Obviously you don't get the power of DirectX (but remember DirectX works with C# too!) with XAML but when taking on a huge project such as creating a Sonic engine you might want to experiment with its capabilities anyway - you never know what you'll find and it could be useful for future projects. Just my .02 pennys.

 

It seems that the rumor about XNA's cancellation is still going around. Even before 4.0 Refresh was released. Some facts: the games run on Windows 8 no problem. The platform has everything you'll ever need for a 2D game and its goals are to be DirecX 9.0c but compatible with Xbox 360 too ( and partially with Windows Phone 7). You can also use its libraries however you want, like doing the math/input/audio stuff in XNA but rendering with OpenGL.
Also you wont have performance advantages with C++ over manages languages like Java and C#. You are just going to spend much more time coding and debugging the logic. Sonic 3 HD (written in XNA) requires just 1GHz single core CPU. Sonic CD 2011 works on mobile phones just fine, I think its in Java. On the other hand a badly written 2D Sonic engine in C++ can tax up to 77% of your core i5-2500K quad core 3.3GHz CPU.
My point is, if you are going to get bottlenecked by something, its going to be the video card first, then the memory consumption, and lastly the CPU processing power, no matter which language you choose, be it C++, .Net or Java.