What year will NUTS first be able to run smoothly on home computers?

[NaturalTvventy]

Just for fun, I saw this thread and it made me wonder, when will people be able to play NUTS on their desktop lag-free, without the massive framerate drop? (I'm pretty sure it's not now though I don't have any sort of modern gaming setup.)

 

Record your guess/prediction here and then if you happen to be right when the time comes you can print this thread out and hang it on your wall. I'm guesstimating 2021.

[Memfis]

More than 10 years ago I think.

[NaturalTvventy]

7 minutes ago, Memfis said:

More than 10 years ago I think.

Damn, I was afraid of that.

[40oz]

9 minutes ago, Memfis said:

More than 10 years ago I think.

Does it work smoothly for you? I haven't tried it in many generations of computers ive owned but I always imagined the massive lag spike of that many active a_chase sequences at once had to do with the game choking on itself than the processing power of the computer running it.

 

edit: I guess were really dating ourselves, huh?

[Programme]

I don't think hardware is the problem. I think Doom literally cannot handle that many enemies at one time.

 

But anyway it's probably 2024 or something

[SaladBadger]

I think one of prBoom+'s claims to fame is that it could run Nuts fairly well, since it is actually fairly efficient. More complex ports, though, its still a bit of a nightmare though. I remember nuts was one of the things Randi was using to test the garbage collector in zdoom, and it increased the performance of simulating all the objects considerably (but rendering was still bad), but even with it there's still lots to be desired in ZD.

[Sergeant_Mark_IV]

Anytime when Graf finds out how to make GZDoom use more than 10% of a CPU's power, or maybe actually use the GPU. And that probably means never.

[kb1]

22 minutes ago, Sergeant_Mark_IV said:

Anytime when Graf finds out how to make GZDoom use more than 10% of a CPU's power, or maybe actually use the GPU. And that probably means never.

That was quite unnecessary. Low CPU usage suggests an efficient design.

 

Nuts runs smoothly for me. The non-obvious issue was a bug in a thinker list implementation in MBF. PrBoom+ fixed that a couple of years ago, as did some other ports.

 

Doom's AI is quite efficient. The frame design creates an natural interleave effect, causing monster AI to be distributed across multiple tics. Stated differently, for a given tic, only a percentage of monsters are actually "thinking", which helps keep the action smooth. Raising the frame rate (interleaving) works against this considerably, causing the renderer to run at full speed.

[Sergeant_Mark_IV]

32 minutes ago, kb1 said:

Low CPU usage suggests an efficient design.

If the game is running at seconds per frame while the rest of the system is still perfectly capable of using the idle power to run Witcher 3 in the background, I think there might be something wrong there. So, to answer OP's question, raw cpu power is useless if the program is not optimized to make use of said power.

Edited August 18, 2017 by Sergeant_Mark_IV

[Grazza]

I believe the correct answer is 2004.

 

[kb1]

4 hours ago, Sergeant_Mark_IV said:

If the game is running at seconds per frame while the rest of the system is still perfectly capable of using the idle power to run Witcher 3 in the background, I think there might be something wrong there. So, to answer OP's question, raw cpu power is useless if the program is not optimized to make use of said power.

You are defending that statement? What, do you think you can just pour a little CPU here and there to correct a GL issue? A better answer is that raw CPU power is useless to cure a GL issue. Why would you think offloading graphics tasks to dedicated graphics hardware could be expedited by asking the CPU to do extra work?

 

I'm pretty sure I know what you were intending to say, but that ain't what you said. Instead, you just chucked out a baseless insult. Which was unnecessary. Which was a nice way to describe it.

 

... "Anytime when Sergeant_Mark_IV finds out how to make nice posts by using more than 10% of ..." heh.

[Linguica]

I just ran nuts.wad with a DSDA timedemo on my base level 2015 Macbook Pro and got 58 FPS. So I'd say we're well past the point of being able to runs Nuts smoothly.

[Edward850]

Do people constantly think that ZDoom is the only source port family that exists? Nuts has been a problem long solved in other ports, explained in the very thread the OP linked. This is getting silly.

[Voros]

Along with NUTS, there's also 100,000 Revenants and Infinite Revenants. I'd like to see some analysis on how those two run on other ports.

[Graf Zahl]

9 hours ago, Sergeant_Mark_IV said:

Anytime when Graf finds out how to make GZDoom use more than 10% of a CPU's power, or maybe actually use the GPU. And that probably means never.

 

It seems you do not really know how modern CPUs work. Windows reports CPU load across all cores, so on a 4 core CPU with hyperthreading one core equals 12.5%. Now for the problem: Doom is a deterministic engine, i.e. all operations need to be run in sequence. This unfortunately limits the game to one thread, i.e. one core and will most likely hover between 12.5 and 20%, depending on how many threads other subsystems use.

 

And why is ZDoom slower than PrBoom? Well, for the simple reason that the engine is a lot more complex than PrBoom or other more basic ports and has higher overhead for checking all those 10000 monsters.

[kb1]

Comparing port performance levels is really an apples vs. oranges ordeal anyway. Doom has hundreds of functions, and dozens of subsystems, with performances that vary by port, by level, and by the hardware the game is running on, and a bunch of other factors. Any given function may run faster or slower than that same function in a different port, different map, different processor, graphics card, memory configuration, user setting profile, etc. Furthermore, the performance of the entire game can be compromised by a single function, that happens to be written differently in one port vs. another. And, the kicker: That same function may be faster than the others on a different map.

 

Saying that one port runs slower than another is generally meaningless, without also providing version numbers, hardware specs, map specs, all user settings, etc. And, even then, the problem could be a graphic card driver, or sound card driver that this port happens to use vs. another.

[Nevander]

12 hours ago, Graf Zahl said:

And why is ZDoom slower than PrBoom? Well, for the simple reason that the engine is a lot more complex than PrBoom or other more basic ports and has higher overhead for checking all those 10000 monsters.

Is this because PrBoom doesn't support DECORATE/ZScript and a handul of other monster/weapon changing lumps? In other words, PrBoom just needs to concern itself with running the vanilla actors?

[PotatoWater]

As soon as we develop computers capable of actually making portals to hell, THEN we can run NUTS at 60fps

[Edward850]

7 minutes ago, PotatoWater said:

As soon as we develop computers capable of actually making portals to hell, THEN we can run NUTS at 60fps

Uhh... You might want to actually read the thread. Again, Nuts is long since solved.

[PotatoWater]

Just now, Edward850 said:

Uhh... You might want to actually read the thread.

I did. It's a joke.

[kb1]

4 hours ago, Nevander said:

Is this because PrBoom doesn't support DECORATE/ZScript and a handul of other monster/weapon changing lumps? In other words, PrBoom just needs to concern itself with running the vanilla actors?

DECORATE itself adds absolutely no overhead during gameplay - it simply fills the already-existing data tables a different way. Now, if a map's monsters are causing scripting code to be run during gameplay, that does have the potential to add some overhead. But, NUTS.WAD is using original monsters, so scripts are not required there.

 

What I was trying to say above is that it is very difficult to point to any one specific reason a map like NUTS.WAD might be slower at times, in one port vs. another. Support for additional gameplay features may be a culprit. A user setting might be behind it. Specifically in the ZDoom family, one example possibility is the over/under code from Heretic that allows monsters to cross over/under each other. I have no idea if this causes ZDoom any slowdowns, but it is an example of extra gameplay functionality available in ZDoom that has the potential for additional slowdown, as a tradeoff for the extra freedom of movement it provides, which would be sorely missed if it were not present.

 

On the other hand, ZDoom may execute faster line-of-sight checks, due to its use of Heretic-like sight code. This is the nature of comparing ports - it's a complicated calculation that changes dynamically as the game plays.

[Linguica]

7 hours ago, kb1 said:

Comparing port performance levels is really an apples vs. oranges ordeal anyway.

I would argue that comparing different programs playing the exact same level in the exact same game on the exact same machine is just about the most apples to apples comparison you could possibly have?

[Edward850]

4 hours ago, PotatoWater said:

I did. It's a joke.

Poe's law something something 

[Doomkid]

Video proof of nuts running smoothly

 

 

[SavageCorona]

GZDoom caps out at 200fps for me and nuts only tanks it down to about 70-100ish so ¯\_(ツ)_/¯

[Graf Zahl]

On 19.8.2017 at 0:42 AM, Nevander said:

Is this because PrBoom doesn't support DECORATE/ZScript and a handul of other monster/weapon changing lumps? In other words, PrBoom just needs to concern itself with running the vanilla actors?

 

No, the main reasons are support for slopes, 3D floors, portals, Heretic and Hexen features and other options ZDoom provides. If you compare some of the core movement functions you'll see that ZDoom's variants are a lot larger because all these things need to be checked as well. And even though for single actors it's not noticeable, when having 10000 monsters and their projectiles active at the same time, stuff will just add up.

[printz]

Most wads aren't like NUTS anyway, so this race for power makes me feel uneasy that I'll NEVER be powerful enough.

[kb1]

On 8/19/2017 at 0:06 AM, Linguica said:

I would argue that comparing different programs playing the exact same level in the exact same game on the exact same machine is just about the most apples to apples comparison you could possibly have?

Yes, for that one map. On another map, it could go either way. It's not definitive. But, you're right, in that it's all we have. Unless, of course, you take averages across tons of maps, with all ports setting similar compatible settings, and the others set to "least interference". Because, even with a suite of maps, there could be one single setting that pushes one port over the edge in either direction. Even with same PC, same map, it's generally just an approximation, without extensive knowledge of each port's settings.

[Sergeant_Mark_IV]

On 8/19/2017 at 0:37 AM, kb1 said:

Now, if a map's monsters are causing scripting code to be run during gameplay, that does have the potential to add some overhead.

Does that includes ACS scripts?

[Edward850]

3 hours ago, Sergeant_Mark_IV said:

Does that includes ACS scripts?

By the fundamental concepts of computational processing, yes doing more processing does indeed require more processing time. It's not even a "potential", it's an absolute. There is no free lunch to computing.

 

Having scripts, any scripts, do additional work for each enemy will have a logical increase of cost at n*o (n being enemy count and o being processing cost of the tasks).