Code walkthrough (overview):

Of course we start in main.c.

  - init threads (if dynamic loading is used - system dependant - will dynamically load)
  - init audio (dynamically loads OpenAL, if used)
  - init ai (right now it just loads the python lib)

We then set the current state using state_switcher (state.c).  This will

  - init the renderer to be used and set the GLUT callback
    - similarly for the keyboard and mouse
  - if the simulation thread is already running we kill it and start the requested state's own simulation thread
  - a timer function is then set to post redisplays as appropriate

We then return to our main (main.c) and enter the GLUT main loop.

At this point we have two running threads, as will be the case always.

The main thread will be where ALL the GLUT functions are called; it is NOT thread safe.  What the timer function does is simply post a redisplay msg and then reset itself.

The second thread is for the actual simulation.  Each state has its own function.  When states change the current thread is kill and the next one is laucnched.  NOTE: to be tested.


Syncronization of data between the simulation thread and the rendering thread is done through sync_*.  Where the * is the state name in question e.g. test.  All data that will be needed will be stored here as well as its [un,]locking functions.  So, in essence we have:

         sync
       /      \
render          simulation


Each of these parts will keep a copy of the data.  I believe it should be this way as running each step of the sim and rendering are time consuming things whereas memcpy is quick.  And we don't want to run into blocking problems.

So, for simulation and rendering we have the data flow:

simulation -> sync -> render

But, the mouse and keyboard data must go in the opposite direction.  So, similarly for that but in the opposite direction.  More on this when it's implemented.
