[v1.1a] REKKR/Sunken Land DOS Standalone

Good stuff. Rekkr is really great, I'll be excited to get it going in DOS!

@Redneckerz sorry I'm late with this btw lol

Now this is awesome.

Great work, Rift!

11 minutes ago, OpenRift said:

@Redneckerz sorry I'm late with this btw lol

No worries! I just realized you also did one with Hacx (As in, i never saw the original thread!) and made a missed opportunity to call that executable DHehx haha.

This is some epic stuff. This shouldn't be hosted on Google Drive! @Doomkid do you think this could be on the Shack or heck in your Vanilla oriented threads?

So some real talk here:

• So Rekkr Classic is now its own DOS game, correct? No FreeDoom stuffs applied. This is even more standalone than HacX DOS, right?
• REKKR.EXE is based on.. Doom2.exe?
• Any plans on making these GPL-compatible when using the recreated Doom2.exe sources from Gamever?
• The second link still links to Rekkr-DOS and not Sunken Land.

@MrFlibbletagging you here because this might be worthwhile to push forward unto other sites (RekkrClassic atleast!).

I should try and see if i get a 486 like experience going. Really love to see how it runs on DOS.

@viti95perhaps you can also chime in and see how Rekkr performs on your systems? FastRekkr, perhaps? ;)

Wow, this is a really cool project. I'll chuck this on my win98 / dos machine, cheers :)

1 hour ago, Redneckerz said:

• So Rekkr Classic is now its own DOS game, correct? No FreeDoom stuffs applied. This is even more standalone than HacX DOS, right?
• REKKR.EXE is based on.. Doom2.exe?
• Any plans on making these GPL-compatible when using the recreated Doom2.exe sources from Gamever?
• The second link still links to Rekkr-DOS and not Sunken Land.

1. Yes, pretty much.
2. REKKR.EXE is based on Doom.exe, since it's an Ultimate Doom WAD.
3. I had been thinking about it, yeah. Although I'm not sure how well the recreated EXEs would play with dehacked, even with adjusted offsets and size in the dehacked.ini. I'd probably need some help with doing that.
4. Whoops! Just fixed it, it should work now.

19 hours ago, Redneckerz said:

 

@MrFlibbletagging you here because this might be worthwhile to push forward unto other sites (RekkrClassic atleast!).

Thanks, I'm interested! But I'd also much prefer a clean GPL-compatible binary, not a DeHackEd Ultimate Doom one, as you've mentioned.

19 hours ago, Redneckerz said:

Any plans on making these GPL-compatible when using the recreated Doom2.exe sources from Gamever?

18 hours ago, OpenRift said:

I had been thinking about it, yeah. Although I'm not sure how well the recreated EXEs would play with dehacked, even with adjusted offsets and size in the dehacked.ini. I'd probably need some help with doing that.

If you are to use NY00123's reconstructed DOS sources as @Redneckerz suggested, maybe it would be easier to apply all actor changes right in the code, before compiling the binary, as opposed to messing with DeHackEd and data offsets?

7 minutes ago, MrFlibble said:

If you are to use NY00123's reconstructed DOS sources as @Redneckerz suggested, maybe it would be easier to apply all actor changes right in the code, before compiling the binary, as opposed to messing with DeHackEd and data offsets?

Honestly, I'm not really a programmer, so I can't really say that applying all of this code-wise would be easier per se. Because you would have to enter everything manually, which just seems like a lot for someone as lazy as myself. As I've said before, I'll probably need assistance if I were to go that route.

I'm not a programmer either, but the data changed by DeHackEd seems simple enough to track down and alter in the sources, e.g.

Thing 2 (Former Human)
Hit points = 45
Attack sound = 3
Close attack frame = 184
Width = 1048576
Far attack frame = 0
Speed = 14

After a cursory glance at the sources, plus consulting this, it appears that the respective data is found in info.c

This should be the Former Human from info.c:

{		// MT_POSSESSED
3004,		// doomednum
S_POSS_STND,		// spawnstate
20,		// spawnhealth
S_POSS_RUN1,		// seestate
sfx_posit1,		// seesound
8,		// reactiontime
sfx_pistol,		// attacksound
S_POSS_PAIN,		// painstate
200,		// painchance
sfx_popain,		// painsound
#if APPVER_CHEX
S_POSS_ATK1,		// meleestate
0,		// missilestate
#else
0,		// meleestate
S_POSS_ATK1,		// missilestate
#endif
S_POSS_DIE1,		// deathstate
S_POSS_XDIE1,		// xdeathstate
sfx_podth1,		// deathsound
8,		// speed
20*FRACUNIT,		// radius
56*FRACUNIT,		// height
100,		// mass
0,		// damage
sfx_posact,		// activesound
MF_SOLID|MF_SHOOTABLE|MF_COUNTKILL,		// flags
S_POSS_RAISE1		// raisestate
 },

I just realised that I completely forgot to factor in a rather obvious matter: if we're using the vanilla binary or any GPL-compatible recreation, this effectively means discarding the bugfixes hat have been long taken care of by source ports. Here's a list of improvements that BOOM makes for example:

So if we take the MBF binary instead of the vanilla one, that would effectively solve the DEH loading problem as MBF handles those internally without patching, plus providing a lot of bug major fixes and optimizations compared to the original Doom. The task of making a dedicated REKKR DOS binary would then amount to changing minor things like a few text strings.

@Redneckerz I'll give it a try, I love seeing new games developed for DOS.

On 2/8/2022 at 11:53 PM, OpenRift said:

1. Yes, pretty much.
2. REKKR.EXE is based on Doom.exe, since it's an Ultimate Doom WAD.
3. I had been thinking about it, yeah. Although I'm not sure how well the recreated EXEs would play with dehacked, even with adjusted offsets and size in the dehacked.ini. I'd probably need some help with doing that.
4. Whoops! Just fixed it, it should work now.

1. Great. Fascinating to see a native DOS game released in 2022 in glorious 320x200 :)

2. Yeah, my bad. The classic release is a Doom based iwad.

3. Luckily, we have a programmer in our midsts... ;) But the recreated source is put to use it seems!

4. Appreciated!

On 2/9/2022 at 6:23 PM, MrFlibble said:

Thanks, I'm interested! But I'd also much prefer a clean GPL-compatible binary, not a DeHackEd Ultimate Doom one, as you've mentioned.

Its both, actually - The executable is actively modified, but it also has a DeHacked patch because of the monsters.

Moving this to a recreated executable would atleast make the whole package more legal - As in, its not the propetiary original anymore. But even so, even as-is the legality question isn't controversal - Id-Software has never protested against these since 1997 as far as i know.

On 2/9/2022 at 6:23 PM, MrFlibble said:

If you are to use NY00123's reconstructed DOS sources as @Redneckerz suggested, maybe it would be easier to apply all actor changes right in the code, before compiling the binary, as opposed to messing with DeHackEd and data offsets?

That would change the code significantly - The reconstructed source should be vis-a-vis the same. I am not sure if you can go beyond DeHacked - That usually means hardcoding it in the IWAD itself. @Revae was working on a Sunken Land update, but not something of this magnitude.

Speaking of which Revae, you should totally check this out, as your game is now a full native DOS title :)

6 minutes ago, Redneckerz said:

That would change the code significantly - The reconstructed source should be vis-a-vis the same. I am not sure if you can go beyond DeHacked - That usually means hardcoding it in the IWAD itself.

I suggested making the changes that are currently handled by REKKR's DeHackEd patch right in the source code of the prospective DOS binary, instead of applying said patch after compiling. I fancy these should be technically easy to do, at least this is the impression I got from looking at the code, with the example above. I did not mean making any changes beyond what the DEH patch currently does -- that would be superfluous. Or did I misunderstand your comment?

11 minutes ago, Redneckerz said:

even as-is the legality question isn't controversal - Id-Software has never protested against these since 1997

Well, since there is an easy GPL-compliant option that does not come burdened with these possible concerns -- I mean using a clean MBF binary which internally handles DEH patches -- then why consider using a hacked id binary at all? It does not make the result more authentic IMO, plus there are unfixed bugs as I mentioned above.

Rad

On 2/10/2022 at 9:54 PM, MrFlibble said:

I suggested making the changes that are currently handled by REKKR's DeHackEd patch right in the source code of the prospective DOS binary, instead of applying said patch after compiling. I fancy these should be technically easy to do, at least this is the impression I got from looking at the code, with the example above. I did not mean making any changes beyond what the DEH patch currently does -- that would be superfluous. Or did I misunderstand your comment?

I still think that requires hardcoding the changes into the executable or WAD, because what you describe isn't a internal dehacked lump, which is present in REKKR.EXE (Which integrates the patch directly).

On 2/10/2022 at 9:54 PM, MrFlibble said:

Well, since there is an easy GPL-compliant option that does not come burdened with these possible concerns -- I mean using a clean MBF binary which internally handles DEH patches -- then why consider using a hacked id binary at all? It does not make the result more authentic IMO, plus there are unfixed bugs as I mentioned above.

Making it MBF means its not a vanilla executable anymore. MBF has significantly expanded features, but going MBF may make it clean but it does not make use of anything that MBF supports - On top of whatever additional processing overhead MBF has. A 486 might struggle there.

Now Gerwin has made a shits and giggles version of MBF for 386 processors, but where Vanilla Doom can run quite well on a 486, MBF is a bit more out there.

5 hours ago, Redneckerz said:

I still think that requires hardcoding the changes into the executable or WAD, because what you describe isn't a internal dehacked lump, which is present in REKKR.EXE (Which integrates the patch directly).

Well, there are two ways here I think. If @viti95 implements DEH support akin to BOOM/MBF in FastDoom, that would likely be the easiest solution from the end-user's standpoint, but such implementation could be a ways away in FastDoom's development roadmap.

The other, which I mentioned above but probably phrased poorly, is to manually transfer the changes in REKKR's DEH lump/file into NY00123's reconstructed code. Like, the DEH file changes Thing 2's hit points to 45, you find the respective part in info.c and change Doom's default value to 45, etc. etc. down the list. It should not be hard from a technical standpoint, but will take a while to carefully make all the changes. I believe that when this is done and the code is compiled into a binary, no further modification of said binary or the IWAD should be necessary.

I think that in some prior discussion, there was mentioned a DOS port/reconstructed binary other than the ones discussed here, which can also internally handle DEH patches similar to MBF. If that is indeed a possibility, perhaps this could serve as the third option?

5 hours ago, Redneckerz said:

Now Gerwin has made a shits and giggles version of MBF for 386 processors, but where Vanilla Doom can run quite well on a 486, MBF is a bit more out there.

I never looked deep into the details, but I distinctly remember either BOOM or MBF claiming better performance in the speed department compared to vanilla Doom, and Gerwin's updates (I mean the 2.04 maintenance release, not the 386 version) supposedly pushed that even further. Does MBF 2.04 still play slower compared to vanilla on a 486?

On 2/12/2022 at 9:15 PM, MrFlibble said:

Does MBF 2.04 still play slower compared to vanilla on a 486?

Alrighty, found the answer myself -- I vaguely remembered there was a dedicated thread by Gerwin. However, it looks like the most recent versions of MBF 2.04 are pretty close in terms of FPS in memory buffer to mode 13h mode. Also Gerwin mentions an updated BOOM 2.03 -- that should be usable as well, if this version has been released, because BOOM can also read DEH patches, just not from inside WADs (IIRC).

Just giving this a bump for those who downloaded the update already today: be sure to download again for Sunken Land, had to fix some issues.

@OpenRift, I noticed that you added custom exit messages and cheat codes, are these your own invention, or from the official Sunken Land binary? (I've not got Steam installed ATM so I cannot check the latter).

Nevermind, I installed Steam and Sunken Land, the new exit messages are found in the LANGUAGE lump inside REKKRSL.iwad.

UPD: the same exit strings may be found in the regular free version (both PWAD and stand-alone IWAD) include the LANGUAGE lump, but they're not used in vanilla DOS or Chocolate Doom.

3 hours ago, MrFlibble said:

Nevermind, I installed Steam and Sunken Land, the new exit messages are found in the LANGUAGE lump inside REKKRSL.iwad.

  

UPD: the same exit strings may be found in the regular free version (both PWAD and stand-alone IWAD) include the LANGUAGE lump, but they're not used in vanilla DOS or Chocolate Doom.

Yeah, I hex-edited those into the DOS exe.

@OpenRift, what about the cheat codes? Sunken Land appears to be using the original Doom ones (at least, the console accepted iddqd but not msslayer). Cheats should be replaceable via DeHackEd too, at least the original HacX release did that IIRC, but the REKKR DEH pattch does not contain any cheat replacements.

UPD: Found the answer here literally in less than a minute after asking.

I didn't change any console commands. But as you saw, I did add cheats in. Theyyyy're:

all keys: 0451

all weapons: 0849

godmode: 1337

noclip: 8000

powerup drops:

5115 - map

5335 - protection boots

5775 - wode

5135 - invuln

5995 - torch

summons a friendly bunny: 1253

mirrormode: 0690

8 hours ago, MrFlibble said:

@OpenRift, what about the cheat codes? Sunken Land appears to be using the original Doom ones (at least, the console accepted iddqd but not msslayer). Cheats should be replaceable via DeHackEd too, at least the original HacX release did that IIRC, but the REKKR DEH pattch does not contain any cheat replacements.

 

UPD: Found the answer here literally in less than a minute after asking.

It's also literally in the main post in the Cheat codes section...