This site uses cookies to ensure you get the best experience. More info
Got it!

Performance Issues



Performance

As I have previously hinted a few times, I am dealing with some performance issues.
Reason for that, is that I overestimated Windows Forms’ performance capabilities.

Main issue here is that Windows Forms rendering is heavily CPU based. It is based on GDI+ library, which utilises CPU to render window applications.

While the GDI+ or Windows Forms itself is working fine on it’s own, any application that is developed under the need of more complex rendering than some simple GUI will sooner or later run into performance issues.

Same happened to me and Praedium where performance started to be an issue when I implemented the camera movement - when big areas had to be redrawn, the performance was dropping dramatically.

And now, when I started implementing terminal layering, the performance started to drop even more.

Trying to resolve the issue

Although I tried to optimize the code, in the end I couldn’t change the way the Windows Forms is rendering the controls, and because of that, about 90% of computing power on my desktop was used on rendering itself (application is running on a single core).

Now, that doesn’t mean that Windows Forms is a bad choice for developing games (although it surely is a strange choice indeed).

If I would follow the classic roguelike games and make the game be turn based - the performance would be definitely way more than enough for the game.

The problem is that I changed the game to be real-time based and rendering occurs very frequently (every game loop iteration) instead of only when an action is actually taken by the player.

Other than that, the code performs quite well and Malison - my terminal emulation library - is fortunately not the culprit.

Where to go from here

Now, the bad news here is I’ll have to change the whole rendering part of Praedium. Fortunately, neither the terminal emulation library, the game or engine itself are dependent on Windows Forms, so making a switch shouldn’t be so hard.

The choice remains as to what framework or engine should I use from now on.

Firstly let’s start from the flagships of C# gamedev.

Unity

I’m not going to make a switch to Unity, because that would mean the game engine I was developing along Praedium would basically be now useless and replaced by Unity.

While that would probably not be a bad choice in the end I would rather keep my custom engine alive.
My reasoning for this is that I greatly enjoyed working on it, tinkering with it and improving it.

MonoGame

MonoGame is another big name in the C# gamedev world.

It is a much smaller thing and probably more suitable for 2D games development, but that being said, it also implies it’s own game loop implementation and a big chunk of lower level code already being implemented.

So, in the end, just like with Unity, I’m going to keep away from it as it would result in nuking the small, poor engine of mine.

SFML.Net

An interesting choice, yet definitely much less popular is SFML.Net - an SFML (Simple and Fast Multimedia Library) binding for .NET languages family.

It offers only what it’s name suggests - a simple, cross-platform object oriented multimedia API.

While I haven’t looked that much onto it as of yet, I’m really keen to try it out.
Other than gaining the cross-platform release capability, I could continue to work on my custom engine and let it take use of SFML.Net.

This is by far the best choice I see at the moment, and one that I’ll definitely try out.

WPF

Technically an upgrade from Windows Forms but still a Windows-only framework.

While this could be an easy transition it continues to limit me to windows platform only, which to be honest I would really like to change.

I feel like users from other platforms should be able to play a text-based game like this too.

Others

While these are only a few, and not all of the possible choices, I have listed those that I knew at least something about. I’m going to do some research here before I take the jump, but for now I’ll be taking these into consideration.

Wrapping up

As you can see I have kind of shot myself in the foot by choosing Windows Forms as my framework for rendering the game.

Fortunately, due to my project architecture decisions, the game code and engine code can be easily separated from the Windows Forms and transitioning to other engine or framework will be quite easy and painless.

The good news is that I’m going to try finding a good alternative that will also supply multiple platforms (hi there, Linux friends!), so the outcome of this issue is actually a nice one.

Overall I’m quite happy that this happened as I’ll be able to get to know another framework and keep on implementing my little engine. I have taken a liking to developing it despite the many issues and slower development process of Praedium as a whole.

That’s it for today’s post. It’s funny how fast 2 months since I started this project already passed. See you next time!