@Uhwrek: No, the copied bitmap in his code does not create 2 bitmaps with the same handle, if you look at the testing code he posted originally, it puts a red cross on the original bmap. When i ran the code, i had two bmaps - one with and one without a red cross on it.
I don't know what code you're talking about, I was talking about Mr. Guests code. Most obviously you're not believing me. As I already said, you better have a look at atypes.h
typedef struct BMAP {
C_LINK link;
long width,height; // original size of the bitmap
long bytespp; // original bytes per pixel (1..4)
void *ptr; // internal use
byte *pixels; // ptr to palettized, 565, 4444, 888 or 8888 coded original image
long flags; // see BMPF_... above
void *d3dtex; // LPDIRECT3DTEXTURE9 (usually a different format than the original image)
float u1,v1,u2,v2; // texture pixel bounds
long u,v; // cutout start size
long refcount; // for implicitely created bmaps
long finalwidth,finalheight,finalbytespp;
long pitch,finalpitch;
long miplevels;
long finalformat;
void *finalbits; // bitmap content when locked, otherwise NULL
} BMAP;
As you can see here the BMAP struct contains the C_LINK struct, which contains the handle. So using the mem_cpy approach WILL copy this handle. As you can see furthermore there are different pointers to image data, namely *pixels, *d3dtex and *finalbits. All this data does not get copied by mem_cpy, just the pointers get copied. Hence the image data does not get copied and copying the bitmap is kind of senseless. If you understand that and are willing to live with the consequences, go for it. But don't cry if this will fuck things up later on.
EDIT: @JustSid: pffffffff....
