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

Agathe, daughter of Mr Dapawa.

Sign in to follow this  
Emmanuel Deloget

272 views

News again



No news. Since you don't read them, why should I write news?

design.continue()


Our last analysis lead us to this potential solution:

class GraphicEngine
{
public:
init();
uninit();
draw(GraphicElement gel);
};


The internal implementation of the draw() function is not known yet. In fact, we
have two possibilities to implement this method.

  • the draw() method init the internal state of the graphic engine with the
    GraphicElement data and launch a rendering operation.
  • the draw() method calls a virtual gel.draw() method which performs the real rendering.


The first solution gives the full drawing control to the graphic engine. The application only have to set up a somewhat small parameter set. The engine is free to ignore the bits he don't want to consider. This is an easy solution, but it has some major drawbacks:

  • since the game do not know what are the data which are used by the engine, it must fill all the GraphicElement members.
  • To add more effect or feature, we have to add more GraphicElement members and more code in the graphic engine - for instance, at least one rendering path might be added. The complexity of the rendering engine will grow exponentially, which is never a good thing in a softare designer point of view.


The second solution clearly beats the first one in the sense that the game application don't need to init everything - only the needed features. Moreover, the complexity of the graphic engine do not change when we add features or effects. On the other hand, it requires that we have an interface to setup the engine and launch the rendering. This is the way graphic API works. Both OpenGL and DirectX let you choose the way you want to perform the operations. The benefits are far more interesting than this potential drawback.

We therefore choose the second solution:

class AbstractGraphicElement
{
public:
virtual draw();
};

class GraphicEngine
{
public:
init();
uninit();
draw(AbstractGraphicElement gel) { gel.draw() }
};


Finished?


Of course not! This was the easy part. We'll continue next time - we have now a rather large subject to deal with: the graphic engine needs to provide an interface to the graphic driver.

So, we continue


Yes.
But not today.

Why?


Because.

You blunt


...


Sign in to follow this  


2 Comments


Recommended Comments

Guest Anonymous Poster

Posted

Can't wait for the next entry.

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!