Jump to content
  • Advertisement
  • entries
  • comments
  • views

Direct3D sprites

Sign in to follow this  


Have finally succumbed and got a GDNet+ account. Now all I have to do is find an avatar image and I'm away.

[EDIT] Got one, but suspect I'll keep getting bored with Avatars and feel the need to change them a lot.

In the unlikely event that anyone is reading this, I am currently absorbed in trying to learn to use Direct3D 9 for 2D sprites. I'm trying to create my own sprite library rather than using ID3DXSprite, not because I think there is anything wrong with the D3DX interface, or that I could compete with it for efficiency, but I just thought that it would be a good way to start to learn about vertex buffers and so on in preparation for moving on to 3D stuff in the future.

So I have a reasonable wrapper up and working with Direct3D 9 that batches quads into an indexed buffer. The next step is a mechanism for loading a bunch of images efficiently onto one texture so I can batch all the sprites together in one DrawIndexedPrimitive call.

I've just finished writing a little Borland C++ Builder application that lets me add bitmaps, along with a red-black image describing the alpha values, to a very simple custom image format that allows for multiple images in a single file and stores the colour information in BGRA format so I can load it directly onto a texture, and I have routines prepared that allow me to copy this data to a specific rectangle on a texture.

However, because the current game I have in mind (my massively single player role playing game or MSPRPG) will require that multiple image files can be specified at run time by the level files but these all need to end up on the same texture, I need a method of organising these onto a texture.

This method needs to be able to deal with each image as it is passed in, with no foreknowledege of subsequent images that will be given to it.

The current best solution I have come up with is to create a big power-of-two dimensioned texture (say 1024x1024 for now), then have a system that allows to specifiy a minimum square size (say 8x8), then generate an array of DWORDs, whose bits map out the texture in terms of 8x8 blocks as used or not.

When an image is added, I intend to search across and down this map until I find a free cell, then search across and down from this cell to see if there is space to fit the image. If there is, copy the image to this position on the texture and return the relevant tu and tv co-ordinates to be stored in an external logging system, and if not, keep searching across and down until a suitable area is located or we run out of texture space (in which case the operation will fail).

This isn't optimal. If a human was arranging these images into a large rectangle and could only consider each image in relation to the previously laid images with no knowledge of the images to come, and also couldn't move previously laid images, then without some kind of experience-based learning, couldn't lay images optimally either as far as I can see.

But as long as the images are roughly the same size, and larger images are submitted before smaller ones, it will be good enough for now. A future improvement might be to add the facility to move previous textures around when space is not found, by examining every rectangle of the new image's size on the map, then examining all the images already within that rectangle and searching to see if they could be located outside the rectangle, and if so, moving them and updating their tu and tv co-ordinates.

Seems a bit complicated so I'm not going to worry about that for now.
Sign in to follow this  


Recommended Comments

If it's your first game with DX, I wouldn't worry about optimising it too much. Hell, this is my third/fourth game and the only thing that I've optimised is my GUI code (and even that isn't very optimised.)

Why not just store all of the images in a single texture to begin with?

Share this comment

Link to comment
Cheers Will F. Glad to be here!

Programmer16 - cheers for the comment. Reason I can't just store all the images on a texture in the first place is I really want to be able to dynamically add new images to the game at run time.

So if, say, all the level blocks were in one file, I want the player to be able to specify their avatar image for the game in a seperate file without modifying the existing data.

Ultimately the idea would be that the player, and perhaps even objects, could exist in totally seperate files (in terms of attributes and graphics) to the level files and other character or object files, and have them all bound dynamically together into one environment when the game is actually run.

However my limited understanding is that if I can then assemble all the images onto one big texture, I can make the rendering more efficient and thus get more on the screen each frame (which is important since I want to implement some kind of shroud and think this might involve quite a lot of quads being rendered to look nice).

Appreciate this all sounds a bit ambitious. I do have a tendancy to set too complicated goals and thus never really finish anything, but then this is only my hobby so that's okay.

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.

GameDev.net 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!