SDL events & the problems they solve

As I was working on the server network logic I realised I hadn't developed a method of message passing in a thread safe way. I'm spoiled with the thread safety in languages like c#. However in c++ thread safety isn't quite as common.

Now some of you are wondering why use threads at all. Well there are at least a couple instances where I will need them.

One is damage over time effects. I need damage to be added every tick which I'm thinking should be once a second. The other way to do this would be to have it tick when it gets the chance and add damage based on the time since the last tick not fixed damage.

The other is the network polling. I want to have as little latency as possible. I plan on my mmorpg being real time and latency is very annoying in any real time game. Now multi-threading won't help the connection the server or clients are running on but it will reduce the about of latency resulting from the protocol and code needed to handle it. I should be able to queue up work for another thread based on information from clients.

For clarification I plan to use an SDL timer for the damage over time however that can be on another thread so anything it shares with the main thread must be thread-safe.

So anyway I'm thinking currently that would be a total of three threads assuming the SDL timer platform implementation uses a separate thread.

I began to look into the problem further and I was looking for an existing solution I didn't want any more threading pain than strictly necessary. It's not fun trust me. So anyway my first thought was a thread safe queue. Of course I didn't want to build one if one already existed I could use.

So as I read around a ran across a reference to the threading abilities of SDL. To be honest every project I have done with SDL in the past has been single thread except for ones in C# that use a .net wrapper library. Which in the later case has plenty of thread safe types to use. So I began to read the API documentation related to threading honestly not expecting a whole lot.

What I found was quite nice though. On top of having support for things like semaphores The libraries event system itself is thread safe. Now this may not sound like a big deal at first but there is actually a user event type in SDL. So basically you can use their event system in a multi-thread environment with out anymore work than it would be to handle keyboard or mouse events with their library.

The push method for the event queue is thread safe so my solution is the problem listed above is as follow.

The main thread will spin on the event polling code. Any user events will be handed off to help classes to prevent the application class from becoming bloated.

Now at the same time the network code in the Server class will be polling enet for new packets. It will determine the type of message do some basic validation and create an event with the data & custom event type id. This new event will be pushed unto the SDL event queue where it can be grabbed by the main thread for processing.

The damage over time manager will be creating events that signal the main thread to apply damage to characters & monsters from a list of combatant locator pointers. It will be in charge of removing damage over time effects that have expired. I will probably just use vector for this.

Now the problem that I have not solved yet is how to get damage over time effects into the this collection. The issue is that they will likely be coming from the main thread. So the question is how to do this. I may just guard the vector with a semaphore and be done with it.


Popular posts from this blog

VK9 - Milestone8 Completed

VK9 - Milestone13 Completed

VK9 - Milestone16 Completed