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.
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