The answer to your 2nd question is probably to make the frames have equal sizes. Enlarge the smaller frames to equal the larger frames.

Quote:Original post by Antonym
Thanks I already found a solution. All I had to do was use the createtexturefromfileEX and set the width and height to the D3DX_DEFAULT_NONPOW2 flag.

Haven't found an answer to my second problem tho..

I guess it is pretty rare now, but some hardware doesn't support non-power-of-2 texture sizes. There is also some overhead in using a separate texture per sprite frame as you will have to switch texture for every sprite you draw, which means you can batch less.

Something to look into is texture atlasing.

Regarding your second question, it would be up to you to maintain the necessary information to deal with different sized frames. One solution might be to load this information from a separate file and keep it available in a way that you can retrieve the dimensions of the frame based on a frame index.

Quote:Original post by Antonym
My problem is that like when you have a ton of frames in the same image how can you find out at exactly what point a particular frame starts and ends in an image. Especially when some of the frames are more spaced than other(You can't just divide the size of the image by the number of frames to find out where they begin and end, also I tried doing this and it gave me a decimal amount which is the reason I can't use RECT).

Texture atlasing won't solve this. I got the impression that you were using a texture per frame.

Dividing the width of the image by the number of frames would only work if a) all the frames were the same width and b) the width of the image was an exact multiple of the frame width.

If you want to procedurally work out the width and height of each frame rather than supply the information manually in a separate file, you will need to do some kind of per-pixel analysis on the image.

One idea might be to take a colour that is not used in any frame and draw a single pixel border around each frame in this colour. You could then step across and down the image looking for this colour, giving you the dimensions of the frame.

Another idea might be to do the atlasing procedurally, so each frame is loaded from a separate image file and procedurally added to a large atlas texture at program start up. You could then get the dimensions of each frame as you load each individual image file. Methods to procedurally pack images into a texture can be investigated by googling texture packing.

This is sort of what I do - my images are all stored in a custom sprite file format where the width and height of each image are stored along with the ARGB data. I use a texture packing system to pack these onto a larger texture and store the relevant texture co-ordinates as I do so.

Quote:Original post by Antonym
'If you want to procedurally work out the width and height of each frame rather than supply the information manually in a separate file'
Supplying the the information manually? What do you mean by this?

Literally just manually working out the dimensions of each image and storing them in a text or XML file which you load when you load the image.

Quote:Original post by Antonym
'This is sort of what I do - my images are all stored in a custom sprite file format where the width and height of each image are stored along with the ARGB data. I use a texture packing system to pack these onto a larger texture and store the relevant texture co-ordinates as I do so.'
Interesting, how did you create a custom sprite format? Seems handy.

I have a command line program that loads in a load of bitmaps with an associated red-black image representing the alpha channel and writes out a binary file that has the following format:

int: number of imagesfor each image    int: width    int: height    for each pixel        byte: alpha        byte: red        byte: green        byte: blue

There are better options than using bitmaps, I just had some handy code for reading them in and accessing the pixel data. My program reads a text file that specifies which images to use and the name of the .spr file to save to.

I then have some routines in my Direct3D code that load the above file, atlas onto a large texture and return the texture co-ordinates.