[RobTF]

Hi,

After getting inspiration from reading this forum and the Sonic Physics Guide I've written a small game engine and used the knowledge from the guide to implement Sonic game play mechanics. The engine is open source and use is unrestricted under the MIT licence, so have at it!

You can find everything at the Github repo at https://github.com/RobTF/spikeball

The engine may be somewhat different from many others as it does not use any existing game development framework, but instead is my own design written using pure C# with no third party libraries. Map/level editing is done using the wonderful "Tiled" map editor. The engine is actually quite generic and could be used as the basis for a Sonic fan game or even something completely different. I've tried to keep everything as simple as possible whilst having enough features to be fun and useful.

The actual engine logic is completely independent from the rendering, there is no dependency on sprite sizes or resolutions so it would be possible to use higher definition graphics (such as those used in Sonic 2 HD) as opposed to the ripped Sonic sprites I'm currently working with />/>

Although I've supplied a renderer in the form of a Windows application using Direct2D, the code is portable to other platforms via Mono/Xamarin and if there was interest, I'd be happy to create a renderer using something like Cairo or SkiaSharp that would work on iOS/Android.

If anyone is interested, has comments or would like to contribute that would be great!

thanks for reading and happy hacking,

Rob

P.S - During development I have noticed what may be a couple of errors in the maths within the Sonic Physics guide. I'm not 100% sure as there is a chance it could simply be a side effect of how I've implemented things but if anyone thinks could be worthwhile I'm happy to post details about this when I get some more time.

[winterhell]

If your math seems off on the slope physics, that would be because in the classic games the angle the game works with and the visual angle are different. You see 27 degrees but the collision data says its 22.5 (or was it the other way?). This was throwing me off in the past, when I was calculating the angles myself.

[RobTF]

Thanks, it was more a couple of instances of weird stuff in the angle calcs - I remember one was signs (e.g a -Sin(angle) being a Sin(angle)). Not really a problem and the numbers were fine in the end, I thought maybe my angle system was different by 180 degrees or something but it wasn't.

The angles in this engine work as the original and have the same possible disconnect between actual ground angle and rendered angle.

Anyway, it all worked out in the end! Take a look at the code and see if you can spot any errors!

[Techokami]

Not too shabby! Some feedback though.
1) For some reason, Sonic feels a bit... slower than normal? I tried rolling down that slope and he wasn't picking up speed very well.
2) Some of the animations look and feel a bit janky. Might want to double check alignments?
3) I do not like the image filtering in place. Can it be turned off for sharp pixel-perfect visuals?
4) If you fall below the level, the entire program crashes instead of killing Sonic.
5) When I open the VS Solution, it tells me I need to connect to someone's Team Foundation Server?! O_o

This post has been edited by Techokami: 17 November 2016 - 07:30 PM

[RobTF]

Thanks for the feedback! To answer your points;

1) I'll look into that, I just took a quick look at the calculation pertaining to slope factor and it looks OK at a glance, but I'll investigate in more detail in the next few days. All I can think of right now is that the magic numbers from the physics guide are multiplied by 60 as I assumed these values pertain to 60hz (NTSC) which this engine simulates at. The physics guide says the values are applied "per step" but I don't think it defines a "step" anywhere so if my assumption on this is wrong it could throw the speed out slightly.

2) I've just pushed up some changes which should clean this up, I noticed a glitch in one of the running frames as well as one of the balancing frames, if there are others please let me know (or even better fix them for me and send a pull request )

3) This artefact is courtesy of Direct2D and I agree about the look, I'll have a play and see if I can switch it off. I also built a WPF based renderer that interestingly enough doesn't do this (despite being D2D based), but it takes a whopping 28% CPU to render so I scrapped it!

4) Yes, this happens as there is no kill plane yet so if you fall out of bounds it simply doesn't like it. As I add further game mechanics this would be sorted of course. I'm undecided how far to go as for people simply wanting to build Sonic levels there are more complete options available, but what this project hopefully brings to the table is a chance for people to see how an engine like this can work from top to bottom, so for me it's a matter of how far do I go developing the nuts and bolts of the gameplay before it stops being worthwhile. I think what I work on will be strongly tied to feedback, if there is strong interest in emulating more and more of the Sonic gameplay mechanics I'd certainly be up for doing this, perhaps even in tutorial form.

5) Ah sorry about that, it was a TFS project originally until I had it in a state where I felt it was ready for Github, Visual Studio hadn't removed all the references from the solution file. I've pushed up a fix for that.


thanks again for the comments!

Rob

[winterhell]

When in 60 frames per second, 1 step is 1/60th of a sec yes. In PAL regions the game would run a bit slower because you have only 50 steps. Anytime the framerate falls the game slows down.
Back then the games were not framerate independent(many still aren't nowadays either).

RobTF, on 18 November 2016 - 05:52 AM, said:

3) This artefact is courtesy of Direct2D and I agree about the look, I'll have a play and see if I can switch it off. I also built a WPF based renderer that interestingly enough doesn't do this (despite being D2D based), but it takes a whopping 28% CPU to render so I scrapped it!

Stupid question but did you try System.Threading.Sleep()? Chances are its using just 1% but it doesn't tell the OS the resources are free. 28% would mean its 'using' 100% of 1 core, if you have 4 cores.

This post has been edited by winterhell: 18 November 2016 - 06:18 AM

[RobTF]

hmm, so my assumptions on that front are OK. I'll investigate and see if I can find anything, it might be something silly like a speed cap coming in at the wrong time.

Regarding the 28%/core stuff, I initially thought that too, but it wasn't that clear cut, for example, if I didn't render the HUD it'd drop to something like 19% so it wasn't a general CPU spinning thing, the actual DrawText call was simply that slow and you could identify where the rest was going (i.e. x% per draw call). As I recall there was a Thread.Sleep in the render loop to limit the rate, if you're interested I can dig the code out of TFS.

WPF also makes this worse by the fact that you can't fully control when it renders, the closest you can get is to create a Drawable and control when the content is updated however WPF handles it's own rendering/invalidation logic on its own dispatcher thread (it doesn't use WM_PAINT, for example). It seems what they say is true and while it can be adapted for games, it really isn't built for it.

On the other hand Direct2D seems to be more purpose built for the sort of things I'm doing with it, and SharpDX has a nice render loop implementation which assists with exactly what you mention below. I suspect it will be easier to find a way to disable anti-aliasing on the D2D implementation than try to battle further with WPF, although it was an interesting experiment! In fact while I'm at it I'll probably also fix the issue where resizing the window allows you to skew the aspect ratio, this shouldn't happen either. My only beef with DX is that I don't find the APIs intuitive to work with.

In the grand scheme of things I'm not too worried at this stage as my feeling is that ultimately if the project were to progress seriously the Windows specific renderers would quickly succumb to a cross platform renderer with a Mono library as the underpinnings and my efforts would quickly focus there.


EDIT: Just to say I've pushed an update which eliminates the antialiasing effect. A side effect of this is the free window resize is gone and instead you can choose 1x,2x or 3x scale but the pixels should remain rendered correctly. A full screen mode could also be implemented going forward.

This post has been edited by RobTF: 18 November 2016 - 10:00 AM

[Cooljerk]

RobTF, on 18 November 2016 - 06:49 AM, said:

On the other hand Direct2D seems to be more purpose built for the sort of things I'm doing with it, and SharpDX has a nice render loop implementation which assists with exactly what you mention below. I suspect it will be easier to find a way to disable anti-aliasing on the D2D implementation than try to battle further with WPF, although it was an interesting experiment! In fact while I'm at it I'll probably also fix the issue where resizing the window allows you to skew the aspect ratio, this shouldn't happen either.

It is. What you do is create a D2D rendering context, then use ID2D1RenderTarget::SetAntialiasMode(D2D1_ANTIALIAS_MODE_ALIASED) to disable linear interpolation.

Quote

My only beef with DX is that I don't find the APIs intuitive to work with.

Regarding your performance problem - you are going to run into problems as you go further if you work with pre-fab 2D engines or otherwise avoid DirectX or OpenGL going forward. Taking a cursory glance at your project, you aren't using a palette when rendering, which is at odds with the way sega genesis art is stored and used. Either you will have to eat a large memory footprint in VRAM to store the many combinations of texture glyphs in multiple color permutations, or you'll have to eat a lot of CPU performance as you have your CPU constantly working to build textures for your video hardware to use.

If you want to maintain a low memory footprint and keep your CPU work low, you need to have your GPU doing as much as possible. The solution to your problems is to create a fragment shader that treats a sub-channel in the reference texture as an index to a palette that you send. Then you simply store your drawing textures as greyscaled images. This lets your video card handle all the drawing for you, and you can use your CPU for other things beyond drawing. I've never used WPF myself, but if I had to hazard a guess, I'd say it's not really using your GPU correctly, and much of the actual image composition is occurring on your CPU.

About APIs being intuitive - I mainly work with SDL2 and OpenGL, which many find even more unintuitive than DirectX. I'll say, however, that neither OpenGL nor DirectX are illogical, they just require a serious commitment to learning how they work.

[RobTF]

Hi thanks for the feedback, to clarify there doesn't appear to be any performance problem with the Direct2D version of the renderer, but I'd be interested to know if I'm using the API incorrectly in some way as I'm not a graphics guy and it was my first attempt. I wasn't too interested in being "Genesis like" enough to use indexed palettes for the art assets (I simply made everything a 32bit PNG) but reading your post was interesting nonetheless.

Unfortunately I had set the antialias mode In the way you described from the start but it wasn't enough as subsequently stretching the viewport seemed to create some kind of aliasing effect perhaps at a higher level. The workaround was to scale up the drawing to prevent it needing to do this.

I absolutely agree that WPF will not be efficient in the way it uses the GPU/CPU as it was designed for purposes other than games, but it has been noted around the internet that some rendering methods are slower than they perhaps should be (DrawText is pointed out on many occasions!). This is why that renderer did not make the cut; It was interesting to try as an experiment though!

I don't necessarily disagree about your statement regarding how logical the APIs are either, and I don't know about OpenGL but DirectX just seems unintuitive in certain ways such as the compatibility story and how you have to do certain operations in a certain order but just "know" the order. I don't doubt with more time I'd be more comfortable with it (I already am after my foray into D2D) but whilst I was working on learning what I needed to write it I found forums and blogs full of people who clearly knew what they were doing but were literally guessing at how to accomplish things which at the very least perhaps means a documentation problem. Using a C# wrapper no doubt makes things more difficult, and I accepted that.

If you know of any good OpenGL/DX resources I'd be interested in hearing about them!

In other notes I noticed there was a small issue with the physics using the running slope factor when rolling which would account for the "slow" feeling Winterhell found and this has been fixed.

Thanks!

[winterhell]

I don't know about SharpDX but I've used SlimDX in the past and the first hurdle is to initialize your window and direct3D device.
After that any C++ Direct3D10/11 tutorials should be pretty straightforward to implement, since the function names and enums are very similar if not the same.

Basically google and inhale all knowledge you can. Random google search for C# based tutorials:
http://richardssoftw...ectX11Tutorials


Personally I prefer OpenGL but both can do the same job.

[Cooljerk]

If you want a simple but powerful way to draw graphics to the screen, look into SDL2. This is a terrific tutorial to get you off the ground:

http://lazyfoo.net/tutorials/SDL/

For the way you want to draw your graphics, SDL2 is fine. And there aren't very many steps involved to getting graphics on your screen through your GPU via SDL2.

[RobTF]

Good stuff, thanks guys! I do have a build now running on Android and iOS using Xamarin with Skia to draw which seems fine on the devices I've tried (I.e not high end devices) but SDL certainly looks interesting and more mature.

Winterhell: from what I've read it seems SlimDX isn't maintained anymore hence my decision to use SharpDX but they look very similar to each other which makes sense. I find exactly the same in that lots of the work as a newbie was in simply getting things like back buffers working and configured, the drawing was fairly ok but there were oddities in the C# wrapper such as interchangeable interop types like RectangleF vs. RawRectangleF which wasn't made clear going in. What didn't help is that after I got it sorted I then found I was using Direct2D 1.0 and to use some of the features I wanted I had to go with 1.1 which annoyingly was a slightly different setup procedure!

[Morph]

Yeah, SharpDX is actively maintained. I'm using SharpDX for a project right now and it's working pretty nicely so far. My only gripe with it personally is that the code is missing a lot of documentation (simply filled in with "No documentation"), so I still have to go sift through Microsoft's C++ DirectX documentation to find a lot of information. Mildly inconvenient, but not a deal breaker.

[Cooljerk]

BTW I'm interested in hearing what inaccuracies you think you found in the physics guide. I myself have been writing some stuff on the side to contribute, and I'd like to see if there is overlap.

[Codr]

This is an amazing engine! However like other people stated, it does have room for improvement, specifically in the way Sonic handles, he seems like he is way heavier than in the Genesis games.