ZDoom

I use RAM disks on all my systems for browser chache and temp files, and occasionally copy single large files or even whole games to them to speed things up.

My current main system has 64 GiB of RAM--sufficient for any Doom mod in existence. I also save many downloads to a RAM disk first before copying them anywhere, especially drivers/installers, so anything but the actual files to be installed would be written to RAM only.

Think NVidia's driver installer. That's one big file and thousands of smaller files that are only written once to your SSD instead of [b]at least[/b] four times (saving, unpacking to temp storage in C:\NVIDIA, installing, deleting... and if anything fails during installation, all but the saving process needs to be repeated, further increasing the wear of the SSD; with a RAM disk, only the installation itself needs to be repeated in a way that actually writes to the SSD). And those installation do fail for the dumbest of reasons.

- Anon

True that - but modern versions of Windows should have that loaded automatically (as a given). I think all versions of Windows since 4.0 (NT4/95) had that enabled automatically so we're well past that point. :)

Actually, your post reminded me: an essential part of doing the doom.wad copying thing was that you had to have SMARTDRV (old DOS disk caching program) loaded. So, that makes sense.

[quote=Enjay post_id=1258147 time=1738600342 user_id=16]
It was even suggested that simply copying your doom.wad before running the game would help cache it into memory. I suspect that was nonsense.
[/quote]

Far from nonsense, that actually does work. But for the humble doom2.wad nowadays (~14mb), the speed difference now is so negligeable with the advent of SSD's that it makes no real tangible difference. And even if you're still stuck with the old platter spindle hard disks, they also sped up so much before they were effectively replaced with SSD's that even then, the difference isn't that great for a file that small.

The reason why it might not seem that effective though, is there are some external factors that can affect how effective it is - i.e. if something else quickly replaces the cache (being RAM starved, for example).

This trick still works well for modestly larger mods (i.e. in the 300mb to 700mb range), and if you have a ton of ram in your system you probably can even chunk 2gb and 3gb files into the RAM cache this way too.

This isn't a myth - but again, it really depends on how quickly the cache gets replaced. If you run it for a long period of time and alt-tab out often and run other stuff in the background, it probably will be evicted from cache relatively quickly. But there's nothing stopping you from running a batch file in the background to do [c]copy /b c:\path\to\file.wad nul[/c] and then [c]sleep 600[/c] (if you have that command installed on your computer) between each copy, to ensure that it stays in ram effectively forever (or at least until you close that command prompt window).

That reminds me of one of the old tricks "back in the day".
People would copy their doom.wad to a RAM disk (anyone remember those?) to speed up loading times.

It was even suggested that simply copying your doom.wad before running the game would help cache it into memory. I suspect that was nonsense.

Might be a nice idea for people with lots of RAM so that GZDoom refers to disk less often? Why not get stuff like mods, wads, resources in RAM then? If so, there must be an option for people with lots of RAM. I've seen some sampler software that has options to choose be it streaming from disk and even a cache size then an option to load everything in RAM on load.

[quote=Kzer-Za post_id=1257904 time=1737751467 user_id=21006]

I am talking about general gameplay and graphical enhancement mods, and by "precaching everything" I, of course, mean "on a per map basis", not "precache everything there is". That is why an option to precache everything (meaning "everything on the map that is currently being loaded") would be an improvement over the current situation.

[/quote]

The engine already precaches everything it can deduce from the map. If it needs more that cannot be deduced it'd have to load EVERYTHING if there are no definitions that properly declare dependencies, (e.g when precaching an imp you also need its fireball.)

I would like to say why, in my opinion it is not such a bad idea as you think.

Of course, it does not mean that I'm trying to persuade you to implement it: it's a free project and nobody owes anyone anything. It just seems to me that we were talking about somewhat different things.

When talking about [quote]Having this as a feature would cause mod authors to go lazy and make the problem a lot worse than what it is now.[/quote] I suppose you are talking about mappers, who should put what needs to be precached into mapinfo on a per map basis.

I am talking about general gameplay and graphical enhancement mods, and by "precaching everything" I, of course, mean "on a per map basis", not "precache everything there is". That is why an option to precache everything (meaning "everything on the map that is currently being loaded") would be an improvement over the current situation.

Such mods need all their data available for [i]any[/i] map, so their choice is either a moment of freezing when this data is loaded during gameplay or make a giant list and [i]always[/i] precache [i]everything[/i]. This is more or less what Beautiful Doom does and this, if I understood you correctly is precisely what you don't want: it carries with it the list of everything there is, to precache it all. (I myself also am going to do it for the mod I am working on).

Since the engine reads the map when it's loading that map, it has the information about what textures and other assets are needed for that map. Well, actors could later be replaced dynamically, but generally the engine has most of the information about what the current map has, so it can, if such an option is implemented, precache what is needed for the map without loading the extra stuff, so the proposed option for the game to precache everything that is in the [i]current[/i] map would be an improvement over the current situation because it would make unnecessary for the general gameplay and graphical enhancement mods to carry with them a giant list of all their assets and always precache all of that.

Regarding the concern that [quote]it will just stash your textures and model data in CPU memory and then start swapping around at the most inopportune times[/quote], I can only testify that on my older machine I observed the opposite picture: if I played with a mod with big textures without precaching them, I observed freezes each time that I entered a new area; but if I made a list of all those textures to precache them all (since it was a general graphics enhancement mod, I needed all of them, since it was to be used with different maps), then I didn't see any freezes. Of course, the game took longer to start, but once started it never froze upon entering a new area.

Once again: I am not saying that anyone has to implement my wishes :) People can be interested in doing other things, I completely get it. I'm just saying, if it's dismissed, it should be because no one is interested in doing it, not because it's a bad idea.

Disappointing, but understandable. If it's outright impossible to do this even for just actors and sounds (the most common culprits), then this can be closed.

This won't work. It literally means "every single texture in all loaded files" and can cause such nice things like out of GPU memory crashes or multi-second long waiting times. Normal levels only use a fraction of the entire available data set so this would explode your memory requirements quite substantially.

What's particularly nasty is that OpenGL will never give you an out of memory error, it will just stash your textures and model data in CPU memory and then start swapping around at the most inopportune times.
Having this as a feature would cause mod authors to go lazy and make the problem a lot worse than what it is now.

I would very much like to see it too. If you are playing an extensive mod and the author did not go to the trouble of specifying all the staff that should be precached, it's always a second of freezing when you enter a new area, like open a door or ride a lift into an area where there is new stuff. I much prefer the approach of Beautiful Doom, where, yes, you need to wait some time for the mod to load, but then there are no freezes during the actual gameplay. But that thanks to Jekyll Grim Payne composing a mile-long list of the things that should be precached, and not every (to put it mildly) author does it.

So yes, I would very much like to see this option too.

That last paragraph was referring to a specific issue I was having with a particular actor, which prompted me to open this in the first place, but that's been fixed locally. The feature suggestion still remains though and it'd be useful for all other cases.

While I could theoretically do this manually in MAPINFO, doing it for all offending classes will take an impractical amount of time to find all cases of classes whose sprites cause stuttering when viewed for the first time. And that's disregarding the fact that I play with many addons where I don't have the luxury of having control of their MAPINFO. Therefore, I'd like to request an option that precaches ALL classes/sounds/textures. I don't mind the added loading times, nor the potential memory usage increase, as long as I get to have a smooth gameplay experience not interrupted by random irritating stutters I am certain are caused by precaching (which I already tested and proved to be true before opening this feature suggestion).

The only thing I haven't tested is whether this stuttering is caused by the actor's sprites being done entirely in TEXTURES using a rather large spritesheet. Likely is, but fixing it by splitting up the sheet is not an option here.