Whilst discussions of graphics APIs are great and all, could a mod please split this thread if possible? Draco came in here with a specific question, and it is unfair to them to have the thread derailed into an unrelated discussion, especially since the problem they are trying to deal with is API-agnostic. Once the thread is split (or not), I shall dive in with my own thoughts on this matter
Going back to the actual concern of the original poster:
Uhhh I'm specifically looking for help using a surface and cutting that surface up into textures.
What I believe they are trying to do is implement this section of the tutorial:
What we need is a way to break up a (potentially large) bitmap into smaller images to be stored in textures. The easiest way to do this is to load the entire bitmap into a Direct3D surface (which have no size restrictions) and then use CopyRects to copy surface sub-images into textures.
The demo program uses D3DFMT_A1R5G5B5, a 16-bit surface format where five bits are reserved for each colour and one bit is reserved for alpha transparency. Other suitable surface formats are D3DFMT_A8R8G8B8 and D3DFMT_A4R4G4B4. (See CreateSurfaceFromFilein the demo.
You need an alpha component in your surface format for transparency, and an RGB component for the colours to display correctly. The exception to this rule is D3DFMT_A8R3G3B2, which (in my experience) has insufficient RGB values to produce a good range of colours and often results in an incomprehensible grey image.
The same surface format is used for the textures. (You will not be able to copy data between textures and surface otherwise.)
In most video cards, the width and height of a texture must be a power of two. A 20x40 image will be stored in a 32x64 texture. This extra area within our texture must be set to a transparent colour or random colours may surround your sprites.
Newer video cards let you create textures that are not limited to powers of two.
To clear the texture we need to create a blank surface and then copy its content over to the texture. Can't we clear the texture directly, you ask? We can but textures placed in the D3DPOOL_DEFAULT pool cannot be locked for clearing [1g]. Placing our textures in D3DPOOL_MANAGED memory will allow us to lock the texture but the copy method works for both cases so it is more flexible. See CreateTextureFromSurface in the demo.
Finally, we can copy the bitmap image over to the texture.
This section specifically addresses the problem of texture sizes. Graphics hardware has traditionally had a maximum size and dimension of textures supported.
This problem applies equally to OpenGL, hence why the API discussions really belong elsewhere (Although for OpenGL, the solution would be quite different).
Looking into IDirect3DDevice8::CopyRects, it seems that Draco's most likely problem is that I think this function no longer exists on the IDirect3DDevice9 interface. One quick search later, and
the appropriate alternatives (in theory) are found!
Developer
