Rendering using your architecture?

[TNTniceman]

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. 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'm sure there is a reason it's just not coming to mind right now. Essentially I am wondering why it would be necessary to ever have more than one Engine and how would those Engines be put to use together?

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.

If anyone from the team or someone who knows how this architecture works could answer my questions that would be great.

[GroundUpEngine]

I believe they use a main engine system then a group of subsystems, the main subsystem is the rendering subsystem which works uniquely because it contains drawing calls which abstract the engine software from the various hardware platforms. This abstraction is done by keeping all the platform specific code separate and depending on which platform they wish to build the code for, before compiling the code they would define that platform activating the platform specific code that is abstracted.

e.g.

Code: Select all

class RenderingSubsystem
{
 void draw()
 {
 #ifdef PC
  glVertex2f()..
  ..
 #elif DREAMCAST
  ..
  ..
 #endif
 }
}

[Falco Girgis]

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.

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.

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.

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();
}

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.

[GroundUpEngine]

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.

Very informative! My bad I was referring to the old engine code

[TNTniceman]

Thank you for answering, I was worried this thread would go unnoticed. I was exhausted when I posted these questions so I'm not surprised that some of them were difficult to understand. Looking at your reply clears my questions about the engine up; you see, I assumed that because you made the Engine class so flexible that you had multiple instances of this class handling different aspects of the game. This was where my previous questions came from, for I was confused as to why you would ever need to have multiple instances of your Engine class managing separate subsystems. I realize now this is not the case.

In the previous iteration of my engine I did something similar, just without the Engine class managing the subsystems... Regardless of its inferiority to the ES engine, it worked out nicely.

[dandymcgee]

Regardless of its inferiority to the ES engine, it worked out nicely.

A humbling statement, but there are many problems for which the ES engine is not the best solution. It is powerful yes, but would be overkill for many small or varying projects.

[TNTniceman]

Regardless of its inferiority to the ES engine, it worked out nicely.

A humbling statement, but there are many problems for which the ES engine is not the best solution. It is powerful yes, but would be overkill for many small or varying projects.

I completely agree, the engine fit what I had in mind, although I scrapped the whole project to start over again. Another bad habit, I suppose.

[Falco Girgis]

[..] although I scrapped the whole project to start over again. Another bad habit, I suppose.

Not really...

Sure, from an outside "why isn't your project done yet, I know nothing about coding" perspective it is, but they aren't the people you're trying to impress. If you never took a step back to rewrite code like that, you would never be able to truly evolve as a developer.

Another thing these people who love to bitch about rewrites don't understand is that if you are not proud of the code you write, you will not be motivated to write it. If I never rewrote any of our engine, I would have already quit by now. I need something that gives me pride and excitement. Old, shitty code gives me neither of these things.

[dandymcgee]

I need something that gives me pride and excitement. Old, shitty code gives me neither of these things.

On top of that, it's a pain in the ass to extend and maintain. The old building a house on sand dilemma (See: New Jersey). Too soon?

[TNTniceman]

I need something that gives me pride and excitement. Old, shitty code gives me neither of these things.

On top of that, it's a pain in the ass to extend and maintain. The old building a house on sand dilemma (See: New Jersey). Too soon?

It's never too soon when it comes to Jersey, they deserve it...

OT: I have to agree that rewriting this engine has been an amazing experience, even though this will be the third time doing so. I am extremely happy with what I am doing right now, so hopefully I won't have to again.