Advertisement Jump to content
  • Advertisement
  • entries
  • comments
  • views

The story of the story of the story of the story o

Sign in to follow this  
Emmanuel Deloget


Day D-1

Tomorrow I'll have an English exam. Nothing very fancy. But I'll know whether I'm good enough to speak 1337 English or not. Oh, wait. I already know.

I'm teh sux0rz at English. Just forgotten that. Crap.

Graphic elements

Yesterday we decided to create an adapter to the graphic driver. Of course, since we are doing this, the first thing will have to do is to define the new interface of this graphic driver adapter (I called it GraphicDriver - the one in the system package is DisplayDriver). And to define it, we need to know what a GraphicElement is because once we are able to say what it is we are able to say how it should use the GraphicDriver.

So, what is a GraphicElement? We have at least three possible choices.

  1. a GraphicElement is a bare resource, for example a texture. In this case the granularity of the DisplayDriver resources encapsulation is very low - and it doesn't seem to be the correct solution.
    a GraphicElement is an intelligent resource - for example, a sprite or a tile. This could be a possible solution.
  2. a GraphicElement is the representation of an in-game object - for example, the player representation or the world representation. A GraphicElement may then hold multiple intelligent resources. This solution seems to be good too.

Once we consider the last possible solutions, the first one is obviously a bad choice. The encapsulation of a system resource should be a graphic resource, and a graphic element should contain them. While being a bad choice, the solution reminds us that we will need to encapsulate the system resources in order to ease their use.

Now we have to choose among the two other solutions. If solution 2 seems to be pretty it is less high level than the other one. Moreover, to define the kind of objects which would be implemented in solution 2 we used a magic word: resource. This should give us hints that would help the design. I'll choose solution 3 because of this hint. Sprites, tiles or tile sets can be implemented as high level resources - which in turn can be implemented by using low level (read system level) resources.

Although the object names would probably need a rework, we now have something like this:

class LowLevelResource
system::DisplayResource rsc;

class HighLevelResource
set llrsc;

class ConcreteGraphicElement : public AbstractGraphicElement
set hlrsc;
create some HighLevelResource items
populates hlrsc
destroy the items in hlrsc
virtual draw(GraphicDriver gdrv)
setup gdrv
draw the different hlrsc items

The main point now is that the graphic engine user is now responsible for creating the ConcreteGraphicElement objects.

Teh Xtrab0lz!

I manage to not write "Teh xtr3b0lz0rz", which may have been too much 1337 for you, young padawan.

The next time we'll speak about the low level and high level resources. And we'll explain things about these two entries. Yeah. Any comments?


Oh, come on! Stop h2'ing your questions. You look like a 10 y.o.
Sign in to follow this  


Recommended Comments

There are no comments to display.

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, you agree to our community Guidelines, Terms of Use, and Privacy Policy. 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!