If you need a fast way of the copy process, you have to copy the pixels directly via memcpy. Create a bitmap as stated by slin with the same format and the same size, and make a clean copy of the pixels structure element in the BMAP structure.
Do not forget to lock the file and (very important) to preload the bitmap you want to copy via bmap_preload.

Hm, I think this should do it :

BMAP* bmSource = bmap_create("whatever.bmp");
BMAP* bmDest = bmap_createblack(bmap_width(bmSource), bmap_height(bmSource) ,bmap_format(bmSource));

bmap_blit (bmDest,bmSource,vector(0,0,0),vector(bmap_width(bmSource),bmap_height(bmSource),0));

I would assume that bmap_blit creates a bit more overhead instead of copying the raw pixel data, as it needs to do some more checks about the boundaries and such stuff.
Also, 8888 is not a valid bitmap depth

MrGuests looks for me also a bit risky, the new bmap couldn't be purged via ptr_remove() and if the source bitmap gets removed, you are probably pretty much fucked. Also: The internal structure might be changed in the future, destroying the memcpy approach completely.

Uuups - too much <ctrl>c <ctrl>v
Corrected it in my previous post.



Well - I dont have an insight into the internals of this function, but I would expect it to calculate the bounderies and then using memcpy. In this specific case I would expect that bmap_blit would do a single memcpy. But maybe it doesn't and if so I agree with the overhead argument.

bmap_createblack + bmap_process. Really fast. Unless you don't have Commercial or Pro.

Jibb

what about bmap_createblack and memcpy finalbits?

@ Mr. Guest:

As usual, sir, you are spot on the money. I ran your code and it creates a copy of the bitmap perfectly. I think this is like the fifth or sixth question youve answered for me. I appriciate your expertise - thank you for taking the time to answer my questions.

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

@JustSid:
given that this Mr. Guests method uses malloc(), and that the source and copy bitmaps are independant of each other, i see no problems with this method. Gamestudios internal structure is irrelevant in this case - since were using malloc()

@Schubido:
I looked at bmap_blit(), ill try it out, but i am leary as the manual specifically states that it is slow. Thanks for the suggestion

@JulzMighty:
Bmap_process? I could not find that in the manual. I have Game studio pro so I should have that command? Or maybe it was only added in A8? (I am on A7.82 atm - once I start a project on one version, i finish it on that version. Saves me alot of time re-writing scripts and such when they decide to change how a given command works.)

Ah. A8 only, I'm afraid.

Jibb

@Caermundh: I warn you to use the proposal of mr. guest. I do not want to sound rude, but the attempt is nonsense and will result in memory leaks, crashs or almost impossible to find bugs.

The code contains several errors

1) All Gamestudio objects are saved in a linked list. The method of a direct memcpy instruction will NOT attach this object to the list.

2) The BMAP structure contains pointers to values. With memcpy you only copy the pointer-values but NOT the values behind the pointers. Therefore the approach is no really copy.

3) 3D Gamestudio objects must be created via 3D-Gamestudio instructions (e.g. bmap_create, snd_create etc.), because you have no idea what the bmap_create instruction is doing besides the attachment to the linked list.

@Caermundh: Not true, here is the struct copied from avtypes.h


As you can see, a BMAP is supposed to be in an linked list (C_LINK link), you destroy this when you copy your BMAP via memcpy. Thus the new BMAP thinks it lives in the linked list and links to its neighbors, but thats not the real case. Calling _ANY_ function that might use this linked list internally will have horrible results. YOU are not the owner of the linked, so don't mess with it!

The next thing ist that there are four pointers, their content isn't copied with memcpy, so you now have two BMAPs that share to some degree their data. Calling _ANY_ function that might alter this data, will alter the data for all BMAPs.

Last but not least: The copy can't be purged from memory via ptr_remove() because it just isn't linked in the linked list. Again, you don't own it, you don't mess with it. When you now use ptr_remove() on the root source BMAP, you will invalidate all copied BMAPs as the shared data is purged and the linked list has changed, thus the copied BMAPs have a wrong state of the linked list (not to mention that this is always the case when a function alters the linked list).


Its _IS_ evil to do it the way MrGuest showed, depending on this function will result for sure in some horrible bugs!


Edit: Another snippet from the atypes.h


Do you still think that you now have two BMAPs with two different handles?