05 May 2010

Structure

It's been hard to persuade myself to drop down a few words about last progresses. I've never been a good speaker, and in special way by means of human languages.
Indeed very few progresses have been achieved and many weeks have been spent for whichever thing demanded by day-by-day life, including rest. I will ever complain for this one not being my job, because my actual job does actually take almost all my resources away, making this a occasional snatchy hobby, and practically a lost cause.

This has its bright side though: this research is not subordinated to production schedule and there is way to mind the what and the how.

These few progresses have been yet a chance to think over things, to take a stock of the situation, to review the road map and also to realize how the long way is even longer than it could be imagined. I'm sensing how this will be a constant.

However this post is here as a pit-stop around the structure and design of this little piece of code. As I always stated, I do believe that a good design is the first important feature to mind of for better addressing efforts. And a so poor, lacking of resources project (1 developer, 2-3 hours per month) couldn't be more needy of good design.

In the very beginning, for a brief while I've bred a rather ambitious structure which separated frameworks, engines and libraries. This because I wanted to fantasize about all elements I could be putting up with in a prosperous future, such as game application, editing application, web application, audio engine, physic engine, AI..

But this layer of abstraction was disturbing the original simplicity, and my inspiration as well. So I soon reverted back to the original structure where there is a unique framework (the windowed application, designed for interactive real-time 3D graphics) playing with a unique engine (the 3D engine) and a few general purpose libraries (currently the I/O and the Math libraries).

My care has then lain on extricating elements in such a way to make them independent entities, as much as possible abstract and machine independent. Special care I have taken on circumscribing those parts which are strictly OS dependent and the ones that are renderer dependent. The rest is code completely unaware of the underlying hardware.



It's total 287 KB of C++ code, still not cross-platform but well arranged to become. In detail:

  • 5% of platform dependent code (Win32)
  • 45% of renderer dependent code (OpenGL)
  • 50% of cross-platform code

The Win32 code is for Mutex, Thread, Timer, Window.. The Window object is also the gateway to interaction with OS, basically for handling events and operations such as inputs, drawing etc. This part is quite stable and only needs to be translated to the other platforms.

The OpenGL part is the renderer dependent part of the 3D engine which, though is still an early version, already includes most of the key features of a 3D engine, such as camera, scene manager, lighting, LOD systems, VBO, shaders (GLSL, ASM, ARB multitexturing).. This part is also depositary of all my knowledge about the old and new OpenGL API so far.

The rest is plain cross-platform code for application logic (including the terrain generation) and libraries. And it's indeed the only part meant to be increasing.