loading textures at Booting time vs runtime

:information_source: Attention Topic was automatically imported from the old Question2Answer platform.
:bust_in_silhouette: Asked By strive_and_conjure

My game will have about 70 different enemies
there are a lot of textures for animations. So far I’ve been loading the animations by hand in the SpriteFrames node, and categorizing all enemies by an identification string
For example: one enemy has the ID “vodok”
its animations will be vodokrun, vodokshoot, vodokidle
and basically my AnimatedSprite node has about 6 animations for every enemy

My question is: what is better,
(i) preloading animations as I am right now, or
(ii) loading animation frames at runtime

In each level, there are 100-150 enemies spawning
5-6 kinds of enemies are accessed per level
Animations are 2-20 frames in length
Mipmapping is turned on, filter is turned off
Frames are 40-100 pixels in size

in (i), because each enemy instance has to carry a useless set of animations in its SpriteFrames, (ii) could be better than what comes off
(ii) might increase my loading time during a level by a few seconds
(i) is tedious to program, (ii) is much easier and doable, as I categorise my spriteframes in the same manner for all enemies in files

This question cannot be answered without knowing the texture sizes and import settings.It depends on many factors. You should give more detailed information. for example, texture size and mipmap settings are more important than frame count.

razah | 2020-08-20 06:52

Okay, I have edited the question.

strive_and_conjure | 2020-08-20 07:47

:bust_in_silhouette: Reply From: sharpmisr

you answer or question

:bust_in_silhouette: Reply From: razah

My advice is to preload all the nodes to be used at runtime. Otherwise, it may hang depending on the hardware while loading into memory.

(120 enemies average * 6 types of animations * an average of 8 frames pre anim * 60x60 pixel size of enemies * some overhead for each animation in the sprite frames) at the start of every level will be added

Will that hang a computer? The problem is quite serious then

strive_and_conjure | 2020-08-23 10:20

use debugger of godot for optimization. You should also consider the computer of the people playing the game.

Yes will hang probably. preload or you have to do object pooling. then enable and disable nodes.

razah | 2020-08-23 20:18

Okay, I’ll look into it. Thank you

strive_and_conjure | 2020-08-28 04:21

:bust_in_silhouette: Reply From: deaton64

I had a similar issue, as I am dynamically loading waves of aliens and the nodes loaded are decided at run time, so I couldn’t preload them.
Loading them at run time caused my game to stutter a bit, so I had to use the background loader that’s documented here

It works really well for me, I can’t tell when something is loading. I don’t use threads to load either.

I can live with the stutter I get atm (about 1 second of frame drop), and it shouldn’t worsen based on my calculations. Now that you mention it, I wonder how it would translate to other computers. I have a 12 gb RAM, and Intel(R) HD Graphics 520 graphics card.
My main concern here is, what if the game runs choppily for a lesser pc, even AFTER the loading screen were over? A sheer drop in frames would be unacceptable right.

strive_and_conjure | 2020-08-23 10:24

Depends what you mean by a lesser PC. Some would argue that your integrated graphics chip isn’t great. It all depends what you need to do with it.
I’m developing on a i5-2500 3.30GHz with a Radeon HD 6450 graphics card and 16GB of RAM. I’m only interest is coding for mobile, so a low spec PC does me. I’ve had 100s of sprites running on screen though and it all seems OK.
I play games on consoles, but even playing Call of Duty in 4K on an Xbox One X, multiplayer Piccadilly map stutters sometimes.

Maybe give the background loader a try and preload as much as you can.

deaton64 | 2020-08-23 15:55

Okay, thanks. I’ll convert to preloading and work it out.

strive_and_conjure | 2020-08-28 04:22