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

FOR I=0 TO 5 STEP 1

Sign in to follow this  
Emmanuel Deloget

258 views

ph24r the 1337


I find the so-called elite speaking cool. The r0x0rz. Not because it is cool, but because it is weird. Probably as weird as the pope singing a rap song. Since he did, I guess there is nothing wrong in da leet language. Quite teh funnay.

Where are the comments?


Since you don't read this, you don't comment this. Quite teh logical. But if (for whatever reason) you want to add a comment - not very difficult you know - feel free to do it. Of course, if you feel you should paypal me, that's even better...

Iterative design


Designing a software is an iterative process. One have to think to a solution, design it, then he must improve its design. Once the software is released, he has to work on the next version, which of course needs more design.
The only one who can create a complete software with only one design iteration Gandalf, but AFAIK he does not exists in our world.

And thus...


yesterday we had a talk about the ownage of the graphic driver. We found that both the graphic engine and the system object can own the driver. Today I want to dig further.

There is nothing wrong in having the graphic driver inside the graphic engine. We saw that it only adds implementation-based drawbacks, and those can be defeated by implementation-based techniques. However the creation of the driver will probably need some access to the system.

On Jan-27, I talked about the system component. It seems that this component needs to provide an access to at least two major UI components: the diplay manager and the input manager. We define the system component with:

namespace System
{
class Display; // not defined yet
class Input; // not define yet
};


Because the graphic driver works tightly with the display subsystem, it will probably have to use it (we already saw that the display system can't be implemented in the graphic engine because of the dependance it implies: it is up to the game frawork to implement it, not to the graphic engine). But, from an abstract point of view, the display system - which is aimed at displaying things - and the graphic driver - which is aimed at (guess...) displaying things - are somewhat equivalent.

If you have two display systems in two different modules then there is something weird. We should be able to factorize things a bit more.

Remember then our first solution (the system own the graphic driver). Now, it seems we have two display systems in a single package. This is really bad, and it is probably not what we want.

Since they are basically the same thing, why don't we factorize at this level? The graphic engine is the display, and the display is the graphic driver. It means that we pull the graphic driver away from the graphic engine.


namespace System
{
class DisplayDriver; // this is the graphic driver!
class InputDriver; // renamed, for consistency
};


Yeah! Teh FacOrizOrz!!!11one


Therefore the driver is now in the system package, meaning that our graphic engine is using the DisplayDriver.
We haven't thought about that until now, but why should the system package (which belongs to the game framework) be aware of the graphic engine who is using it? You'd say that we never said something like that. But we just took a graphic driver from the engine and we put it in the system package. How do we know is the driver is aimed at 2D rendering or not? Even if its interface is an abstraction of the real underlying driver, it should not be designed with 2D game in mind, because we won't be able to reuse it. But we don't want our engine to cope with some advanced 3D rendering issue - hell, it is a 2D engine.

Again, as always, we are lucky. The GoF gave us the solution: we have to use the Adapter pattern (check here if you are unfamiliar with this pattern - although the site speak of C#, the pattern description is fairly generic).

The Adapter pattern will allow us to provide a 2D graphic driver - internal to the graphic engine, this time - which will encapsulate the system DisplayDriver.


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

class GraphicEngine
{
GraphicDriver gdrv;

createDriver(system::DisplayDriver drv)
{
gdrv = new GraphicDriver(drv);
}
destroyDriver() { delete gdrv; }

public:
init(system::DisplayDriver drv) { createDriver(drv); }
uninit() { destroyDriver(); }
draw(AbstractGraphicElement gel) { gel.draw(gdrv) }
};


Quite teh c00lz0r, isn"t it?

Hey, you won't stop now!


Hey, I have a life! See you next time :)
Sign in to follow this  


3 Comments


Recommended Comments

Are you telling me that I have at least one regular reader? You made my heart bump! [grin] (anyway, thanks for your support.)

Share this comment


Link to comment
Guest Anonymous Poster

Posted

I'm regular reader too. I'm working on a Dungeon Master clone and want to abstract the graphic engine, so I find your column quite informative. Keep going !

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!