program too big to fit in memory
BlitzMax Forums/BlitzMax Programming/program too big to fit in memory
| ||
| Hi I got an error message: program too big to fit in memory after compiling and running about 10 times with debug mode. blitzmax compiled it ok but when I clicked on the build and run it came up with this message. The whole program compiled with all the graphics and music included is only 26MB. Do you have to destroy objects say after the game ends or the program exits? I was under the impression that if a object for a sprite isnt linked to a pointer that it gets deleted. I have been building and running the program in debug mode and hitting the stop icon to go back and edit out any bugs. Any help would be apprieciated Dibble |
| ||
| Are you by any chance trying to allocate any enormous multi-dimensional arrays? It's really easy to underestimate how large some of them can get, and by default Windows will only let a 32-bit program allocate a total of 2GB RAM, max. If you can run the program sometimes, then switch to the windows task manager when it's running, look at the process list, and see how much RAM your application is using. |
| ||
| lol, this happened to me just the other day! I was using the LeadWerks evaluation package and it just hit me like that! :D Dibble, Are you using LeadWerks? I find this error to be triggered by something not being typed correctly in your code. As sphere=CreateSphere() should be Global sphere:TMesh=CreateSphere() Hope that helps! :) Last edited 2012 |
| ||
| An explanation of the Captain's last example: When you assign an object to an integer variable, an "integer handle" is created for that object and placed in the variable, rather than the raw pointer. Since the garbage collector can no longer track it, a reference is kept in an internal, inaccessible list that links handles to objects. Once this handle has been assigned, it needs to be removed from the internal list manually, with the Release command. As long as the object is on this list, it's locked out from garbage collection. Mistakes like this are one of many reasons why it's strongly recommended that you always use SuperStrict mode: then there's no way to have this happen by accident (you have to declare all variables and explicitly type tag them, so no implicit integer variables cropping up out of nowhere). If you have been coding in non-Strict mode (or even regular Strict, which doesn't demand type tags), it's possible something like this could creep in without you noticing. Last edited 2012 |
| ||
| Ah yes thanks Yasha Ive now put superstrict instead of Strict and I have found all of my globals do not have a type identifier if they are an integer. If they are of type string, float, double this is declared. good job that I put all my globals in one include file. which is 5 pages long. I do use lists to hold all my objects and dont delete them after the game or program exits. The lists are cleared when the game starts with the init methods for each of the game objects. So bad programming on my part. Thanks for your help :) Dibble |
   |