Right now to do this I use:

al_toggle_display_flag(context,ALLEGRO_FULLSCREEN_WINDOW,fullscreen);

But the problem with this is I cannot set the fullscreen resolution. What do I do if the user wants to go fullscreen at 640x480 but the desktop is at 1280x800?

Thanks

I think you have to use the regular fullscreen mode if you want to control the resolution. Otherwise you'd effectively be changing the user's desktop resolution, which kind of defeats the purpose of the fullscreen windowed mode. And the user probably wouldn't be too happy about it either.

So basically I should decide this at application startup and when the user selected fullscreen I should tell them this will take effect the next time the application is started?

A related question - what happens to all your video bitmaps when you change from a windowed to a fullscreen resolution? Are they all compatible with the new display?

If you're using the fullscreen_window mode, you don't need to do a thing.

If you "switch between" windowed and fullscreen modes with the other drivers you have to recreate the displays, and all bitmaps have to be re-uploaded, but I THINK allegro will do that for you, at least 5.1 will. And 5.0 might? I can't remember the full details.

I can't remember completely, but I think I read somewhere that SFML only uses a single OpenGL / DX context, so I don't think it would suffer the same problem.

I don't know much about OpenGL or DX, but why does allegro need to recreate the 'context' for every display? Could there be a al_initialize_graphics() function that performed this task, and then every successive al_create_display call would use the same context, thus eliminating the need to re-upload textures?

Also, wouldn't that eliminate the problem of secondary threads not being able to correctly access video bitmaps?

I'm pretty sure the context tends to be tied to a given "window". Destroy the window, and there goes your context.

Doubt it. OpenGL context and state is per thread. You have to have one thread give up exclusive access on that context, and then have your other thread acquire the context, then do stuff with it. If the first thread wants access back, you have to do the same thing all over again, just in the reverse direction.

Can SFML switch between fullscreen/window mode without re-uploading textures? If yes then there must be a way.

For Allegro (under Windows, in Linux changing video modes doesn't touch the context anyway) what happens is the display gets destroyed and all bitmaps tied to it get converted to memory bitmaps (if it's the last display at least). Then when you create a new display in 5.0.x they stay memory bitmaps and you have to re-upload them. In current SVN with the default flags the bitmaps will automatically be re-uploaded and get assigned to the new display (I think). So at least in 5.2 you won't have to do anything.

Also in SVN is an example which has a background thread loading bitmaps.

Does switching from fullscreen to window work properly? When I try it, I get a window that is glued to the upper left of the screen, and doesn't have a title bar. Maybe I'm doing it wrong? And of course, I get 3 fps because I haven't reuploaded the textures. I'm using 5.0.5 on Windows 7.

I tried switching from fullscreen to window with ex_display_options, but that just crashes.

I really don't know, I would have to do some research to be sure. From the docs it seemed like it could though (or maybe it just automatically converts all it's bitmaps and just gives the illusion of compatibility).

Grr... Just can't seem to reach the goal of being able to simultaneously display and load resources into video bitmaps. But I guess it might not make sense to have more than one thread with access to the GPU at a time.

But it can only load them into memory bitmaps right? And then the main thread with the display has to convert them to video bitmaps? It would be nice if they could be loaded directly into video bitmaps instead.

</wishlist>

Yes, you need to do the conversion manually.

I think it's not possible, because as Thomas stated OpenGL context and state is per thread, and in my deep ignorance I think the reason it's per thread is because of the hardware acceleration, I think OpenGL wants just one thread accessing to the GPU memory directly.

You can make it work, I'm not sure how well or how smooth it would go, but you can do something like...

1. (thread1) Display loading screen
2. (thread1) give up context
3. (thread1) signal thread2 to acquire context (and sleep)
4. (thread2) acquire context
5. (thread2) load one bitmap
6. (thread2) give up context
7. (thread2) signal thread1 to acquire context (and sleep)
8. goto 1

But that is still serial processing and not parallel, so why bother having more than one thread in the first place?

while (!done) {
   Display();
   CheckInput();
   done = LoadNextResource();
}

I've been looking at SFML, and their RenderWindow has a Draw(Drawable& d) function. Their Image class doesn't have any way to specify memory or video bitmap use, so that must be automated somehow, and you can have more than one RenderWindow draw the same Drawable, so either there is some automatic conversion between contexts, or somehow it is shared. I'd have to dig through their source code to find out though, and I don't have time for that right now.

Well thread1 can be doing other stuff at the same time. logic and what not. it doesn't have to sleep the whole time.

I think you can have shared contexts in some cases, but I don't think they work everywhere (on all platforms).

append: or rather, you can have two GL contexts that can share data. But I'm not sure how well it works, and if its all that fast? and again it probably isn't supported in all places.