How to free memory associated with 3D Entities
Community Forums/General Help/How to free memory associated with 3D Entities
| ||
| How do I free memory associated with 3D entities prior to executing the End command? |
| ||
| If you're talking about Blitz3D then 'ClearWorld' will do it, or just delete the individual entities using 'FreeEntity'. The memory will get freed when the 'End' command is used also. |
| ||
| "Memory associated with"? ClearWorld will get rid of everything in the 3D scene; EndGraphics will get rid of any other graphics stuff as well. Beyond that... it's all manual. If you've got a third-party extension DLL, either it provides some relevant clear-everything method or it doesn't. However, when your program is ending is really the one time you don't normally need to pay much attention to this. At the very least, the OS will reclaim all the memory it used and close open file handles and so on (only the most pathetic excuses for student-project OSen - nothing in major use at the moment - will fail to do this). If you're still experiencing the crash-on-End problem... 1) Ensure it's End: use debug mode to print debug messages or insert Stops before everything that happens as the program ends, so you can be sure it reaches the End command 2) If you're using any DLLs, try dummying them out: just comment out your entire HUD if you're using FastImage, for instance. If the error goes away, take note of which one you removed in that stage 3) Create a new project, copy your code into the new project in chunks until it reproduces the error 4) If all else fails and you have a pure-B3D project that definitely crashes on the End command that can be reproduced by creating it anew... it's a B3D bug While you should eventually also check things like media if you can't find the problem before then, this would still point to a B3D bug as it should have no trouble unloading anything it was able to load in the first place. You;ve probably already thought of this stuff, but eh. |
| ||
| At the very least, the OS will reclaim all the memory it used and close open file handles and so on This is a very important point. No need to free client-allocated memory if you're going to terminate your application right after; leave it to the OS. |
| ||
| @Yasha & Zethrax - thank you for the suggestions, will run through that when I get home at the weekend. |
| ||
| @Yasha, thankyou for the suggestion - I inserted a few DebugLog commands (never used those before - not even sure how they work - didn't quite get that far) however, it NOW QUIT s WITHOUT ERRORING. Woo hoo! I can only presume the debuglog commands are letting whatever wasn't getting a chance to finish... finish. (:D Blitz 3D rocks ;)  That was, until I created an executable - oh well. I am trying a debug compile now and interestingly I am getting Array Index out of bounds, before it even starts to render - however within the executable it just 'coped' with it. So, turns out I'd one 3D and one 4D array, the first I incremented to 4d and seems to be okay. Been doing this so long can't recall how I hung it together anyways ;) Last edited 2012 |
| ||
| never used those before - not even sure how they work - didn't quite get that far If you run in Debug mode (naturally), the Debug Window that shows your code when you pause the program also has an "empty" tab. DebugLog simply prints text to this tab. It's mainly more useful than Print because, like a file, it persists without you having to redraw it every frame (and without affecting the appearance of your application), and you can dump huge amounts of formatted text (newlines work!), and you can select-all and copy to a text editor to store the data for later if it's important. the executable it just 'coped' with it. One of the reasons Debug mode is a) useful and b) slow: it includes bounds-checks on both arrays and banks. In Release mode, array and bank accesses are just unchecked memory offsets... and doing these into empty space is always unpredictable (it's entirely dependent on what the background memory management system has decided to do with that empty space - often, as you've found, it will be misleadingly "safe" because the space is still part of the main available block for the application). Blitz 3D rocks ;) Blitz3D's debugger was one of its awesome killer features back when it was new (everyone has them now...)! Along with excellent documentation, it's pretty much why I got into it. |
   |