Favorite Source Port? (Multiple Choice Poll)

For some reason just mentioning "source ports" is enough to throw some DW members into an irrational rage. It's almost like pouring salt on open wounds.

Sadly, this behavior isn't restricted just to forum trolls or relative to the holiness or not of this or that source port, but it extends to some of the moderators, and, apparently, even to metadiscussions about source ports.

In another thread I had posted twice how (quite literally) "One will have a better chance to have a rational, cold-headed conversation with Richard Stallman himself on the GNU/Linux naming controversy, than debating about source ports on DW", and both times it was silently deleted, despite it being no more scathing or irrelevant than John Smith's stream-of-consciousness, John Romero-making-of-the-bitch like scatological posting.

Seems I struck several exposed nerves with that one...well, I'll add that it's easier to get a hardcore Mac user to have a rational, polite, and cold-headed, objective debate with a hardcore "el cheapo" h4xx0r 0v3rcl0xx0r PC user, than debating about source ports on DW ;-)

AHEM...



My 2c?



ZDoom and prBoom+, with a lightweight frontend such as ZDL (not to be confused with the utterly broken ZDLauncher). And their GL counterparts of course, depending on the mood/hardware/map type.

Why? Well, they play almost everything, they are fast, have good control response, and don't use weird/quirky IWAD/PWAD storage schemes like e.g. the Doomsday Engine.

My pick for an authentic vanilla Doom experience has to be Chocolate-Doom. It delivers in every aspect and that includes pixel-perfect accuracy, which other source ports have sacrificed for a variety of technical reasons.

One thing that I can't do well without is customizability, and (G)ZDoom has become the undisputed king in that field, plus the documentation is quite extensive, leaving virtually nothing for people to guess.

On a totally unrelated note, anyone contemplating the possibility of staying here, will have to get used to everything being ruled and contaminated by stupid, intolerant, arrogant and completely full of shit socialist kids.

That's my two cents.

derp said:

Yeah, uhm, just throwing it out there that I don't give a crap about you're argument about fps and sh*t. I just wanted to know what Source Port was the best to play a variety of single player maps in better graphics.

Better graphics is very subjective, and it depends less on the port and more on the mods you load. (It does depend a bit on the port because relatively few of them can load models and/or hi-res textures. Personally I prefer the original sprites anyway, I find the models not convincing enough to be worthy of the bother.)

Variety of single player maps is easier to quantify. So since you've said you're kinda noobish, a first little introduction to some jargon:

• DeHackEd: an old utility which allowed to modify the game's behavior by directly changing values in the executable. ("Doom.exe Hack Editor".) Before dehacked, some mods were packaged with a binary patch, but since there have been many versions of Doom, they couldn't be applied to any existing version. Dehacked patches are text files that were to be read by the dehacked utility and then it patched the exe accordingly to the version it detected.
  
  Nowadays, practically all ports are able to read the dehacked patch files and apply them to their game data in memory on startup, so patching the exes is no longer needed.
  
  
• Demo: Doom lets you record a demo of your playthrough. The system for doing so is rather clever: it takes advantage of the random number generator not being truly random and only record the RNG's seed and the actions of the player, which are the only things that it cannot predict on its own. Then when the demo replays, the monster behavior is magically the same. Unfortunately, this system is very sensitive to engine changes, as even the smallest factor that affects the simulation can cause demo desyncs.
  
  
• Boom: the first source port to add many additional editing features, it has become a standard. It added many features (generalized linedefs, conveyor belts, and more) which can be critical to allow a map to be played correctly. A huge quantity of maps have been made for the Boom standard, so you'll probably want a Boom-compatible source port. As a trivia point, Boom was the first port to add the ability to interpret dehacked patch files.
  
  
• MBF: a derivative of Boom, which added yet more features. Sometimes, a map presented as being for Boom-compatible ports actually use a few MBF features (usually the sky transfer effect).
  
  
• SMMU: a derivative of MBF. Added several things, the most important of which were the console (like in Quake) and a scripting language, FraggleScript.
  
  
• Legacy: another historical port, Legacy was originally aimed at multiplayer games (even added splitscreen mode!) and eye candy (with light coronas, fancy water effects). It also took FraggleScript from SMMU and added 3D floors to allow room-over-room effects, so it had many interesting editing features.
  
  
• Heretic: a game developed by Raven Software, originally derived from the 1.2 version of Doom. Heretic had its own additional features, such as an inventory system, the ability to pass over and under solid things (you can't in Doom, that's why you have both solid and nonsolid versions of some hanging gore decoration...), terrain effects like splashes in water, and wind or current effect (like Boom's conveyor belts, though developed earlier).
  
  
• Hexen: sequel from Heretic and developed by Raven Software, it offered much broader changes to the engine, which necessitated a different map format. Among its features are a scripting language (ACS), moving geometry through "polyobjects", a "hub" system allowing to revisit maps, and different player classes.
  
  
• Strife: a game developed by the now-defunct Rogue Studio, originally derived from the 1.4 version of Doom. It featured independent implementation of several Heretic/Hexen features (wind/current, splashes, inventory, hub) and a conversation script system. The source code was never released, but it has been thoroughly reverse-engineered, originally by Samuel "Kaiser" Villareal (when creating SvStrife), Randy Heit (for ZDoom) and Janis Legzdinsh (for Vavoom). The reverse engineering effort has recently resumed in the hope of getting it as perfect as possible, by Kaiser and Quasar.

That's it for the history lesson. With all that said, a few ports, gauged on the "variety of maps" criterion:

• Doomsday: not Boom-compatible at the moment (it's planned, but the Doomsday developers are rewriting just about everything so it'll have to wait until the new architecture is working). You can try Risen3D instead, since it's a fork of an older version of Doomsday and added Boom support.
  
  
• Eternity: a derivative of SMMU, which removed FraggleScript but added many new features. It's an interesting port, but sadly underused as there are only two maps made specifically for it. Still you can play Doom, Boom and MBF maps on it.
  
  
• GLBoom+/PrBoom+: a derivative of MBF, which features "complevels" to ensure that the gameplay can be rigorously identical to the chosen "target exe", among which you can find Doom II, Final Doom, Ultimate Doom, Boom and MBF. The main draw of this mechanism is that it lets you replay a wide variety of demos. This port has not added any gameplay-changing feature to avoid creating yet more complevels, but some additional features that have no impact on the simulation have been added, such as hi-res textures, detail textures, skyboxes, etc.
  
  
• ZDoom: originally a Doom port, ZDoom has been enhanced with support for other Doom-engine games, namely Heretic, Hexen and Strife. The approach chosen was to support all these games together, allowing features from each to be used in the others. As a consequence, the enhanced map format used by Hexen (with its own scripting language, ACS) could be used for Doom mods, for example. Since then, it has continually added new features (including support for most Boom features) or enhanced the existing ones, making it very popular for mappers. There's a lot of maps that require ZDoom. On the other hand, there are a few that don't work at all with it, the most noteworthy being the Batman Doom TC (one part of the dehacked patch, the last weapon, doesn't work correctly which will make you lose the last fight all the times, and a handful of levels are broken and cannot be finished without noclipping to the exit.)
  
  
• Vavoom: the originality of that port is that it is heavily based, of all things, on the Quake source code. The renderers it offers have some of the most advanced lighting effects in Doom ports because of that. Like ZDoom, it offers support for Heretic, Hexen and Strife. Also, it has liberally taken large parts of ZDoom and is therefore mostly compatible with ZDoom mods (as long as they don't make use of the most recent features).
  
  
• GZDoom: a version of ZDoom which offers an OpenGL renderer, FraggleScript support, and 3D floors. It is mostly, though not entirely, compatible with existing Doom Legacy mods and Vavoom mods (though you may have to repackage them a bit). It's also of course compatible with ZDoom and all the games it runs. Recently, several mods have been made specifically for GZDoom to take advantage of the OpenGL effects and 3D floors it offers. So for sheer variety, it's probably the best bet. (But Batman Doom doesn't work there as well, and the renderer cannot detect or replicate some of the hacks that are used to achieve special effects in some mods.)

The general caveat being that no port is a perfect all-in-one solution. If you want to have no option closed, you'll need to install two or three at least.

entryway said:

The first ports you should try are g/zdoom and doomsday.

I agree. For new users trying out source ports for the first time, these are the most sensible options.

derp said:

Yeah, uhm, just throwing it out there that I don't give a crap about you're argument about fps and sh*t. I just wanted to know what Source Port was the best to play a variety of single player maps in better graphics.

Welcome to Doomworld, where an innocent question can spark a five page flame war. :-)

There's no one "best" port despite what some may say, they all have strengths and weaknesses so most players have two or more installed to cover most contingencies. I'm interpreting "better graphics" as OpenGL ports, of which the pick of the bunch are probably GZDoom, Doomsday/Risen3D (if you want models instead of sprites) and GLBoom+ (which accompanies PrBoom+).

I died a little inside after reading this topic

Graf Zahl said:

You forgot one caveat:

Eternity used SDL Mixer so it can't take any advantage of multithreading on multi-core CPUs. (well, but so does PrBoom+ :P)

Does that crash happen when timidity is used? Anybody know? MIDIes are partially broken anyway with any SDL_mixer based port on non stone-age operating systems.

GreyGhost said:

Welcome to Doomworld, where an innocent question can spark a five page flame war. :-)

Interesting isn't it?

Someone says a (even remotely) bad word about Eternity and the resident fanboys run amok.

But it seems to be largely tolerated if someone bashes ZDoom or its derivatives - one could get the feeling it's even considered good manners.

Hypocrites!

Fuckin' hell guys.

Chocolate Doom
PrBoom+
JDoom

So far noone has mentioned Vavoom, which arguably got the most advanced graphics engine of all Doom source ports.

EDIT: Ok, Gez did that. But I might as well stress that a bit further seeing how that is generally what the OP is after in this case.

kristus said:

So far noone has mentioned Vavoom, which arguably got the most advanced graphics engine of all Doom source ports.

That's really debatable. Yes, it got some interesting features but it's all negated by the problems it also exhibits. I couldn't in good conscience recommend it to anyone due to all the issues it has, nice lighting features or not.

It's also a perfect showcase that all the technical buzz isn't worth anything if you can't produce a relatively stable and polished product.

I mean, seriously, despite its crufty setup requirements, even Doomsday is giving me less problems than Vavoom.

derp said:

It would be nice to play some new maps and maybe have better graphics too. Which one is the best for what I'm looking for?

Please reply soon. Thanks :)

I personally use GZDoom, as it has better graphics, more options, none of the bugs/limits that the original game had (though many can be turned on in options) and generally it's not very often that I come across a wad that can't be played with it.

If the main thing you're after is recreating the original game as closely as possible but still with better graphics, then glBoom+ is probably better at that (although I don't use it myself as I'm not into that). You'll still need the above port as well though to play wads that require ZDoom/GZDoom.

As for new maps, there's tens of thousands of them out there ;)

http://www.doomworld.com/idgames/index.php?dir=levels/ (the database for the doom archive, which contains the vast majority of maps made since 1994)

http://www.doomworld.com/10years/ (the most highly rated wads up to 2003)
http://www.doomworld.com/cacowards/ (the most highly rated wads after 2003)

Those awards are based on popular opinion, so you'll find stuff in there that you don't like and stuff outside of there that you do like. Either way, there's plenty to keep you going for as long as you want.

I really can't say what sourceport is "best" since I know nothing about sourcecode and such... but I can speak of which ones I've had the most success with on my Windows 7.

Mostly I use GZDoom:

http://grafzahl.drdteam.org/

...which is based upon ZDoom:

http://zdoom.org/News

With GZDoom I get the best video quality, compatability and versatility for just about any WAD I want to run. As mentioned earlier here, having a frontend launcher makes things even better:

http://zdoom.org/wiki/ZDL

With the launcher you can easily switch between IWADS like Doom, Heretic or Hexen, switch between sourceports, load numerous resources and PWADs and, with this one, even load things from zip files. My second choice for a launcher would be Unleashed:

http://vb6.martin2k.co.uk/exes/unleashed.php

I've been playing Doom on my PC for a couple of years now, and so far there hasn't been anything I couldn't run with these.

But as I said, I'm no programmer, so surely someone else will be able to argue for other sourceports as well.

Graf Zahl said:

Interesting isn't it?

Someone says a (even remotely) bad word about Eternity and the resident fanboys run amok.

But it seems to be largely tolerated if someone bashes ZDoom or its derivatives - one could get the feeling it's even considered good manners.

Hypocrites!

Just note that we, as the developers, are not going to be drawn into this. It's all rather petty. I'll note nobody has ever volunteered to actually help get uncapped framerate support into EE, despite all the requests and bitching/moaning about it. And especially not entryway, whose response to my previous queries on the matter was that it was "simple" and to look at d_net.c. Well I did, and it's not.

Unfortunately Eternity and PrBoom+ have completely different main loop architectures. d_net.c was rewritten multiple times in PrBoom, and then again in PrBoom+, to the point where there is really not a single common line of code in the entire module. Eternity has to have support for console command transmission and other various issues for which PrBoom's network protocols obviously make no allowance. Therefore I cannot just copy in PrBoom d_net.c and pray it will work - it cannot.

I have never been opposed to adding an optional uncapped framerate to Eternity. I AM opposed to doing it half-assed, or delaying development over it for months while I try to figure it out on my own - it's not going to happen.

The idea is actually quite simple: Don't wait until the current tic has expired and if no tics have passed since the last call don't run the tickers in TryRunTics and return from that function immediately so that the renderer can do some work.

So from a quick look over your function:

// Loop until we have done some kind of useful work. If no
// game tics are run, RunGameTics() will send the game to
// sleep in 1ms increments until we advance.

Don't do that. Return immediately if no work is to be done.

In TryRunTics: Leave immediately if no tics are pending, even if none were run this call.

A few more adjustments may be needed but this should be most of it already.


Aside from that it's 'only' the interpolation stuff but that's on a much higher logical level.

Graf Zahl said:

The idea is actually quite simple: Don't wait until the current tic has expired and if no tics have passed since the last call don't run the tickers in TryRunTics and return from that function immediately so that the renderer can do some work.

So from a quick look over your function:

Don't do that. Return immediately if no work is to be done.

In TryRunTics: Leave immediately if no tics are pending, even if none were run this call.

A few more adjustments may be needed but this should be most of it already.

Aside from that it's 'only' the interpolation stuff but that's on a much higher logical level.

That's really it? Seems easy enough. I was under the impression that some D_Display calls had to be added somewhere, at least, so that the display updates between tics - or is this lumped in with the interpolation? (Because without interpolation, after all, it's actually only going to redraw the same frame multiple times).

Without interpolation the benefits of unlocking the framerate are minimal. But I figure with two interpolation implementations floating around to look at for reference, I could figure that part out. It's always been the main loop changes that tripped me up.

Quasar said:

That's really it? Seems easy enough. I was under the impression that some D_Display calls had to be added somewhere, at least, so that the display updates between tics - or is this lumped in with the interpolation? (Because without interpolation, after all, it's actually only going to redraw the same frame multiple times).

No, the whole trick is not to wait and let the main rendering loop run more often. If you take a look at ZDoom's code you'll find precisely two places where 'cl_capfps' is used (in TryRunTics and somewhere in the renderer where the code needs to decide whether to interpolate or not) and you'll also see that the most important thing that's different is to skip the code that waits. TryRunTics just returns without doing anything (except one NetUpdate call) if it finds that no new tic has started.

If 35 Hz classic Doom is a problem, then how about the rumor that graphically rich Doom 4 will run at only 30 Hz? Shudder.

Graf Zahl said:

Interesting isn't it?

Someone says a (even remotely) bad word about Eternity and the resident fanboys run amok.

But it seems to be largely tolerated if someone bashes ZDoom or its derivatives - one could get the feeling it's even considered good manners.

Hypocrites!

Excuse me, but where was the ZDoom bashing in this thread? It was, unsurprisingly, recommended by quite a few users.

In any case, whatever about "resident fanboys;" I was just attempting to clear up misinformation or exaggerated statements. From Entryway's posts, you'd think EE is somehow totally unsuitable for use by anyone and is only recommended out of spite or something. (in b4 someone says this is the case) :P

esselfortium said:

Excuse me, but where was the ZDoom bashing in this thread? It was, unsurprisingly, recommended by quite a few users.

I did. I called it a bait.

printz said:

I did. I called it a bait.

What does that even mean, though?

Actually, forget it. I probably don't want to know.



...

Sigh.

esselfortium said:

What does that even mean, though?

Actually, forget it. I probably don't want to know.



...

Sigh.

Dunno, I tried to find an answer to your question located in this thread, looking for the possibly offensive word. It means that it's easy to start by ZDoom and at the same time forget about the rest, that it's like a bait.

esselfortium said:

Excuse me, but where was the ZDoom bashing in this thread? It was, unsurprisingly, recommended by quite a few users.

I wasn't talking about this thread but about the common Doomworld attitude. Someone talks 'bad' about Eternity: People come in and complain about this attitude; someone talks 'bad' about ZDoom: People come in and join the bashing.

And a part time ZDoom dev, Gez, didn't conincidently just write nothing about Doomsday in his 'list of ports post' above other than it doesn't support Boom. Yet when he describes ZDoom, he's gushing about it's features.

To be honest though, one would expect any authour of any port to promote his or her's above all others.

Haha stop that nonsense guys.

I love most sourceports because of their own features and their own great wads. That's what makes Doom so tasty nowaday.
Thus I'm more focused on wads than sourceports, there is no need to search a best one, derp.
If tomorrow I use Eternity everyday it'll surely be because of Vaporware and alikes I guess.

Those that I use the most often are PrBoom+ and GZDoom though. But I like Chocolate Doom and ZDoom too. Oh and also... well, I shut my mouth.

Long story short: there is no "Best" port as they each serve different purposes.

Personally I consider this question to be akin to asking: Which is better - bus or train?

Vermil said:

And a part time ZDoom dev, Gez, didn't conincidently just write nothing about Doomsday in his 'list of ports post' above other than it doesn't support Boom. Yet when he describes ZDoom, he's gushing about it's features.

If you had paid attention, I said quite clearly that it was a list of ports according to the "variety of single player maps" criterion.

I had originally started a list for the "in better graphics" part of the OP's request, but I dropped it because I couldn't make an exhaustive enough list of ports supporting hi-res textures and/or models. Does EDGE support models? Did Eternity got hi-res texture support during its texture manager rewrite? I'm not sure (as I said, I never personally cared much for models and hi-res packs so I haven't looked into it), and the post was getting long enough anyway.

At this rate, I'm almost tempted to recommend CDoom to newbies as "BEST PORT EVAR111!!! VOTE 5!!11" , and let them gnaw their fingers to the bone on it.

I added the following lines of code to EE at lunch today:

(in RunGameTics):
  if(d_uncappedfps && count == 0)
     return true;

(in TryRunTics):
  do
  {
    ...
  } while(!(d_fastrefresh || d_uncappedfps) &&...);

I can set d_uncappedfps to true or to false, and it makes no visible or noticeable difference in the way that EE runs on my machine. I am either missing something obvious, or there is going to be more to it than this.