Game Development Community

Asynchronous events

by Tony Richards · in Torque Game Engine Advanced · 02/23/2009 (11:48 am) · 5 replies

I'm in the process of porting my Event Driven Database resource from TGE to TGEA for Ari from BrokeAss Games (among others), but I find myself in unfamiliar territory. I used TGE for so many years, I'm finding TGEA to be a completely different beast. :P

TGEA moved away from the event queue and switched to a multicast signal / slot mechanism for things such as network event notification, but at a glance I'm unable to to determine how it works.

The documentation only hits the new game flow at a very high level.

Essentially the original design used the non-blocking game queue for returning records from database queries and forwarded them to C++ or script callbacks.

Since the game queue is gone, what would you suggest I use instead?

I'm reviewing the code and hopefully I'll figure it out, but if anyone (preferably a GG employee) is intimately familiar with TGEA and has a clue what I'm talking about, would you mind pointing me in the right direction?

Thanks... and Ari thanks you as well :P
Tony Richards's profile picture
Torque 3D Owner Tony Richards

About the author

I am the founder of IndieZen.org, a website dedicated to the Indie 2.0 Revolution where a number of Indie game development studios and individuals collaborate and share a suite of custom built open source game development tools and middleware.

Recent Threads

  • Interest in a RPG genre kit for TGE / TGEA / T3D?
  • TGEA UDP dropping packets from localhost
  • Torque Owner
  • Questions about T3D Feature List and EULA
  • TGEA Docs - Input Model
    • NextNext Thread
    PrevPrevious Thread
    More from Torque Game Engine Advanced


    Torque 3D Owner Tony Richards
    #1
    02/23/2009 (2:20 pm)
    So, the Signal<> class won't do the trick. It's a simple single-threaded signal / slot implementation. No queue.

    My next course of investigation led me to MessageQueue and the Dispather namespace, since that appeared to be how network events were being handled.

    But, as it turns out, MessageQueue is also a single-threaded event dispatcher being used to poll each of the sub-systems to give each of them a slice of time in the main rendering loop. It's not a message queue at all.

    It appears that the network select() is now being done in the main rendering thread, not in another thread as it was being done in TGE.

    StandardMainLoop::doMainLoop()
...
      if(!Process::processEvents())
         keepRunning = false;

    using the code in Dispatcher eventually calls:

    Net::process()
...
      Net::smPacketReceive.trigger(srcAddress, tmpBuffer);

    because of the initialization code:
    Net::init()
...
   Process::notify(&Net::process, PROCESS_NET_ORDER);

    The trigger() eventually calls:
    NetInterface::processPacketReceiveEvent(NetAddress srcAddress, RawData packetData)

    because of the initialization code in 
    StandardMainLoop::init()
...
   Net::smPacketReceive.notify(GNet, &NetInterface::processPacketReceiveEvent);

    I figured since I was here, this might be something useful to document.... but it still doesn't solve my problem.

    /me goes back to digging.

    Associate Rene Damm
    #2
    02/24/2009 (5:02 pm)

    Hmm, not quite sure what you mean by the game event system being gone. Do you mean the SimEvent system? That's still there and it's mutexed, so should be safe to be called from a different thread.

    If I understand correctly what you want to do, then you could create a custom SimEvent on your database thread, post that to the Sim using Sim::postEvent, and then have it processed on the game thread and call into C++ or script code within the frame loop.

    Torque Owner BrokeAss Games
    BrokeAss Games
    #3
    02/24/2009 (7:51 pm)
    I'm right there with ya, I'm having to relearn alot.

    Associate Tom Spilman
    Sickhead Games
    #4
    02/24/2009 (11:56 pm)
    Quote:It appears that the network select() is now being done in the main rendering thread, not in another thread as it was being done in TGE.
    That shouldn't be the case... if it is... it should be fixed ASAP.

    Torque 3D Owner Tony Richards
    #5
    02/25/2009 (2:19 pm)
    A game client having the network code in the same thread as the rendering, physics, scripts, etc could potentially run faster, but it is something that needs to be profiled on a game by game basis.

    Server side, however, I think this is a very bad way to go.