Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
beloko

GLESZDoom - GZDoom for potatoes

Recommended Posts

Just now, beloko said:

 

 

To be clear, are you saying the 0.2 version of GLES is faster than the first 0.1 version when using the HW renderer?

 

When using the Software renderer only iirc, though given how absurdly unstable it is i wouldn't doubt if it's an anomaly and just isn't actually related to the version. In hindsight i should've wrote that down in a more organized manner given how bad my memory is.

Share this post


Link to post

Sorry for the spam, but i've also been testing it with my UMDF map, and it doesn't only seem to run pretty well despite all of the dynamic lights, portals, 3D floors and thousands of linedefs everywhere, but also absolutely nothing seems to break either. However, the console seems to be spitting out these... errors? every few minutes/seconds as i'm flying around the map (but not when i'm standing still)

image.png.5a2508ec52dd60c313000b8be4769459.png

 

I'm guessing it's got to do with just dynamic lights and floor glows (mostly the latter).

 

Also now that i'm using it semi-regularly i've picked up on a few things and i have some questions:

This might seem silly but in GZDoom the furthest you can push mouse sensitivity in the menus is 10, while in this fork the limit is actually 8. Could you consider changing that? I'm extremely used to setting my horizontal sensitivity to 10 in GZDoom so it feels weird not having it here.

 

Also, is there any chance to re-adapt palette tonemap mode and software sector mode to this? Those don't seem to affect performance at all for me, yet they help to keep that software renderer *look* (which is something i know some other people also like to have in GZDoom)? Either way i apologize if these requests seem unrealistic, i don't know exactly how much effort would go into additions like these, but if i had to pick two things to adapt to this fork they would easily be software sector light mode and palette tonemap filter.

Share this post


Link to post
8 hours ago, MattFright said:

Sorry for the spam, but i've also been testing it with my UMDF map, and it doesn't only seem to run pretty well despite all of the dynamic lights, portals, 3D floors and thousands of linedefs everywhere, but also absolutely nothing seems to break either. However, the console seems to be spitting out these... errors? every few minutes/seconds as i'm flying around the map (but not when i'm standing still)

 

Please keep testing if you can, it very much helps ensuring the changes I made aren't too broken. Those are debug output and are shown every time a new shader is generated and compiled, they give me an idea of how many shaders are used and what features they use. I can put behind a CVAR so you can turn them off. You may notice a few frames dropped when they are created.

 

8 hours ago, MattFright said:

 

This might seem silly but in GZDoom the furthest you can push mouse sensitivity in the menus is 10, while in this fork the limit is actually 8. Could you consider changing that? I'm extremely used to setting my horizontal sensitivity to 10 in GZDoom so it feels weird not having it here.

 

 

I haven't changed anything at all except for the rendering, but it uses what ever was in 'master' from a few weeks ago so that must be a future change for GZDoom I guess? Pretty sure nothing I did would have done that!

 

8 hours ago, MattFright said:

Also, is there any chance to re-adapt palette tonemap mode and software sector mode to this? Those don't seem to affect performance at all for me, yet they help to keep that software renderer *look* (which is something i know some other people also like to have in GZDoom)? Either way i apologize if these requests seem unrealistic, i don't know exactly how much effort would go into additions like these, but if i had to pick two things to adapt to this fork they would easily be software sector light mode and palette tonemap filter.

 

Yes I need to put those back, there was a reasonable amount of shader code for those features which I removed, will see how I can put it back in and avoid most branching in the shader code.

Share this post


Link to post

Hi again, I decided to go back to this thread since I had been testing GLESZdoom for a few days now and I think I'm gonna add a few things I kinda noticed...

 

so, I noticed when you're playing either Brutal Doom or Project Brutality and you're being shot at, sometimes the hitscan enemies need more time to aim because the entire screen freezes for a second sometimes when they have taken aim. Especially the chaingunners. I haven't noticed it in Vanilla tho, at least not consciously but I definitely remember playing a Mega-WAD with Project Brutality lagging a little very clearly!

 

Also it doesn't really make a difference performance-wise on my PC, like, I still get the same choppy Frame-rate even with the GLESZDoom when I play a mod with a lot of gore when all that gore has to be rendered and I'm playing it using Vulkan because I have AMD. But yeah that's just my experience so far. I think for me personally, GZDoom might be the better solution so far. And I have Windows of course if that helps! And the 64-bit version. Had to take the 64-bit version because of something my PC seemed to demand.

Share this post


Link to post
3 minutes ago, 0o0[ULTIM4TE]L1FE[F0RM]0o0 said:

Hi again, I decided to go back to this thread since I had been testing GLESZdoom for a few days now and I think I'm gonna add a few things I kinda noticed...

 

Appreciate the update! 

 

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

I still get the same choppy Frame-rate even with the GLESZDoom when I play a mod with a lot of gore when all that gore has to be rendered and I'm playing it using Vulkan because I have AMD.

 

Are you saying you are using the binary I posted with Vulkan? 

Share this post


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

Yeah, I'm always choosing Vulkan because in Doom 2016 it runs a lot better so I just assume OpenGL will also not work well on GZDoom or GLESZDoom.

 

OK I have not touched the Vulkan engine so it will play exactly the same as before (except if I have broken it by accident).

You need to run the binary I posted with OpenGL selected otherwise nothing will change! It still may not make much difference but you HAVE to select OpenGL mode if you wanna try it out :)

Share this post


Link to post

Hey, the source port crash when trying to run WAD on software mode (not true color), it also happen to DOOM2.WAD:

Spoiler

OS: Windows 10 (or higher) (NT 10.0) Build 15063
    
M_LoadDefaults: Load system defaults.
Using program directory for storage
W_Init: Init WADfiles.
 adding D:/doomed pc/GLESZDoom_0.2/gzdoom.pk3, 682 lumps
 adding D:/doomed pc/GLESZDoom_0.2/game_support.pk3, 2514 lumps
 adding ./DOOM2.WAD, 2919 lumps
 adding D:/doomed pc/GLESZDoom_0.2/game_widescreen_gfx.pk3
, 1 lumps
I_Init: Setting up machine state.
CPU speed: 1094 MHz
CPU Vendor ID: GenuineIntel
  Name: Intel(R) Celeron(R) CPU N3350 @ 1.10GHz
  Family 6, Model 92, Stepping 9
  Features: SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 HyperThreading
V_Init: allocate screen.
S_Init: Setting up sound.
I_InitSound: Initializing OpenAL
  Opened device OpenAL Soft on Speakers (Realtek High Definition Audio)
  EFX enabled
ST_Init: Init startup screen.
Checking cmd-line parameters...
S_InitData: Load sound definitions.
G_ParseMapInfo: Load map definitions.
Texman.Init: Init texture manager.
ParseTeamInfo: Load team definitions.
LoadActors: Load actor definitions.
script parsing took 444.66 ms
R_Init: Init Doom refresh subsystem.
DecalLibrary: Load decals.
M_Init: Init menus.
P_Init: Init Playloop state.
ParseSBarInfo: Loading custom status bar definition.
D_CheckNetGame: Checking network game status.
player 1 of 1 (1 nodes)
I_InitInput
I_StartupMouse
I_StartupKeyboard
I_StartupXInput
I_StartupRawPS2
I_StartupDirectInputJoystick
GL_VENDOR: Intel
GL_RENDERER: Intel(R) HD Graphics 500
GL_VERSION: 4.4.0 - Build 22.20.16.4708
GL_SHADING_LANGUAGE_VERSION: 4.40 - Build 22.20.16.4708
Resolution: 800 x 600
Shader: shaders/glsl/func_notexture.fp, 00000080 
#define MAXIMUM_LIGHT_VECTORS 129
#define DEF_TEXTURE_MODE 0
#define DEF_TEXTURE_FLAGS 0
#define DEF_BLEND_FLAGS 0
#define DEF_FOG_2D 1
#define DEF_FOG_ENABLED 0
#define DEF_FOG_RADIAL 0
#define DEF_FOG_COLOURED 0
#define DEF_USE_U_LIGHT_LEVEL 0
#define DEF_DO_DESATURATE 0
#define DEF_DYNAMIC_LIGHTS_MOD 0
#define DEF_DYNAMIC_LIGHTS_SUB 0
#define DEF_DYNAMIC_LIGHTS_ADD 0
#define DEF_USE_OBJECT_COLOR_2 0
#define DEF_USE_GLOW_TOP_COLOR 0
#define DEF_USE_GLOW_BOTTOM_COLOR 0
Shader: shaders/glsl/func_normal.fp, 00000082 
#define MAXIMUM_LIGHT_VECTORS 129
#define DEF_TEXTURE_MODE 2
#define DEF_TEXTURE_FLAGS 0
#define DEF_BLEND_FLAGS 0
#define DEF_FOG_2D 1
#define DEF_FOG_ENABLED 0
#define DEF_FOG_RADIAL 0
#define DEF_FOG_COLOURED 0
#define DEF_USE_U_LIGHT_LEVEL 0
#define DEF_DO_DESATURATE 0
#define DEF_DYNAMIC_LIGHTS_MOD 0
#define DEF_DYNAMIC_LIGHTS_SUB 0
#define DEF_DYNAMIC_LIGHTS_ADD 0
#define DEF_USE_OBJECT_COLOR_2 0
#define DEF_USE_GLOW_TOP_COLOR 0
#define DEF_USE_GLOW_BOTTOM_COLOR 0
Shader: shaders/glsl/func_notexture.fp, 00008080 
#define MAXIMUM_LIGHT_VECTORS 129
#define DEF_TEXTURE_MODE 0
#define DEF_TEXTURE_FLAGS 0
#define DEF_BLEND_FLAGS 0
#define DEF_FOG_2D 1
#define DEF_FOG_ENABLED 0
#define DEF_FOG_RADIAL 0
#define DEF_FOG_COLOURED 0
#define DEF_USE_U_LIGHT_LEVEL 1
#define DEF_DO_DESATURATE 0
#define DEF_DYNAMIC_LIGHTS_MOD 0
#define DEF_DYNAMIC_LIGHTS_SUB 0
#define DEF_DYNAMIC_LIGHTS_ADD 0
#define DEF_USE_OBJECT_COLOR_2 0
#define DEF_USE_GLOW_TOP_COLOR 0
#define DEF_USE_GLOW_BOTTOM_COLOR 0
Shader: shaders/glsl/func_normal.fp, 00008082 
#define MAXIMUM_LIGHT_VECTORS 129
#define DEF_TEXTURE_MODE 2
#define DEF_TEXTURE_FLAGS 0
#define DEF_BLEND_FLAGS 0
#define DEF_FOG_2D 1
#define DEF_FOG_ENABLED 0
#define DEF_FOG_RADIAL 0
#define DEF_FOG_COLOURED 0
#define DEF_USE_U_LIGHT_LEVEL 1
#define DEF_DO_DESATURATE 0
#define DEF_DYNAMIC_LIGHTS_MOD 0
#define DEF_DYNAMIC_LIGHTS_SUB 0
#define DEF_DYNAMIC_LIGHTS_ADD 0
#define DEF_USE_OBJECT_COLOR_2 0
#define DEF_USE_GLOW_TOP_COLOR 0
#define DEF_USE_GLOW_BOTTOM_COLOR 0
Shader: shaders/glsl/func_normal.fp, 00008080 
#define MAXIMUM_LIGHT_VECTORS 129
#define DEF_TEXTURE_MODE 0
#define DEF_TEXTURE_FLAGS 0
#define DEF_BLEND_FLAGS 0
#define DEF_FOG_2D 1
#define DEF_FOG_ENABLED 0
#define DEF_FOG_RADIAL 0
#define DEF_FOG_COLOURED 0
#define DEF_USE_U_LIGHT_LEVEL 1
#define DEF_DO_DESATURATE 0
#define DEF_DYNAMIC_LIGHTS_MOD 0
#define DEF_DYNAMIC_LIGHTS_SUB 0
#define DEF_DYNAMIC_LIGHTS_ADD 0
#define DEF_USE_OBJECT_COLOR_2 0
#define DEF_USE_GLOW_TOP_COLOR 0
#define DEF_USE_GLOW_BOTTOM_COLOR 0

----------------------------------------

MAP01 - Entryway


Execution could not continue.

Unable to map buffer for software rendering

On hardware rendering, it runs fine.

Share this post


Link to post
9 minutes ago, lokbustam257 said:

Hey, the source port crash when trying to run WAD on software mode (not true color), it also happen to DOOM2.WAD:

On hardware rendering, it runs fine.

 

Tnx. Yep don't use SW mode I have broken it (there is no point anyway as it won't be any difference even if it did work).

Share this post


Link to post
Just now, beloko said:

 

Tnx. Yep don't use SW mode I have broken it (there is no point anyway as it won't be any difference even if it did work).

oh ok. Hope you got it fix.

Share this post


Link to post
2 hours ago, lokbustam257 said:

oh ok. Hope you got it fix.

 

2 hours ago, beloko said:

 

Tnx. Yep don't use SW mode I have broken it (there is no point anyway as it won't be any difference even if it did work).

Basically:

Run this using the OpenGL renderer. Not software, not Vulkan. This will activate the GLES2 render path.

Share this post


Link to post
10 minutes ago, 0o0[ULTIM4TE]L1FE[F0RM]0o0 said:

Hi again... I'm really sorry for what happened yesterday. Okay so basically I take Vulken because it's said to run faster on AMD systems! Also, if I run GLESZDoom with OpenGL, will it still be faster than regular GZDoom using Vulkan?


Vulkan will not may do that impact if your AMD System it's old. If your GZDoom can use the Vulkan option, the best thing to do should be a playtest with the framerate and framepacing showing in your screen. 2 Playtest in the same map and same mods, one with.
 

  • Official GZDOOM with Vulkan.
  • GLESZDoom with OpenGL.
     

And with that info, we can say what's better for your system.

Share this post


Link to post
4 minutes ago, 0o0[ULTIM4TE]L1FE[F0RM]0o0 said:

Hi again... I'm really sorry for what happened yesterday. Okay so basically I take Vulken because it's said to run faster on AMD systems! Also, if I run GLESZDoom with OpenGL, will it still be faster than regular GZDoom using Vulkan?

No need to apologise for anything. 

Will it be faster? Well I don't know, you just need to give it a try. There seems to be so many variables which effect it. If you don't have trouble with performance on Gzdoom just use that, it has more features and is gaureteed to work.

If you have a really old GPU and low average frame rate is it possible the binary I posted may help.

Share this post


Link to post
2 minutes ago, jamondemarnatural said:


Vulkan will not may do that impact if your AMD System it's old. If your GZDoom can use the Vulkan option, the best thing to do should be a playtest with the framerate and framepacing showing in your screen. 2 Playtest in the same map and same mods, one with.
 

  • Official GZDOOM with Vulkan.
  • GLESZDoom with OpenGL.
     

And with that info, we can say what's better for your system.

 

My PC is like 3 years old I think, it belonged to my sister but she didn't need it any more later so we re-installed everything, and then I just kinda connected my audio system to it which was way too complicated because I needed like 3000 extra special cables. I know this Vulkan thing because for some reason, Doom 2016 runs on like 40 FPS when I play with OpenGL, but if I choose Vulkan I suddenly get like 180 FPS on the highest settings possible... I'm not joking, it's insane! Even though it has so many graphic effects. So I don't think the PC is really bad. I just wish I knew where to see what Windows version I have. That stuff is just so complicated to me.

 

8 minutes ago, beloko said:

No need to apologise for anything. 

Will it be faster? Well I don't know, you just need to give it a try. There seems to be so many variables which effect it. If you don't have trouble with performance on Gzdoom just use that, it has more features and is gaureteed to work.

If you have a really old GPU and low average frame rate is it possible the binary I posted may help.

 

Also, I apologized because I was a little bit tripping out at the moment, everything already felt like a magic drug trip but I'm better now! Well, I wanted to try GLESZDoom because of the little screenjerking that's going on when there's too much Brutal Doom on the screen, like it's sort of lagging and it feels weird to use the mouse. Also how do I make that blurriness go away? I tried changing the texture settings multiple times but it just keeps on looking blurry, it's actually extremely nauseating to look at

Share this post


Link to post
10 minutes ago, 0o0[ULTIM4TE]L1FE[F0RM]0o0 said:

Also, I apologized because I was a little bit tripping out at the moment, everything already felt like a magic drug trip but I'm better now! Well, I wanted to try GLESZDoom because of the little screenjerking that's going on when there's too much Brutal Doom on the screen, like it's sort of lagging and it feels weird to use the mouse. Also how do I make that blurriness go away? I tried changing the texture settings multiple times but it just keeps on looking blurry, it's actually extremely nauseating to look at

 

If you pc is only 3yrs old and runs doom 2016 at 180 fps there is a good chance this won't help you out (and may be worse) , but just try and see what happens. 

 

I did an update which should fix the texture filtering modes, make sure you have downloaded the new 0.2 version. Let me know if it still doesn't work. 

Share this post


Link to post
2 hours ago, Redneckerz said:

Run this using the OpenGL renderer. Not software, not Vulkan. This will activate the GLES2 render path.

The Softpoly backend it's not the same as the software render modes, once this thing runs on GL2 the software modes should run there too (and we know 8 bit is faster under GL than under Softpoly).

Share this post


Link to post

Hi again! So I measured how many FPS I'm getting and it gets me around 1200 FPS. You can see that at the upper left corner. Well, it definitely runs a lot better than the other Doom games but everything is just way too bright like I can just see everything without a problem in areas that are supposed to be dark... I think you definitely have to fix that, because Darkness(And I'm not talking about the band) is a fundamental element of Doom! So yeah, it's really impressive but it also doesn't function properly yet...

Screenshot_Doom_20210317_182659.png

Share this post


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

Hi again, okay so I tried the new version and the resolution is much better now, it's looking really clear like GZDoom but for some reason everything is way too bright, why is that?

 

(Full menu options) Display Options- > Hardware Renderer ->Sector Light mode: Change to something else, some of them are broken

Share this post


Link to post

Hi, so I tried it and this time the light fully works and also the gore is rendered properly this time except for some reason it has a few weird lines... I made a screenshot with an arrow pointing at it. And also don't worry that I'm only having 63 FPS on the screenshot, it originally was like 300 but for some reason when I tab back to snipping tool it reduces itself to 63 and I have no clue why... so yeah don't worry about it. It looks and feels pretty good tho!

 

https://prnt.sc/10oe8oq

 

Also, sorry I'm posting a link to a screenshot instead of uploading the screenshot, the forum gives me weird error messages.

Share this post


Link to post
1 hour ago, 0o0[ULTIM4TE]L1FE[F0RM]0o0 said:

Hi again... I'm really sorry for what happened yesterday. Okay so basically I take Vulken because it's said to run faster on AMD systems!

But this does not use Vulkan, but GLES.

 

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

Also, if I run GLESZDoom with OpenGL, will it still be faster than regular GZDoom using Vulkan?

That heavily depends. You say your machine is 3 years old, so its likely less cut out for GLESZDoom than a 10 year old rig.

 

38 minutes ago, drfrag said:

The Softpoly backend it's not the same as the software render modes, once this thing runs on GL2 the software modes should run there too (and we know 8 bit is faster under GL than under Softpoly).

We will just have to wait it out. Im just waiting till the OGL3.3 requirement is dropped so i can test this out ;)

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

Hi, so I tried it and this time the light fully works and also the gore is rendered properly this time except for some reason it has a few weird lines... I made a screenshot with an arrow pointing at it. And also don't worry that I'm only having 63 FPS on the screenshot, it originally was like 300 but for some reason when I tab back to snipping tool it reduces itself to 63 and I have no clue why... so yeah don't worry about it. It looks and feels pretty good tho!

 

https://prnt.sc/10oe8oq

 

Also, sorry I'm posting a link to a screenshot instead of uploading the screenshot, the forum gives me weird error messages.

You mean this:


kvsa_MSoSFCwznm2ASDf0g.png

Looks dithered to me, or part of the gore (bloodsplats)

 

You also run this with either Brutal Doom and/or Project Brutality: Two of the most known mods. PB is known for breaking compatibility, especially inbetween versions. So if GLESZDoom can't run this flawlessly, i would first look into PB or try any other mod than these two for testing.

Share this post


Link to post

Oh, alright, I didn't know that Project Brutality likes to break stuff... well, It's not GLESZDoom's fault then, 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.

Share this post


Link to post
19 hours ago, MattFright said:

Sorry for the spam, but i've also been testing it with my UMDF map, and it doesn't only seem to run pretty well despite all of the dynamic lights, portals, 3D floors and thousands of linedefs everywhere, but also absolutely nothing seems to break either. However, the console seems to be spitting out these... errors? every few minutes/seconds as i'm flying around the map (but not when i'm standing still)

It might be GLESZdoom ridding any need of those hardware rendering options used by GZDoom, since many modern hardware (even high-end ones) can't handle GZDoom's modern OpenGL stuff very flawlessly. My guesses was that GZDoom devs wanted it to have all these hardware rendering options to compete against eDuke32's Polymost renderer but it failed due to most modern hardware failing to handle GZDoom's modern OpenGL renderer.

Share this post


Link to post
1 hour ago, Wadmodder Shalton said:

It might be GLESZdoom ridding any need of those hardware rendering options used by GZDoom, since many modern hardware (even high-end ones) can't handle GZDoom's modern OpenGL stuff very flawlessly. My guesses was that GZDoom devs wanted it to have all these hardware rendering options to compete against eDuke32's Polymost renderer but it failed due to most modern hardware failing to handle GZDoom's modern OpenGL renderer.

If that's the case then why does GZ run just fine on said modern hardware?

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×