GLESZDoom - GZDoom for potatoes

7 minutes ago, 0o0[ULTIM4TE]L1FE[F0RM]0o0 said:

I mean it doesn't run 100% flawlessly, it's laggy sometimes in Brutal Doom and PB(Project Brutality)

Have a read at this please. Have a good day :)

Interesting. Well, this is a lot of text so I'm going to read it later.

23 minutes ago, 0o0[ULTIM4TE]L1FE[F0RM]0o0 said:

I mean it doesn't run 100% flawlessly, it's laggy sometimes in Brutal Doom and PB(Project Brutality)

Because PB is a unstable mod? And BD's excessive gore can trample systems.

Damn, really? I didn't think it was the mod itself that's just programmed poorly or something. Sorry then, my bad

And even Aeons of Death is unstable in many areas.

Damn. Okay, I will note that I shouldn't combine Aeons of Death with Project Brutality...

8 minutes ago, 0o0[ULTIM4TE]L1FE[F0RM]0o0 said:

Damn, really? I didn't think it was the mod itself that's just programmed poorly or something. Sorry then, my bad

That's the very reason I wrote the guide I linked you- research on mods and their effects are a must if you're going to be testing something. Read all about it :)

Yeah, BD is famous for its spaghetti code that is a nightmare for other modders to work with and PB is still in development.

Anyway, I tried this with the Lithium (mod) with NOVA (mappack) and I saw some improvements with the FPS, but not much. It's better in most cases but if there's a lot of entities in one area it performs worse. This is being compared to GZDooM 4.5 Stable with Vulkan. 

My Specs:

CPU:
  Info: Dual Core model: Intel Celeron N3050 bits: 64 type: MCP 
  L2 cache: 1024 KiB 
  Speed: 1033 MHz min/max: 480/2160 MHz Core speeds (MHz): 1: 1033 2: 763 
Graphics:
  Device-1: Intel Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx 
  Integrated Graphics 
  driver: i915 v: kernel 
  Device-2: Microdia Integrated Webcam type: USB driver: uvcvideo 
  Display: x11 server: X.Org 1.20.10 driver: loaded: intel 
  unloaded: modesetting resolution: 1366x768~60Hz 
  OpenGL: renderer: Mesa DRI Intel HD Graphics 400 (BSW) v: 4.6 Mesa 20.3.4 
Yes, I use Linux so I use Wine.

Ah, okay. Well, I bookmarked it to my web browser, I'll definitely make sure to read it, I just kinda need a break because I've been doing mapping for 3 hours non-stop now

Just now, Karl515 said:

Yeah, BD is famous for its spaghetti code that is a nightmare for other modders to work with and PB is still in development.

Anyway, I tried this with the Lithium (mod) with NOVA (mappack) and I saw some improvements with the FPS, but not much. It's better in most cases but if there's a lot of entities in one area it performs worse. This is being compared to GZDooM 4.5 Stable with Vulkan. 

My Specs: 

CPU:
  Info: Dual Core model: Intel Celeron N3050 bits: 64 type: MCP 
  L2 cache: 1024 KiB 
  Speed: 1033 MHz min/max: 480/2160 MHz Core speeds (MHz): 1: 1033 2: 763 
Graphics:
  Device-1: Intel Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx 
  Integrated Graphics 
  driver: i915 v: kernel 
  Device-2: Microdia Integrated Webcam type: USB driver: uvcvideo 
  Display: x11 server: X.Org 1.20.10 driver: loaded: intel 
  unloaded: modesetting resolution: 1366x768~60Hz 
  OpenGL: renderer: Mesa DRI Intel HD Graphics 400 (BSW) v: 4.6 Mesa 20.3.4 
Yes, I use Linux so I use Wine.

 

Ah, interesting. Well, I think Vulkan is just superior then I guess. And Mark should definitely make the code less weird then, I recently heard a similar thing about Minecraft to be honest, so they made an entire Update just to make the code less chaotic. Also I have no idea what that stuff is you're talking about except for Linux, I know what that is, kind of.

1 minute ago, 0o0[ULTIM4TE]L1FE[F0RM]0o0 said:

 

Ah, interesting. Well, I think Vulkan is just superior then I guess. And Mark should definitely make the code less weird then, I recently heard a similar thing about Minecraft to be honest, so they made an entire Update just to make the code less chaotic. Also I have no idea what that stuff is you're talking about except for Linux, I know what that is, kind of.

Well SgtMark is working on his own game so it might take a while before the next update. Vulkan is just better so I wont be using this engine for a while.

13 minutes ago, 0o0[ULTIM4TE]L1FE[F0RM]0o0 said:

Damn. Okay, I will note that I shouldn't combine Aeons of Death with Project Brutality...

How it's that's possible AoE it's bring features of others games to Doom, and also PB changes alot of the gameplay behaivor, this will make a mismatch of all they 2 codes, i just suprised that your Gzdoom launched the game.

 

7 minutes ago, Karl515 said:

Well SgtMark is working on his own game so it might take a while before the next update. Vulkan is just better so I wont be using this engine for a while.

Ah shit, alright, we should probably not bug him about it then...

Also...

5 minutes ago, jamondemarnatural said:

How it's that's possible AoE it's bring features of others games to Doom, and also PB changes alot of the gameplay behaivor, this will make a mismatch of all they 2 codes, i just suprised that your Gzdoom launched the game.

 

I have a little trouble comprehending this sentence because honestly your English isn't really that good, not meaning to be rude, but you gotta work on it a little. If I'm guessing correctly you're trying to tell me you're surprised that AoE and PB even booted right? Well, I haven't tried AoE and PB yet, right now I'm actually playing Project Brutality together with the Hellbound WAD while listening to some Hellripper in the background but I might maybe try it. Just to see if it will even work at all, that might be interesting!

2 hours ago, 0o0[ULTIM4TE]L1FE[F0RM]0o0 said:

and also this was Brutal doom Version 13 or something like that I think. But together with the Bolognese gore mod and Nash's gore mod all loaded up at once.

29 minutes ago, 0o0[ULTIM4TE]L1FE[F0RM]0o0 said:

And Mark should definitely make the code less weird then, I recently heard a similar thing about Minecraft to be honest, so they made an entire Update just to make the code less chaotic. Also I have no idea what that stuff is you're talking about except for Linux, I know what that is, kind of.

Erh, are you ussing that old version of BD? BD V21 Gold it's really a more optimized code that the olders one.

 

16 minutes ago, 0o0[ULTIM4TE]L1FE[F0RM]0o0 said:

If I'm guessing correctly you're trying to tell me you're surprised that AoE and PB even booted right? Well, I haven't tried AoE and PB yet, right now I'm actually playing Project Brutality together with the Hellbound WAD.

Oh, yeah, was that, but i see you're not running thoses 2 wads together, so not problem

Just now, jamondemarnatural said:

 

Erh, are you ussing that old version of BD? BD V21 Gold it's really a more optimized code that the olders one.

 

 

Oh, yeah, was that, but i see you're not running thoses 2 wads together, so not problem

I mostly play either Brutal Doom v21, v20 or v13, but apart from that I have almost all the versions except for a few that are lost to time which is extremely sad but apart from that, I have Project Brutality version 3.0 and 2.03. And yeah, I'll definitely try BD v21 next time. But I'm not sure if I'll go back to GLESZDoom though, it's incompatible with Vulkan... I'll reconsider if Beloko makes a version for Vulkan, though.

Since this is solely a "mod-talking" sort of comments, I think I need to step up a bit and post what I think of it.

First of all, this fork doesn't have much of a difference compared with the latest stable version of GZDoom (or dev versions) if the user has a good PC with decent specs to run, idk, Bastion of Chaos in its low-spec version. However, it can have a difference if it's using a potato PC. I tried myself in my laptop with vanilla Doom 1, good old E1M1 with only dynamic lights as the activated feature and, in both ports gave me an overall framerate of 250 fps.

If I were using my old potato laptop, I would have noticed an improvement for sure.

Second of all, mods that can use an excessive amount of effects or actors, like gore/smoke/particles in Brutal Doom or Project Brutality, won't improve your performance that much if you are using those mods to the limit, especially at larger maps.

Oh, damn. Well, I'll definitely stick to regular GZDoom then.

I tried it on my 2017 laptop (with intel i5 8th gen CPU and AMD Radeon 530 GPU) and I got varied results.

Areas that are not CPU intensive and more GPU intensive gave better performance. For example, areas that have lots of dynamic lights performed much better on GLESZDoom than on GZDoom. I didn't calculate exact numbers, but the performance improvement was anywhere between 20% to 40%.

However, areas that CPU intensive (mostly maps that have lots of detail and thus lot of BSP calculations) performed at least 30% slower for me. One example is the starting part of Eviternity's Map26. If I stare towards the rest of the map from the starting place, I get about 22-24 fps in GLESZDoom vs 30-33 fps in GZDoom with equivalent settings.

2 hours ago, ReaperAA said:

I tried it on my 2017 laptop (with intel i5 8th gen CPU and AMD Radeon 530 GPU) and I got varied results.

I think it's possibly the updating of the vertex data which uses a very old method in the GLES2 code. There is a common extension to GLES2 to allow the use of glMapBuffer, I'll be adding that in as an option which  might make a difference for larger maps.

I tried this with "Total Chaos:DC Retro Edition" and I got a significant FPS boost. On GZDooM 4.5 Vulkan (running on Native Linux) it runs on 5-35 fps while on GLESZDooM (running on Wine) runs on 15 to even 60 fps. This definitely helps run the more graphical demanding mods than the normal ones.

This looks VERY promising so I'll be eagerly waiting for new developments.

On 3/18/2021 at 12:13 AM, 0o0[ULTIM4TE]L1FE[F0RM]0o0 said:

Damn, really? I didn't think it was the mod itself that's just programmed poorly or something. Sorry then, my bad

The issue there is the actor spam. Spawning a new actor that has logic (i.e. reacts to environment in any way) has a fair performance cost. This is not an issue when there are only few such actors spawn per second.

However main BD/PB gimmick - location damage - relies on spawning several additional actors per monster, 10-15 times per second. This kills performance rather quickly, especially on maps with 400+ monsters - you will have about ~6 times worse FPS than without BD. (70-80 fps vs ~500 for example). Now combine it with complex map that runs at otherwise fine 120-150 fps and you'd get sub-30 framerate. Add in gratuitous blood splatters each one being separate actor as well, and you get the idea lol.

You can't do anything about it without completely rewriting the core of its main feature to use some sort of script instead of actor spawning, which would require too much effort to bother for people who could actually do it.

Since it has very little to do with the rendering, and much more with the core game logic, it can not be improved by graphic engine optimisations (i.e. this fork)

4 hours ago, Sinael said:

The issue there is the actor spam. Spawning a new actor that has logic (i.e. reacts to environment in any way) has a fair performance cost. This is not an issue when there are only few such actors spawn per second.

Yeah, different actors for different parts of the body. Even the damn gibs are treated as actors. Decorations are actors too. And, if you enable the shootable rocket ammo, they'll be treated as actors too. I think it can be fixed if the engine has limited rendering distance for actors.

https://forum.zdoom.org/viewtopic.php?f=49&t=71889

Depending on the results of this benchmarking campaign, this may get folded back into GZDoom and/or LZDoom. :)

Huh, interesting. Too bad my gfx card is newer so I cannot run a meaningful test. Wait, that's a GOOD thing!

7 hours ago, Gez said:

https://forum.zdoom.org/viewtopic.php?f=49&t=71889

Depending on the results of this benchmarking campaign, this may get folded back into GZDoom and/or LZDoom. :)

I mentioned this to Rach and she was aware, so in happy she followed up on it. This was obviously something that would interest her.

Ill join in on her request because of my setup.

11 hours ago, Gez said:

https://forum.zdoom.org/viewtopic.php?f=49&t=71889

Depending on the results of this benchmarking campaign, this may get folded back into GZDoom and/or LZDoom. :)

Thanks for the link! Very interesting to see the results when they come in and how the modification translates to PC platforms and if they help or make it worse.

Actually I tried the build on a Raspberry Pi 3, definitely helped in a speed but still wasn't playable running at 15-20 FPS which long pauses when loading new shaders. May work on Raspberry Pi 4, I'll give it a try when I get one.

Also did a few updates, interesting one is now 'Fixed color map' is working again, this fixes the black and white 'invulnerability' screen mode.

It doesn't use a second pass, instead performs the color fragment operation in the main render pass - this mostly works but currently looks bad with transparent objects.

New code is now in this branch: https://github.com/emileb/gzdoom/commits/master

13 hours ago, beloko said:

May work on Raspberry Pi 4, I'll give it a try when I get one.

I'll see what I can get working on mine and try to report back.  I have a pi 4 with 8GB, I forget the clock speeds.  I'll see what it can do and try to report back.

9 hours ago, CrbnBased said:

 

I'll see what I can get working on mine and try to report back.  I have a pi 4 with 8GB, I forget the clock speeds.  I'll see what it can do and try to report back.

Oh great! Yes wait though, I'll make a branch with a couple of changes to use, otherwise the Pi will try to use GL3 context with some sort of emulator (that's what my Ri Pi 3 did anyway) 

On 3/31/2021 at 10:48 AM, beloko said:

 

Thanks for the link! Very interesting to see the results when they come in and how the modification translates to PC platforms and if they help or make it worse.

 

Actually I tried the build on a Raspberry Pi 3, definitely helped in a speed but still wasn't playable running at 15-20 FPS which long pauses when loading new shaders. May work on Raspberry Pi 4, I'll give it a try when I get one.

 

 

Also did a few updates, interesting one is now 'Fixed color map' is working again, this fixes the black and white 'invulnerability' screen mode.

It doesn't use a second pass, instead performs the color fragment operation in the main render pass - this mostly works but currently looks bad with transparent objects.

New code is now in this branch: https://github.com/emileb/gzdoom/commits/master

 

Ill put in my results soon. Any chance of renaming the executable to ZDoomGLES (and the port itself) to make it a bit more official since Graf has stated to keep this (for now) in its own build?

It still won't run on GL2 hardware, check my post at zdoom.org.