Memory Use Guidelines

[NakedApe]

I'm wondering if there are any practical limits to how many sounds, fonts, images and arrays I can have open in a QB64 program before it starts to bog down. I'm working on a space game on a Mac, and the Activity Monitor tells me I'm using about 150 MB of memory, and with the program running I'm using from 36% to 98% of the CPU. It runs fine right now, just wondering if I need to be very careful with the resources. Thanks.

[mnrvovrfc]

Allocate only the fonts, images and sounds that you need. Do not do it in a loop.

For example, do not switch fonts only by calling _LOADFONT. It's a huge shocking waste. It's only necessary to use _LOADFONT once to get a handle and save it to a LONG variable, then use _FONT to switch to that font.

Try to keep images small and sounds short. It doesn't matter what is the format of an audio file, the PCM data requires a lot of RAM. If the original was 22050Hz sampling rate or less, it is converted by QB64 to 44100Hz or maybe even 48kHz depending on the system QB64 is running in, which requires more memory. Load only one background image for a 4k screen because this rule about RAM might apply also to images. 32-bit images generally require more memory than those with 16 or 256 colors.

Always check the return values of _LOADFONT, _LOADIMAGE and _SNDOPEN. If not, it could cause memory leaks. It could be helpful to use _FILEEXISTS before one of those other functions to make sure a resource is found on disk. If not your program could crash unexpectedly to a runtime error box. QB64 could be a bit unpredictable about this. Sometimes it doesn't like a font. There's no choice but to use another one. Sometimes you have to give more parameters to _LOADIMAGE so an image is loaded at all, or it's loaded at the highest quality possible.

[NakedApe]

Allocate only the fonts, images and sounds that you need. Do not do it in a loop.

For example, do not switch fonts only by calling _LOADFONT. It's a huge shocking waste. It's only necessary to use _LOADFONT once to get a handle and save it to a LONG variable, then use _FONT to switch to that font.

Try to keep images small and sounds short. It doesn't matter what is the format of an audio file, the PCM data requires a lot of RAM. If the original was 22050Hz sampling rate or less, it is converted by QB64 to 44100Hz or maybe even 48kHz depending on the system QB64 is running in, which requires more memory. Load only one background image for a 4k screen because this rule about RAM might apply also to images. 32-bit images generally require more memory than those with 16 or 256 colors.

Always check the return values of _LOADFONT, _LOADIMAGE and _SNDOPEN. If not, it could cause memory leaks. It could be helpful to use _FILEEXISTS before one of those other functions to make sure a resource is found on disk. If not your program could crash unexpectedly to a runtime error box. QB64 could be a bit unpredictable about this. Sometimes it doesn't like a font. There's no choice but to use another one. Sometimes you have to give more parameters to _LOADIMAGE so an image is loaded at all, or it's loaded at the highest quality possible.

Gotcha, thanks. And best practice to check return values would be, for example,  "IF beep1 > 0 then _SNDPLAY beep1"  every time a sound is played? Or can the checks be done once upon startup?  Or?

[OldMoses]

I would think that it would be sufficient to check that sounds, images and fonts load correctly at startup. Once they're there, they're there and can be used until they're freed. As for bogging down, I'm generally less concerned about memory usage than I am with CPU load. As long as your memory isn't steadily ticking up, or doing so at specific points in the program, you should be OK.

Using hardware images should help with CPU usage, if you have a lot of images that move around but don't change frequently. That helped me with my billiards program, where the balls moved about the table, but didn't roll.

Move as much of the math as possible outside of loops, and stick to integers and longs if you don't need the precision.

If you're drawing large and/or complex graphics that move beyond the display, you should use algorithms that skip such drawing when a feature is out of the display bounds. That was a big issue with my space flight simulator that took me months to figure out.

[SMcNeill]

As for max memory limits:  1.5GB or less on a 32-bit OS.  No more than 75% of whatever your PC has on a 64-bit OS.

[NakedApe]

Excellent. Thanks for the feedback, everybody.