First, some news
I've been busy these days because I had to... OK. Let's forget personnal things, you obvioulsy don't want to waste some time. Just to say it: I am the happy owner of a 128MB USB2.0 Verbatim USB key. It was bundled with a pack of 50 CD-R. I bought this 24 euros (something like $30US). Cool enough. That's the price of either the CD tower or the USB key.
I was very happy with my rating. 1343. Was cool. Then I said something (stupid? Not sure. Believe it was that, but I can't verify) and I was rated--. And I ended up to be 1337 rated!!1one Soooo coooooool [grin].
And I really love this journal.
We have some work to do now
Resources are a key element in both 2D and 3D graphic engines. There are a lot of them and they should be managed in a way that won't affect performance.
Last week (yes, it was last week) we spoke about high level resources and low level resources. The distinction between the two is rather easy to do, because there is an obvious difference between a sprite and a bare bitmap, or a mesh and a vertex buffer. High level resources can be used to directly abstract game object representations. To do such, they have to use one or more low level resources because those are the underlying system objects which are needed to really draw something.
I should tell you that there is nothing terribly exciting in this journal entry, because this is more an enumeration of our resources type than something else. Anyway, it has to be done, so...
the return of system::DisplayDriver
Remember that the design of the system abstraction is not our business since we are creating a 2D graphic engine. Nevertheless, since we are designing both at the same time, I allow myself to think about the system::DisplayDriver. This is important because - as I said some days ago - the low level resources are system resources, ie they are created by the DisplayDriver.
As of today, classical DisplayDriver resources are:
- surfaces - textures, render targets, and so on
- vertex and index buffers
- shaders car also be considered as resources - mainly because they are used in the same way, even if their purpose is different because they are not passive.
- some may also consider the internal driver state to be a resource. This is arguable and I believe this is not a good design solution.
Driver state may be implemented as a resource because it really looks like a resource. You can set it, get it, create a new state and such. But creating such a resource kind do not allow us to make little modifications to the current driver state because the granularity of such modification would be below the granularity level of resources.
I won't discuss more about these, mainly because it is not our goal. The main point is that we now have a list of available low level resources to build our high level resource abstraction.
High level resources?
We don't want to cope with these low level resource at the application level, mostly because, hell, we are doing a 2D graphic engine, not a full featured 3D engine with low level control on every bits of information.
Do you remember my very first entry about this design? I asked myself what should be needed in our graphic engine. Let's do it again: what are my answers?
- We need to be able to draw our world - if there is one, of course
- We need to be able to draw our entities - the player, the ennemies, and any other non static entity.
- We also need to be able to use some special effects as well
All of these actions needs to use at least two resources: a bitmap surface (a texture) and an implicit rendering surface (different rendering surfaces may not break our design. We can therefore safely ignore them for the moment, but we'll have to think about them later). Some of these actions may even need more than one bitmap surface - the non static entity should be a sprite and may be animated, for example.
There exists numerous techniques to draw a world. All of these techniques are dealing either with a tiled world (zelda-like, for example) or with a non-tiled, bitmap based world (the great, incredible Worms, for example). Since we didn't say anything about the game type we want to implement, we have to provide the two possibilities.
Entities are objects which are not part of the background. I call them non-static they can change. Not all of them will actually change but the possibility make them - in my humble opinion - non static. As non-static objects, they can be represented by one image (if they don't change their appearance) or multiple images (if they change) or one image with multiple states defined inside this image. 2D special effects can be implemented as special entities since they share the same properties.
Before we continue we have to consider something which we didn't consider yet: we'll always draw quads. This will implicitely use a vertex buffer. There is no reason to actually expose this buffer to the rest of the world. Thus, he will probably be hidden in our graphic engine.
So, what did we get?
We finally got a list of possible 2D high level resources:
- simple bitmap
- sprite with multiple bitmaps or states
- tile with a underlying tileset
These objects will be implemented as our high level resources.
I know, you probably want more. These articles are so good (I have 2 regular readers! gosh!).
Have a good night now, cos I need to go to bed again (this probably means I'm still teh sux0rz).