ZDoom

by **phantombeta** » Sat Sep 28, 2024 2:10 pm

Graf Zahl wrote: ↑Sat Sep 28, 2024 1:21 pm It wasn't Project Brutality but I once saw a weapon mod running out of memory because every single weapon frame - and there were a lot was a full 320x200 image so they didn't have to mess with the alignment - and not surprisingly that quickly ran out of memory and it was quite hard to convince the creators that this setup could even stress a high end card of its time to the limit.

That's exactly what Project Brutality does. Here it's even worse because each weapon has hundreds of frames for "smoothness", then combine that with the amount of weapons...

by **Graf Zahl** » Sat Sep 28, 2024 1:21 pm

It wasn't Project Brutality but I once saw a weapon mod running out of memory because every single weapon frame - and there were a lot was a full 320x200 image so they didn't have to mess with the alignment - and not surprisingly that quickly ran out of memory and it was quite hard to convince the creators that this setup could even stress a high end card of its time to the limit.

by **Rachael** » Sat Sep 28, 2024 2:05 am

This is what Project Brutality is known for. They are massively inefficient with resources, abuse the everloving fuck out of the engine and then when they run into problems doing that, they blame the engine developers for it trying to claim GZDoom is way less efficient than it really is - they are unwilling to look within, at their own problems. It ultimately doesn't matter what you do to fix the problems, they'll find a way to stretch it to the limit so they can pass the blame again. It is a textbook example of being unwilling and unable to understand that computers have limitations.

by **dpJudas** » Sat Sep 28, 2024 1:52 am

phantombeta wrote: ↑Fri Sep 27, 2024 4:44 pm Project Brutality uses very large amount of sprites for weapons, all with large amounts of empty space. Lots of duplicate frames, too. So I wouldn't be surprised if it used up 12GB of RAM with any upscaling + texture precaching enabled, considering all the animations and the amount of weapons.

If that's the case then it is really a mod problem. The best the engine could do would be to implement a GPU texture budget and swap out textures if there's no room. Then it wouldn't crash, but of course the complains would turn into stuttery performance or low resolution textures (depending on which strategy such a texture streaming implementation would use).

I find it incredible that any mod could use this much memory. Would have to be really dumb for it to get that far. That's why I assumed there could be some bug where maybe it was uploading the same textures multiple times or something.

by **phantombeta** » Fri Sep 27, 2024 4:44 pm

dpJudas wrote: ↑Fri Sep 27, 2024 10:49 am There must be more to this crash than simply the upscaler. There's just no way a 2x upscaler would run out of memory with 12 gb vram unless the mod itself is using very very large textures.

Project Brutality uses very large amount of sprites for weapons, all with large amounts of empty space. Lots of duplicate frames, too. So I wouldn't be surprised if it used up 12GB of RAM with any upscaling + texture precaching enabled, considering all the animations and the amount of weapons.

by **d64** » Fri Sep 27, 2024 4:20 pm

Attached is my ini.

I am running Windows 10, my command line is:

gzdoom -iwad doom2.wad -file sunlust.wad Project_Brutality-master.zip

GzDoom version is 4.12.2.

md5sums:
25e1459ca71d321525f84628f45ca8cd *doom2.wad
72bdb54a847e42d71be4535c52f90731 *sunlust.wad
9e1b067467f36dc5078481f4d8909604 *Project_Brutality-master.zip (downloaded from github last monday)

Issue persisted for me with previous versions of PB and many other wads.

Once main menu of Doom has loaded, there is no need for a save game: just open console, do "map map03", if it does not crash on loading the first map, go "map map04", "map map05", I didn't get further than three map changes in my tests, but quite often it crashes on the first one already.

I have noticed that having a browser displaying a Twitch channel or a Youtube video on other screen makes the crash more likely. I was sometimes able to get a map to load by closing the video, loading map, then starting the video again after.

I have attached a screenshot of task manager memory graph showing initial loading of the game engine, and then giving the map command. In comparison, with texture upscaling set to off instead of 2x, there is a very modest bump in memory use on map load, maybe 1 gigabyte.

Thanks for looking into it. For me the workaround of not using upscaling is fine, but maybe there is something to learn here.

by **dpJudas** » Fri Sep 27, 2024 2:39 pm

I guess if you give me the complete list of mods you played with and upload a save game I can load (or some instructions on how to end up in the same situation) then maybe I'd be able to see on my computer what GZDoom is using all the memory on. I unfortunately don't think there's any additional info in the crash itself you can give me.

by **d64** » Fri Sep 27, 2024 2:03 pm

dpJudas wrote:
> There must be more to this crash than simply the upscaler. There's just no
> way a 2x upscaler would run out of memory with 12 gb vram unless the mod
> itself is using very very large textures.

How can I get more info on the crash? The console shows nothing before the error message, and the debug logging options I tried didn't add anything relevant.

by **dpJudas** » Fri Sep 27, 2024 10:49 am

There must be more to this crash than simply the upscaler. There's just no way a 2x upscaler would run out of memory with 12 gb vram unless the mod itself is using very very large textures.

by **d64** » Fri Sep 27, 2024 4:05 am

This problem was quite persistent for me when trying to play practically any wad with Project Brutality. I have 32gb of ram and RTX 4070 super with 12gb vram. Still, loading a saved game almost always failed with just 2x upscaling. Problem is solved by disabling upscaling entirely.

Does not add much but just noting issue does not only impact older gpus with less vram.

by **Professor Hastig** » Wed Jul 10, 2024 2:24 am

This won't really do much good, ultimately. It only delays the crash. The precacher loads all textures being used in the map, so as you continue playing, more and more textures will be loaded until eventually the RAM gets filled and you get a seemingly random crash somewhere in the map.

by **Kedman** » Tue Jul 09, 2024 9:05 am

Hello Doom enjoyers!

I know this topic is a little dated, but I have come to solve this problem. I also use an upscaler, and zDoom crashed all the time, so just disable the texture preload option in the display options, so that the game starts. The only problem is that you may have microfreeze. The solution is to then lower your upscale slightly, so you enjoy Doom in HQ. I hope it can be useful !

For information, my current configuration :
Ryzen 5 2600X
Nvidia GeForce 1660 Ti
16Go RAM (2x8Go)
Screen in 1920x1080 100Hz

by **Major Cooke** » Sun Feb 25, 2024 2:26 pm

I noticed recently this bug returned as well. I don't play with any extra upscaling or additional textures, it's just standard gameplay.

by **theleo_ua** » Tue Oct 17, 2023 4:58 am

Professor Hastig wrote: ↑Mon Oct 16, 2023 11:49 pm I'm a bit surprised, though. How can a 4GB card run out of memory with Doom, unless using hi-res textures?

Hi-res textures, yes. Same for my HHMIX mod, it has a lot of hi-res content. And sometimes, when out of memory, it will not crash GZDoom, but will create video artifacts, here is an example: https://www.youtube.com/watch?v=ETYcL9Q ... t=2h21m53s (watch at 2:21:53)

Please note, that on that video I had GZDoom 4.5.0 x64, Windows 7 Ultimate, AMD Phenom 2 x4 3000 MHz,16 GB RAM, Geforce GTX 770 2GB (latest windows and driver updates for 30 JAN 2021). And yes, sometimes GZDoom crashed on that PC with that mod, and sometimes created video artifacts

by **dpJudas** » Tue Oct 17, 2023 3:07 am

I assume that RebirthOfCronos uses a lot of textures or other assets that consumed the memory.

The vulkan backend in some situations uses a bit more memory than OpenGL does due to its way of keeping resources in memory until a rendered frame has completed. If it finished all work on the GPU and flushes the deleted resources before filling the cache on map load then maybe this situation would not happen for this particular map and GPU. Ultimately though, that just raises the limit for when it will happen.

OpenGL generally doesn't crash here because it swaps textures out to CPU memory in situations like this.

ZDoom

Crash when out of video memory

Post a reply

Expand view Topic review: Crash when out of video memory

Re: Crash when out of video memory

Re: Crash when out of video memory

Re: Crash when out of video memory

Re: Crash when out of video memory

Re: Crash when out of video memory

Re: Crash when out of video memory

Re: Crash when out of video memory

Re: Crash when out of video memory

Re: Crash when out of video memory

Re: Crash when out of video memory

Re: Crash when out of video memory

Re: Crash when out of video memory

Re: Crash when out of video memory

Re: Crash when out of video memory

Re: Crash when out of video memory