The NUTS Debacle

[Voros]

NUTS is notorious for its nests of demons. It's so noxious that it spawned sequel of equally nondescript quality, namely NUTS2 and NUTS3.

Which NUTS did you like the most? The original for being plain and simple? The 2nd and/or 1st Anniversary Gold Plated Plutonic Aloy Coated Eight volume Nuclear Donkey Edition for the smallest number of enemies present out of the whole trilogy? The final instalment for its triple nuts and double mongooses?  

I only like NUTS2 because NUTS is too much while NUTS3 is even more too much. NUTS2's subtitle is epic, there are fake Mancubi here, Chaingunners look like Megaspheres and the shotgun looks like BFG even though it isn't. What isn't there to like here?

Edited August 14, 2017 by Voros

[Traysandor]

You can't beat the original NUTS.wad - it far and away blows the other two out of the water when it comes to the impact it had at the time it was released, and even to this day. Not even highly optimized source ports can come close to handling it, but it's mostly because Doom itself is trying to do way too much at once and can't handle the thousands of monsters at once, thus slowing the game to single digit frames per second (And often it's less than 1 FPS). One time I used the Doom 4 Doom mod on it and fired the Doom4 BFG... 5 minutes later, the engine rendered maybe a handful of frames at best.

 

Sure, it is technically possible to beat them all, but only if you turn off infinite actor heights and employ a don't shoot anything tactic (If you need to run around, let the monsters do the infighting for you)

 

The NUTS series also why most later slaughtermaps that came after its release have their monster counts distributed differently. Sure, someone can make a map with 5,000 monsters, but the secret to keeping it running is never to have more than a few hundred active and in the vision of the player at once.

[Edward850]

49 minutes ago, Traysandor said:

Not even highly optimized source ports can come close to handling it

Lol wut. PRBoom+ handles it perfectly, while Eternity isn't far behind (I suspect it has some hidden costs in its rendering that's giving away too much CPU time). ZDoom-based are the only ones that have serious problems with it.

Edited August 14, 2017 by Edward850

[CapnClever]

Can't say I have a favorite, but NUTS3.WAD gets points for actually pretending to be something:

 

 

I don't think BPRD had that in mind when making the original, though. These days they (but typically NUTS.WAD) are just used as stress-testers and, although they can be beaten, I wouldn't recommend playing the map for any other purpose.

 

---

 

EDIT: Was able to find frame counters for every port (thanks fabian and Voros) so a few values have been rewritten. Also added glboom-plus, since it's pretty different from prboom-plus.

EDIT2: Better frame counter for Eternity Engine (thanks Litrivin).

 

On the matter of stress-testing, I decided to explore a few source ports to see how they stack up. This isn't a formal review by any means, but I thought it was worth checking out the capacity of various ports using my 2011 machine (8GB RAM, Intel i5-2400; with a GeForce GTX 650 Ti added a couple years later). Video resolution will be 1024x768 or the closest thing to it.

 

I used four points of interest:

1. Standing at the starting point. You wouldn't expect any massive rendering problems here, though viewing thousands of enemies simultaneously in a large room should probably cause a hit at some level.
2. Making a shot from the standing point. This wakes up all the enemies and causes immeasurable projectiles to come flying at the player. I turn on Degreelessness and Noclip modes so I can stand still while all the projectiles show up.
3. Running through the enemies to the mid-level. This is primarily to test a situation in which a lot is happening in-game and on the screen, but without all those projectiles at once.
4. Turning around at the mid-level point. Fewer projectiles than #2, but thousands of moving enemies to render at once.

 

All ports I've tested here have a frame counter: accessing it will be mentioned alongside the data for those interested in stress-testing. (There may be multiple ways to do so, I explain but one.)

 

Now, onto the data:

• Crispy Doom is probably the closest thing to vanilla that can actually play NUTS.WAD with modern computer resources.
  • Type SHOWFPS in-game (as you would IDDQD) to bring up the frame-counter.
  1. Standing point shows 236fps
  2. Shooting at standing point goes as low as 115fps
  3. Running through enemies quickly rises to 200fps
  4. Watching the level is around 170fps
• Doom Retro does quite well for itself, which makes sense given it's forked from Chocolate Doom as well.
  • Access the console and type vid_showfps on to bring up the frame-counter.
  1. Standing point shows 264fps
  2. Shooting at standing point eventually dips to 80-85fps, but doesn't stay there (due to enemies dying in the time it takes to get to it)
  3. Running through enemies goes towards 120fps but quickly rises
  4. Watching the level bottoms out at 100fps
• PrBoom+ does see some drops, though nothing completely unplayable:
  • Type IDRATE in-game (as you would IDDQD) to bring up the frame-counter.
  1. Standing point shows 152fps
  2. Shooting at standing point goes as low as 27fps
  3. Running through enemies is about 60fps
  4. Watching the level stays around 75fps
• GlBoom+ uses a hardware renderer so it's different enough to compare against PrBoom+:
  • Type IDRATE in-game (as you would IDDQD) to bring up the frame-counter.
  1. Standing point shows 460fps
  2. Shooting at standing point lowers to 140fps briefly
  3. Running through enemies is 200fps and quickly rises
  4. Watching level steadies out at 170fps
• Eternity Engine is a fair bit slower than PrBoom+, though nothing that'd hit single digits
  • Access the console and type d_drawfps on to bring up the frame-counter.
  1. Standing point hovers at 172fps
  2. Shooting at standing point drops to 25fps
  3. Walking through monsters rises back to 45fps
  4. Watching the level normalizes at 65fps
• GZDoom has two renderers and they both rate a little differently:
  • Access the console and type vid_fps 1 to bring up the frame-counter.
  1. Starting point: software at 40, hardware at 50
  2. Shooting at starting point: software at 5, hardware at 4-5 briefly but mostly 6-7
  3. Running through enemies: software around 12, hardware in 6-7 range
  4. Watching level: software around 17, hardware around 15
• Risen3D has some high highs and low lows:
  • Access the menu and select Options > Video > Enable FPS Counter to bring it up. Turn off vsync for values beyond 60fps.
  1. Starting point plays at 184fps
  2. Shooting at starting point quickly drops to 3fps but holds there
  3. Running through enemies was also a constant 3fps: I could visually tell it was displaying at that rate, so it checks out.
  4. Watching level started at 7fps but quickly rose to 30fps within 5-10 seconds.
• 3DGE acts oddly, with large pauses at times:
  • Access the menu and select Options > Video Options > Framerate Counter to bring it up.
  1. Starting point is around 60fps
  2. Shooting at starting point drops as much as 5fps, though the game itself freezes frequently
  3. Running through enemies is more like 10fps, with fewer freezes
  4. Watching level stays around 10fps as well
  • This one's definitely unplayable, if only because the engine itself can't act smooth (even the music pauses).
• Doomsday chugged far more than any other.
  • Access the menu and select Options > Show Taskbar, then click Gear > Video > Show FPS to bring up the frame counter.
  1. Starting point is already 4-5fps
  2. Shooting at starting point quickly rock-bottomed to 0.2fps
  3. Running through monsters and watching level were also 0.2fps

 

It's important to note that the data's based on my exact own settings on a fairly old machine, and while it might be marginally useful qualitatively, it's not indicative of what the causes of these drops are. For example, it's well-known that GZDoom uses stuff like DECORATE and ZScript to allow for custom actors, but the framework in which these tools perform is more compounded and therefore eats up processing power, causing the overall game to slow down. There are many ways the code may be unoptimized, or it could already be very optimized but simply unable to work under such radical conditions: the outcome depends on what the port strives to do as much as what it does. I thought it was interesting how they measured up to each other, though that's about it.

Edited August 18, 2017 by CapnClever
new data for Eternity Engine with better in-game frame counter

[Edward850]

12 minutes ago, CapnClever said:

Crispy Doom is probably the closest thing to vanilla that can actually play NUTS.WAD with modern computer resources.

What kind of CPU do you have? I only have a mid range i3 6100 and it runs nuts.wad on PRBoom+ at 60FPS (interpolation on of course) without hesitation at all times. The 6100 is actually from the last generation sockets, which makes me suspicious about what your hardware is.

12 minutes ago, CapnClever said:

Eternity Engine is a fair bit slower than PrBoom+, though nothing that'd hit single digits

As a neat trick, boot it with -vanilla -warp 1 to disable all the MBF stuff.

Edited August 14, 2017 by Edward850

[CapnClever]

12 minutes ago, Edward850 said:

What kind of CPU do you have? I only have a mid range i3 6100 and it runs nuts.wad on PRBoom+ at 60FPS (interpolation on of course) without hesitation at all times. The 6100 is actually from the last generation sockets, which makes me suspicious about what your hardware is.

Intel i5-2400

 

Out of curiosity, how do you know it runs at 60fps smoothly? I freely admit the method I used for ports that lack a frame counter is sketchy: the fact that I'm recording using an external program at 120fps puts its own strain on my machine and could therefore introduce frame drops regardless of the game. If you have a better way to verify I'd be glad to try it myself and re-perform the evaluation.

[Edward850]

I was using Nvidia Shadowplay's overlay performance counter. As everything it does (including recording) is on the GPU, it has a very minimal impact on Doom's playsim performance on the CPU. Mind you it can't record at 120FPS.

It also helps to be sure that you are running an OpenGL surface (check the video options), to make sure you aren't spending a lot of CPU time on software page flipping.

Edited August 14, 2017 by Edward850

[Memfis]

NUTS is a single joke.

NUTS2 is a few jokes.

NUTS3 is an art object.

[Voros]

I hate NUTS3's skybox. It's blinding to look at. Or maybe that's considered art these days.

[Coraline]

If you're running a fairly powerful machine, EDGE can achieve a semi-constant framerate:

 

 

 

[fabian]

On 14.8.2017 at 11:25 AM, CapnClever said:

For ports lacking a frame counter (underlined for reference),

But Crispy does have a built-in frame counter, just type the SHOWFPS "cheat" in-game.

[Voros]

And type in IDRATE in PrBoom+.

[CapnClever]

Retested and rewrote data given for ports that previously did not use in-game frame counters, as I managed to find a means to bring one up for each of them (thanks fabian and Voros). Eternity Engine's only goes to 35fps for some reason? I made sure to turn on Uncapped Framerate and Interpolation to be sure, might've missed something else that's critical.

 

I don't doubt that better machines can handle some ports far better than mine can. If you're interested in performing this yourself, as a way to compare ports on your machine, I implore you to do so. More data is generally a good thing.

[Diabolución]

3 hours ago, CapnClever said:

Eternity Engine's only goes to 35fps for some reason? I made sure to turn on Uncapped Framerate and Interpolation to be sure, might've missed something else that's critical.

 

v_ticker is obsolete, d_drawfps is the proper command.

 

https://forum.zdoom.org/viewtopic.php?p=563008#p563008

 

“v_ticker command shows the speed of the gameloop which will lock at 35 fps. d_drawfps is a newer command however, and it will show you the actual frames per second being rendered to the screen (ie. iterations through D_Drawer per second).”

[CapnClever]

19 hours ago, Litrivin said:

v_ticker is obsolete, d_drawfps is the proper command.

Thanks for the info! That's not on their wiki at all so I never would've found it myself.

 

Main post's been updated with more accurate Eternity Engine fps readouts.

[invictius]

On 8/14/2017 at 7:25 PM, CapnClever said:

Can't say I have a favorite, but NUTS3.WAD gets points for actually pretending to be something:

 

 

I don't think BPRD had that in mind when making the original, though. These days they (but typically NUTS.WAD) are just used as stress-testers and, although they can be beaten, I wouldn't recommend playing the map for any other purpose.

 

 

What wad is that skybox from?

[Varis Alpha]

it's from Nuts 3. i'd guess it's an original work by B.P.R.D himself, since his WADs often had custom textures and resources in them of pretty good quality.

[NinjaLiquidator]

Not even one. All effortless, I can copy-paste in things mode too...

[Degreelessness Mode ON]

NUTS 1 and 2 are basically just gags designed to make people go... well, nuts. Kind of like all those Mario Maker stages that are just 100 Bowsers on rails with bullet bills everywhere. The third is a legitimate challenge map that can be beaten through very skillful use of infighting and projectile leading.