|
|
|
This thread is locked; no one can reply to it.
|
| switching between windowed and full screen. |
|
William Labbett
Member #4,486
March 2004
 |
Hi again, as far as I can see, if we want to switch between a windowed mode and into a full screen (by which I don't mean fullscreen windowed), and back, a new display has to be created.
|
|
Trent Gamblin
Member #261
April 2000
 |
Yes.
|
|
Kris Asick
Member #1,424
July 2001
|
*nods* Fortunately, loading and sending textures to a graphics card is lightning fast, even if you've got a ton of them, and on an OS like Windows they'll all be buffered anyways from recent access. This is why I group all of my graphics loading and unloading into their own routines which I can call whenever I need to. For specialized graphics that you only need loaded for certain sections of code, or if you're using a dynamic loading/unloading system, you'll need to track what's already loaded and reload them if you switch the display mode. --- Kris Asick (Gemini) |
|
William Labbett
Member #4,486
March 2004
|
Okay, thanks for those answers. So when a bitmap gets loaded in video memory on the graphics card on windows and then freed, then loaded again how does windows know that it's already got the image in cache ?
|
|
Thomas Fjellstrom
Member #476
June 2000
 |
Windows 7 uses free memory to store a cache of files on disk. Much like linux has done for years and years. Instead of hitting the disk, it will hand you files from the cache if they are there. -- |
|
Arthur Kalliokoski
Second in Command
February 2005
 |
I don't know how Direct X does it, but when I was using raw OpenGL, I'd load the pixels for an image into system memory using fstream functions, then tell OpenGL to upload it as a texture. If I didn't free() this image in system memory, I could have uploaded it as many times as I wanted. They all watch too much MSNBC... they get ideas. |
|
David Couzelis
Member #10,079
August 2008
 |
I'm a little confused by this question... I'm working on a 2D game. For the PNG images I use, I created a library that will load them only when requested, will only create a bitmap once for all objects to share (to prevent loading multiple copies of the same bitmap into RAM), and will prevent needing to constantly open and close a file on the drive (slow). What do you mean by "we have to reload all the graphics"? Do bitmaps need to be reloaded from PNG image files when switching to fullscreen? Is my library still necessary? Thank you. |
|
William Labbett
Member #4,486
March 2004
|
Not if you only change resolution but keep in windowed mode. Sounds like, if you change to full screen mode you have to reload the bitmaps already in VRAM.
|
|
Luiji99
Member #12,254
September 2010
|
Is this necessary in general for hardware-accelerated graphics or is it specific to Allegro 5? Programming should be fun. That's why I hate Java. |
|
Thomas Fjellstrom
Member #476
June 2000
|
I should clarify that point a little. You don't have to reload from disk, you just have to reupload the bitmap data to the gpu. That is, all of the textures need to be re-created. With Allegro 5.0 I believe you have to take all of your existing normal (non-memory) bitmaps and call new_bitmap = al_clone_bitmap(old_bitmap); on each one. With Allegro 5.1 I believe you can use al_convert_bitmap(bitmap); or possibly (I'm not sure on this) al_convert_bitmaps(); which should take all bitmaps that were lost (assuming you didn't turn on the ALLEGRO_NO_PRESERVE_TEXTURE flag) and reupload them to the gpu. This is assuming that the current bitmap flags have ALLEGRO_VIDEO_BITMAP set, which is the default (you actually have to set ALLEGRO_MEMORY_BITMAP to turn ALLEGRO_VIDEO_BITMAP off iirc). DX is fun in that, if your window is hidden for some reason, it will loose the contents of video memory, so you have to re-upload. Android is a bit worse in that if android sees fit, it will decide to destroy the EGL context, thus losing all video memory contents as well as the entire EGL and GLES state. Allegro has to bend over backwards to hide that from the user as much as possible. As for the case of manually destroying and re-creating a display, I belive allegro will convert bitmaps to memory bitmaps. Once you have a new display, you can do the clone or convert trick mentioned above. -- |
|
Luiji99
Member #12,254
September 2010
|
In most (all) of my engine designs I can handle having to redraw the screen when the state is destroyed. Would there be any speed benefit to disabling Allegro's magic on that part and handling it at the game level? Programming should be fun. That's why I hate Java. |
|
Thomas Fjellstrom
Member #476
June 2000
|
It's not just about the screen needing redrawn, you also need to get your bitmaps re-uploaded to the gpu. Which which is what happens when you either re-al_load_bitmap, or use al_clone_bitmap or al_convert_bitmap[s]. But there can be a speed advantage to disabling Allegro's magic ability to preserve your bitmaps automagically. Note though that the automagicall bitmap preservation only happens with D3D and GLES (android for sure, not sure about iOS) so far as far as I know. Regular OpenGL makes sure your textures aren't lost. -- |
|
|
