UPDATE: Out of date

Tentitive and Incomplete!


main.c --- thread.h  ---  thread_pthread.h
        |             |
        |             --  thread_pthread_dynamic.h
        |             |
        |             --  thread_ ...
        |
        |
        -- audio.h  ---  audio_openal.h
        |            |
        |            --  audio_ ...
        |
        |
        -- keyboard.h  --- keyboard_map.h
        |               |
        |               -- keyboard_ ...
        |
        |
        -- mouse.h  ---  mouse_map.h
        |            |
        |            --  mouse_ ...
        |
        |
        -- render.h ---  render_map.h
        |            |
        |            --  render_ ...
        |
        |
        -- state.h

  For things like audio and thread, there can really be only one.  So, a selection needs to be made.  These selections will be made by a preprocessor directive.  Any other source file that needs thread or audio will include [thread,audio].h and those headers will contain a #ifdef structure that will include the proper file.  Each of these will basically wrap the "local" api with our defined wrapper functions.

  For threads, we know that every OS is going to be different.  But, since most OS's have an implementation of pthreads, that will be the default.  We also know that at least one (windows) has a pthread lib that is inappropriately licensed (LGPL) we need to establish dynamic loading as well.

  For audio, we have choosen OpenAL which is licensed inappropriately.  So, like with pthreads on windows, we need to dyanmically load it.  It is also somewhat limited as it isn't officially supported on several platforms.  So, we include a no audio option and have #ifndef's like pthreads for inclusion of other audio libs.

  For threads and audio, since both have a need for dynamic loading, there needs to be an init() to take care of the dynamic loading.  The others that don't have dynamic loading will of course implement the function, but leave it empty.


  Now, mouse, keyboard and render are somewhat connected.  What I propose is to have a stack (of sorts) for these functions pointers.  The 0th element of the stack will be able to be switched but not popped.  The render function will be run somewhat different.  Although the only mouse and keyboard function will be the "top" of the stack, ALL render functions will be run in the stack /from the bottom up/.


  What I'd like to do is to have a "simulation" thread that controls people moving on a map, etc.  This will use glutPostRedisplay to update the display as necessary.
