Nugget Doom 3.1.0 (updated May 16th, '24)

[s4f3s3x]

"Seizure" is the coolest screen wipe possible for a Doom port. Pure pixel crush genius!

 

Like... seriously.

[CacoKnight]

Don't want to start an OT but not sure where to post this, I thought with all the new hardware/SDL integration the main ports were going to be kind of all alike regarding smoothness etc., to make a real comparison I haven't touched anything else other than Nugget and Woof! (testing) since they integrated SDL/hardware rendering. Earlier I was playing Atmospheric Extinction and I notice noticed MAP04 was struggling a little with Nugget so I was like this is the perfect moment to see if DSDA is the same now, loaded DSDA and it's damn smooth like butter, it's like a different game. How the hell is that possible if both load the GPU with the same SDL APIs? What kind of optimization is DSDA using?

Edited March 9, 2024 by CacoKnight

[Shepardus]

20 minutes ago, CacoKnight said:

Don't want to start an OT but not sure where to post this, I thought with all the new hardware/SDL integration the main ports were going to be kind of all alike regarding smoothness etc., to make a real comparison I haven't touched anything else other than Nugget and Woof! (testing) for like a month), I noticed MAP04 of Atmospheric Extinction was struggling a little with Nugget so I was like this is the perfect moment to see if DSDA is the same now, loaded DSDA and it's damn smooth like butter, it's like a different game. How the hell is that possible if both load the GPU with the same SDL APIs? What kind of optimization is DSDA using?

Care to share what settings you're using for each? You're not comparing software rendering with dsda-doom's OpenGL renderer, are you?

[CacoKnight]

Just now, Shepardus said:

Care to share what settings you're using for each? You're not comparing software rendering with dsda-doom's OpenGL renderer, are you?

Nugget's "new" default on dev builds loads with Direct3D9 but I tried OpenGL too and DSDA in OpenGL, both native res 2560x1440.

[Shepardus]

1 minute ago, CacoKnight said:

Nugget's "new" default on dev builds loads with Direct3D9 but I tried OpenGL too and DSDA in OpenGL, both native res 2560x1440.

If by "DSDA in OpenGL" you mean you set "video mode" to OpenGL in its options menu, that's a hardware renderer that is totally different from setting the SDL render driver to "OpenGL."

[CacoKnight]

10 minutes ago, Shepardus said:

If by "DSDA in OpenGL" you mean you set "video mode" to OpenGL in its options menu, that's a hardware renderer that is totally different from setting the SDL render driver to "OpenGL."

Ah, no wonder, I thought DSDA was using SDL too and added optimizations on top that's why I was wondering why it's so much smoother. So, trying to understand cause I'm not a programmer, SDL just tells the software that it can use the GPU via Direct3D and OpenGL APIs but hardware renderer is using the GPU directly?

Edited March 9, 2024 by CacoKnight

[Shepardus]

Just now, CacoKnight said:

Ah, no wonder, I thought DSDA was using SDL too and added optimizations on top that's why I was wondering why it's so much smoother. So, trying to understand cause I'm not a programmer, SDL just tells the software that it can use the GPU via Direct3D and OpenGL APIs but hardware renderer is using the GPU directly APIs?

dsda-doom does use SDL. Setting the SDL render driver essentially tells SDL what API to use to push pixels to the screen (I don't know the details), but doesn't change anything about how those pixels are calculated. Whether you set it to Direct3D or OpenGL or software, Woof and Nugget Doom are still using a software renderer. dsda-doom, however, has an "actual" hardware renderer (originally GlBoom) that uses your graphics card to render the scene, and that's what you're choosing when you select OpenGL in the menu. It's akin to selecting the software vs. hardware renderers in GZDoom.

[CacoKnight]

I see, we're talking about the same thing then but you're still referring to the stable Nugget/Woof!, I'm talking about the dev builds with hardware renderer, DSDA still feels like a different world. Try them on some large maps.

 

Editing the first post there, not a month but I've been testing and exclusively using since Nugget/Woof! dev integrated SDL with hardware rendering.

Edited March 9, 2024 by CacoKnight

[Shepardus]

4 minutes ago, CacoKnight said:

I see, we're talking about the same thing then but you're still referring to the stable Nugget/Woof!, I'm talking about the dev builds with hardware renderer, DSDA still feels like a different world. Try them on some large maps.

 

Editing the first post there, not a month but I've been testing and exclusively using since Nugget/Woof! dev integrated SDL with hardware rendering.

I'm not aware of any hardware renderer for Nugget Doom or Woof, where are you seeing this?

[CacoKnight]

3 minutes ago, Shepardus said:

I'm not aware of any hardware renderer for Nugget Doom or Woof, where are you seeing this?

It was the whole thing of Woof! 14.x man https://github.com/fabiangreffrath/woof/releases, for Nugget you have to get the dev builds from GitHub, I try to bring up stuff I notice before the main releases no matter how stupid they are so they can look into it, most of the times though are just stupid things.

[Shepardus]

9 minutes ago, CacoKnight said:

It was the whole thing of Woof! 14.x man https://github.com/fabiangreffrath/woof/releases, for Nugget you have to get the dev builds from GitHub, I try to bring up stuff I notice before the main releases no matter how stupid they are so they can look into it, most of the times though are just stupid things.

I have Woof 14.2.0 and I follow the repo. Neither Woof nor Nugget Doom has a hardware renderer, and what you're referring to as "hardware rendering" is just setting the SDL render driver. It'd be a lot more code than that if you were to actually rewrite the renderer. For a taste of what that looks like in dsda-doom, take a look at the files with the gl_ prefix in the dsda-doom source code.

 

Another thing you can try is enabling freelook and looking up and down - if the view distorts as you do so, that's a software renderer (unless you went out of your way to do that in a hardware renderer).

Edited March 9, 2024 by Shepardus

[CacoKnight]

Perfect and thank you, sorry for the confusion. I'm doing 20 different things now and between my son calling and phone messages I don't even know what year it is anymore. It was just an observation more than anything anyway, trying to understand etc., they're not going to take Nugget from my DOOM folder!

Edited March 9, 2024 by CacoKnight

[Alaux]

I've a feeling that you might be mistaking Woof (and Nugget)'s newly-implemented support for high, arbitrary resolutions as hardware rendering. That is not the case; they're unrelated concepts.

[CacoKnight]

Yep, I thought it was the exact same thing. GZDoom and DSDA are the only two that use "real" hardware rendering?

[Alaux]

4 minutes ago, CacoKnight said:

GZDoom and DSDA are the only two that use "real" hardware rendering?

Some other ports related to those two also support it, and there must be others, but I don't know much. What I can say is that Woof and Nugget do not have real hardware rendering.

[CacoKnight]

And that's why I keep all 3, GZDoom in Vulkan, DSDA in OpenGL and Nugget in whatever default you and fabian think is best. Thanks for the clarification and again sorry for the confusion and so many posts.

[Shepardus]

20 minutes ago, CacoKnight said:

Yep, I thought it was the exact same thing. GZDoom and DSDA are the only two that use "real" hardware rendering?

There's also DelphiDoom, Doom Legacy, Doomsday, EDGE-Classic, Helion, K8Vavoom, and Risen3D. And Zandronum and PrBoom+ if you consider them distinct from GZDoom and dsda-doom.

Edited March 9, 2024 by Shepardus
Missed a few

[Alaux]

11 minutes ago, CacoKnight said:

Nugget in whatever default you and fabian think is best

Nugget, and also Woof, always use a software renderer. I repeat, Nugget and Woof always use a software renderer. They have no other renderers, only a software renderer.

 

Basically, the never-changing software renderer generates the image, while the variable SDL render driver is merely what shows the image to you. GZ and DSDA use SDL too, so there's even a chance that while you might be using the OpenGL hardware renderer in them, they're actually displaying the image through an SDL render driver that's not OpenGL.

Edited March 9, 2024 by Alaux

[CacoKnight]

It's hard to understand the inside of how software really works when you're not a programmer and never really cared to be one, I am more on the servers, networking, security side of things. Let's say I like to beta test, play around with configs and ports etc.

 

That's another reason I was pushing to stick with OpenGL (or at least keep the setting in the .cfg file so people can easily test) even on Win and now I get it more that each system actually works better with different rendering API, I genuinely thought it was the whole thing that was switching and I would've picked FOSS instead of MS today.

 

Also funny I was just testing The Last Sanctuary and Nugget is clearly smoother than DSDA so go figure, wtf do I know :|

Edited March 9, 2024 by CacoKnight

[rfomin]

1 hour ago, Alaux said:

Basically, the never-changing software renderer generates the image, while the variable SDL render driver is merely what shows the image to you. GZ and DSDA use SDL too, so there's even a chance that while you might be using the OpenGL hardware renderer in them, they're actually displaying the image through an SDL render driver that's not OpenGL.

 

No, OpenGL rendering in DSDA-Doom and GZDoom only uses OpenGL to display the image. But otherwise you're right, that's why I think this "sdl_render" config setting is not important and just confuses people.

 

1 hour ago, CacoKnight said:

Also funny I was just testing The Last Sanctuary and Nugget is clearly smoother than DSDA so go figure, wtf do I know :|

 

In general the performance of Woof/Nugget/DSDA-Doom/PrBoom+ is very similar. The software rendering and playsim is almost the same (copied from MBF with some optimisations and fixes).

 

PrBoom+/DSDA-Doom in OpenGL mode is faster at high resolutions, but it's hard to emulate many classic software render quirks in hardware rendering (see this list for example: https://github.com/kraflab/dsda-doom/issues/338). For the latest Woof/Nugget, I recommend setting a reasonable resolution scale and enabling dynamic resolution. You'll get smooth performance in most places and it's hard to tell the difference from native resolution, to be honest.

[CacoKnight]

Am I doing something wrong? Dynamic ON looks worse than 400p:

 

 

[rfomin]

2 minutes ago, CacoKnight said:

Am I doing something wrong? Dynamic ON looks worse than 400p:

 

 

Perhaps it is 400p, dynamic resolution will reduce resolution to maintain the target framerate. What is your framerate limit? Monitor refresh rate?

 

To see the current resolution, use the IDRATE cheat code.

[CacoKnight]

Ohh I see, Dynamic is better with VSync off, monitor is 144Hz and to stay at ~144fps it goes down to exactly 400p yep but with VSync off it goes up to 800-900p. I'll keep VSync on and Dynamic off for now, I like it more that way.

[ceski]

@CacoKnight Some details in addition to what rfomin already said:

 

"Software" rendering in source ports means the CPU is used to execute drawing functions that are similar to the vanilla game but with some optimizations. The pixel data calculated by the CPU is then copied to a texture which is scaled by the renderer to fit the game window.

 

SDL handles the texture and renderer using the GPU, and that's where people get confused. The GPU is only used for blitting, scaling, and filtering at the very end of this rendering process (via SDL's "direct3d9", "opengl", etc. render drivers). The GPU isn't used for any of the initial pixel data calculations. So like rfomin said, there's no real benefit to changing the default SDL render driver and it can lead to compatibility issues.

 

Chocolate, Crispy, Woof, Nugget, DSDA (in "software" mode), and countless others all use this general approach to "software" rendering.

 

This is good and bad. It's good because it's accurate to the vanilla game. Sprites are drawn at the correct height without being clipped, colormaps behave correctly, translucent/reflective floor tricks actually work, and so on. But it's also bad because using the CPU to do this is slow and mostly single-threaded (working around this is why Rum and Raisin Doom is so interesting).

 

So what about "hardware" rendering in source ports (e.g. DSDA in "OpenGL" mode)? To keep it simple, separate drawing functions are required to take advantage of GPU processing and the results won't match "software" rendering. It's possible to get close with some clever workarounds, but there's a performance impact in doing so. Even then, there will be small differences such as the spectre effect and everything mentioned above.

 

[CacoKnight]

Damn fantastic explanation, it all makes much more sense now and I'm going to save this text. There are like 5-6 people in this forum that I think they are on another level and you're one of them 100%, I've been reading your stuff many times over for months now, also because of my English of course.

 

So, thank you so much for taking the time to all of you guys.

Edited March 9, 2024 by CacoKnight

[Meerschweinmann]

1 hour ago, CacoKnight said:

Ohh I see, Dynamic is better with VSync off, monitor is 144Hz and to stay at ~144fps it goes down to exactly 400p yep but with VSync off it goes up to 800-900p

 

You can optimise the dynamic resolution a bit when you cap the framerate for example at 105fps. It is three times of DOOMs original framerate and very smooth too. Then you have a constant framerate with higher resolution.

Edited March 9, 2024 by Meerschweinmann

[CacoKnight]

1 hour ago, Meerschweinmann said:

You can optimise the dynamic resolution a bit when you cap the framerate for example at 105fps. It is three times of DOOMs original framerate and very smooth too. Then you have a constant framerate with higher resolution.

Seeing from the tests I did I think VSync works best for me, I don't play much anyway, if I limit to 105 with VSync off it will struggle on big maps no? I noticed with Xonotic, I used to keep VSync off and limit at 480 but if I remove the limit some maps go up to 3000fps and yet, VSync at 144fps is just as smooth if not more.

 

Again, I'm not really a gamer so I'm doing all these tests for the first time kind of with Doom (I played HL2 some months ago and I just turned VSync on and that was it), I remember I read somewhere that if VSync is off then you should limit at Monitor Hz*2+some so like 300/320 in my case?

 

This is all good now I don't want to go too OT, that clarification on software, hardware, SDL was awesome.

Edited March 9, 2024 by CacoKnight

[Meerschweinmann]

1 hour ago, CacoKnight said:

I limit to 105 with VSync off it will struggle on big maps no?

 

If a limit of 105fps helps you that big maps don't struggle depends on your hardware and the map. The number 105 was only an example. You can set whatever you want.

It was only an idea because i read something about 144fps and 800-900p.

With 105fps cap in this case the resolution should go higher than 900p with a constant fluid framerate.

 

And when i get it right what you said that 144fps is just as smooth as 3000fps for you, i would say that is correct.

With 3000fps you are only burning electric energy, because you are the weakest part in this row. It is hard to notice a big difference above 144Hz as an adult.

Between 60 and above 100fps i find it really noticeable when turning around in games.

 

And that rule with montior Hz*2 has one big flaw. What is when your PC is not able to reach this framelimit?

With a freesync monitor that should be not a thing.

Edited March 9, 2024 by Meerschweinmann

[CacoKnight]

In the "Overlay Automap" I don't see any difference when changing from Off to On to Dark, I'm pretty sure I used to see it change, tested with the latest devs of Nugget and Woof!, same on both. I opened the Automap with TAB, went to settings and switched between those modes.

 

One more: Eternal Doom is not working with Nugget (some NULL error), haven't tried on Woof! but drag&drop the .zip to GZDoom and DSDA works fine.

Edited March 11, 2024 by CacoKnight

[Alaux]

1 hour ago, CacoKnight said:

In the "Overlay Automap" I don't see any difference when changing from Off to On to Dark, I'm pretty sure I used to see it change, tested with the latest devs of Nugget and Woof!, same on both. I opened the Automap with TAB, went to settings and switched between those modes.

I can't reproduce this on neither port. Could you share your .cfg?

 

Do note that if you have Menu Backdrop set to Dark, you won't see a difference between the On and Dark overlays. That's intentional.

 

1 hour ago, CacoKnight said:

One more: Eternal Doom is not working with Nugget (some NULL error), haven't tried on Woof! but drag&drop the .zip to GZDoom and DSDA works fine.

eternal.zip contains a NULL.WAD file, which Woof and Nugget error out to. Said file is empty, though, so you don't need to load it.

If you unzip eternal.zip and load just ETERNALL.WAD, it works fine.