I've implemented switching between fullscreen and windowed modes in my game. I destroy the old display, then create a new one. The next step is to reload the bitmaps, so I don't get FPS in the single digits. Just loading them from disk again works fine.

I'm not sure, but I'm going to be committing a change soon that should help. It adds an ALLEGRO_PRESERVE_TEXTURE flag (default off so nothing changes) that when used, will save your textures in system memory. Then in combination with ALLEGRO_CONVERT_BITMAP, you can simply destroy a display and create a new one and all the bitmaps are automatically converted.

Yeah, I guess if your scenario is like... user presses button, toggle fullscreen, then you don't really need the ALLEGRO_PRESERVE_TEXTURE flag, in which case your code should work, provided that you are not cloning the bitmaps after destroying the display... but then they should be converted to memory bitmaps so I don't know why it isn't working. The use case for the ALLEGRO_PRESERVE_TEXTURE flag is when the bitmaps can become invalidated at any time, such as hotplugging monitors.

This is the code that does the switching, and creates the lovely white boxes. I tried waiting until after I created the new display with destroying the old one, but that didn't work. When switching from fullscreen to windowed, I got a window of the correct size, but that had no title bar, and was glued to the top left of the screen. Like the old and the new display conflicted somehow.

Does 5.0.5 have the bitmap auto-conversion that Elias and Matthew added? If so it seems like it's not working. In fact, some part of me thinks that I fixed a bug in that code while doing the ALLEGRO_PRESERVE_TEXTURE code... actually I'm almost sure of it. I can send you a patch to that file so you can look for changes I made, if you want, but you'll have to just ignore the big chunks I added... the only thing holding this patch up from being committed to 5.1 is that there is a race condition I couldn't pin down and put in an al_rest(1) for the time being (in the iphone display creation code).

I'm not sure if the auto-conversion is present in 5.0.5 or not. I can't find it in the docs. Working around it by loading the files from disk again works fine at the moment, since I have only 30 relatively small bitmaps.

The auto conversion stuff is not in 5.0. It needs more testing before that happens.

And before you commit anything that alters its behavior, you should probably post on AD first just to make sure the bug isn't actually a feature. Elias wrote the code, so I don't know it is implemented, but I know how it's supposed to work.

Ok, I looked at it and I didn't actually change anything except adding a conditional branch. But it shouldn't matter AFAIK, destroying a display has always been supposed to convert to memory bitmaps. One quick fix might be to clone the bitmaps before destroying the display (save them in an array or some such, then copy them back.) Sounds like a hack though. This really sounds like the problems I was having with hot-plugging displays, except my textures were all black or had some noise in them. Are you using D3D or OpenGL?

Looks I'm using Direct3D, I checked the log file. I tried cloning all the bitmaps (with al_clone_bitmap) after calling al_set_new_bitmap_flags(ALLEGRO_MEMORY_BITMAP), before destroying the old display. Then I called al_set_new_bitmap_flags(ALLEGRO_VIDEO_BITMAP) after destroying the old and creating the new display, and then cloned all bitmaps again. But it just crashed.

Yes, I was talking about before the AUTO_CONVERT flag was introduced. At that time there was no conversion except for destroy display->displays video bitmaps converted to memory, and all platforms did it. I'm not sure either which of those 3 is used now, but I guess it could be relevant. I'd have to ask Elias which is used, which might tell us why the first code snippet of torhu's didn't work.

I think destroying a display always converts all display bitmaps to memory bitmaps (if it is the last display sharing the bitmaps). Both in 5.0 and 5.1. The reason was to never have zombie bitmaps I think. I'm all for changing it, so that a VIDEO bitmap would never be a MEMORY bitmap unless it is set to auto convert (which it would be by default).

The drawback is that we'd have to introduce the concept of zombie bitmaps, i.e. bitmaps which cannot be drawn at all, not even as memory bitmaps. The only valid operation on them would be destroying them.

When I tried just destroying the old display and creating a new one, all the bitmaps seemed to be ok. So the automatic conversion to memory bitmaps works. It's when I cloned them after creating the new display that some of them turned into white boxes.

The drawback is that we'd have to introduce the concept of zombie bitmaps, i.e. bitmaps which cannot be drawn at all, not even as memory bitmaps. The only valid operation on them would be destroying them.

If video bitmaps were to be invalidated, Peter's comment was:

Quote:

They should be 0x0 bitmaps without any data associated. We should allow al_create_bitmap to create 0x0 bitmaps anyway

I'm not sure if he meant that those bitmaps should be able to be drawn (null op) or not.

Regardless of whether they can or not, I still prefer it (zombie bitmaps) because I think it makes it easier to document, explain, and understand when conversions happen: if you don't set the conversion flag, the bitmap will never be converted, and if you destroy the last display, the bitmap is lost.

The al_clone_bitmap() call in the first loop in my function has a tendency to return NULL. Is there a limit to how many bitmaps I can create or something? I destroy the old ones, but maybe there's some resource that gets depleted.

“Throughout history, poverty is the normal condition of man. Advances which permit this norm to be exceeded — here and there, now and then — are the work of an extremely small minority, frequently despised, often condemned, and almost always opposed by all right-thinking people. Whenever this tiny minority is kept from creating, or (as sometimes happens) is driven out of a society, the people then slip back into abject poverty. This is known as "bad luck.”