Jump to content
  • entries
    109
  • comments
    175
  • views
    117439

The Return of the Giant Mummy: Revenge of the Unde

Sign in to follow this  
Emmanuel Deloget

258 views

I write this while my gf is sleeping. There is something I still don't understand concerning my relation with computers. I mean, she's a girl, so she is probably more interesting than my notebook. But I continue to speak to my notebook (you know, the one with a sux0rz kebord).

Lack of updates


I told you, I was ill. I can't sort ideas when I'm ill. So I didn't write anything here during that time. But now, I'm fine.

I just remember that you don't bother with this kind of information.

A poor graphic driver in a poor graphic engine


This is probably the central part of the graphic engine. On Jan-26 we saw that our graphic engine tells the graphic elements to draw themselves. To be able to do this, they need to use a graphic device driver (let's call him the graphic driver) which is able to handle low level resources.

Now, who does instanciate the graphic driver? As I see it there is two possibilities.

First, as it name implies, the driver can be viewed as a system resource. Therefore, it should be created by the system framework (just as the display and the input objects). This sound rather logical but if we dig further then the problems are coming. For example, the driver will probably need to expose some resource creation methods - and these resources looks like graphic objects. Therefore the graphic driver should know what is a graphic object - and therefore it should know some part of the graphic engine. Which is plain stupid since it adds a circular reference in our design.

The second solution avoid this problem: the graphic driver, although it seems to be a system object, is considered as a graphic engine entity. The graphic engine is responsible for its creation. The problem we now have is that the graphic engine now relies on a system object. But is this really a problem? Let's see the biggest impact of this solution: it makes the graphic engine dependant on the platform, which is not what we want. We are lukcy, because this dependance can be avoided using a clever directory structure (a la Loki). But this is an implementation trick and we should not speak about these now.

Inside or outside?


Each possible design seems to be the complete contrary of the other. Actually they are, because they are using a diferent paradigm. One tells the graphic engine: "hey, you should use this driver", while the other tells "the graphic engine is using this driver".

Our main issue is that it seems that none of the proposed solution is acceptable.

Well, this is not really true.

Let's consider our first solution. I told you that the graphic driver resources are graphic objects. Indeed they are: it sound weird to not consider a texture (for example) as a graphic object. But we can view the problem using another point of view: "I am the graphic driver, I'm a system object, so why don't you consider the resource I create as system objects?". After all, this is equally true. For example, a DX texture holds a reference to the underlying IDirect3DTexture9 object, which may be considered as a system object if we consider IDirect3DDevice9 as a system object too. Using this point of view we don't need the dependencie over the graphic engine anymore - basically: we solve our problem.

Now, let's have a look to the second solution. The engine creates the driver - and therefore the code of the driver is inside the engine itself. This does not allow us to transparently plug another driver - because only one driver is known. Is i a problem? To answer the question, let's ask another one: why do we want to plug another driver into the system?

I am hearing your answers: "because maybe there is a more efficient driver". Then we should use it and discard the first one. "But maybe it would be good to support multiple platform". You mean: at the same time? No matter what your answer is, you'll be able to find arguments who defeat the purpose of supporting multiple drivers at a design level. Of course, when it comes to implementation, maybe we'll create more than one driver. But the key word in the later sentence is implementation. And the answer to this problem had been written some paragraphs ago: Loki does it, so why don't we use a clever directory structure? A single compilation flag will enable us to produce a program which will use one of the 88 driver we wrote. We can even create a driver which is in fact a driver loader - which will load a particular driver at run time.

So both are good


Yes (well, as of today, it seems that both solutions are acceptable. Remember a design is an itrative process. Maybe we'll ffind another problem concerning one of these solutions).

You may ask: "why do you say that? Now we don't know which model to choose!".

There is one important thing about design that I didn't said already. There is more than one correct design. This sound obvious but is often forgotten. When we design, we often try to do our best. Sometimes, we have to choose between two or more solutions. When one is obviously better, hen we have to choose it. But when they are equally good (or, since it may happen sometimes) equally bad, where is the problem then?

Rule of thumb: don't create problem where there is no problem :)

And the winner is...


I won't tell you who wins :) Since you already knows that the two solution are correct, the one I pick is only a matter of taste - and I must encourage you to develop your own taste ;)

Anyway the result is there: now, we have a graphic object to manage. Wether it has been created by the engine or given by the system is not really our problem, since it does not change the representation.


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

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


Next point?


Now it begins to be easier. We know the fundamental objects and how they interact. Now we probably have to think about the details...

We have still another big point to consider: my explaination off the game MVC was rather short. We need to complete it in order to have a decent view of what is the system, the game, tthe ame engine and so on.

Anyway, good night, and I hate Hulk.
Sign in to follow this  


0 Comments


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 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!