On Mon, Jun 6, 2011 at 5:50 PM, Matthew Leverton
<meffer@xxxxxxxxxx> wrote:
I haven't looked at this yet, but how does it handle this case:
1) create display
2) create video bitmap
3) destroy display
video bitmap now a memory bitmap
4) create display
Do you still have to call al_convert_all_video_bitmaps() to upload
that video bitmap?
Yes and no, see your second scenario below. However, curiously enough, if you first create the new display and then destroy the old one, it seems the bitmaps are (sometimes?) transferred already and stay display bitmaps. Just some undocumented behavior someone must have added a long time ago. In light of that it might make sense to now auto-convert them in your scenario.
The obvious use-case is if the game has a settings screen and settings are changed in a way which requires a new display. Then it would of course be nice if when you just delete/create the display Allegro could automatically store and restore bitmaps as needed. (Not in a big game which has to do additional on-demand texture management, but in a typical Allegro game it should work.)
Also, what is the end result when doing this?
1) create video bitmap
video bitmap now a memory bitmap
2) create display
3) convert all video bitmaps
memory bitmap now a video bitmap
4) destroy display
video bitmap now a memory bitmap
5) create display
Good question. I did not (at least intentionally) touch the existing automatic conversion to memory bitmaps. A quick glance at the (X11) code tells me they are converted to actual memory bitmaps so al_convert_all_video_bitmaps has no more effect on them.
Is that what we want? Now that we have those new memory-but-really-video bitmaps could convert to that instead of actual memory bitmaps instead.
Also the Windows code was already doing lots of memory<->video bitmap conversions for some reason unbeknown to me. If someone could shed some light on that would be nice - but as long as the Windows port still works (seems to still work in Wine here) doesn't matter too much.