stres test?

what port(s) can I use to test how fast a given pc/video card will run doom? Excluding running nuts.wad of course, since that isn't really quantifiable (e.g meant to be slow all the time, and no pc I've ever owned has ran it beyond a few fps anyway)

Testing video cards only makes sense with hardware accelerated rendering.

Aside from that, I can't give any recommendations. Ports behave differently so you have to test them all - at least those with uncapped frame rate.

Testing a port locked to 35 fps won't give you any useful information because most of the time is lost waiting.

Try playing some of the older versions of Brutal Doom, The sheer amount of sprites and decals on the screen at once is sure to slow most computers to a complete stop

sgt dopey said:

Try playing some of the older versions of Brutal Doom, The sheer amount of sprites and decals on the screen at once is sure to slow most computers to a complete stop

Some of that will be video related but lots of actors can slow things down even if they aren't on screen because the engine has to keep track of them all.

You can show this with WADs like "Nuts" or "Helm's Deep" where, even if you get yourself to a place where all you are looking at is a wall, you can still experience significant slowdowns on some machines once all the actors are moving around.

Even a level with lots of enemies will slow down dramatically if you have a gore mod loaded and (in ZDoom) you type "kill monsters" at the console from the player start point. You may not see a single one of the monsters dying but all the gore flying around throughout the level can slow things to a crawl.

invictius said:

what port(s) can I use to test how fast a given pc/video card will run doom? Excluding running nuts.wad of course, since that isn't really quantifiable (e.g meant to be slow all the time, and no pc I've ever owned has ran it beyond a few fps anyway)

What are you talking about? Nuts.wad is an excellent test of the overall speed of a source port and, by extension, of its runtime environment (or lack thereof). For example, it taxes the gameplay code with thousands of objects to update and literally tens of thousands of projectiles spawning and being destroyed at every frame, thus putting cache coherency, memory allocation and garbage collection (if present) to the test.

The rendering code is also taxed heavily for obvious reasons, though it's very biased towards sprite rendering + sorting, not much to show off map geometry-wise.

Still, put these two together, and you have a pretty awesome gaming benchmark which focuses purely on the CPU and how well it can do logic + awkward graphics pushing, without any candy-ass hardware rendering.

And, if you use a recent build of ZDoom and any prBoom+ build made in the last 4 years (WITHOUT MBF friend code on), nuts.wad should be perfectly playable on anything with the "Pentium 4" logo on it. Hell, it's even playable in Mocha Doom, and even rivals certain prBoom+ releases sometimes (I suspect that Java's built-in garbage collection gives it a slight edge in such degenerate situations).

Maes said:

And, if you use a recent build of ZDoom and any prBoom+ build made in the last 4 years (WITHOUT MBF friend code on), nuts.wad should be perfectly playable on anything with the "Pentium 4" logo on it. Hell, it's even playable in Mocha Doom, and even rivals certain prBoom+ releases sometimes (I suspect that Java's built-in garbage collection gives it a slight edge in such degenerate situations).

I must be doing it wrong. Latest build of zdoom on a 3ghz dual core system, nuts slows down to a crawl the instand I fire a weapon and the monsters "wake up". This is running in 640x480, too.