Something that I realized way later than I should.
During some of my Godot development, I’ve finally hit the debugger tab of the editor while the game was running, saw the “Video RAM” and found something very odd. My 2D game was eating up over 500MB of VRAM, which was way too much for what was on screen. Since the debugger lists all the files currently in memory, I could see how much RAM each file consumed.
My characters were made of several separate files (2 arms, 1 leg, 1 torso, 1 head) and all those files had the same total resolution of ~1000x1000, but different “useful” areas, like 200x200 on the head, 40x100 on each arm. Turns out each goddamn pixel of each file had to be kept in RAM, because, unlike disk space, the game “needs” to be aware of the WHOLE image, because it doesn’t know whether RGBA(0,0,0,0) at XY 0,0 is any more or less important than whatever is at XY 120,250.
Yeah, after I cropped the images to only have the area they actually have drawn, VRAM usage dropped to ~200MB (the drawn area was still large)
If anyone ever complains that your game is slow, or that you should optimize how you organize your images, it’s very likely you should look into that for better performance.
In a game that is production ready you would be going through individual assets with the person who designed them and you’d establish when to spawn and despawn them. As designers tend to go crazy and not worry about memory at all, I tend to guide them to think about memory availability in a particular scene. Really depends on the game you’re making though
I think Godot handles the despawn decently, my problem is that many graphical nodes are loaded but kept invisible/hidden until needed, things I’ll keep in mind whenever I go for another project.
Other than that, a lot was due to my shoddy practice of leaving single pieces as a 1000x1000 images, instead of a ~40x100 like the arm, the RAM savings are significant
