xttl

@DADi590 I don't know if you've already found out about it, but some time ago a proper hacker going by the name kgsws figured out a way to get code exec from a PWAD at map load time in vanilla Doom (with some suitably corrupted map data), and developed a simple "framework" (if you can call it that) for patching the game with compiled C code so that this exploit could be more easily used to do some interesting and even flashy stuff from a PWAD. See this thread Also see this github repo https://github.com/kgsws/doom_ace and especially this branch https://github.com/kgsws/doom_ace/tree/doom2_ace The last linked example patches the game in memory to add (limited) ZDoom DECORATE support to it, but of course you could even replace the whole game in memory if you wanted to, or conversely only do some much smaller changes. Might be worth looking into it, at least if you don't mind using gcc instead of Open Watcom to compile your code and the AT&T syntax for x86 asm GNU tools insist on sticking with. :P It seems you'll also have to write small asm wrappers for all functions from the main game binary your patch code calls, at least if the binary was built using the fast register-based calling convention (up to 4 args passed via regs, it seems gcc simply cannot be easily told to do this) Watcom offers. Does Fallout have some stack pushes before pretty much every function call, or just before printf & friends and some other rare exceptions? Instead of exploiting the game and putting the loader code in the REJECT lump of a map, just permanently patch the provided loader code into the game binary and adapt it slightly where necessary (as in read the code blob from somewhere other than a PWAD lump). I know if I ever return (unlikely any time soon) to tinkering around with this crap I'll just take kgsws' stuff and be done with it. Yes, anything you attach to the end of the EXE file should be completely ignored by the loader in DOS4GW (or workalike) unless you make some corresponding LE header edits.

Well, now that I looked more at the game code I noticed two more problems besides the external driver's and game's pitch value getting out of sync: - The game itself also tracks current view pitch in two different places which can and will get out of sync with each other: local static var oldAngle in G_BuildTiccmd (used by the code which handles input from external control driver) and players[x]->lookdir. Really, oldAngle should always be reset whenever players[consoleplayer]->lookdir is reset (or the code should stick to using lookdir only), but it isn't. - useexterndriver is checked in P_ZMovement to disable automatic view centering whenever the player has just dropped down from a large height. This can break demo / netgame sync because information about if useexterndriver was enabled while recording isn't stored in a demo and neither is it a per-player variable which is synced between nodes in a netgame. (edit: seems P_PlayerThink checks it too to disable automatic view centering if flight powerup has just ran out)

¯\_(ツ)_/¯ No idea then. Maybe if/when someone implements the same idea as an exe hack it'll work.

I almost wonder if this could somehow be caused by DOSBox being able to run code too fast on your system. Personally, I've had no problems with ravmouse but I'm stuck with testing on relatively old CPUs only at the moment. Could you try limiting CPU cycles and see if it helps? (eg. "cycles 10000" on DOSBox command line before you start ravmouse, you could also try "core normal") edit: also just in case you were doing that, don't try to use novert and ravmouse at the same time (though turning sideways and buttons should still work even if novert was loaded) No plans for this at the moment. Just saying the external control driver approach as it is has some annoying limitations. :( (an exe hack which solves these limitations can still stay netgame/demo compatible btw.)

I updated the program at some point to support negative values for -vs, which is (perhaps counterintuitively, you might expect it to invert direction) interpreted as meaning that the vertical input value from the mouse driver is to be divided by that value (absolute value to be precise) rather than multiplied, but seems the version on archive.org is too old as is the version I've posted as an attachment here once before. Here's a version with that feature (and 16-bit Open Watcom C source) included: ravmouse2.zip Note that the limited vertical look resolution afforded by the external control API starts to become more and more of an issue the lower you go in vertical sensitivity. This really needs to be a heretic.exe/hexen.exe modification anyway because there is no way for the external control driver to know if the view pitch has been reset (by teleportation, level exit, etc.) or if the game was paused or in menus when mouse was moved, both things which it really needs to know due to the way looking up/down via the external control API works. It seems a bit difficult to even solve this by reading game memory from the driver because it is a 16-bit real mode program and the game is running in protected mode using memory above 1MB. No idea why that might be. :( (assuming mouse is fully working in other games and programs)

Lol, I remember back in the day a game reviewer in a local magazine theorized that Raven added some optimizations to the engine in Heretic since it was smoother on the reviewer's system than Doom 2, and even congratulated them for this supposed feat. I always thought that was bullshit (I knew the engine was *older* than in Doom 2, and on my system there wasn't really any noticeable difference in scenes of similar complexity), but this explains it well. (also, isn't the LoS algorithm used by eg. enemies looking for the player faster in <=v1.2 as well, after all? only learned about that one years later...)

Yes, the id Anthology situation came to my mind as well. I don't even know anymore if they sold any DOS v1.1 (1.1r1 or 1.1r2) CDs at all... I was sure I had 1.1 on CD, but my own CD is also 1.0. I had not looked at the disc in a long time, I got it for christmas when I was barely 10 years old and it's actually in a quite sorry condition nowadays. :P I did remember downloading the 1.0 to 1.1 patch from a BBS and being disappointed about how they removed the trick to skip the castle hub almost entirely... but I also wasn't sure if I got an illicit copy of 1.0 from someone before pestering my parents to get the game for me, perhaps after losing said copy due to bad floppy disks, or just for the CD audio tracks (since I was stuck with a FM only soundcard). All the CD images I've found from the Internets so far either have the same v1.0 files on the first track (1.0r1 as loose exe file, 1.0r2 inside installer's archive), or they're Hexen 95 CDs which also have 1.1r1 for DOS as loose files (the old DeICE installer has been completely replaced with a simple batch file). edit: checked out a few more and it's still only v1.0s and Hexen95 + 1.1r1s, I give up. also, the MJ3 files are identical(!) between the Quake shareware CD and the newer games/ftp, so they must all contain the same version (and use the same obfuscation method) even though the shell was updated so that keys from the old keygen cannot make it deobfuscate the MJ3s anymore... but this is getting off-topic

"broken" might be a bit of an overstatement actually. :P The only bug that got fixed in v1.1r2 vs. v1.1r1 is quite minor: breaking suits of armor could spawn monsters even if -nomonsters was specified on command line. There is more talk in this older thread here. I have not personally bought the game on GOG, but I just extracted a GOG Hexen installer I managed to find from somewhere and it contains the older v1.1r1 hexen.exe. It may not be the current version of GOG's installer though, since I didn't actually get it from GOG themselves. If you want to check your own hexen.exe version in Windows (Vista or newer), you can use certutil on command line certutil -hashfile hexen.exe SHA1 note: if it says unknown algorithm, make sure you typed SHA1 in allcaps ("sha1" doesn't work in Win7 but MS fixed that some time after Win7) Here are SHA1 hashes for all known non-beta, full version hexen.exes: hexen.exe v1.0r1: 8efd52454de3ca04e14e7ca6f6ac7d25bf7a1d69 hexen.exe v1.0r2: 4bc2504d53b06244a7c043bf9a4c7ccfcd87f066 hexen.exe v1.1r1: b0b99b13a2d4f7987d1e918e2289deb9c421e561 hexen.exe v1.1r2: 049bb269018a79a090cb37171c554cfd89a1c42b ...I've been going through different Hexen CD images from the Internets, and also dug up my own original CD from the 1990s (a GT UK/Euro release). Guess what? None have 1.1r2, not inside the installer archive nor as loose files on the CD. :D When I made that first post I was actually working with a decrypted DeICE installer from the old Quake shareware CD you could buy an unlock key for (or use the widespread keygen...). That installer contains 1.1r2. All the v1.0 CDs I've seen have 1.0r1 as a loose file on the CD (meant for running the game from CD without installing to hard drive), but 1.0r2 inside the DeICE installer's archive. This is why I (mistakenly) assumed any v1.1 DOS Hexen CD-ROMs would have 1.1r2 inside the installer archive, and 1.1r1 as a loose hexen.exe or zcdhex.exe file. By the way, the official 1.0 to 1.1 update generates hexen.exe 1.1r1. Now I actually don't know anymore if you could get 1.1r2 any other way than installing it from the TestDrive encrypted "idstuff" installer they put on the Quake shareware CD (or from the "idouts" installers with updated encyption updated TestDrive "shell" they put on rereleases of some of their other games and at their ftp server). Also, the only floppy images I've found from the Internets so far contain a DeICE installer with the 1.0r1 exe, and the official 1.0 to 1.1 upgrade patch that's on idgames and cd.textfiles.com doesn't work with that executable! Only 1.0r2! I don't think there was ever any official patch from 1.0r1 to 1.0r2... Perhaps those who bought this version could have worked something out by contacting id/GT?

Well, here is a page with vcdiff patches (which you need to apply manually) to take hexen.exe & hexen.wad up/down, from any version to any version (plus zips with the support files from the full beta, v1.0 and v1.1, and the date check crack & blink remover for beta exe): https://hilla.kapsi.fi/~vv/hex_up_down/ I was a bit unsure about the upgrade patches from the full beta to v1.0 or v1.1, but eh, if you wanted the full game for free, it's easier to find v1.0 or v1.1 than the beta anyway (which itself seems to be easier to find nowadays than what I remember it being 15-20 years ago without any special access to scene archives or such, though eventually after spending enough time I did find it from the open web or p2p). I may still remove them... but it just felt appropriate to put those there for completeness. I also may drop the upgrade patches completely since the official upgrade patches already exist anyway... Seems that for Heretic a v1.3 retail to v1.0 registered downgrader already exists? What about Strife?

Ahh, I was afraid Steam (well, Activision Activision®|Blizzard® via Steam) might be selling the earlier broken v1.1 exe, well here's a vcdiff to turn that into the "retail beta" exe (no neat-o patcher package, sorry, maybe later): hex11r1_exe_vcdiff.zip (again, if you aren't familiar with vcdiff files, you can use xdelta3 or a couple of other alternative tools to apply these, either my decode only DOS build from hx11beta.zip or whatever you can get/build yourself for your primary OS)

Since it seems there's nothing like this out there yet, I thought I'd create a downgrader which turns Hexen v1.1 into the "retail store beta" version, even if the beta is not as difficult to find from the open, public Internet as it used to be. This is the full beta version which leaked to the warez scene before the game's official release date, the one where the cheat codes that got printed in many magazines back in the day ("conan", "martek", etc.) actually work. It is not the same thing as the four level beta demo. This includes all of the maps, and also has a few more differences versus the final game than the beta demo does since it is a slightly earlier build. Altogether it's very close to the final version, though. Don't expect to find anything earth-shattering here even if you haven't seen this version before. Instructions: 1. install a fresh copy of the DOS version of Hexen v1.1 2. copy all files from zip to the same directory 3. run patcher.exe, press some keys, wait 4. use hexbcrak.com to remove date check from hexen.exe (also optionally the blinking "BETA" text if it annoys you), or set clock between Sep 26 to Oct 29 1995 Note: This will only work with the later revision of hexen.exe "v1.1", with SHA1 hash of 049bb269018a79a090cb37171c554cfd89a1c42b. This is the version you should have if you INSTALLED the game from the original CD or floppes (or extracted files from the DeICE installer) instead of copying loose files from the CD. Note2: The patcher is garbage, but hey, at least it's still slightly slicker than a bunch of BAT files that call the unregistered version of a shareware binary patcher tool (MDIFF) with ridiculous artificial delays inserted. ;-) It creates temporary files with the actual xdelta3/VCDIFF data (extracted from patchlib.bin), then calls xdelta3.exe to apply the patches since I couldn't figure out how to get things working via the xdelta3 API yet and wanted to release *something*. This is why there is no progress indicator when it's applying a xdelta3 patch, and why the error messages aren't displayed correctly in the textmode window if xdelta3 fails. The code could also be cleaned up a bit otherwise. I tested this in PCem set to emulate a 386DX/33 and the patching speed was still tolerable. With 486DX/75 setting it's very tolerable. (in DOSBox with the dynamic core & cycles set to auto it's really fast even on my 6-7 year old laptop, but file timestamps aren't set correctly because vanilla DOSBox can't do it ;) I tested it with 6-8MB of RAM, so it should work on pretty much every computer where the game itself runs tolerably. hx11beta.zip src.zip edit: also here are the plain vcdiff files (plus the beta's dwango.exe as is) if you want to apply the patches yourself manually using xdelta3: hex11_to_beta_vcdiffs.zip (then you can use dwango.exe as reference if you want to fix the timestamps using eg. touch)

It *could* have been done, but it'd have been a lot of work for very little gain. (then, on the other hand, same applies to pretty much all of this hacking of DOS binaries of games that have been open sourced for over 20 years...) With kgsws' tools which allow patching with C code it'd be a lot less work, so maybe one day...

I'd say the biggest impact from including a DHE parser would be slightly increased memory requirements (whether you are going to use the parser or not). Performance shouldn't be affected noticeably. Old DOS Boom's DeHackEd parser would probably be less work to integrate than the one from Chocolate Doom, but it is also not as good. Simply updating DOS DHE to support FastDoom binaries is not a very good idea because FastDoom is still being developed so it's a moving target.

Yes, that version is from between the press beta and 0.99 I believe. I just checked all four alphas and 0.4 & 0.5 indeed are using unchained mode just as I remember, as is 0.3 which I wasn't sure about.

Press beta uses regular mode 13h, but 0.99 and everything onwards is using unchained mode. Press beta using regular 13h is a bit weird because IIRC alphas 0.4 and 0.5 use unchained mode. 0.2 uses 13h, so they went from 13h to unchained to 13h to back to unchained again.