Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Discussion / Running out of memory?

Author
Message
Hangar18
18
Years of Service
User Offline
Joined: 13th Mar 2007
Location:
Posted: 28th Jul 2008 02:50
Hi All, I've been working on a space sim that is now over 20,000 lines in length and have encountered the following problem. After a few hyper jumps from one system to another, (during which a lot of objects and images are first deleted and then reloaded) every so often a message of "image not found" will appear. This is definitely not because the image does not exist, but because (I think) the computer runs out of memory. However my pc is pretty near top of the range, and when I use the various System DSEM etc commands I get

Video Memory = a "4" followed by lots of numbers
System Memory = a "-1" followed by lots of numbers
Total Memory = a "5" followed by lots of numbers

Now at first I though the system memory being negative was the problem but when I run these commands on their own without my 20,000+ lines of code I still get a negative (which is bizarre - any ideas why?)

Furthermore, although running these commands alone without the 20K of code simply produces a slightly bigger number for each of the memory components (e.g. Video memory is a "5" followed by lots of numbers.

I have no idea why my pc is running out of memory (assuming this is of course the reason it cannot find the image) or how I should go about fixing it. Has anyone else encountered anything like this before?

One other point to mention is that I also load in about 30 sounds (most of which are only about 50K in size) so unless there is some sort of preloading issue with sound in DB then I dont get it.
Dark Dragon
17
Years of Service
User Offline
Joined: 22nd Jun 2007
Location: In the ring, Kickin\' *donkeybutt*.
Posted: 28th Jul 2008 02:54
I get that alot.

Actually i just re-run my program 3 million times and then it works?....Db Glitch.......
Sorry but i have no idea how to fix it...

Your signature has been erased by a mod - Please reduce it to 600x120 maximum size
Irojo
17
Years of Service
User Offline
Joined: 21st May 2008
Location: Eating toast.
Posted: 28th Jul 2008 05:55
I get that problem too. If reloading it doesn't work, turn your computer off, and on. If that doesn't work, then your code is the problem.

I urge you to watch the film "Who killed the electric car". Support electric cars! Did you know their used to be more electric cars then gassoline cars?
Hangar18
18
Years of Service
User Offline
Joined: 13th Mar 2007
Location:
Posted: 28th Jul 2008 07:15
Yes turning the computer off and on helps but its a nuiscence to have to do that everytime the problem occurs. I cant see how it can possibly be the code if it works sometimes but not at others. I do wonder if it has something to do with MP3s, as I know Vista has a major issue with some of them even with the DLL installed (not that I have vista - I have XP)
Latch
18
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 28th Jul 2008 11:10 Edited at: 28th Jul 2008 11:42
A couple of things to try:

Whenever you are done deleting images or objects (changing levels or scenes) try the command
FLUSH VIDEO MEMORY

You will have to reload all the textures that you want to use though.

Another thing that may help: Instead of deleting your objects, save different meshes to memblocks then save the memblocks as a series of files. Instead of deleting and reloading an object, load the memblock mesh and use the command
CHANGE MESH FROM MEMBLOCK. You, in essence, replace the specific limb (including limb 0) with new mesh info changing the shape of your object. You'll most likely have to retexture it. You could also store your textures in memblocks and use MAKE IMAGE FROM MEMBLOCK. If you have an object with limbs, you can change the mesh of each limb individually.

The other thing that I've discovered is, whenever I use GET IMAGE, I have to follow it with a sync or a wait 0. Sometimes I can get away with not doing it - but I can't find the consistancy to say when that should be the case.

If you are using any DLLs, I find that depending on the DLL, the speed of the function is faster than DBC can handle and I can get unpredictable results - including systems crashes. Again, if I place a sync or wait 0 after the DLL call, it gives DBC time to catch up to the function - or putting the DLL call inside of a DBC function seems to do the trick as well.

If you've used/are using the windows GDI to capture images or screen shots, you have to manage the DC's very carefully or you can use up your resources in the blink of an eye.

Always make sure you are using the correct size (and pointers if you are using them) of your memblocks. If you are off by a byte here or there, it can bleed into areas of memory you didn't intend and cause problems.

Undim arrays that are hanging around doing nothing.

Avoid recursion in functions.

Also try loading textures directly into video memory or using compression
Load image <name>,<img>,1 : rem load directly to video memory
load image <name>,<img>,2 : rem compressed texture

Unless you are very careful wih your management and cleanup of objects, images, bitmaps, memblocks, file nums, etc., avoid code like:


make object something, objectnum
load object something, objectnum

This can leave you with a bunch of objects as numbers you don't even know are around. But if you are careful with management and cleanup after such calls, you should be ok. I only use these types of calls when I'm creating a temporary something that I will soon be deleting. I think it's better to declare outright what value you are going to use for what if something is going to have permanence in your program.

I'd be curious to know if any of this helped...

Quote: "I do wonder if it has something to do with MP3s, as I know Vista has a major issue with some of them "


Maybe try using .ogg files and a DLL to play them.

Enjoy your day.
Hangar18
18
Years of Service
User Offline
Joined: 13th Mar 2007
Location:
Posted: 29th Jul 2008 09:36 Edited at: 29th Jul 2008 09:38
Thanks Latch I'm sure this will prove to be very helpful as it gives me plenty of avenues to explore to improve the situation. I have since discovered that my problem does appear to relate to a video memory problem. What seems to happen is that as I jump from one solar system to the next, although the planets and objects are deleted, the memory isnt completely freed up (for some reason but not related to objects not being deleted).

The problem I encounter also gets worse whenever combat takes place in my game which could be due to the following:
i) creation of plains (followed by texturing of laser blobs) during laser fire
ii) The texturing of plains already "glued" to a ship when I want that ship to burst into flames. The textures are preloaded at the very start of the game so there shouldnt be any additional memory drain here

Although the plains from i) are deleted once they hit an object or reach a certain (shortish) distance and the plains in ii) return to hidden status whent the flames are dowsed or the ship blows up, there is some sort of memory leak that i dont understand.

I do have big arrays the biggest of which is a 1300 x 26 array but I need it to be there 24/7. Didnt realise that arrays can really chew into memory to a significant extent.

The "flush video memory" command sounds most promising but unfortunately this will mean I'll need to reload a load of textures that I had preloaded at the beggining. Still if it does the job I'll be happy.

Anyway I'll check out your suggestions and let you know what works / doesnt which may also help others encountering this problem.

BTW: The game is now about 80% complete - let me know if you are interested in checking it out and I'll email you a download link.
Hangar18
18
Years of Service
User Offline
Joined: 13th Mar 2007
Location:
Posted: 30th Jul 2008 00:24 Edited at: 30th Jul 2008 03:38
Latch, you genius!

FLUSH VIDEO MEMORY does the trick and best of all it doesnt wipe out pre loaded textures. All it seems to do is wipe out all the junk that somehow gets accumulated into the video memory. The only very minor downside is that the screen freezes for half a sec when the command is issued but, if I use the following approach it will be unnoticeable 99.9% of the time.

If System Dsem available() < 20000000 then FLUSH VIDEO MEMORY

Rem 20,000,000 is somewhat arbitrary close enough to zero not do flush memory too often but far enough away that it minimises the the risk of a sudden memory overload causing a failure of some kind.

Furthermore every time the game moves away from the cockpit to a menu screen, flush video memory will be used, thereby minimising the number of times the above 'If' statement is used.

Thanks again Latch, you dont know how pleased I am with this solution. I was worried that if there was a solution at all it would most likely involve spending hours of recoding.

By the way, how did you know about this as the command isnt listed in DB's internal Help Index?
Latch
18
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 30th Jul 2008 05:33
Quote: "FLUSH VIDEO MEMORY does the trick and best of all it doesnt wipe out pre loaded textures"


I would test this out extensively just to be safe. You might have to include a backup test to see if a texture disappears - maybe writing it to a memblock and testing a specific pixel's color - if the color is ok, you don't have to reload it... I dunno.

Quote: "By the way, how did you know about this as the command isnt listed in DB's internal Help Index? "

I have the boxed version of DB that I picked up at a store years ago. Inside is a manual with a list of hidden commands.

Quote: "BTW: The game is now about 80% complete - let me know if you are interested in checking it out and I'll email you a download link."


I'll send you an email address.

Enjoy your day.
Hangar18
18
Years of Service
User Offline
Joined: 13th Mar 2007
Location:
Posted: 30th Jul 2008 06:17
I'm 99.9% sure the textures dont need to be reloaded because

i) When objects are hidden 'pre flush' and then shown 'post flush' their textures remain as they should and that applies to objects off the screen as well as in range.
ii) preloaded images are definitely not being reloaded post 'the flush' and yet are remaining in memory as they are being textured to plains without any problem.

However, the big fear is that what works on my home computer may not work on all computers. I say this because the Set object objnum, 1,0,1 command (i.e. make black rgb(0,0,0) pixels transparent) DOES NOT WORK on all PCs and I have no idea why. I've tried a number of different tests but nothing conclusive has been found.

Do you know if is there a place where the other "hidden" db commands are listed. I did a quick search on hidden db commands but no joy.

Let me know if you need my email address to be able to send me yours ?
Robert The Robot
18
Years of Service
User Offline
Joined: 8th Jan 2007
Location: Fireball XL5
Posted: 30th Jul 2008 15:56 Edited at: 30th Jul 2008 16:02
@Hangar18
Here's a complete list of the DBC Hidden Commands. I've copied them them from the DB Manual 1.13, which you can download for youself here. (Click the 'Next' button, then you'll see the manual download link).



Enjoy!

"I wish I was a spaceman, the fastest guy alive. I'd fly you round the universe, in Fireball XL5..."
TheComet
17
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 30th Jul 2008 23:43 Edited at: 30th Jul 2008 23:44
Quote: "I have the boxed version of DB that I picked up at a store years ago. Inside is a manual with a list of hidden commands."


Hang on, hang on!

You mean there are HIDDEN commands, nowhere to be found?! Why would Lee do something like that?

Suicide is away of telling God, You can’t fire me I quit !!!!!
Hangar18
18
Years of Service
User Offline
Joined: 13th Mar 2007
Location:
Posted: 31st Jul 2008 02:39
@Robert the Robot: many thanks!!!

@TheComet: Its baffling isnt it? Its like buying a car and not being told there's a secret compartment that can be used as extra storage space
Latch
18
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 31st Jul 2008 04:58
I doubt it's to be covert. One reason they may not be avaiable was because they may have been designed to test other things in DB out by the developers and they may not have been guarenteed to work as regular commands (perhaps resulting in memory leaks, file corruption, unchecked error handling, etc.) They may also be a precursor to functionality that would eventually be installed in later versions.

If you go through the examples with a fine toothed comb, you'll find a few others that aren't listed in the manual:

set static objects wireframe on
set static objects wireframe off

statistic(1) - gives back the number of polygons being rendered

! not operator A!B = 1 if A is not the same as B 0 otherwise
& binary AND A & B result is number with bits that are 1 in both A and B being 1 and 0 otherwise
5 & 3 = 1 0 1 & 0 1 1 = 0 0 1 = 1
| binary OR A | B if either bits in A or B are 1 the resulting bit position is 1
5 | 3 = 1 0 1 | 0 1 1 = 1 1 1 = 7

There are more around, but without proper documentation and understanding why they exist in the first place, one would use them at their own risk.

Enjoy your day.
TheComet
17
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 31st Jul 2008 19:32 Edited at: 31st Jul 2008 19:33
The commands mousemovez() and mousez() are also not listed.

Mousemovez() works the same as mousemovex() and mousemovey(), but it returns the movement of the scroll button.

Mousez() works the same as mousex() and mousey(), but it returns the position of the scroll button.

Suicide is away of telling God, You can’t fire me I quit !!!!!
Robert The Robot
18
Years of Service
User Offline
Joined: 8th Jan 2007
Location: Fireball XL5
Posted: 31st Jul 2008 21:02
Blimey, there are more hidden commands?????

I had no idea about Statistic, I thought that one was just for DBPRo and GDK!

"I wish I was a spaceman, the fastest guy alive. I'd fly you round the universe, in Fireball XL5..."
Benjamin
22
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 31st Jul 2008 21:04
Quote: "You might have to include a backup test to see if a texture disappears - maybe writing it to a memblock and testing a specific pixel's color - if the color is ok, you don't have to reload it... I dunno."

If the texture doesn't exist, you can't write it to a memblock anyway.

Hangar18
18
Years of Service
User Offline
Joined: 13th Mar 2007
Location:
Posted: 1st Aug 2008 01:48
@Benjamin, thanks but this is something I'm not fully getting. I dont use memblocks much but given they are chunks of memory wouldnt this also take up video memory space? Kind of like robbing Peter to pay Paul. This could be really important for my the next steps in my project so please let me know if I am missing something.

Cheers
Bluestar4
19
Years of Service
User Offline
Joined: 19th Dec 2005
Location: USA
Posted: 4th Aug 2008 12:02
Quote: "You mean there are HIDDEN commands, nowhere to be found?! Why would Lee do something like that?"


@the comet : they are in the dbc 1.13 manual whitch was released some time ago with the 1.13 upgrade. you can find complete manual for 1.13 here :
http://darkbasic.thegamecreators.com/?f=upgrade_language
just click the next button and you'll be right there !


@Hangar18 : using FLUSH VIDEO MEMORY appears in this case to be only a work-around that temporarily fixes the actual underlying bug in your program. I have had this problem before using other compilers and I offer this advice - 1st you need to track down the bug or your program will have frequent crashes when you least expect it (even when you think you have it fixed )
second, its not an easy bug to see because it sounds to me like its an accidental recursive error - perhaps one of the most hardest to track down because from all aspects of the programmer the program appears that it should run correctly , however there are a couple places to that you can look :
fistly , do you use goto anywhere in your program ?
secondly , does your program repeat any parts of code? if it does make absolutely sure that it breaks out of the loop completely before exectuing the same loop again.
Anywhere your program repeats certain parts of code or does loops should be carefully analyized to ensure that it cleanly breaks out of each loop - in this case , I'll bet that your actual bug starts right before you hyperspace. you can continue to use the FLUSH VIDEO MEMORY however, as I said above, the results between flushes will remain unpredictable until you take care of the actual bug that is causing this.

Quote: " I was worried that if there was a solution at all it would most likely involve spending hours of recoding."


it is possible that once the error is found that you may have to re-write a few lines so I hope you documented your code quite carefully.

As far as compiling goes , I dont think you need to worrry about how many lines you have or how big the size of your code is because the source code file to my last project (hero battles) is about 1/2 meg and takes a while to compile but it does work.

Lastly, I love space games , if you would kindly post a download link or email it to me I would be glad to test it out and give you a private unbiased opinion.

Hangar18
18
Years of Service
User Offline
Joined: 13th Mar 2007
Location:
Posted: 5th Aug 2008 02:39
@Bluestar4:

Thanks, I do use a Goto but only once, and its when the player dies which does circumvent the "return" of some gosubs. However I dont think this is the problem for 2 reasons:

i) Whilst playtesting I set the hull strength to somehting huge so that dying never happens.
ii) There is a memory leak from even this very simple code:

Do
text 0,0,"Video Mem: "+Str$(system dsem available())
Load object "Spaceship.x",1
Sync
Delete Object 1
Loop

Thanks for volunteering to check out the game - would love to hear your feedback (good or bad). I will email you a link once I set up another free 14 day trial with www.sendit.com .
Bluestar4
19
Years of Service
User Offline
Joined: 19th Dec 2005
Location: USA
Posted: 5th Aug 2008 10:32 Edited at: 5th Aug 2008 14:42
Quote: "However I dont think this is the problem "

thats whats so ellusive about this kind of bug - As the programmer you think it runs the way it should and that there should be nothing wrong and no memory leaks and everything is coded according to plan and from all aspects it should work flawlessly, but it doesn't. Now what your forgeting is , that every piece of code you circumvented is now completely forgotton, with that in mind you now have the task of rewriting everything that those routines cleaned up because they arn't there anymore to do the work for you - remember goto does not return - it jumps and forgets. but the resources the program used before the jump stays unless they are removed which ='s small to large memory leak. now suppose Im right and you find the leak but retain using the video flush commands in your program, can you immagine how much faster it will run after this is taken care of ?
now as for the leak in that little bit of code - there is a memory leak in dbc strings that was never fixed, however, it wouldn't account for such a large amount that it would crash a program.
suggestion : this is a little advanced , but I suggest that you load all your image files in a global fashion - as in before any subs, or gotos, or function calls, since they are by default global anyway. my other suggestion is that you experment with using meshes as its Far faster to load a single mesh and the needed texture files than 1000 or two .x's . For example , you have 1000 ships and 2000 asteroids in a sector. most users would normally load each object seperatly for a total of 3000 calls to the load object command. however using meshes, both the asteroids, and the ships use the same model so you would actually only need 2 instances in place of 3000. you would simply load the meshes and their normal texture files and then use the make object command in a loop. This ofcourse in turn means that although you have 3000 objects you would only be using 2 image files for all of them in place of 3000 seperate texture files giving you a heck of a lot more memory
Another area you should be aware of is that disk access is by nature slow - so by using this method everything loads into memory and this cuts load times by a large noticable amount : what took 3 minutes before would now only take about 22 seconds.
as for your files - I recomend hotlinkfiles.com
currently you are allowed not only an enourmous amount of space (max file size is around 50meg I believe) but a gorgeous amount of bandwidth (large large large ! ) and its metered by the month

---edit ---
hotlinkfiles.com has been down for a couple days. They are apparently having severe server problems right now but Perhaps when the site comes back up you can check it out , until then though all you will get is a blank page that says "too many connections"

Hangar18
18
Years of Service
User Offline
Joined: 13th Mar 2007
Location:
Posted: 6th Aug 2008 00:33
Thanks Bluestar, really appreciate your assistance. I'll check out using meshes (which I'm not very familiar with- only use them when creating limbs for ghosted plains). Just so I understand correctly what your recommending is loading all .x objects at the start and then store them as meshes so that when a new object is requried is already prestored as a mesh?

I didnt know about the text leak problem but I dont think this causes my memory leak because i) in the game text is printed to the screen every second loop but the drop in video memory is very small as you say. However when I run the 5 or so lines of above code I lose about 1Meg of video memory every second!

Thanks for the hotlinkfiles option, although the max size of 50M is a problem as the game is 215M when zipped (maybe I could partition it into chunks of 50). However I've sent up another free account with www.yousendit.com (max file is 2Gig - well for 14 days at least). Will send you a download link.

Thanks again for your help and offer to review the game. By the way please note that I forgot to remove the "debugging" framework which means the ship you have is about 3 times faster than normal, has a hyperdrive capacity 10x normal and has a hull strength 100x normal!! But at least you will be able to see what the game is about without dying very often. You also have 80% of all equipment!
Hangar18
18
Years of Service
User Offline
Joined: 13th Mar 2007
Location:
Posted: 8th Aug 2008 02:13
@Bluestar4: Hi, I tried to send you a D/L link but am concerned you might not have received it. Can you let me know?

Cheers
design in mind
16
Years of Service
User Offline
Joined: 8th Aug 2008
Location:
Posted: 9th Aug 2008 01:52
I suggest an open beta, for more feedback.
Bluestar4
19
Years of Service
User Offline
Joined: 19th Dec 2005
Location: USA
Posted: 9th Aug 2008 18:03
I never got the download link - send it to [email protected]

Quote: "Just so I understand correctly what your recommending is loading all .x objects at the start and then store them as meshes so that when a new object is requried is already prestored as a mesh? "

allow me me to explain a little further on this. If you have a bunch of objects that basically use the same .x file such as an asteroid and you want 1000 asteroids here is what you do :

first , you need to load the .x file as a mesh using the
load mesh command
now you have your basic mesh , but any objects made with it will appear white without an image to texture it with so you next need to load the image file that it is to be textured with using the load image command

next you use the make object command for each object you wish to create. here is a basic example :

in the code you will note we have 1000 objects loaded, but only 1 image file is retained in memory. one your done using the mesh, you can either delete it, or save it for creating more objects on the fly - if you dont think you will need to create any more objects of that type for the rest of the game you can go ahead and delete the mesh.

had we done this :

we would have 1000 objects and 1000 images loaded into memory and the program would be constantly accessing the disk to load the files which would slow down load time.

Hangar18
18
Years of Service
User Offline
Joined: 13th Mar 2007
Location:
Posted: 13th Aug 2008 05:20
Hi bluestar/Latch, I've sent you both a link to download the game. Please let me know if you have any issues with it.

@Bluestar: Thanks for the info on mesh's. I definitely plan on experimenting with this as it will at least fix another problem (a 1 sec slow down when a new ship hyperjumps (and object load is required)) if not the main problem.
Bluestar4
19
Years of Service
User Offline
Joined: 19th Dec 2005
Location: USA
Posted: 13th Aug 2008 05:51
link recieved - I'll send you an email about the program after I have thourougly tested it.

There is more info on the meshes that you should be aware of -

when using meshes, it loads the .x file into a single mesh - what had 10 limbs now has none. so , meshes are good for things that dont require animation or movement of limbs other than typical rotation and movement. This command therefore would most especially be useful with ships that aren't blowing apart, and asteroids which seldom require anything more than rotations.

Next on the list of saving memory is static objects -
objects/meshes can be loaded into memory then made into static objects. Static objects cant be moved or rotated but after made you can delete the original object/mesh. You can use the make object static command to create objects that dont require movement or rotation of any kind but still need to be there . A good example of this would be trees or shacks.
You can additionally save even more memory and processing power by attatching objects to the static world when they aren't being animated by using the attatch to static command and then use detatch from static when your ready to use them.

Login to post a reply

Server time is: 2025-06-07 06:53:17
Your offset time is: 2025-06-07 06:53:17