When did pc's begin to handle all of zdooms' higher software resolutions?

[Spleen]

All of the resolutions? Can anyone run Sunder in software mode on a 4k monitor at a decent framerate yet?

[Reisal]

Spleen said:

All of the resolutions? Can anyone run Sunder in software mode on a 4k monitor at a decent framerate yet?

Why is that prBoom/prBoom+ can have an adequate framerate from Sunder and not the ZDoom ports?

[invictius]

Glaice said:

Why is that prBoom/prBoom+ can have an adequate framerate from Sunder and not the ZDoom ports?

From what I remember zdoom doesn't handle things too well. Same reason why nuts works fine in prboom.

[Graf Zahl]

Internally ZDoom is far more complex than PrBoom+. And with thousands of monsters this complexity simply adds up.

[Csonicgo]

Allow me to answer the question:

Depends on the port, depends on hand-tuned assembly, but I remember 233Mhz-300Mhz Pentium processors (with MMX) handling 640x480 , and even 800x600 at acceptable frame rates with ZDoom. my 500 Mhz Pentium III could handle up to 1024x768 on some maps, and 512x384 on maps with a lot of complexity (RTC-3057 comes to mind). GZDoom upped that even further, I was able to play those maps at the max resolution of my monitor with little issue. Note that I always maxed out the L2 cache on these boxes, so that might've helped too.

Spoiler

As for the Raspberry Pi, the multi-core Pi 2 and higher can handle up to SXGA resolutions with little issue (1280x1024), the Pi 1 B+ can handle up to 800x600ish if using timidity or something for midi and not OPL synth. As the Pi only has one processor core, it can get a little sluggish at times.

Ideal resolutions for these (that I play at personally)
For 35 fps capped:
Pi 1: 640x400
Pi 2: 800x600
Pi 3: 1280x1024, 1024x768

A Pentium MMX 233 should be able to play ZDoom at 800x600 at "acceptable" framerates, 640x480 if you want 60fps. my Pentium II 300 MHz laptop can run the ZDoom at its max res (800x600) at 60 fps, no problems. It's much faster than Doom95 ever was, that's for sure.

So if you want a year, I'd say...1999,2000-ish? If the map wasn't a detail-fest like Gothic99, that is.

EDIT: Before anyone points it out, yes, I did have a 300MHz Pentium MMX in a laptop. I realize they are very rare, but they do exist.

[kb1]

invictius said:

From what I remember zdoom doesn't handle things too well. Same reason why nuts works fine in prboom.

Graf Zahl said:

Internally ZDoom is far more complex than PrBoom+. And with thousands of monsters this complexity simply adds up.

And, with that assessment, you cut ZDoom short. There are plenty of situations where ZDoom blows the doors off of anything else in regards to speed. There are a million variable differences in the source which cause miniscule differences in performance between both ports.

For example, ZDoom has a very specialized renderer that greatly reduces cache issues when rendering the screem. Conversely, due to ZDoom's awesome editing capabilities, the code has to do a lot of additional tests that aren't required in other ports (because those other ports aren't as flexible).

On a purely vanilla map, PrBoom+ wins often. But, on a map with sloped surfaces, 3d floors, and scripting, ZDoom is infinitely faster, because PrBoom+ cannot play the map at all :)

Just being able to compare apples to apples is extremely difficult: Same map, same video and sound technologies and settings, same gameplay settings - there's a lot of setup to really be able to do justice to a scientific side-by-side comparison. Most likely, any significant difference is due to a very small handful of differences in how one port does something vs. the other. Good luck finding them!

Csonicgo said:

Allow me to answer the question:

Depends on the port, depends on hand-tuned assembly, but I remember 233Mhz-300Mhz Pentium processors (with MMX) handling 640x480 , and even 800x600 at acceptable frame rates with ZDoom. my 500 Mhz Pentium III could handle up to 1024x768 on some maps, and 512x384 on maps with a lot of complexity (RTC-3057 comes to mind). GZDoom upped that even further, I was able to play those maps at the max resolution of my monitor with little issue. Note that I always maxed out the L2 cache on these boxes, so that might've helped too.

Spoiler

As for the Raspberry Pi, the multi-core Pi 2 and higher can handle up to SXGA resolutions with little issue (1280x1024), the Pi 1 B+ can handle up to 800x600ish if using timidity or something for midi and not OPL synth. As the Pi only has one processor core, it can get a little sluggish at times.

Ideal resolutions for these (that I play at personally)
For 35 fps capped:
Pi 1: 640x400
Pi 2: 800x600
Pi 3: 1280x1024, 1024x768

A Pentium MMX 233 should be able to play ZDoom at 800x600 at "acceptable" framerates, 640x480 if you want 60fps. my Pentium II 300 MHz laptop can run the ZDoom at its max res (800x600) at 60 fps, no problems. It's much faster than Doom95 ever was, that's for sure.

So if you want a year, I'd say...1999,2000-ish? If the map wasn't a detail-fest like Gothic99, that is.

EDIT: Before anyone points it out, yes, I did have a 300MHz Pentium MMX in a laptop. I realize they are very rare, but they do exist.

Those are respectable numbers for those machines. You mentioned cache: There used to be a big issue with 1024x768, as the horizontal resolution of 1024 wreaked havoc with the processor's cache, because fo the power-of-two thing. I think it was Entryway that discovered that, if he made his internal buffers just a bit bigger (1028), he could get a LOT more performance, by "tricking" the cache subsystem to stop flushing so frequently. Amazing stuff.

It's simple things like that that make certain ports have speed advantages, but usually only in very specific circumstances.

[Graf Zahl]

kb1 said:

And, with that assessment, you cut ZDoom short. There are plenty of situations where ZDoom blows the doors off of anything else in regards to speed. There are a million variable differences in the source which cause miniscule differences in performance between both ports.

For example, ZDoom has a very specialized renderer that greatly reduces cache issues when rendering the screem. Conversely, due to ZDoom's awesome editing capabilities, the code has to do a lot of additional tests that aren't required in other ports (because those other ports aren't as flexible).

That's what I meant by being more complex. Since ZDoom needs to calculate a lot more stuff to do its monster AI this will naturally have an effect on monster heavy maps, which this was all about.

Of course I profiled this code to see what's up, but in the end it was simply that functions like P_TryMove or PIT_ChangeThing need to do a lot more to handle all those added features.

[Maes]

I take that those numbers are for vanilla maps, or PWADs of about that level of complexity. I'd like to point out that older versions of ZDoom at least had strange issues with loading PWADs (ANY PWAD, even one that changed e.g. a single sound or graphic) that somehow resulted in a severe speed penalty. I don't know if that's still the case, or it only appeared on a very specific build (e.g. the infamous 2.0.47).

[Graf Zahl]

I wonder where you get this nonsense. Can you point out some source for that claim? It probably was just related to some semi-broken system setup.

[Maes]

I had documented it ages ago in one of my Pentium box build threads in Blogs (?). Feel free to search for them, even though they probably carry no value as bug reports anymore. And it's not the first time you threw a fit about them, either.

The gist of it was that the combination of Windows 98 + some shit-old version of ZDoom I just happened to use on a Pentium I system, exhibited this weird bug. Not Prboom or Prboom+, not Doom95, just ZDoom, on the same system.

[Graf Zahl]

As expected: It was an isolated occurence on an out-of-date system, not some general occurence, like you made it sound.

[Fonze]

Graf Zahl said:

As expected: It was an isolated occurence on an out-of-date system, not some general occurence, like you made it sound.

Maes said:

I don't know if that's still the case, or it only appeared on a very specific build (e.g. the infamous 2.0.47).

*Edit*

v Aha interesting. Thanks for the clarification.

[Graf Zahl]

He made it sound like some old build had this as a general problem, but as it turned out it was just an old computer.

In that context it is irrelevant if he says 'may just have been an old version.' No old version had this problem on anything that could be considered up-to-date hardware at its time.

[Maes]

Still, it would be worth investigating what part of the WAD handling code could result in a quite measurable overhead on a Pentium-class system, even if only triggerable under very specific circumstances. After all, if such an overhead was confirmed to exist, it would be present even with a more powerful CPU, but instead of sapping e.g. 40% of CPU time as it did on a Pentium-200, it would sap only 5% or 10%.

[Graf Zahl]

I still say that the problem existed on that computer, not in ZDoom.

[CODOR]

Csonicgo said:

A Pentium MMX 233 should be able to play ZDoom at 800x600 at "acceptable" framerates,

This was my experience; one of these was my primary system from 1997-2002 and a backup of zdoom.cfg (last modified in 2000) shows that I was running at 800x600.

[kb1]

Graf Zahl said:

That's what I meant by being more complex. Since ZDoom needs to calculate a lot more stuff to do its monster AI this will naturally have an effect on monster heavy maps, which this was all about.

Of course I profiled this code to see what's up, but in the end it was simply that functions like P_TryMove or PIT_ChangeThing need to do a lot more to handle all those added features.

Sorry, Graf and invictius - I was trying to reply to Glaice...

Glaice said:

Why is that prBoom/prBoom+ can have an adequate framerate from Sunder and not the ZDoom ports?

...but, I quoted invictius's reply to Glaice mistakenly, and I quoted Graf's response as well. Both were related, but it was confusing who I was replying to.

Anyway, as you said, Graf, enhanced monster AI means more conditional branching in the code, which means slower run times, especially on monster heavy maps.