GZDoom crashes back to desktop in OpenGL ES with error

[DeathCold]

So yeah, i have this bug or glitch in latest GZDoom on OpenGL ES render. When i play Ultimate Doom with Project Brutality mod in OpenGL ES render on second, or any other, episode of Ultimate Doom, i could get a strange bug, that will later lead to a crash with error. First time it happened for me when i was trying to beat E2M1 map in Ultimate Doom with Project Brutality mod. When i press the button on the wall in the game to end the level, before going to score screen, the screen itself becomes black, then goes back to score screen, and when i go to the next level, the game will crash with a error, with message about reporting this error or not, which leads to closing the game. I saved the crash report, and i will attach it to this post.

Using GZDoom 4.8.0.0 by the way.

There is also few more things that i wanna point out. First of all, when i'm playing any other mod on GZDoom with OpenGL ES render, none of this happens. Like, i'm playing mod called Brutal Pack, Brutal Doom Black Edition, Embers of Armageddon or, let's say Eternal Slayer mod, and they work very smooth and none of the errors like this happens. But when i play Project Brutality mod in OpenGL ES render, this error ALWAYS crashes the game. And i have no idea, why it happens. Second, i can play only first episode with Project Brutality mod of Ultimate Doom, which is knee-deep in the dead and this error will never happen, but when i go to second, third or fourth episode, then there is like 99% of chance that this error will happen and crash the game.

And the last thing that i wanna point out that, different bug shows up when i play Doom 2 with Project Brutality mod. On the Crusher level, sometimes textures disappear, game starts to lag like hell and i can't do nothing but to quit the game by pressing Alt+F4. Also, when dynamic lights turned ON in OpenGL ES render, and when i encounter any object that has lights, the game will lag very hard. But when i turn around from the light source, the lag stops. The same happens when i shoot with guns that has dynamic lights applied to them. Let's say a shotgun for example. It will cause the lag too, because of dynamic lights in OpenGL ES render. Sure, i can just turn OFF the dynamic lights and problem will be solved, but then again, it would be cool if this problem could be fixed.

And that is all of the bugs and errors that i wanted to report. And like i said, i will attach a crash log, so you can check it out and tell me, why this is happening when i'm playing Project Brutality in OpenGL ES render.

[Graf Zahl]

How much video RAM does your graphics card have? And how much RAM do you have?

This behavior all points to an out of memory condition.

[DeathCold]

How much video RAM does your graphics card have? And how much RAM do you have?

This behavior all points to an out of memory condition.

Strange. So, why i don't have these problems while playing on simple OpenGL render or when playing other similar mods? And i have 2 GB of RAM and 256 MB of video memory. Sure, it's not enough, but Doom is a old game, and thus this should be enough for this game. Or even more than enough.

[Graf Zahl]

256 MB of video ram is very much on the low side. As an example, when running at 1920x1080, the internal render buffers alone will eat at least 64 MB of that and if you load some graphics intensive mods this can quickly make you run out of memory.

The main difference between GL and GLES is that GLES recompiles the shaders on demand, but if all your memory is already used up by textures you may get an unexpected error resulting in a crash.
On the other hand, if you create too many textures, they will get swapped out and back in, this only results in performance loss but not a crash.

[Rachael]

Strange. So, why i don't have these problems while playing on simple OpenGL render or when playing other similar mods? And i have 2 GB of RAM and 256 MB of video memory. Sure, it's not enough, but Doom is a old game, and thus this should be enough for this game. Or even more than enough.

Sorry, but I have to nip this in the bud while it's still fresh.

This is a very common misconception. The original Doom.exe will run just fine on that system under DOS - but that's not what we're actually doing, here.

GZDoom is a modern source port built for modern systems with modern needs. Obviously as you can see it does run on your system but actually running and actually providing a decent experience are two different things.

So saying "it's just Doom lol" ignorantly and stupidly ignores a lot of what GZDoom actually does and the very legitimate reasons why it requires the expanded system requirements. Among them is the vastly expanded actor and scripting features since Doom v1.9, plus a ton of different rendering changes and options that are more fitting to modern environments, not to mention requiring a modern enough operating system that simply will not even run on a system from Doom's era.

And that is why GZDoom simply will not run on DOS with the original 80486 machines with 8 mb of RAM that the original game was designed for.

[DeathCold]

256 MB of video ram is very much on the low side. As an example, when running at 1920x1080, the internal render buffers alone will eat at least 64 MB of that and if you load some graphics intensive mods this can quickly make you run out of memory.

The main difference between GL and GLES is that GLES recompiles the shaders on demand, but if all your memory is already used up by textures you may get an unexpected error resulting in a crash.
On the other hand, if you create too many textures, they will get swapped out and back in, this only results in performance loss but not a crash.

I'm not running Doom in high resolution. In fact, my screen resolution is only 1280x1024, but i run it in even lower resolution, which is 1204x768. Also, i don't use any visual mods for Doom. In fact, i don't like any visual mods for any game, cause it makes the game look even worse, than it was. To put it other way, i simply like the original Doom visuals. I like original pixel art more than a some kinda of 4k ultra hd visuals or something.

[DeathCold]

Strange. So, why i don't have these problems while playing on simple OpenGL render or when playing other similar mods? And i have 2 GB of RAM and 256 MB of video memory. Sure, it's not enough, but Doom is a old game, and thus this should be enough for this game. Or even more than enough.

Sorry, but I have to nip this in the bud while it's still fresh.

This is a very common misconception. The original Doom.exe will run just fine on that system under DOS - but that's not what we're actually doing, here.

GZDoom is a modern source port built for modern systems with modern needs. Obviously as you can see it does run on your system but actually running and actually providing a decent experience are two different things.

So saying "it's just Doom lol" ignorantly and stupidly ignores a lot of what GZDoom actually does and the very legitimate reasons why it requires the expanded system requirements. Among them is the vastly expanded actor and scripting features since Doom v1.9, plus a ton of different rendering changes and options that are more fitting to modern environments, not to mention requiring a modern enough operating system that simply will not even run on a system from Doom's era.

And that is why GZDoom simply will not run on DOS with the original 80486 machines with 8 mb of RAM that the original game was designed for.

Well, my system is not that old. Sure, it is outdated by todays standarts, but it can run things and it works. Sure, i maybe don't have too much of a video memory, but like i said, when playing other mods via GZDoom in OpenGL ES, i don't encounter this problem. It only happens to me with Project Brutality mod. Every other mod works fine. I can list all of the mods that i'm running via GZDoom in OpenGL ES, if needed, but again, i think that there is something in that Project Brutality mod that causes that crash because, i think it is not very well optimized with OpenGL ES render. But, i reported this problem to PB mod creators and they basically said the same stuff that you said. That it is not their mod problem but a source port problem. And if none of you are gonna help me with this, then looks like i'm gonna need to stop playing some of the mods simply because, instead of "help" i get one answer: get better pc. And trust me, if that were possible during a war, that is happening right now in my country, then i would get a new PC. But also, do you think i would play old Doom or mods for it? Hell, the only reason i'm playing original Doom mods is simply because i'm having outdated PC. And if i had a modern powerful PC, then i would just play Doom Eternal instead and didn't a give a flying F about your source port or mods for original Doom. No offense, but i'm tired of hearing just this one line of "buy a new PC". For freaiking 30 years old game! If none of you wanted to help then just say it. And maybe you will never see me again.

[Graf Zahl]

Well, my system is not that old. Sure, it is outdated by todays standarts, but it can run things and it works. Sure, i maybe don't have too much of a video memory, but like i said, when playing other mods via GZDoom in OpenGL ES, i don't encounter this problem. It only happens to me with Project Brutality mod. Every other mod works fine.

Which is a strong indicator that PB is doing something that does not work on your system and most likely exhausting some system resource.
No matter what you think of Doom - PB is not a lightweight mod and your system is at the very bottom of what we barely still declare supported.

[wildweasel]

But also, do you think i would play old Doom or mods for it?

yes, because they're fun

And if i had a modern powerful PC, then i would just play Doom Eternal instead and didn't a give a flying F about your source port or mods for original Doom. No offense, but i'm tired of hearing just this one line of "buy a new PC". For freaiking 30 years old game! If none of you wanted to help then just say it. And maybe you will never see me again.

The unfortunate march of progress. Fact is, these mods get made by people with powerful computers, who don't have an easy way to determine what parts, if any, are going to cause problems on older hardware.

[Rachael]

I sympathize with your inability to upgrade your system at the present time, especially due to the war, but there is not much we can do about it. And trying to force it to be our problem like that isn't going to help things.

Much as the authors of Project Brutality might like to "pass the potato around" so that they don't have to take responsibility for the way their mod operates with the GZDoom engine - fact of the matter is, the ball really is in their court. Fancy effects require fancy hardware - that's just the end of it right there. Don't blame GZDoom for the problems that you create with your mod. And if they're not willing to optimize their mod, or at least make the laggiest parts of the mod optional, then it will always be virtually unplayable on low-end systems.

Yes - GZDoom is very well optimized. Yes - it could be even more optimized, but not by much. No, GZDoom is not the most perfectest thing ever in the entire universe of existence to have ever existed since the start of the universe - but people - you have to understand - neither is Brutal Doom - neither is Project Brutality - and as long as we have these stupidly contrived golden calfs where the fans of said mods are literally incapable of looking inward for their problems, nothing will get done to improve the situation, and you will always continue to have unplayable "Brutal" mods.

You didn't pay to play GZDoom or to mod for it. If the developers really got sick of the community piling problem after problem onto them they could just quit tomorrow. That isn't a threat - that's exactly how many hobby projects like this actually die. And then you would have no one to fix or even point out the problems you have with making it work. What would you really have accomplished, then? Would you be happy with yourself?

Even if GZDoom was the most perfectly optimized program in the entire universe and even implemented full LLVM/Clang optimizations into its JITted code - mod authors can *still* cause problems with the engine slowing to a halt. If GZDoom can do it as badly as you think it already does - trust me a mod can do it too, because all GZDoom is doing is executing the mod's code. If code can do it, then so can code. Is that really so hard to believe? Why?

[DeathCold]

I sympathize with your inability to upgrade your system at the present time, especially due to the war, but there is not much we can do about it. And trying to force it to be our problem like that isn't going to help things.

Much as the authors of Project Brutality might like to "pass the potato around" so that they don't have to take responsibility for the way their mod operates with the GZDoom engine - fact of the matter is, the ball really is in their court. Fancy effects require fancy hardware - that's just the end of it right there. Don't blame GZDoom for the problems that you create with your mod. And if they're not willing to optimize their mod, or at least make the laggiest parts of the mod optional, then it will always be virtually unplayable on low-end systems.

Yes - GZDoom is very well optimized. Yes - it could be even more optimized, but not by much. No, GZDoom is not the most perfectest thing ever in the entire universe of existence to have ever existed since the start of the universe - but people - you have to understand - neither is Brutal Doom - neither is Project Brutality - and as long as we have these stupidly contrived golden calfs where the fans of said mods are literally incapable of looking inward for their problems, nothing will get done to improve the situation, and you will always continue to have unplayable "Brutal" mods.

You didn't pay to play GZDoom or to mod for it. If the developers really got sick of the community piling problem after problem onto them they could just quit tomorrow. That isn't a threat - that's exactly how many hobby projects like this actually die. And then you would have no one to fix or even point out the problems you have with making it work. What would you really have accomplished, then? Would you be happy with yourself?

Even if GZDoom was the most perfectly optimized program in the entire universe and even implemented full LLVM/Clang optimizations into its JITted code - mod authors can *still* cause problems with the engine slowing to a halt. If GZDoom can do it as badly as you think it already does - trust me a mod can do it too, because all GZDoom is doing is executing the mod's code. If code can do it, then so can code. Is that really so hard to believe? Why?

I get it. No one wants to do anything, only point the fingers and saying stuff. Ok then. Looks like i'm gonna need to turn the bage to the other side, remove all gzdoom files and forget that gzdoom even a thing. Maybe someday you will be on my side, where it's you, who gonna have the same problem, but in the end you get no help. I hope that you will feel what i feel someday. Anyway, sorry for wasting your time. I knew i should not report this stuff cause, no one is gonna help but just talk back at me about my PC and my problems. I'm out!

[openroadracer]

So you're just going to throw the baby out with the bathwater? What kind of issue is in your head that would drive you to this conclusion?

Why not try to talk something out with the developers of the mod instead of acting like this?

[Rachael]

Hell, at this point, even Brutal Doom of all things is doing more to address its problems than just blaming GZDoom. From what I understand it is still in development and isn't public yet but I have been getting reports that Sgt Mark IV has actually been making *some* effort into tying up some of the low hanging fruits in his mod to push some higher FPS numbers. I haven't seen it for myself though, so I wouldn't know, but it's worth a shot.

Maybe someday you will be on my side, where it's you, who gonna have the same problem, but in the end you get no help. I hope that you will feel what i feel someday. Anyway, sorry for wasting your time. I knew i should not report this stuff cause, no one is gonna help but just talk back at me about my PC and my problems. I'm out!

As I've said, I sympathize with you, but I will *never* handle it like you just did. Unlike you, I understand that everything is being provided to me *free of charge* and that I have *no right* to demand that people cater to *my* situation. If I was unfortunate and got straddled with a system that couldn't do jack shit, I would just have to make do with what it can do, and that's that.

[Graf Zahl]

I've never managed to get a memory dump loaded to show me the crashing code - and I no longer have the makefile for 4.8.0 so I cannot look this up. Have you tried with 4.8.2?

[Redneckerz]

Well, my system is not that old. Sure, it is outdated by todays standarts, but it can run things and it works. Sure, i maybe don't have too much of a video memory, but like i said, when playing other mods via GZDoom in OpenGL ES, i don't encounter this problem. It only happens to me with Project Brutality mod. Every other mod works fine.

What does the bolded tell you in your opinion?

I find the vast majority of any issues people run intovia GZDoom deters back to PB and BD. BD less so, and PB is rather infamous for how seemingly (often?) it seems to break hardware. It is easy for a mod author to point the finger at the source port, when the mod itself gets updated enough (Well, last i checked anyways..) to introduce issues over its time.

And if none of you are gonna help me with this, then looks like i'm gonna need to stop playing some of the mods simply because, instead of "help" i get one answer: get better pc

That's rather a oversimplification of what is suggested here. Especially since PB is not the lightest mod around. Running it at 1280x1024 (Hey, i have the same monitor size!) and 256 MB video ram may not cut it (And indeed it does not). You say your computer isn't the oldest, but what are we talking about here? I haven't read detailed specs.

I feel adding ''the war'' argument into this is unecessary but more over, unwarranted. Because you could argue that the other way around aswell.

I get it. No one wants to do anything, only point the fingers and saying stuff.

If that's what you get from all that is said then you have got your conclusions already ready, then.

Maybe someday you will be on my side, where it's you, who gonna have the same problem, but in the end you get no help. I hope that you will feel what i feel someday.

Spoiler: I was you. But you know what i did? I didn't complain that BD didn't run on my stone age rig, but i rather looked at ways to get a similar experience. Even with my new SFF PC, i know very well what i am up against - Forget about running heavy model-laden mods and post-processing to boot. It helps being realistic and not blaming the port for it - 9 out of 10 its not the port, but rather, the assets you want to run it with.