Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Average

Fasted Engine These Days?

Recommended Posts

If memory serves ZDoom was considered to be the fastest (least resource intensive) engine in the past. Is that still the case?

Over the past couple of years there have been a number of new engines as well as a lot of development on the stalwarts. Are any of these more efficient than ZDoom?

The reason I ask is mostly just curiosity but partly because I'm looking for the best engine for my netbook (AMD C-50).

Share this post


Link to post

Whatever you mean by "least resource intensive", I'm pretty sure that PrBoom-plus/GlBoom-plus are faster than ZDoom, if only because they're well optimized for what they have, and their range of features/flexibility is lesser than ZDoom's and therefore less burdening on the engine.

Share this post


Link to post
Average said:

If memory serves ZDoom was considered to be the fastest (least resource intensive) engine in the past. Is that still the case?

I don't think this was ever the case. Prboom/glboom has always been faster, it probably still is the fastest.

Share this post


Link to post

Heh heh, Zdoom the fastest engine?
Lol very much, but no, Zdoom is not the fastest engine, PRBoom/GLBoom as mention above is much faster than Zdoom and that is because you can run slaughter megawads at a stable framerate, whereas in Zdoom you'll run at a slower framerate.
Just keep in mind, Zdoom mods won't work on any other source port other than Zdoom, GZDoom or Zandronum.

Share this post


Link to post

For pure rendering, ZDoom is the fastest in the "software" category and GLBoom+ the fastest in the "OpenGL" category.

If you add in mobj processing, then PrBoom+ is faster than ZDoom. Something like nuts.wad will be greatly faster on PrBoom+ than on ZDoom once the monsters have been awakened.

Share this post


Link to post

^ I doubt it works like that ("the simplest must be the fastest"). I'm not sure if current Chocolate Doom even uses Lee Killough's game logic optimizations, respectively which ones and which not. For one oddity, Chocolate Doom actually renders each tic twice. I also read somewhere that Chocolate Doom spends some processing power on resizing a 320x200 screen buffer onto a 640x400 actual screen window. Also see this post and the following two, where fraggle himself admitted that Chocolate Doom was generally unoptimized (that was posted almost 4 years ago, though).

Share this post


Link to post

The Boom optimizations can make quite a difference so it's conceivable that a Boom-based engine without any of the compatibility cruft that's needed for demos would be the fastest around.

ZDoom adds a lot of complexity which of course affects performance. You still need multi-1000-monster slaughtermaps to see the difference, though.

Share this post


Link to post

On modern Windows systems PrBoom+ seems to be the fastest for me on maps with lots of detail or high thing counts. I don't think Chocolate Doom is that fast since it's not optimized. This is probably a good thing because adding optimizations might break some compatibility with the original executables.
I only use GL ports when they are required for a mod so I haven't really tried GLBoom enough to compare it to GZDoom.
I have no idea what port would be fastest on Linux or a Mac. Probably still some form of Boom.

Share this post


Link to post

Chocolate Doom doesn't need optimizations since it cannot run complex maps anyway. Also, it does not benefit from higher framerate than 35, the resolution is the same etc :-D

Share this post


Link to post

Yeah ChocoDoom only needs to put out 320x200x35 pixels per second. A port with uncapped framerate and high resolutions will require more optimization. You need about 52 times as much processing power to output 1600x1200x60 pixels per second. Now factor in the needs of much larger maps (limit-removing) with transparency (Boom) and 3D floors (ZDoom) and a grossly inefficient rendering process that is still fast enough for a post stamp-sized window may no longer be enough.

Share this post


Link to post

KBDoom is pretty darn good in the frame rate department, if I may say so. On the list of priorities, engine speed comes in right after compatibility, and code-readability. One day, maybe, I can prove it - by releasing my source. It still has quite a few features that I have yet to see in any other port.

KBDoom's speed comes from literally hundreds of tiny optimizations, some mine, many from other ports. The biggest targets are: the software renderer, renderer frame prep, mobj update, line-of-sight checks, lump management, sound prioritization, lean netcode, and memory management. Once you get those reasonably fast, it becomes a bit more tricky to find things that are both cleanly optimizable, and worth the trouble. I find it important to maintain this balance. Ugly, hard-to-read, optimized code will haunt you forever...

On my home LAN, KBDoom plays a mean, smooth, SlaughterFest2012 MAP30 (13k+ monsters), 2-player co-op in 1920x1080 software, with animated wall splats, massive extra blood-n-gibs, and translucent smoke and explosions add-ons. (I did build a proper REJECT map for the level, which provided an obvious boost.)

I have not done a proper side-by-side comparison against other ports, but, rather, against my port, before and after code changes. So, what I can say for certain is that my current version is highly optimized, when compared against previous versions.

Happy New Year, everyone!

Share this post


Link to post

What is the code lineage of your port kb1? And if it's not crashilicious, why don't you release it and get feedback?

I love testing out Doom source ports, if you send a build to me I'll surely respond with dozens of bug reports and suggestions :-D

Share this post


Link to post

IMO, PrBoom+ is the fastest since I managed run huge maps (such as Protean Cybex) with barely any lag (Software of course). And OpenGL runs ok still. Either way, its stable. Zdoom is not the fastest with all its enhancements running.

Share this post


Link to post

A few years back it was a Big Deal that only PrBoom+ (without even resorting to GL) could run infamous WADs like NUTS.WAD with no slowdown, while ZDoom degenerated into an exponentially slowed-down mess.

When OpenGL is thrown into the equation however, other factors are at play, and the end result might not necessarily be faster than software rendering.

Share this post


Link to post

Everybody forgets EE of course. I make no claims regarding comparisons, but it *has* had hell of optimizations done to it.

Share this post


Link to post
Edward850 said:

It's not as if ZDoom can't run nuts.wad, mind you.


So could Vanilla ;-) If I recall correctly, the main difference between PrBoom+ and ZDoom/PrBoom was the behavior of some MBF flag (MBF Friend flag?), which caused polynomial/exponential running times when turned on, and it was on by default in those latter ports.

In any case, soon after the NEW and IMPROVED PrBoom+ came out, needless to say, ZDoom had to improve its game too.

Share this post


Link to post

ZDoom doesn't even implement MBF friends so it can't be that.

Anyway, despite some issues with monster AI performance, Nuts.wad running in ZDoom is still spending far more time in the renderer, than in the AI.

I can't do easy comparisons because PrBoom lacks the performance measuring tools to show how much time is spent where.

Share this post


Link to post

For some reason GZDoom on D Touch 3.2 can't run NUTS.WAD and NUTS3.WAD but it can run NUTS2.WAD (no wonder).

But PrBoom+ runs all three... And I only like to play NUTS2.WAD.

Share this post


Link to post
scifista42 said:

Chocolate Doom actually renders each tic twice.

Not any more. The stable version on the website includes the fix for this bug.

That said, the comments from other people are basically correct. I've never put any significant effort into optimizing Chocolate Doom because it seems like a waste of time, and besides that. optimization in general is not something hugely interesting to me.

Share this post


Link to post
Voros said:

For some reason GZDoom on D Touch 3.2 can't run NUTS.WAD and NUTS3.WAD but it can run NUTS2.WAD (no wonder).

But PrBoom+ runs all three... And I only like to play NUTS2.WAD.



Can't say without timing values for PrBoom+.

My guess would be the sprite rendering code, which for ZDoom features is quite a bit more complex than for a simple Boom-compatible engine, and on slower hardware that can become a problem.

Share this post


Link to post

On maps like NUTS.WAD aspects other than the renderer or gameplay code can come into play too, like e.g. how aggressive or lazy the memory allocation code is, how efficient a malloc/dealloc operation is on a given platform, how much RAM is there available etc.

For example, I was surprised that with Mocha Doom I got playable framerates which almost rivaled those of PrBoom+ on certain hardware on NUTS.WAD (a NUTS.WAD lmp used to be part of the repo, until v1.4), without putting any effort into it, but simply literally copying the vanilla code (well, maybe with a few flavors of Boom here and there). Then I realized one of the reason this happened was that memory/objects was being managed VERY lazily: all those short-lived projectiles didn't necessarily trigger a dealloc/destroy operation everytime they were let loose by the engine, unless I constrained the starting memory to be very low.

Share this post


Link to post
VGA said:

What is the code lineage of your port kb1? And if it's not crashilicious, why don't you release it and get feedback?

I love testing out Doom source ports, if you send a build to me I'll surely respond with dozens of bug reports and suggestions :-D

It's pretty stable. It'll crash on bad map data, as I haven't yet added much sanity checking of the map data. LAN peer-to-peer net games are rock solid, and even support in-game option changes and fair multi-user cheats. It's really nice to be able to clip across a one-way door in a coop session :)

I do plan on releasing my source, but only after:

. I've finished adding features that could affect demo-sync (which is just about everything).
. I've tested all features to the best of my abilities.
. I've fixed all known bugs.
. I've thoroughly documented all features.
. I've thoroughly documented the source, and supplied credits for each resource.

Basically, I want to release a fully-featured, bug-free port.

Share this post


Link to post
kb1 said:

Basically, I want to release a fully-featured, bug-free port.



Take some advice here:

Forget that attitude, please. You won't do yourself a favor.

I still remember the bad old days of ZDoom 2.0.x when Randy made an occasional new version every few months. They all were littered with bugs, mostly caused by typical developer blindness to one's own creation.

In contrast, the first 2.1 release was nearly rock-solid out of the box, because the development code got lot more testing due to public exposure through SVN.

I can guarantee that you'll end up the same, and you will inevitably start fixing stuff that may affect demo compatibility. So better have this ironed out before setting a particular set of behavior in stone. Users just have to be aware that interim releases won't guarantee demo compatibility.

Share this post


Link to post
Graf Zahl said:

Can't say without timing values for PrBoom+.

Few years ago I posted screenshots from VTune for glboom and gzdoom.

Spoiler

Spoiler

Share this post


Link to post

... that doesn't help me much, unfortunately, because I cannot compare them with how GZDoom performs on my machine.

Share this post


Link to post

If I'm reading that correctly, the most expensive portion is the blockmap iterator? That's not surprising considering ZDoom allows for objects to attach to multiple blocks to fix collision imprecisions. This also boosts the number of possible collisions as well.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×