Game state objects should be accessible from other threads (e.g. rendering and control i/o)

[t3kt]

No description provided.

[JimAnkrom]

@t3kt is this not complete? Seems to me it probably is...?

[t3kt]

this is definitely not done yet. the only multi threaded part is the
control input. I'll try making a message queue so that nothing has to
directly interact with the game objects

On Fri, Dec 26, 2014, 10:28 AM JimAnkrom [email protected] wrote:

@t3kt https://github.com/t3kt is this not complete? Seems to me it
probably is...?

—
Reply to this email directly or view it on GitHub
#14 (comment).

[JimAnkrom]

Ok, cool. Make sure I know how to update player state appropriately (tho I
may be on my own threads fron socket requests).
On Dec 26, 2014 11:24 AM, "tekt" [email protected] wrote:

this is definitely not done yet. the only multi threaded part is the
control input. I'll try making a message queue so that nothing has to
directly interact with the game objects

On Fri, Dec 26, 2014, 10:28 AM JimAnkrom [email protected]
wrote:

@t3kt https://github.com/t3kt is this not complete? Seems to me it
probably is...?

—
Reply to this email directly or view it on GitHub
#14 (comment).

—
Reply to this email directly or view it on GitHub
#14 (comment).

[t3kt]

I added a basic message queue class (see core/MessageQueue.h). There's a version of it that wraps around an ofEvent, where you can push messages onto the queue, and then have something in another thread call .sendEvents(), which will pull any event messages out of the queue and trigger them using the standard event mechanism.
See d457be5