[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.