Crash when out of video memory

[d64]

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.

[phantombeta]

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.

[dpJudas]

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.

[Rachael]

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.

[Graf Zahl]

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.

[phantombeta]

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