Preload resources into cache memory

[Tiger]

High resolution (PNG, for example), 3D Models, and Voxels should be preloaded in to the cache memory rather than loading during in game. As it currently is, if you were to enter a huge open space sector that contains alot of unrendered textures and models, it can take more than two seconds before it is possible to play the game again. However, having the ability to preload all of the contents inside the map will help eliminate having to be frozen in game while the engine renders the contents before being viewed. Furthermore, engines like EDuke32, and Risen3D load all contents on each map before it is actively played. Thus, making the games run much more smoothly and faster. In conclusion, this feature will give the players the ability to play any PWAD on GZDoom without having to be frozen in game while the textures, models, and voxels are being rendered.

[Salad Viking]

It's really not as bad as you describe it. I've never spent more than a second waiting for resources to load, and loading up every item at the start of each level would take up a lot of memory, especially in mods that use lots of resources (imagine waiting to load all of Deus Vult II's textures at the start of each level), which would be bad for players with limited system resources. Plus, users tend to get impatient and frustrated when programs are unresponsive, especially at startup. When I first opened the voxel demo map, I nearly ctrl+alt+deleted out of GZDoom because I thought the voxels had crashed it.

I say it's fine like it is.

[Xaser]

You do realize that, if added, this will be a toggleable option, right?

Though I haven't really played much of anything that would need such a lengthy preload time, I'd much rather have the loading to happen at map start rather than during gameplay when there might be a pissed-off demon in my face.

[Tiger]

and loading up every item at the start of each level would take up a lot of memory

Wouldn't it be the exact same of the data was being rendered on the fly?

especially in mods that use lots of resources (imagine waiting to load all of Deus Vult II's textures at the start of each level)

DVII does not really use much of resources from Doom2.wad, and thus not really affecting much from the HiRes pack that I mentioned in the topic. Although, some might be used, but not really enough that would cause a real huge impact. Moreover, 3D models are possible on that said PWAD, but it can still jitter the game play to a degree; HiRes textures along with the models are the best degree to notice the latency time like, for example, map29 on Doom2's stock maps.

which would be bad for players with limited system resources.

I don't believe so. Precaching if I understand correctly, can load into the system memory and later can direct into the VRAM (Video RAM), and from their it is rendered and displayed. However, I highly doubt a lot of users have <128MB RAM and <128MB VRAM with an OS that does not support file swapping. Eventhough I mention File Swapping as a means of additional RAM, it is only efficient if the application uses the free RAM registers and not the HDD. furthermore, even if users have a real low end and can still run GZDoom on GL just fine, then a CVar would be efficient for this. Furthermore, I also believe that GZDoom supports texture compression. So, no I don't believe that is really true.

Plus, users tend to get impatient and frustrated when programs are unresponsive, especially at startup.

I personally would rather wait for the game to load, rather than stalling on a DM game, or an intense coop game that I will be frozen will it loads the resources; furthermore, having to be hanged while in 'any' game that is active so the engine can render the data is also frustrating to users like myself. But again, a CVar can accommodate this.

[Salad Viking]

Alright, to each his own. I don't think it would take that much effort to put in game, so Graf might add it.

[Graf Zahl]

Caching the resources in RAM is more or less pointless. Since all WADs' contents need to be read on startup anyway to initialize the textures they'll be in the HD cache once the game starts.

The problems described here come from caching textures in texture memory - and that's a different matter. If I were to precache all textures on engine startup it'd add minutes of waiting if you were to use a hires texture pack. Keeping too many textures around may also degrade performance so many textures are pruned each time a level starts to keep the memory footprint of the graphics system low.

So no, I will not add such a feature.

[Tiger]

Caching the resources in RAM is more or less pointless. Since all WADs' contents need to be read on startup anyway to initialize the textures they'll be in the HD cache once the game starts.

Honestly, there has to be a better way for this to be handled. The load time latency on a basic and common SATA HDD can dramatically kill the performance on this engine with using HiRes textures and models.

If I were to precache all textures on engine startup it'd add minutes of waiting if you were to use a hires texture pack.

Why not during each map load? The only draw from this method, is the loss of performance if a texture was changed via ACS. Although, I would not have much problem if that occurs.

There has to be a feasible way for this to work out, and still give GZDoom a more refiner speed boost while using these resources. Like, for example: async i/o while the map is being played, the engine would load the HiRes Textures while the game is in play but in the mean time uses the standard bmp textures.

[Graf Zahl]

Honestly, there has to be a better way for this to be handled. The load time latency on a basic and common SATA HDD can dramatically kill the performance on this engine with using HiRes textures and models.

There's no way around it. And no, I have yet to see a mod where this takes more than a few seconds.

Why not during each map load? The only draw from this method, is the loss of performance if a texture was changed via ACS. Although, I would not have much problem if that occurs.

Precaching per level is already done. If not, check the related menu option.

[Gez]

It's only tenuously related, but would it be possible to cache converted voxel models like GL nodes are cached? The Doom voxel pack takes more than one minute to process now when starting a new game...

[Graf Zahl]

When I find time I first need to analyze the converter if something is wrong with it.
If that turns out negative yes, I intend to do it.

[Graf Zahl]

Can you retest the voxel demo? I changed the hash for the voxel vertex map and for me the version of the demo I had jumped from 10 seconds setup time to 1 second.

[Edward-san]

Whoah! I've tested voxel_test.wad, and indeed now it takes 1-2 seconds to load the map! Nice improvement!

[Tiger]

And no, I have yet to see a mod where this takes more than a few seconds.

I can easily point out PWAD's that can. But for the best result using the Doom2 stock maps, use 3D Models and HiRes Textures on map29, that lift soon becomes the new laggin'-lift! [Five seconds worse of latency, atleast]

Precaching per level is already done. If not, check the related menu option.

Code: Select all

GL_Precache

It does nothing for me at all. I see no difference if it is enabled or disabled. Is this only effective with BMP formatted textures?

[Enjay]

Is this only effective with BMP formatted textures?

Unlikely. I don't think BMPs are supported at all by the (G)Zdoom engine.

[Gez]

Can you retest the voxel demo? I changed the hash for the voxel vertex map and for me the version of the demo I had jumped from 10 seconds setup time to 1 second.

Wow, that made a huge difference. Definitely not merely ten times faster on my computer. Before D_RUNNIN had the time to loop, now the wait is less than a full second.