Graphics3d and ClearWorld effect on memory
Blitz3D Forums/Blitz3D Programming/Graphics3d and ClearWorld effect on memory
| ||
| There may be a discussion on this but I can't find it... 1. Does the Graphics3d() command run a ClearWorld() as well? The experimental code below creates 100,000 cones and then runs a second Graphics3d() and/or ClearWorld(). It pauses at each step so you can observe the effects in task manager. Both Graphics3d() and ClearWorld() have the same effect; they drop memory consumption from about 415 MB to about 113 MB. Shouldn't it go down to the original 9 MB? 2. Do you get the same result? 3. Why is 113 MB not released, and 4. Is that going to happen with each successive Graphics3d? The practical impact of this is that most games give the user the ability to change graphics modes either on-the-fly (in-game menu) or after navigating back to the main menu. Either way, Blitz3d would leak about 1/4 of entity memory after each change if it's consistent with this test. That's pretty horrible. 5. Does that mean we shouldn't allow the user to reset the graphics without restarting the game? 6. Is there a way to restart the game itself from within the game? None of this is mentioned in the documentation of either the Graphics3d() or ClearWorld() command. The Graphics() command is slightly more informative in that it does mention that images loaded will be deleted and handles will not work, but I don't see any mention that myFont=LoadFont("arial", 40) will also have to be redone after the Graphics3d() command, although that seems to be the case. What about sounds? So... 3. Is there an official or unofficial list of what has to be redone after Graphics3d() is re-run? Images, textures, fonts (loading as well as setting); and of course all entities (even cameras and pivots?) Thanks! Last edited 2011 Last edited 2011 |
| ||
| As far as I see after a Clearworld() you have to reload any 3D graphics, but not sound. If I remember correctly you even don't have to reload 3D sounds, although this would be rather inconsistent, since they are part of the 3D entity system. After a EndGraphics (or a Graphics) there should also all 2D and fonts be lost. In my tests I was able to have stabile, nonleaking amounts of Vram and Ram. I was only using Clerworld(). There may however be Ram fragmentation if you are not releasing huge chunks frequently. I didn't see many (actually none) Blitz3D games that were allowing to change the screen resolution at runtime (besides maybe in that scalable mode). If your game has savegame then it may be possible, otherwise you better outsource to Screen Settings IMHO, adding a Settings Link to the programs menu, so people know from beginning on where to alter the settings. |
| ||
| Thanks for the reply. Regarding the lack of B3D games that allow the user to change graphics settings in-game; that's exactly my point. This issue is presumably the reason why. Still, if I'm the only one experiencing the memory loss issue it may not be a problem, as long as I exercise discipline in saving everything in some way before resetting graphics. The project I'm working on is actually a generic menu engine for B3D, with default menuis for graphics (resolution, depth and window mode), sound (music and game sounds), controls (joystick, mouse, keyboard and steering wheel, with mappings screens for each of these), Play button, Quit Game button and Back button. Of course they can configure it to remove the elements they don't need and add new ones. I suspect programmers assume that the menu system will a be piece of cake after all the time spent creating their game itself; then they find out how problematic (and uninteresting) it is it's just too easy to put it off and work on the next game. Thus, they never ship. I'm trying to make a basic menu that covers the likely requirements of most games that they can pretty much load as an include file and call a function. Pure native B3D. I've got the graphics settings down; now I've got to ravage the code archives for the best mapping solutions/ideas (giving credit where due of course). Once I have that piece in place I'll post to the showcase... Thanks again jfk -Pete |
| ||
| I was able to achieve real-time exchange of graphics modes, using endGraphics (), the only thing I noticed is that the larger the memory used graphical increased, then returned to the previous mode and the number offspring. I do this to achieve a touch to the project better be looking for a txt file where the user changes the graphics modes. |
   |