Basically what I am trying to do here is to create an event system for a simple game engine I am working on.

I'm trying to make this program as platform independent as possible with the C++ language so I am ruling out threading for the moment.

The basic idea that is that:

//outside game loop (initialization)
o_check_for_events(O_CHECK_ALL_EVENTS); // this should add the events to some sort of list

// inside game loop
event = o_get_next_event(); // return the next event in the queue
// .. 
// do stuff with events

That would be a sample game event loop. What I want out of this though is an option that I can ask the system to wait for an event (easier of the two) and/or be able to check for events even while the game is running.

What I want to know is if it is more efficient to have methods that interrupt the flow for a short period of time, or else a threaded program that checks for events simultaneously (assume that the thread functions are safe)?


closed as off-topic by bummzack, Sean Middleditch, Anko, MichaelHouse Sep 18 '13 at 23:51

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Programming questions that aren't specific to game development are off-topic here, but can be asked on Stack Overflow. A good rule of thumb is to ask yourself "would a professional game developer give me a better/different/more specific answer to this question than other programmers?"" – bummzack, Sean Middleditch, Anko, MichaelHouse
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    \$\begingroup\$ Why do your functions start with o_? Also, C++ has platform-independent threading facilities, which you will find in <thread> header. Also, what do you mean by "more efficient?" \$\endgroup\$ – Bartek Banachewicz Sep 16 '13 at 14:56
  • \$\begingroup\$ @BartekBanachewicz the o_ is just a naming convention in the project. \$\endgroup\$ – PurityLake Sep 16 '13 at 15:22
  • \$\begingroup\$ Then it's a bad convention. A namespace should be used instead. What about my other points? \$\endgroup\$ – Bartek Banachewicz Sep 16 '13 at 15:32
  • \$\begingroup\$ I don't see what the problem is with the convention. and by more efficient I mean which will be able to deliver messages quicker while also using as little resources as possible i.e. processing power and memory \$\endgroup\$ – PurityLake Sep 16 '13 at 15:36
  • \$\begingroup\$ Have you profiled the current method to see if it's really a hotpath in the execution? The problem with the convention is that it introduces unnecessary noise and doesn't really help with name clashes; both of those problems can be easily solved with a namespace. Have you taken a look at C++'s threading/async model? \$\endgroup\$ – Bartek Banachewicz Sep 16 '13 at 15:39

You have multiple questions here, but your question of whether or not it is more efficient to have threaded asynchronous event handling or blocking message handling is likely going to lean in the direction of asynchronous handling. Unless you are encountering some very extreme locality of reference issues, which would honestly likely be encountered regardless of threaded or not. I would recommend you do not implement an asynchronous callback system, as your engine is likely going to see far better improvements from threading other intensive operations. Callback systems are extremely low overhead.

To answer more your architectural question, I will explain a simple architecture I have seen in modern AAA game engines, and something I have written myself. Typically, the game engine framework will have an entire system dedicated to handling events, and this is often built on top of a generic messaging, or callback system. Events are triggered at specific points throughout the program flow, and are typically delivered immediately by the corresponding event/callback (unless you support time delay events). At that point, any entity, or system that implements a callback listening interface, and is subscribed to that event will receive the notification and potential payload.

As a final note, your method names == scary. :)

  • \$\begingroup\$ I see what you are saying. I think I can come up with something using what you just said. Also its just a naming convention, that methods to do with the engine named Orpheus (not my idea) begin with o_ then the rest is also seperated by _ e.g. do_something() \$\endgroup\$ – PurityLake Sep 16 '13 at 15:24
  • \$\begingroup\$ Instead of starting with an o, the methods should all be inside the namespace Orpheus. (That is if you want to conform to normality and not irritate to hell any outsider/new project member looking at the code) \$\endgroup\$ – w4etwetewtwet Sep 16 '13 at 17:02

Not the answer you're looking for? Browse other questions tagged or ask your own question.