Initial design architecture

Hi all,

Time to begin. My major intent here is to get practice and experience of game development, so I won't try to create something complex. Just simple 3D arcade, with some limitations and features.

First of all I would like to specify some requirements for the subsystems of the game engine.

• graphical output subsystem - openGL;
• physical engine;
• user events processing;
• target platform - OS Linux;
• engine has to be pluggable - ?;

Initial 3D engine structure is provided at the picture below.


Brief description of 3D engine components:

• Scene Manager (SM)- abstract entity targeted to manage content of the scene; Scene Manager implements the set of API required to add/remove scene nodes, groups, lights, animation states for nodes; prepares the render queue, fills it with user viewable objects only, and call the API of render subsystem to proceed with pre-processing and drawing objects;
  
• Resource manager (RM) - abstract entity to store meshes, textures, bumpmaps, animations etc., and provide links to them for in-game objects;
• Render queue (RQ) - Z-ordered queue; This queue is prepared by scene manager and passed further into the rendering subsystem; The queue contains Z-ordered renderable objects. These objects contains data required only for drawing them via OpenGL layer;
• Engine rendering subsystem (ERS)- performs pre-processing (apply mesh transformations, rotations, animations, whatever? without calling to openGL API ) at the render queue and after that draw the renderable items using openGL API;
• game manager (GM) - suppose to be major entity of game core, implements manipulating of all in-game objects. GM implements calls to SM, in case if new node needs to be added into the scene or remove from it, to set up links between scene node and mesh, mesh and texture, etc;
  

In other words the one frame rendering design overview could be represented as follows:



==
From the high level perspective the 3D engine has two separate threads - one for drawing scene, another one for capturing events from user. The activity diagrams for both threads is provided below:

At this moment I plan to both threads be blocked:

• drawing thread is blocked until updateScene method isn't called by Game Manager (or ?);
• event capturing thread blocked until new event comes; this thread is waiting for new event by calling XWindowEvent; After event is received it calls the game core event handle callback function (see picture below);

Q: Why event event capture thread is located and running at the 3D engine layer?
A: The 3D engine layer besides drawing also creates render target - window (X-Window) and stores its data inside of internal data structures. So it seems logical to run this thread inside of 3D engine, and use callback function to pass events to the game core.

And one more picture, now about high level overview of message processing architecture:

The ring-buffer is used to pass event data from 3D engine core into game core. Here we have two threads:

• event capture thread, running at the 3D engine layer and waiting for event from X-server for our window;
• event processing thread, running at the game core layer, also waiting for new events; but this thread waits until new event appears at the ring-buffer;

==
couple comments about realization:

• event handling subsystem requires callback function (pointer) to be provided before start event processing loop; I'm not sure about using ring-buffer for passing user events from 3D engine to game event processing layer, since such design obviously implements some timings;
  
• 3D drawing subsystem requires callback to drawing function(s). In this case 3D engine becomes more flexible, but such realization seems to me unnecessary right now;
  

WBR,
Vadim

p.s. eventually it is a not such easy work to describe design and provide documentation to it; but I'll try..