Hello,
I'm having problems with my system crashing when I call destroy_bitmap() when the bitmap is a system or video bitmap, but not when it is a memory bitmap. This is roughly what I am doing, I'm in 32bpp and my bitmaps are 32bpp, allegro is fully initialised and ready to go:

void someclass::LoadFunction()
{
 BITMAP* tmp;
 this->Image=load_bmp(filename,NULL);
 if(WantSystemBitmap)
 {
  tmp=create_system_bitmap(Image->w,Image->h);
  blit(Image,tmp,0,0,0,0,Image->w,Image->h);
  if(tmp)
  {
    destroy_bitmap(Image);
    Image=tmp;
  }
 }

Everything works fine and the graphic is displayed in the game.

4. On quitting I do this (allegro is still initialised, so no problems there).
if(Image) destroy_bitmap(Image);

Anyone got a clue as to what could be causing it to crash? the bitmap definitely exists on the call to destroy and can still be viewed ok, it's memory address is the same as when it was initially created. It has no sub-bitmaps, etc. It only crashes when it is a system bitmap, so I guess it must be something to do with the creation of the bitmap, but I can't see a fault.

Your problem is not destroying them. You're setting Image to a deleted pointer. You need to do this:

That should do 100% better

EDIT: On second look, you're not setting it to a NULL pointer, but try this way anyways. It should work better.
EDIT AGAIN: Also, try calling release_bitmap(someclass->Image); brefore deleting it? Maybe? I dunno. That might help shrugs

I'll try it, but I don't see how it would work any better.

I'm getting lots of wierd things happening. If I display the same bitmap but have enabled paging/triple buffering these graphics all point to the wrong images. It's as if creating my 2 or 3 video bitmaps for the screen buffers is affecting system/video bitmaps I create from the above method in my first post, in that instead of pointing to the correct image they are pointing to another image.

Neil.

Which order are you allocating things in? Of course some freaky stuff has to be done to support Allegro's "unique" screen update system in DirectX and there seems to be a lot going on that isn't documented in the normal readme files. But to directly copy a large chunk of text from the top of src/win/wddbmp.c:

I'm not 100% sure what to make of all this, but it definitely seems you should allocate your video surfaces that may become the frame buffer first...

I think (I'll look at the code tonight), but I'm first creating 3 (or 2 for paged) video bitmaps to cover the screen bitmaps, then I'm creating the smaller bitmaps from the memory bitmaps.

Thomas, was my code right or should I be doing it the way Synaps Jump recommended, as I can't see anything wrong with my code.

I should say, that when I'm getting errors with the video/system bitmaps seemingly looking at the wrong bitmap (though memory bitmaps work), only happens when I'm using sub-bitmaps of video or system bitmaps.

I can let you see my code if you wish, but it's spread over a couple of files

One final nail in my video/system bitmap is when I try and delete my surface bitmap, e.g. destroy_bitmap(page[0]) it crashes with a pointer error, but I've checked and I haven't got the screen locked for drawing and just a few seconds before this my game loop was showing the video pages fine.

Now, another problem I'm having that I noticed on a very simple example that just used textprintf_ex() was there was lots of white noise in blocks over my screen when I use video bitmaps for the surface. I'm simply using the code as shown in the allegro help file.

I can't see any real difference in validity between the two snippets of code in this thread. I have vague memories of receiving crashes on destroy_bitmap for video bitmaps when I felt I shouldn't many years ago, but I don't think Allegro.cc was around at the time and I don't think I submited a bug report. OS X Allegro doesn't support video or system bitmaps so I've had no real experience lately.

Was this perchance related to using the Allegro mousecursor and not calling show_mouse(NULL) before destroying the bitmaps? Only now (post 4.2.0) has it been mentioned in the docs.

AE.

Fixed a couple of things! which I guess might serve as something to remember for others!

1. my system was crashing at the end because I was calling set_gfx_mode(GFX_TEXT...) before I deleted my video bitmaps

2. I was experiencing white noise because I'd forgotton to clear the bitmaps prior to using them (memory were ok)

3. I was sometimes not seeing text because it was written to the screen object and I guess when you use paging/triple you shouldn't be doing this.

As for the code Thomas mentioned:

I don't understand this, as it sounds like video_bitmaps are only used for screen buffers and are allocated to flipping_page[x]. What about normal bitmaps that you want to simply store in video memory?

Indeed!

In that case, your malloc() clears the returned memory. This isn't guarenteed and you can't count on it, even for memory bitmaps. Always clear bitmaps you just allocated.

Correct. You draw onto the pages you allocate. This is mentioned in the docs, but I can understand if you missed it:

The reason for all these crap coding errors was that my framework is a large beast now and triple/paging was put in at the end so I had to go through all my code and check whether all the stuff that accessed the current buffer was valid code and/or had to change, and as this is the first time I've used system/video bitmaps and paging/triple buffering it took a few re-reads of the code to find them all as the code by itself looks ok, just in the context of video buffers isn't.

But yes, I did read those bits, they are the reason why I fixed my code. God bless the Allegro manual

I've only my mysterious switching sub-bitmaps when using video/system memory as the parent to look at now

Well, what I sortof meant to say was, if you think there are things that can be improved in the manual to make some of these caveats more obvious, feel free to say so.

Not really, the manual is a reference guide and serves it's purpose brilliantly.

Maybe if someone wrote a programming guide to go with it, that would be a different story, as that would tie the stuff together.

Neil.