Are images kept when you EndGraphics and reopen?
BlitzMax Forums/BlitzMax Beginners Area/Are images kept when you EndGraphics and reopen?
| ||
| Quick question about the graphics context keeping images in video ram between close and open ..... does it work now? If I do EndGraphics or CloseGraphics and then do GLGraphics or Graphics afterwards, are the Images I was using still in video ram and useable by OpenGL or do I have to reupload them all? Wasn't there some bug with this? Was it fixed? What is the correct method to shut a screen down and reopen it (perhaps switching to a window and back) without losing the loaded images? |
| ||
| All graphics are derived from a built in Blitz base class called Object, so I would imagine it would have it's own de-constructor which is initialised on termination, so everything derived from Object would also be de-constructed when EndGraphics is called. That's my guess anyways. |
| ||
| In my game to switch from window/full and back again, I make a call to EndGraphics() and then create the new screen using Graphics(). I do not have to load media again. However, I'm using Dx and do not go back and forth between dx/opengl, etc, etc. I would guess as long as you're not switching graphics drivers you don't have to reload your media. |
| ||
| Thanks. Anyone else have a difinitive tested answer? It sounds from what you said MGE that the graphics are kept in memory. I suppose this is one of those things I'll just have to test myself. I thought there was some issue with this not working properly a while ago, like some images would get corrupted or turn into white squares? |
| ||
| Blobulos has the option for changing the graphics driver (and resolution), neither require reloading any media. |
| ||
| Bullet Candy doesn't reload images after a graphics mode change and it doesn't seem to have any adverse affect. Cheers Charlie |
| ||
| To enable and disable the full screen and windows mode, you can reinitialize the Graphic mode and in respective way 0-> Windows Mode 16, 24, 32 -> FullScreen, and other the representation of sprites or others goes normal. |
| ||
| Ahh good, so it sounds like everything is working correctly now. That's nice to know. I thought maybe it was based on the graphics `context` object, like when getting the canvasgraphics object in maxgui? ie if you free the context, would it not lose everything? |
| ||
| they stay in main memory in case the display context is lost. you do not have to reload any of images but when the display context is lost they will need to be pushed back to vram. now this is usually not a concern especially in blitz because it's automatic. if you have a lot of media that you need on the card you may want to pre-stage it (again). there have been topics on this site that discussed doing this at start up. it would be the same for these switches. |
| ||
| Okay so at what point and under what conditions do the graphics gets flushed from video ram? If a person is writing custom GL code they need to know when to upload textures to video ram, and whether they will stay there between screen changes. What you wrote suggests they are no longer in video ram after a screen close? |
| ||
| ok, I guess I'm just speaking from Direct experience but I would assume that opengl has to be the same... the graphics will get flushed by either a loss of it's display or even by some other graphics, possibly another app pushing it out. you would get a draw failure when this would happen or even a message... now again, this is DX and just dx7 maybe 8 at that. I haven't done anything beside Blitz since 01 so this might all be different now so forget what I said ;) |
| ||
| I suppose we could test this by loading your media then ending the graphics for a good while before opening it again (with different resolution/driver/fullscreen-windowed). |
| ||
| Regarding DX mode. (I don't use OGL) I've tested this 100's of times in my game framework. You only lose device in full screen mode when someone presses the windows button or another program pops up. But... the graphics are stored in system ram, so only the device is lost, and recovered automagically via bmax code. The textures do not need to be loaded again, but the gpu does copy from system ram back into vram when the device is restored. This is via the "managed" flag set by the internal code that loads textures. I think older versions of the code loaded directly into vram only, causing the need to re-load when a device was lost. |
| ||
| Interesting. Plash - I don't think I'd feel comfortable with ever assuming that the graphics will be around `on the offchance` that they didn't get flushed out by some other application. Waiting a given period of time shouldn't even be considered, either we need to know that the graphics definitely are `officially` there and we're pointing to them and controlling them still, or they have been released and we can't trust that they'll still be there. MGE - The gpu does not copy texture data from main memory to video memory, it doesn't have access to main memory at all, it's the CPU which copies from main memory into video memory so that the gpu can see it. This is perhaps part of how Max2D is set up to work - it keeps the image as a pixmap in main memory even after it's been uploaded to video ram, so that if the time comes to need to re-upload it it's already in main memory and doesn't have to be loaded from disk. But even if it's doing that, that doesn't mean the video-ram texture is being kept inbetween screen changes. That's mainly what I'm asking, do I need to re-transfer images to video memory after reopening a screen. I think I will just do a little test, opening a screen, loading a pixmap, uploading it to an OpenGL texture (bypassing Max2D), rendering it, closing the screen, reopening the screen and then see what happens when i try to render the texture. But then... that may not prove it if the graphics are just hanging around in video ram due to another app not flushing them out. I'd like to know from Blitz's perspective whether it lets go of opengl state when the screen is closed. |
| ||
| oops.....I should have said the D3D Driver loads the data back into vram as needed. This is why you can load all of your textures at the start of the game and have the D3D driver swap from sram to vram as needed. One of the nice things of "managed" texture usage. The only drawback is if you don't pre-cache what you need at the start of a level, etc,etc, you will see some stuttering as the game pulls from sram into vram. |
| ||
I have done some test in my machine, where I load the images before I set the graphics mode/driver and it works fine with DX and OGL. My conclusion is that all data is kept in RAM and fed to the GPU as needed but, it might not be the same on all computers.
s:timage = LoadImage("spif.png")
SetGraphicsDriver GLMax2DDriver()
Graphics 800,600
DrawImage s,100,100
Flip()
WaitKey()
|
| ||
| bit late in replying but my framework switches from full to windowed and DX to GL and the gfx are never lost. They are kept in RAM and will be re-uploaded to VRAM automatically by Blitz, even after and Alt+Tab or whatever (this used to crash but was fixed a while back) |
| ||
| yep, that's what I said. ;) |
| ||
| well I'm happy to add weight to that then ;-) |
| ||
| Interesting! Because technically when loading a texture via DX7 they are stored in system memory and then pooled into the vram when needed. This is the "managed texture" flag being set when the texture is created. If we can create TImages regardless of graphics driver being used, then Blitzmax must be storing the (TImage) data in a format that can be used or copied to internally created DX or OpenGL surfaces. Which leads me to think there must be 2 copies of every texture in memory then? One for Blitzmax (pixmaps?) , one for managed DX (textures). ? ? ? |
| ||
| Yah it refers to them as frames, where it stores the pixmap and occasionally uploads it as a texture. That's also how it deals with locking the image, I am guessing - ie it doesn't re-download the texture into a pixmap, it just uses the pixmap that it has stored, lets it be edited, and reuploads it as a texture when you unlock the image. Anyway, thanks for all your input guys. However we've veered slightly off track from what I wanted to know. I don't need to know how BlitzMax handles textures via Max2D. I know already that it keeps them in pixmaps and reuploads them as textures *at some point*. My question is, if you are not using Max2D and are writing your own OpenGL code to upload textures, at what point is it necessary to re-upload from main memory to video ram? You can't say that Blitz handles it for you because I'm not talking about using Max2D. Let's say you skip Max2D altogether, you load image data into a memory bank, then you create a texture handle in OpenGL, then you upload the memory bank to the texture with something glTexImage2D(). The data is copied from the memory bank to a video ram `texure` within the OpenGL system. The question now arises - if I close the screen, close the graphics object, switch to a windowed display, or close the windowed display, am I going to need to re-upload from the memory bank to the texture? Does it lose any data? Does it lose only the texture data? Does all OpenGL state get lost when you close the screen/window? |
   |