[CrashPilot]

Hello everyone,

I am embarking in the wonderous world of 2D animation and using directx9. I am a complete noob in the world of game engine design etc. I find DX quite usefull and in fact easy to use but in my opinion it's the engine design that makes or breaks the application. There are a massive amount of tutorials on the web explaning how to render a single image to a target but not so much for rendering a lot of sprites.

In order for me to figure out that I have understood the concept of this I would like to get some advice on this issue.

1) A sprite is not a image but an object that is linked to a device that takes an image and some other aditional information and display's that to the target. As such having one DirectX.Sprite object is all you need for the entire engine. You only need your own custom SpriteObject that holds the actual information to draw.

2) If the above is true then:
In order to draw a image multiple times I would recycle a image (or texture) multiple times. Therefor the customSprite object does not contain an actual image but holds a pointer to a collection of preloaded textures. ( This should save memory significantly I believe)

3) The memory of the graphics card only holds the information that it will need for calculating the current scene, I need to provide the graphics card with all the information it needs in order to operate every scene and is transmitted over the PCI-Ex bus every time.

For most of you these questions may seema bit simple but I find it hard to find any good documentation on how graphics cards actually work.

Greetings,

Crashpilot

[Qua]

1. DirectX provides the Sprite class which wraps a lot of functionality making it easy to render 2D images and animations. It is correct that the sprite part of your game can be rendered using a single instance of the Sprite class. To render sprites with the class it has the Draw method which takes several inputs - grouping these parameters in a class would be a sound decision indeed.

2. With all kinds of data that you be shared among several instances without being modified specifically for a single instance you should have an object/data manager that takes care of loading-, serving- and disposing the objects. In your case this could be a texture manager class which holds a dictionary of the loaded objects (this is a very common approach in game engine design and you will see it used in major engines such as the Unreal engine).

3. The main thing that will reside in your graphic cards memorh is texture data and vertices / matrices. Texture data especially will be the one source taking up most of the space. As for where the data is transmitted with respect to hardware I have absolutely no clue. But, obviously all the data will not be transfered back and forth between the graphics device and motherboard in every single frame. Your load data into the graphics card, and in turn it does processes the data and outputs a few bits to whatever monitor(s) is connected.

[CrashPilot]

Thanks for that *Very* quick response !

Point three was more focused on the possibility that there may be a few functions that allow you to transfer images or textures to the card that you will use nearly every scene.

Thanks again.

[Qua]

Originally Posted by CrashPilot

Thanks for that *Very* quick response !

Point three was more focused on the possibility that there may be a few functions that allow you to transfer images or textures to the card that you will use nearly every scene.

Thanks again.

When you load/create a texture it is automatically stored in the graphic cards memory until you dispose of it. The only thing you need to take care of in your code is only to load the same textures once, and then referencing it throughout your code.