xttl

Here's an updated version of DeHackEd 3.0a with support for both Final Doom executable variants (regular and anthology) added. Required offset values for the first Final Doom revision are taken from the old, binary only DHE 3.1 release. For the second revision I figured them out on my own. (which wasn't really THAT difficult to do :) It is called a "special edition" (dumb name I know) because it is not an update to 3.1 (the source code to which was never released). Instead, it's really its own fork based on 3.0a. I also added a new color scheme just for the heck of it, it can be disabled via dehacked.ini (add "origpal = true") if you do not like it. Patches tested and working: - vsmooth.deh (vanilla smooth weapons) - pl2.deh (Plutonia 2) - all DHE 3.x sample patches except sample.deh please test different patches and report problems here Download (updated source code for Borland C++ 3.1 included): dhe_special_r3.zip

@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.

Ever wanted to play vanilla Heretic or Hexen with mouselook or freelook like in ZDoom and other advanced ports? Well now you can! First, disable internal mouse support from Setup (set your controller to keyboard only). Then, download this little program, place it into the same directory with your vanilla game executable file and run it. Sensitivity and button mappings can be adjusted with command line parameters, use ravmouse -? to see how. It works fine in demos and netgames even if the other players do not have ravmouse. It should also work fine with Heretic+, Hexen+, heretic.com and any other EXE hacks you might be using since it doesn't modify the executable at all. Tested in DOSBox only so far but I see no reason why it wouldn't work on real hardware. Source code (for 16-bit Open Watcom) here if you're interested. EXE hack for Strife, this one does not support demos or multiplayer...

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...)

Here's something I made back in 2011 (when No Rest for the Living was still supposed to be Xbox 360 exclusive, heh) but never released: nr4tl.exe. It's a hacked Final Doom (id Anthology version so teleports work properly) binary that plays No Rest for the Living with proper music, level names, secret exit, par times and ending text in DOS. Use doom2.wad or doom2f.wad as your IWAD, load No Rest for the Living manually using -file. It's probably not that useful for most people but thought I'd post it anyway. Well, actually just for the heck of it, I also added support for both regular v1.9 and "v1.91" longtics demos in the same binary back then, which I think no other vanilla EXE hack still has (but I haven't been following the Doom scene actively for a while now). Too bad that it doesn't support playing anything besides No Rest for the Living anymore. :) Shoulda have made it just another gamemode/gamemission...

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

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)

"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)

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.

Just say no. (unless it's a mod or another game with actual high res textures)

Nope, haven't even tried. Indeed it makes it impossible to use the same approach as in newer versions. Thanks for the offer, but seems that at this point it won't be needed. I suspect that it wouldn't have contained information about the file formats anyway. (most users of the compiler wouldn't need it, they'd probably put it in a supplement of some kind or maybe the reference book)

Current status is: Doom 0.2 can launch and display the TITLEPIC. It gets stuck in an infinite loop waiting for variable lastscan to change (normally it is changed by the installed custom keyboard interrupt handler but obviously there is no such thing now). If that loop is patched out, it gets into the game and draws the HUD border but no actual game view and gets stuck in another loop inside IO_NewFrame where it is waiting for processedframe != playercmdframe[consoleplayer]. If THAT loop is also patched out, it fails due to a divide by zero in FixedDiv (called from R_DrawPlanes, at 0x69CE). If I install an exception handler that just ignores divides by zero, it does not crash but still draws nothing on screen except for the view border. forgot to increment the instruction pointer inside the exception handler, anyway it's still not working, it's crashing in HIGHBLIT now forgot that obviously I need to alloc executable memory in my malloc hook handler because of that thing, now it's not crashing but it still isn't drawing the game view on screen either I dunno how much more I'm going willing work on this, running the 0.2 alpha isn't that useful. OMG IT FINALLY DID SOMETHING INTERESTING It's just stuck there but at least it rendered one actual ingame frame. Also the guess at the fixup data format seems 100% correct so far. (full list of fixups from Doom v0.2) (I'm going to say it IS 100% correct since the loder managed to launch the game)

It probably tells the fixup type at least, eg. you may need to fixup a 16-bit addres in some cases.

Yeah, I already figured that out and edited the previous post. :P ATM I'm going to try and see if I can get v0.2 or v0.3 to launch inside a 32-bit process in Windows/Linux (so like LE loader but for MT).

@SaladBadger First, read 32-bit value at @ 0x18 (=0x3A in Doom 0.2) and jump to there, that is the start of fixup data. Here are two 16-bit values, first is the count of fixup records following, the second is unknown so far. Now follow count times 16-bit values which are the fixup records themselves. I think the first n bits may be some sort of flags (eg. if you take first 4 it's always 8 in Doom 0.2) and then the next n bits are the fixup source address. Target address isn't specified at all, the loader must just read the unrelocated value already stored in the code/data anyway (this is how Windows PE .reloc data also works). If you loop through the data setting addr=value&0x7FFF, the addresses all make sense for Doom v0.2, up until and including 0xFFF5 which becomes 0x7FF5. That's also at the end of the first fixup "section". If you don't filter the bits at all, the addresses from the first "fixup section" will be 0x8000 too high, but then the addresses from the second section (eg. first is 0xD974) do match reasonable locations in the exe or memory dump. edit: hmm I guess the unknown value stored along the count of fixups in "section" may be related? In Doom 0.2 it's 0 for the first fixups, 1 for the second, 4 for third, 7 for fourth. If you filter addresses with &0x7FFF, then take that unknown value and multiply it by 0x8000, and use it as the base address for fixups in the following "section" you get this. I have to go through some of those and see if they're reasonable... (output format in that paste is raw 16 bit fixup data => guessed bit flags, guessed address)

Okay I can't really be bothered to cut the dumps to exact size, BUT here are 2MB memory dumps for Doom 0.2 and 0.3 you can load as raw 32-bit binaries @ 0x2000000 (entrypoint is 0x2000010). Lots of nulls at the end so they compress to about 80kB. They were both dumped just as the C main() function of the game started executing (breakpoint on first instruction). For some reason the exes weren't fully loaded in memory if I set the breakpoint on 0x2000010 (at the jump just before "dbgoto main" which seems to be the real start of code section and also entry point), at least it looked that way in the debugger's data view... @SaladBadger did you already create a tool for dumping the debug symbol info (and perhaps convert it to a IDC or MAP file) from Doom 0.2? As for 0.3, seems it doesn't have any symbols. :( MemDumps.zip edit: Hey look at what's on eBay. Sadly it is too expensive to buy just for something like this (and the seller does not even offer shipping to Europe, though of course they might agree to it if asked), and it probably does not even have any information on used file formats. There's also at least a "Intel 386/486 C Code Builder Kit Reference Manual" besides this book. Finding the complete v1.1 version of the compiler could also be helpful but it seems the only thing leaked to the public Internet is the incomplete v1.0 package. edit2: The "DT" debug info header which begins straight after the main game "MT" in 0.2 is probably: 000 uint16_t magic 002 uint32_t totalsize....: 0x0001abef (109551) 006 uint16_t recordcount..: 0x0007 (7) 008 uint16_t unknown......: 0x001c (28) then recordcount times uint32_t pointers to different kinds of debug data table1[0]: 0x0000f799 (63385) table1[1]: 0x00011036 (69686) table1[2]: 0x000149be (84414) table1[3]: 0x0001a7d4 (108500) table1[4]: 0x000202e0 (131808) table1[5]: 0x00022a5d (141917) table1[6]: 0x000247c6 (149446) These are counted starting from the beginning of the main game MT, not from the DT header (or whole exe). I do not know how exactly the debug data structures or tables those pointers to work yet. It does not seem like the 7 pointers just point to debug data for 7 source files because the formats look completely different, though if you only look at what's every other pointer it seems more similar. I'll take a look at the fixups for you tomorrow. Also the dword at 0xE in the main header (unknown4) definitely seems to be initial stack pointer. Try setting a breakpoint on program entry in DOSBox, change it and compare ESP values. yet more editing: @SaladBadger I'm starting to get how the fixups work now. I'm too tired to investigate more, write good explanations or post some code right now thoug (been having some problems getting sleep...) Remove the last uint32_t from the main header definition, that's already part of fixup data. It probably tells the count of fixup records (probably each is exactly 2 bytes) which follow (=0x4AD in v0.2). If you skip that many bytes*2 ahead, you'll hit what I think is another fixup record count with more records to follow. After the first count you can see the fixup data starts 0x15 0x80 0x36 0x80 ... ... Well, if you look at the disassembly, 0x15 and 0x36 (0x2000025 and 0x2000046 after relocation if you look at memdumps that start from 0x2000000) are excatly where the first addresses that need fixups applied are in the code, parts of mov instructions. This actually mighy be much less overdone than LE fixups (and more like PE was IIRC). I've also got a little trick for you that might help investigating more: you can change the address the loader will load the MT to in memory! Open the exe in a hex editor, see how there's "ORG=" in ASCII near the beginning and 0x2000000 in binary (00 00 00 02) right after that? Well, you can change the value and it really does also change the load address! But beware, some addresses will just crash DOSBox. ORG=0x3003412 (12 34 00 03) is one alternative to 0x2000000 that works. Now you can generate two memdumps using the DOSBox debugger with the game relocated to two different base addresses and compare them to quickly find all locations where fixups are applied.