Aurora - introductions and code structure

[Matthew Jack]

Aurora is our name for our current runtime-compiled C++ testbed - that
is, not the runtime-compilation code itself, but the simple game
engine we apply it to. We've developed the "Pulse" simulation-game
under Aurora to show off the runtime-compilation tech, and we hope to
develop other

It consists of some external open-source components, some of our own
code for engine functionality such as logging, and the core runtime
compiler system itself. In Visual Studio's solution explorer you'll
see the following projects:
- Audio_VS2010 - Sound module, currently a simple wrapper for the
OpenAL audio library
- Common_2010 - Some simple types for handling colours, math, etc
across the engine and gamecode.
- Renderer_2010 - Very simple renderer
- Rocket* - These are the RocketLib modules that provide our GUI
system
- RuntimeCompiler_VS2010 - The lowest layer of the runtime-
compilation functionality, reponsible for actually recompiling runtime-
modifiable code and interfacing to it
- SimpleTest - The Pulse demo, a simple game/simulation based on an
immune system
- Systems - Simple core engine components such as logging, timing
etc. Ideally all external systems would be exposed to the engine
through a simple "System" wrapper

Systems I want to explain in a little more detail: the project
populates a global environment struct ( SystemTable * gSys ) with
single instances of engine components, either simple enough to compile
from scratch (e.g. logging) or a wrapper for an externally compiled
library - preferably a DLL or a small static lib. It forms a central
place for bringing together all of these components in a coherent
fashion. Note that out of the "systems", SimpleSerialiser and the
ObjectFactorySystem are crucial to the runtime-compilation code,
whereas the rest are quite decoupled.

Some things we have in mind for the Aurora framework include:
- completely replacing the Renderer module
- porting it to Linux and Mac OS, as a precursor to porting to games
consoles
- possibly removing the entity system
- we may or may not stick with RocketLib

Aurora is just one possible testbed. For instance, we might bring in a
whole new open source engine alongside it to expand our possibilities,
hopefully sharing all the runtime-compilation code. On the flip-side,
we hope people will find it useful to fork Aurora and make drastic
changes to the runtime-compilation code to try out their own ideas -
with all the systems and example projects in place to test out the
results.

Any questions you have about the Aurora engine framework rather than
runtime-compilation itself, feel free to post them here.

[Doug]

If you've downloaded the source, compiled it and ran the demo and are
wondering what this is all about, here's a first simple tutorial to
show what this is all about:

1. Run the demo from Visual Studio with debugger attached (not
required, but helps).

2. Click on the splash screen to see the red blood cells.

3. In Visual Studio uncomment line 144 in GameObject.cpp (it's in the
Runtime Modifiable folder of SimpleTest). You'll find the workflow
nicer if you can view both VS and the demo at the same time. Line
should now read:

m_pRenMesh->SetColor( AUColor(1,1,1) ); // Demo

4. Save out the file GameObject.cpp

5. Watch the file get compiled - this is being done by the demo with
debug output to VS.

6. Watch the red blood cells get turned to white.

If you can't find this line in the code then we've potentially updated
the codebase - and hopefully should have updated tutorials you can
find to go with it!

[Sam Batista]

Holy smokes guys! The first time I did that I nearly shit myself. It's
so seamless and fast. I'm gonna have to look deeper into the tech
behind this.