Quote: "In fact there is no difference between the loaded textures at all."
Is that true? I thought DirectX was able to store image data in a variety of formats and it seems possible to me that DBPro might not load all images into the same internal format. For example, aren't DDS images loaded directly into the corresponding DirectX surface format?
For example, from the DX9 SDK docs:
Quote: "D3DFORMAT
Defines the various types of surface formats.
Syntax
typedef enum _D3DFORMAT {
... (values)
} D3DFORMAT;
There are several types of formats:
BackBuffer or Display Formats
Buffer Formats
DXTn Compressed Texture Formats
Floating-Point Formats
FOURCC Formats
IEEE Formats
Mixed Formats
Signed Formats
Unsigned Formats
Other
Constant Information
All formats are listed from left to right, most-significant bit to least-significant bit. For example, D3DFORMAT_ARGB is ordered from the most-significant bit channel A (alpha), to the least-significant bit channel B (blue). When traversing surface data, the data is stored in memory from least-significant bit to most-significant bit, which means that the channel order in memory is from least-significant bit (blue) to most-significant bit (alpha).
The default value for formats that contain undefined channels (G16R16, A8, and so on) is 1. The only exception is the A8 format, which is initialized to 000 for the three color channels.
The order of the bits is from the most significant byte first, so D3DFMT_A8L8 indicates that the high byte of this 2-byte format is alpha. D3DFMT_D16 indicates a 16-bit integer value and an application-lockable surface.
Pixel formats have been chosen to enable the expression of hardware-vendor-defined extension formats, as well as to include the well-established FOURCC method. The set of formats understood by the Direct3D runtime is defined by D3DFORMAT.
Note that formats are supplied by independent hardware vendors (IHVs) and many FOURCC codes are not listed. The formats in this enumeration are unique in that they are sanctioned by the runtime, meaning that the reference rasterizer will operate on all these types. IHV-supplied formats will be supported by the individual IHVs on a card-by-card basis.
"
Or have I misunderstood something?
