Ninety-Six, on 25 May 2021 - 08:08 AM, said:
I didn't realize that was broken.
The problem with that approach is that the DOS executables (and the more pure source ports) lack a lot of modern quality of life improvements, as well as overall stability. The DOS executables were a lot more prone to fatal crashes, and there are significant control problems in both the DOS versions and the more pure source ports. Doom admittedly has it far worse than Duke does in that department, being one slip-n-slide of drunken movement and the severe lack of customizable bindings (you can't even use the numpad). Duke is a lot easier to customize, but the mouselook is wonky, even with adjustable X and Y sensitivity scalers.
And then there's the lack of modern conveniences, such as stat tracking, widescreen support, various bug fixes, smaller enhancements, minor visual improvements, etc., that make the experiences a lot less frustrating overall.
I like to tinker and experiment with the DOS versions, but more out of curiosity and some minor nostalgia, rather than for serious play. I will if I absolutely have to, but I'd rather play in a port that lets me track my progress (as a completionist), has widescreen support and higher resolutions overall (so it doesn't look like the main character needs glasses), and allows for custom minor improvements, such as Darkus' fantastic fixed GAME.con or Fox's lingering gib code (which I don't think are compatible with the DOS version), or being rid of the obnoxious blockmap bug and correcting the blood colors in Doom.
I might give RedNukem a try, though I don't actually know a whole lot about it other than it exists and is based more directly on the source code vs. eDuke32 which apparently is based off the original eDuke which was built from NAM/WWII GI? Or something to that effect?
Yeah, it was one of the things that got fixed in the EDuke32 Addon Compilation version of the mod. The mod behaved strangely in EDuke32 because it also showed the two episodes with glitched titles (as far as I remember from when I played the mod first time many years ago), though this one might have been fixed in EDuke32 in last couple of years, not sure when but I highly recommend just playing the addon compilation version in EDuke32 to get some extra improvements on top of it as well, like a new soundtrack for the Water Bases episode. Otherwise, if you plan to play the original version of the LR&WB addon (available at gamers.org and dukeworld, don't bother with Moddb repacks by random people), play it in vanilla Duke3D 1.5 in DOSBox or something (man how much I wish I still had that old Windows 98 PC, maybe one day I might build an old Windows 98 PC just for the DOS and early Windows games because even DOSBox is unreliable for playing certain DOS games).
I get what you mean and I agree with your points. I also dislike the lack of level stats (monsters killed, secrets found and time elapsed) and various bugs/glitches that exist in DOS versions of DOOM and DUKE3D but I noticed that many modern ports of the games just don't have that nostalgic feeling because of the many changes they did, it feels like you're playing a slightly different game or recreation in another engine, at least that's how ZDoom feels to me and this is coming from someone who discovered ZDoom (I think it was an unofficial 2.0.96x build that was used for some mods) back in 2007 as the first source port and while I loved many enhancements it brought, I also felt there's been many regressions, when comes to certain changes (the lack of demo loop, centering weapon when firing, etc) or fixes or features (bullet holes, blood splats, projectile decals) they added. Even back then I felt that I was missing that original feeling and wished I could re-experience the Doom engine games, Duke3D and others just like how was back then when I was a few years old. I hadn't heard of DOSBox yet at that time (other than seeing it on some YouTube videos in 2010 or so when they showed the original Doom or Duke3D) and I didn't know of source ports Chocolate Doom or PrBoom+ yet, even though I may have heard of them at that time by watching some random YouTube videos. I guess I wasn't curious enough to download and try them out, plus the fact why I didn't initially like PrBoom+ was that it's set up a bit poorly by default (so you must mess with some settings to get it right, luckily it takes a minute to change a few settings related to Video modes, disable transparency, enable ENDOOM screen, while leaving everything else by default), complevel thing also confused me back then because I wouldn't know to tell if the parameter had any effect in game and the way YouTubers had it configured (and they most likely ran GlBoom+ which is very ugly, a lot uglier than GZDoom is with texture filtering on, which I always disable BTW, GZDoom doesn't look too bad once you disable the texture filtering).
OK, to clarify, some Doom source ports (at least the vanilla/boom compatible ones) still retain the original vanilla feeling, so they might as well replace the original executables (especially with the new Unity ports that are a great way to re-experience the original games, wish I owned these ports though) and no one would complain about the absence of them (except the hardcore purists, I'm NOT a hardcore purist BTW as I don't want to play on low resolution on source ports for example). Sadly, this isn't really the case with Duke3D. We lack a proper vanilla source port that can play all the DOS versions (or at least both 1.3D and 1.4/1.5 rather than just 1.4/1.5). Other than RedNukem (that only plays Duke3D 1.5 and uses the EDuke32 interface), the closest thing would be XDuke and its various forks (I think there were other older ones like icclus.org and Rancidmeat but who cares about them?) but the most notable one is called Chocolate Duke3D and it sucks. They (XDuke family ports) are all very underwhelming, filled with various bugs (example: missing spinning icon when loading a saved game, the demo cameras don't work during playbacks, though the latter one is apparently a bug inherited from the official Duke3D source code) that I don't recommend them. I once read somewhere that even the original levels are broken (I think E2L4 or E2L5 was one of the levels mentioned) but I can't confirm that myself because I never played XDuke or Chocolate Duke3D other than just testing the first level and that was back in 2012-2013 when I was looking for a Chocolate Doom equivalent for Duke3D instead of only using DOSBox. I am hopeful one day we get a proper Chocolate Duke3D that is based off original source code and has a few improvements but still retains the vanilla Duke3D feeling.
I don't know but to me the original DOS versions of Doom and Duke3D play just fine with default keyboard controls (no need to rebind the controls), meaning just arrow keys for movement, though I do admit is slightly harder to dodge enemy attacks and shoot them while you are dodging, as I use the < and > keys for strafing in those cases or even just trying to dodge backwards if I have enough room to dodge. In Doom, as far as I know, the mouse moves you forward and backward, making traversing on catwalks really painful if you were playing the DOS versions with a mouse or certain source ports that have this enabled by default, like Chocolate Doom and PrBoom+ (not a problem in ZDoom ports where I always have mouselook enabled and smoother controls). I realize there is an utility called novert but I just don't see why you have to download a separate utility to fix the broken mouse movement. Mouse aiming is also wonky for BUILD engine games, I did play through Duke3D and SW (that was in 2014 or so, which was also when I played SW first time) with mouse and I found annoying how in Duke3D 1.3D the mouse aim was inverted (so you needed to go in SETUP.EXE for mouse controls and put a value of -1.0 or something like that), though Atomic 1.5 didn't have this problem, so the mouse aiming was a bit more reliable but still a bit wonky and since then I never bothered again with mouse in the DOS version of any FPS game, I just do it keyboard only and I can do just fine, I rarely die in original levels (other than in first two levels of Ultimate Doom and maybe some levels in Final Doom and Master Levels, though I haven't played the latter two in quite a long time to remember painful levels). For the record, I use mouselook in EDuke32, along with the new modern controls that are set up by default and it is a very smooth experience, especially for the new custom maps and mods created for it, meaning I have a much higher survival rate and it makes it easier to engage with the monsters than just peeking around the corners. But there are occasional changes that break certain maps over time, meaning we go to the issues I mentioned above and I don't want to repeat myself again.
I appreciate being able to play the game natively on the OS instead of having to mess with emulators but sometimes it is nice to have the original executables around, at least for the original levels and certain older maps/mods. I always try to look for solutions and choose the best way that makes sense for me, whenever I get back to the original levels or feel like playing a new map/mod once in a while.
ReaperAA, on 27 May 2021 - 01:39 AM, said:
Actually, this is much less of an issue with Doom wads. Especially if we talk about vanilla/limit-removing/boom compatible wads, then the modern Boom-compatible ports like DSDA-Doom, PrBoom+, Eternity Engine, GZDoom should be able to run pretty much every vanilla/limit-removing/boom compatible wads there exists (even from the 90s).
The only issue comes with wads/mods made for advanced Doom source port. Very old ZDoom mods may or may not work fine in GZDoom. Likewise, there are certain mods that use a modified version of a source port (like there is the Caverns of Darkness mod for Eternity Engine) that doesn't work in the base source port. Even then, the issue is less pronounced than it is in the case of EDuke32 mods. I have played ZDoom mods going as far back as 2012 that worked fine in newer GZDoom.
I agree. In general most stuff should run just fine in the latest version of a particular port (GZDoom in your case, latest version should run pretty much everything with an occasional broken map every now and then). There are some exceptions of wads that only work with a certain version of the source port, though in some cases they come with their own port included as well, at least the standalone mods. I haven't tried running Caverns of Darkness in recent versions of Eternity but I recall not too long ago I downloaded the wad and its executable, put it into its own COD folder (and dropped DOOM2.WAD in it), loaded in DOSBox (as it's a DOS executable) and it crashed during loading. The same issue occurs with another old port (SMMU, aka Smack My Marine Up, which I wanted to test only for the Quake-like start map included) and I'm not sure why. I guess it needs a DOS extender utility? I think Mr.Flibble can help here explain better because last year he helped me make an old EDUKE mod from early 2000s run in DOSBox without crashing. I'm getting a bit off-topic, so I will just ask Mr.Flibble in another PM about running those two (I can run BOOM and MBF in DOSBox just fine for example, so it's just COD and SMMU executables that are crashing dosbox 0.74-3).
I know there's also many older ZDoom wads that require specific older ZDoom versions to run correctly (I use ZDoom 1.22, 1.23b33, 2.0.98 and 2.1.7 for older ZDoom wads up until 2007 or so, then I use ZDoom 2.8.1 for the rest that came since then) but I've also had a few older GZDoom wads (from early 2010s) that randomly crashed GZDoom 1.9.1 (which is the minimum version I use for every old GZDoom wad and it was released in early 2016), while they worked fine in GZDoom 2.4.0 (released in 2017). Do you have an explanation for that? Because I have no idea what's up with that and I use GZDoom versions 1.9.1, 2.4.0 and 3.7.2 for wads released until 2018-2019 or so (not using 4.x series yet for the newer wads as I wait until the final 4.x release, sorry I can't play yet amazing stuff like Faithless Trilogy). If you wonder, the problematic mods in question were Phocas Island 2, Realm of Cheogh (Cheosgh?) and Putrefier. They crashed GZDoom 1.9.1 either upon starting a new game (Putrefier) or halfway through (on PI2, I could access the first map with difficulty options but crashes upon loading next level, then on Roch it crashed at various points so it was hard to beat even with cheats (GOD, FLY, NOCLIP) because I had to be careful to not trigger some monster pop-up traps or some cutscenes that caused the crash) but they worked just fine in GZDoom 2.4.0 without any issues from the small tests I took (PI2 allowed starting the next map just fine, Roch no longer crashed on those monster pop-ups or cutscenes), plus I completed Putrefier (100% everything) that way recently, will go back on PI2 and Roch at a later time.
Bottom line, I always try to have a minimum version of certain source ports (in more vanilla ports like Chocolate and Crispy, I usually have the latest version installed since there is no need to keep an older inferior version of the port, on Eternity I'm stuck with 4.00.00 until I finish some older Eternity wads and then I will upgrade to 4.02.00 for more recent releases, while for PrBoom+ I still use 2.5.1.4 for most wads out there, then I will use the umapinfo fork for newer releases).
Sorry for getting off-topic, maybe some of these posts should be split into a separate topic since the DukeVR issue was resolved long ago. I can only advice for others with a similar problem, to use the original executable when encountering a broken map/mod under EDuke32 or any other source port for any other game.