I haven't updated for a few days, but I've been slowly bringing things together for the next release, which should hopefully happen soon-ish. This is shaping up to be one of the most stable DirectQ versions ever as lots of little glitches and niggles are getting nicely smoothed off.
I've also done yet another full run through ID1 over the Easter weekend, and my previous revised impressions of e4 are coming through even stronger - definitely the best.
There's going to be another rewrite of the main surface refresh coming up shortly too. The current version uses a dynamic vertex buffer which I intend switching over to static; this should see major performance improvements in maps with complex brushwork or high polycounts. There are still some - hopefully relatively minor - niggling issues to be worked out regarding handling of brush models, but I'm starting to get a clearer picture of what it's going to look like and how it's going to work. That's a few releases away yet, so I'll say nothing more for now.
Meanwhile...
Wanted: Sane Doom Source Port
I'm in the market for a relatively sane Doom source port. I've gone hunting through a few, including ZDoom, PrBoom-Plus and Doomsday, and I've been fairly dismayed by what I've found. In one way they remind me of where Quake engine ports were at maybe 10 years ago, in that they all seem to include:
- Lots and lots of DLLs that are necessary to run the engine.
- Additional external content that the engine won't run without.
- Unnecessary eye-candy effects.
- Support for mouselooking, MD2 files, high-resolution textures, etc etc yadda yadda.
- Third-party audio and/or video libraries (SDL/OpenAL/etc) needed.
22 comments:
Chocolate Doom might be your best bet.
Oi! ZDoom isn't that bad, is it? I've got it for running the big five (Doom, Doom 2, Heretic, Hexen, and Strife) and it only uses one external library, fmodex.dll
Are you thinking of making your own? DirectDoom? By the Gods, man, do it, but it's gotta include support for the big five.
GZDoom is my favorite OpenGL source port of Doom. The home page is here:
http://www.osnanet.de/c.oelckers/gzdoom/index.html Or the latest SVN builds here: http://svn.drdteam.org/gzdoom/ I use the ZDL 2.1 launcher to make it easier to configure and run. I think the only external libray that it uses is fmodex. In addition, it supports external textures like the jdtp. by the way, DirectQ is my favorite Quake client, by far. Keep up the great job you are doing on it. I'm looking forward to the next release
Eternity is the only other major active Doom port that hasn't been mentioned, but I don't see why you would like that one if the others won't do.
Chocolate Doom is definately the purest gameplay experience, right down to requiring a seperate setup.exe for configuring key bindings, emulating all the buffer overruns and other bizarre bugs, etc. However, the main developer is on Linux, so you get all the SDL baggage.
The Doom community wouldn't be around today if the source ports like like Boom hadn't greatly expanded the editing capabilities that you seem to lump into the "yadda yadda." You have to remember that a lot of these ports started out in DOS and gradually transitioned to Windows/Linux/OS X, which necessitates all those external libraries.
When it comes to Doom ports you are pretty much out of luck there. The biggest at the moment is ZDoom but even then that's got FMODEx and an external PK3, which seems to be a little pointless. But really Most Doom ports these days use SDL and they all aim to be cross platform rather then just focusing on one solid 3D API like DirectX or GL. I think gone are the days of smart people just trying to get their game working on their own platform and hello to the days of screw windows and lets port.
Eternity is the only other major active Doom port that hasn't been mentioned, but I don't see why you would like that one if the others won't do.
Chocolate Doom is definately the purest gameplay experience, right down to requiring a seperate setup.exe for configuring key bindings, emulating all the buffer overruns and other bizarre bugs, etc. However, the main developer is on Linux, so you get all the SDL baggage.
The Doom community wouldn't be around today if the source ports like like Boom hadn't greatly expanded the editing capabilities that you seem to lump into the "yadda yadda." You have to remember that a lot of these ports started out in DOS and gradually transitioned to Windows/Linux/OS X, which necessitates all those external libraries.
Chocolate is a great port for classic feel and simplicity. They actually try to make the engine as close to the original engine as possible. The game runs with one executable, there's the setup exe, a server exe, and SDL x 3 dlls.
Basically their goal is Vanilla-on-modern-systems.
Making a DirectD is kinda semi-tempting but mostly I just want to mess around with Doom. I've a definite and very strong preference for a clean and simple engine that doesn't include loads of dependencies, but I appreciate the tradeoff that if you want full portability you've got to have a certain amount.
If I was to make a DirectD I'd probably base it on an existing port rather than start from scratch, so obviously a port that includes the least amount of dependencies is preferred from that perspective. I do have some ideas of what an end result would look like, but right now I've no commitment to make one.
I don't think any of the ports are really "clean and simple." ZDoom has added tons of editing features. Chocolate Doom/PrBoom has to bend over backwards to maintain demo support - demos in Doom are just player inputs, so the engine has to behave exactly the same (bugs and all).
Also, why do some of my posts never show up? I tried posting yesterday twice, but they never showed up...
I am another Chocolate Doom fan.
Not sure if it meets your requirements though.
I think the blog software might be just fucked. I've had a few glitches myself with FireFox on occasion.
Hmm - the idea of a D3D11-only Doom port is perversely appealing, isn't it?
Depends what you are going for. From hearing about Doom developers experiences, the engine doesn't match up very well with how DirectX/OpenGL expect to work. If you're just sticking to rendering the original levels this isn't that big of a deal, but some of the modern community levels are monsters that will destroy performance. The Doom engine also has a ton of bizarre rendering glitches that lots of custom levels rely on as 'special effects.'
I haven't played doom since like 1999, but at the time zdoom was a fairly conservative, faithful port.
Yeah, Chocolate Doom is pretty much the only option for sanity. (It's still a headache launching .wads and .dehs but at least it supports pretty much anything that would run on vanilla doom)
I'll echo David's opinion. Currently I'm using GZDoom to play through the appalling, nightmarish, completely hilarious grind that is sunder.wad, in which several levels feature hundreds of monsters onscreen at once. If you were to create a DZDoom (Direct3D Zdoom), or even go through the raging dog's breakfast of GZDoom's code and give its rendering backend a good, stern talking-to, I'd be in your debt. That particular WAD has even managed to briefly cause framerate to dip below perfect smoothness on an 896 MB GeForce GTX 260. Something's a bit amiss, you could say.
Oh, and of interest to the historic goals of DirectQ, sunder.wad makes an i915 run GZDoom worse than a low-end 386 runs (ran?) Doom v1.9.
Hmmm, neither ZDoom nor GZDoom compile, Chocolate Doom requires Cygwin (instant turn-off), not sure about the rest yet.
Found out why GZDoom is so slow by the way - our old friends glBegin/glEnd are at work.
Oof. You may not have heard, but the actual renderer in GZDoom's basically unmaintained at this point. I'm sad to hear it won't compile... that reduces any likelihood that you could fix or improve it, doesn't it? :-/
Did you look at the ZDoom compilation instructions? Are you trying to compile 2.5.0 or the latest SVN? ZDoom has a bad habit of going way, way too long between "official" releases.
Graf Zahl gave up on serious GZDoom development after one too many people attacked him for the perceived poor performance (99.9% of these people were clueless trolls). The guy never claimed to be an OpenGL expert. Apparently there are some unique aspects to Doom that make it a challenge to leverage the true potential of modern hardware. Here is a semi-recent DW thread with basically all of the hardware accelerated port authors discussing some performance stuff (Graf Zahl, entryway, DaniJ).
Did you look at the ZDoom compilation instructions? Are you trying to compile 2.5.0 or the latest SVN? ZDoom has a bad habit of going way, way too long between "official" releases.
Graf Zahl gave up on serious GZDoom development after one too many personal attacks due to the perceived poor performance (99.9% of these people were clueless trolls). The guy never claimed to be an OpenGL expert. Apparently there are some unique aspects to Doom that make it a challenge to leverage the true potential of modern hardware. Here is a semi-recent DW thread with basically all of the hardware accelerated port authors discussing some performance stuff (Graf Zahl, entryway, DaniJ).
OK, what the hell. I made a post yesterday that I verified as having been committed (I checked in two browsers). Today it's gone.
The blog software was detecting them as spam: http://www.google.com/support/blogger/bin/answer.py?answer=187141
I've unspammed them.
Post a Comment