Jump to content
  • Advertisement
  • entries
    109
  • comments
    175
  • views
    117335

Design II : Attack of the GraphicEngine

Sign in to follow this  
Emmanuel Deloget

308 views

Abstract of the previous shows


In the previous installment of my ongoing journal activity, I decided to speak about UML design. I now see that my wording is obscure and contains a lot of (sometimes kebod related) english errors. My bad. Nevertheless I decided to continue to speak about this subject - I find it interesting. Since noone really read this journal (thanks Mushu for the info), I bet it will not hurt your brains.

Good design, bad design


The preliminary design I got yesterday is a bit small. Some pseudo-C++ gives us:1


class GraphicEngine
{
public:
init();
uninit();
draw(World world);
draw(NonStaticObject object);
};


It raises an interesting question: who performs the drawing? Should we say that the GraphicEngine draws the World object or should we say that the World should draw itself using the GraphicEngine? The answer is not very simple.

First, let's consider a simple design issue: what if I decide to modify the graphic engine? I may decide to finally go the 3D way. I probably won't want to rebuild all the game code because of this modification- even it if is a large modification. Or I may decide to adapt the drawing to the device capabilities (a mobile phone is more restricted than a PC). Using this wording it seems that I should let my GraphicEngine draw the world. It means that my GraphicEngine will have to know how a World object is built. Here comes the problem...

OTOH the GraphicEngine is a base component that should not be aware of what the game really is. If I decide to modify my underlying World representation later - because of some important design issue - I will need to modify the GraphicEngine as well - even if the rendering itself do not change. Moreover, if I decide to add a new object type that have to be drawn then I'll have to modify the GraphicEngine as well.

Conclusion: there is something missing. We have to forget our preliminrary design and we need to find better answers to the questions I asked yesterday: who will use the graphic engine, and what will the actor do with it?

To be continued... :)
Sign in to follow this  


3 Comments


Recommended Comments

I never was a big fan of function names like "Initialize" and "Uninitialize". I always prefer semantics like "Open" and "Close" or "Start" and "Stop" or "Create" and "Destroy".

Also, in most implementations, a graphics engine is a singleton, and because of this, it can have a single, global, point of access. The natural consequence of this is that everything that needs to be drawn should have access to it.


class SGraphicsEngine
{
public:
static bool Open();//or Start, or Create
static void Close();//or Stop, or Destroy
};



Furthermore, in a rendering list, it should not matter what you are rendering... each object should inherit from a single base class, perhaps "IRenderable". The graphics engine would contain a list of renderables, and when it comes time to render a scene, it goes through and tells each object to draw itself.


class SGraphicsEngine
{
public:
static bool Open();
static void Close();
static bool AddObject(IRenderable* pObject);
static bool Render();
};

Share this comment


Link to comment
The above is a good example, however the render function of the renderable object may depend on resources stored within the graphics object. If this is the case the renderable object would need a reference to the core engine as well as an interface to retrieve the resources. If you didn't want an instance of the graphics engine stored in the renderable object you could pass it as a parameter of the render function.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!