Mother of god, these are very broad, open-ended questions... But I'm feeling particularly warm and fuzzy right now after a good several mile run and a Lortab 7.5, so I will indulge your curiosity, my friend.
TNTniceman wrote:Looking at the screenshots on the blog posts and reading the articles allowed me to understand a lot about the way the engines and systems within your project handle themselves; however, it is a confusing system and I am asking for a bit of clarification.
I am pleased to know that you found the articles at least slightly educational. They have a shitload of hits (I can see from our admin panel), so I know you guys are reading them, but almost nobody seems to want to comment on them. If I were you, I would post any specific questions you may have in their respective forum topics... That's why they're there. I am more than willing to discuss the particulars of the code.
TNTniceman wrote:My first question is, why is it necessary to have Engines which contain Systems when you could simply have one collection of Systems that manage the game?
I am honestly not sure what you mean by this. What is an engine other than a collection of code handling certain tasks in the game? Whether you put the label "system" on these code segments or encapsulate those "systems" within an "engine" class doesn't change anything... Is it not still an engine?
It isn't
necessary to have an engine architected in such a manner. It isn't
necessary to even have "Systems" that manage anything... There are plenty of games written in C and ASM that completely lack the concept of an object. Understand that these are highly philosophical, "design" questions and that there are a million different ways one can opt to design the high-level object-oriented aspects of a game engine.
TNTniceman wrote:My second question is within these Engines and Systems, where is the rendering handled? I assume that it is within the systems, but then I can think of multiple problems with this scenario.
Each "subsystem" within our engine generally has its own render method that is invoked from the engine's render funcion... Code snippet from engine.cpp:
Code: Select all
void Engine::render(void) {
gyVidSceneBegin();
gyMatLoadIdentity();
//Begin rendering things affected by camera
_cameraSystem->PushTransform();
_terrainSystem->Render();
Entity::RenderAll();
_collisionSystem->Render();
_cameraSystem->PopTransform();
//Begin rendering overlays
guiSystem->renderOverlay();
gyVidSceneEnd();
}
GroundUpEngine wrote:Code: Select all
class RenderingSubsystem
{
void draw()
{
#ifdef PC
glVertex2f()..
..
#elif DREAMCAST
..
..
#endif
}
}
God no. We haven't used #ifdefs like that in actual engine code since before the inception of libGyro...
The whole point of libGyro is to give the engine a single hardware-agnostic API to call. The above approach is considered a form of compile-time polymorphism. LibGyro opts for link-time polymorphism. The library defines a collection of functions for the API, then each libGyro implementation implements its own set of platform-specific functions. The actual function invoked (whether it be render on Dreamcast or OpenGL) is determined at link-time based on which version of the library you link to.
