Knee-Deep in KDiZD: Released! It's KDiZD for doom2.exe - 1.7.1 is now on /idgames

[esselfortium]

23 minutes ago, Altazimuth said:

Correct. Options > Status Bar >  Single Key Display (set to no).

Thanks, I should probably put that in the OPTIONS lump.

 

25 minutes ago, TasAcri said:

Is it possible to make an addon-mod that replaces the Super shotgun with the original one?

 

I never understood why they decided to change the original with that ugly KDIZD model.

KDiZD doesn't use any Doom 2 assets at all, so they needed to do new SSG sprites.

 

It would be possible for you to edit KDiKDiZD to use the original Doom 2 sprites instead if you want that, but I think the KDiZD SSG has a different number of animation frames than the Doom 2 one, so it would possibly be awkward to do without also modifying the dehacked patch.

[nickxcom]

Playing through this new build in Nugget Doom just to switch it up a bit. I'm still Still blown away by how most of this is even possible in Vanilla to be honest. Great music too, especially with a good soundfont. My thanks to everyone on the team for this one.

[Vader]

I think I found the culprit for the secret exit not working for me... I was using the german version of the Doom2 IWad wich censores the secret Wolfenstein maps and thus directly goes to map 16. However, I never had problems with other mapsets so far using it and I alway assumed this version just didn't have a map31 and 32 and that's it.

Normally I don't use Eternity much, so I wonder if it is an engine specific thing? Does it have a check for this particular version of the Iwad and prohibits the secret exit in map15 to work altogether?

Trying it on another megawad seems to confirm this, as it didn't work there either.

 

Either way, I'm using the BFG edition Iwad now and it takes me to z1m9 as intended :D

[Altazimuth]

6 minutes ago, Vader said:

I think I found the culprit for the secret exit not working for me... I was using the german version of the Doom2 IWad wich censores the secret Wolfenstein maps and thus directly goes to map 16.

I'm going to sleep now so can't reply further but that looks like it may be the case. It looks like Boom is what introduced that behaviour initially, via a variable called "haswolflevels", so maybe dsda-doom exhibits the same thing. It probably should be fixed in some capacity, though I'll need to get my mitts on the German IWAD to do so.

[Gregor]

I have a question: I decided to play the original KDIZD to better appreciate the differences with this set but with the new custom soundtrack by you guys instead of the default Doom tracks it used. Now, when copying the midis from the wad, i noticed that the midi for map13 is named D_E1M1 instead of D_DOOM2, the midi for Map14 is named D_E1M2 instead of D_DDTBL2, and so forth. Why does renaming them work in vanilla here?

Edited November 14, 2022 by Gregor

[Captain Ventris]

This is badass. Great visuals all around, the music is fantastic and moody. Really great work and such a good demonstration of the engine. Baffled at what you were able to achieve.

[deathz0r]

14 hours ago, Redneckerz said:

@viti95please test this out in Fastdoom.

 

What amount of SDRAM is needed for real DOS vanilla compatibility?

The amount of RAM is irrelevant for SDRAM, since the smallest SDRAM sticks I'm aware of are 16MB - the more important reason for why SDRAM (late-socket 7 motherboards until early-Pentium 4/Athlon XP) is preferred over EDO (late-486 until mid-socket 7) or FPM (mid-286 until mid-socket 7 - both EDO and FPM can be found as 72-pin sticks that are mechanically and electrically compatible) RAM is simply because the thoroughput of SDRAM is significantly higher than both EDO and FPM. Additionally, the L1 cache of socket 7 CPUs has anywhere between twice to four times the thoroughput of 486 CPUs and since this was still an era where L2 cache was on the motherboard, there were improvements with the mobo chipsets combined with lower latency and increased thoroughput of newer cache chips which also significantly improve the performance. Different mobo chipsets can also impact performance, but I don't have enough mobos sitting around to get data that granular. (also I killed the socket 7 mobo that I did the playtesting from Z1M3 onwards, and prices for good socket 7 mobos are stupid on eBay)

 

So why is that relevant?

 

For shits and giggles I started doing my playtesting playthrough on a 486 DX4-100 setup (with a good ol' VLB video card and FPM RAM) and I got through Z1M1 and Z1M2, noticing that there was increasing amount of stutter the further I progressed. When I was testing Z1M3, I was noticing atrocious performance with vanilla in

 

the computer area map room

 

even when using a 1.4Ghz Pentium 3 setup (quick sidenote: L2 cache is now baked in the CPU and running at full speed at this point, so there's no longer a performance penalty between L2 cache on a mobo and a CPU) where it was getting choked hard and continuously stuttering non-stop. Something didn't seem right about that and I told essel about it. A bit of optimising with animated textures happened and suddenly Z1M3 became a lot more playable. I decided to go back and check the start of Z1M2 (as there's noticable delay between being teleported into the main map) and figured out from that what was the minimum CPU and type of RAM required - Z1M2 being a good indicator because it has a ton of midtex work at the start of the main map and 486 CPUs choke on heavy midtex usage, 386 CPUs choke even harder relative to their performance.

 

My estimate for 32MB is based on the testing before animated texture optimisation - I suspect 16MB would have a small amount of stutter in certain areas. I have picked up a "cheap" socket 7 mobo a couple days ago which has both SDRAM and EDO/FPM slots, so I can do a bit more testing for whether there's a difference in the stuttering for texture/flat heavy areas like Z1M3. I'll get to that soon(tm)

[Shepardus]

34 minutes ago, Gregor said:

I have a question: I decided to play the original KDIZD to better appreciate the differences with this set but with the new custom soundtrack by you guys instead of the default Doom tracks it used. Now, when copying the midis from the wad, i noticed that the midi for map13 is named D_E1M1 instead of D_DOOM2, the midi for Map14 is named D_E1M2 instead of D_DDTBL2, and so forth. Why does renaming them work in vanilla here?

The DeHackEd has string replacements like

Text 6 4
ddtbl2e1m2

Plutonia 2 is another WAD that does the same.

[NightFright]

Is it intended that there are two different INTERPICs in these wads? One overwrites the other in the end.

[ludicrous_peridot]

9 hours ago, esselfortium said:

Those flags are for color remapping (normally used for multiplayer player sprites), to go along with the palette changes.

 

Thanks! I was making an assumption that these were some undocumented magic flags, but indeed I can just see them in dehacked.exe when I load the patch. This explains the issue I am seeing as being due to how Tartar does blood puff recoloring by translating the red ramp, which makes this quite fix-able.

[TasAcri]

Playing this with OPL1 emulated, the music sounds glitchy and weird. At least on map 3.

 

Is the music made with more modern soundfonts in mind?

[ludicrous_peridot]

12 minutes ago, TasAcri said:

Playing this with OPL1 emulated, the music sounds glitchy and weird. At least on map 3.

 

Is the music made with more modern soundfonts in mind?

 

I think they wrote above the mod had MIDI soundtrack, so the way I interpret this is it will sound good with any synthesizer that is SoundCanvas-like, e.g. MS built in one if you are on windows, or SC-55 patches (quite a few of them out there) with anything else, but not necessary with an Adlib.

 

EDIT: If you an FM-music fan, you could try an OPL MIDI synthesizer, like ADLJack for example, and see if this gives you grooves you are after without actual OPL emulation in the engine.

[esselfortium]

5 minutes ago, ludicrous_peridot said:

 

I think they wrote above the mod had MIDI soundtrack, so the way I interpret this is it will sound good with any synthesizer that is SoundCanvas-like, e.g. MS built in one if you are on windows, or SC-55 patches (quite a few of them out there) with anything else, but not necessary with an Adlib.

Yes, SoundCanvas instruments are definitely the way to go. The default Windows midi synth should be fine.

 

OPL emulation seems to really struggle with the voice count on these midis, so lots of notes drop out or don’t get played at all.

[esselfortium]

2 hours ago, NightFright said:

Is it intended that there are two different INTERPICs in these wads? One overwrites the other in the end.

Oops, no, that’s just an oversight.

[NightFright]

I guess the one showing the ep.1 intermission screen is the intended one?

[esselfortium]

7 minutes ago, NightFright said:

I guess the one showing the ep.1 intermission screen is the intended one?

Yep.

[ni1chigo2115]

I would like to see it working in UnityDoom somehow, but from the thread, it seems like I need to get the developer's cooperation. It seems difficult to make it happen. (I'm afraid we'll have to fight over the rights to the additional enemy sprites to begin with...)

 

Incidentally, when I first saw this project, playing in VR was on my mind, although it is true that if you want to have fun with QuestZDoomVR, which can only be based on GZDoom, it is better to play in the original KdiZD. (I kind of wanted to play the original KDiZD in VR, I think this project will have a good influence on the original KDiZD in terms of comparison. Great!!!)

[Murdoch]

"Advanced Objective System" "Make demons leave".

Sound plan.

 

But yeah this looks crazy. Hard to believe it is fully vanilla compatible.

[roadworx]

On 11/12/2022 at 7:02 PM, deathz0r said:

Having tested this on vanilla with a REAL 90s PC, I can say that you need a Pentium MMX @ 166Mhz and SDRAM to run this somewhat smoothly but there's only so much you can do to get around the 8MB heap size limit of vanilla, so there's still unavoidable stutter especially when there's lots of textures and flats. Using doom32 and having sufficient RAM (most likely 32MB) will most likely remove the main performance bottleneck, but I was interested in making sure that KDiZDiZD [WORKS IN INTENDED SOURCE PORT] and I'm glad that I got to see cool shit going on and helped point out performance bottlenecks.

 

It makes me want to see FastDoom's dehacked support get improved massively, because I'm curious to see it working at good speed on a 486DX4-100.

unfortunately doom32 doesn't work with dehacked, at least not when i tried it on my win98 pc ;-;

[Doomkid]

I can confirm that if you rename Doom32.exe to Doom2.exe, it will work perfectly with DeHackEd even on Windows 98! The trick is just renaming it, as far as I can tell.

[roadworx]

6 minutes ago, Doomkid said:

I can confirm that if you rename Doom32.exe to Doom2.exe, it will work perfectly with DeHackEd even on Windows 98! The trick is just renaming it, as far as I can tell.

i actually did do that. the issue is that dehacked seems to do a verification process, and unfortunately this causes it to not recognize doom2.exe despite the file (albeit a modified version) existing and dehacked.ini correctly pointing to its location. iirc @Altazimuth (i think it was him, anyways) said something about dehacked not being able to detect the file if a header or something isn't in the correct place? i don't remember the specifics, but i do know that doom32 is different enough that it can't be read by dehacked

Edited November 14, 2022 by roadworx

[Doomkid]

13 minutes ago, roadworx said:

i actually did do that. the issue is that dehacked seems to do a verification process, and unfortunately this causes it to not recognize doom2.exe despite the file (albeit a modified version) existing and dehacked.ini correctly pointing to its location. iirc @Altazimuth (i think it was him, anyways) said something about dehacked not being able to detect the file if a header or something isn't in the correct place? i don't remember the specifics, but i do know that doom32 is different enough that it can't be read by dehacked

Hmm.. that’s really strange. Doom32.exe is absolutely DeHackEd compatible beyond any shadow of a doubt. I suggest scrapping dehacked.ini altogether as it’s an unreliable piece of garbage and just doing it the automated way, it’s likely to get around the issue you’re experiencing. This quote below should get you where you need to be:

 

On 10/28/2020 at 4:05 PM, Doomkid said:

1) Pop these files: dehpick.zip in your clean Doom2 directory alongside whatever wads and dehs you want to play

2) Run DEHMAKE.BAT, pick the .deh you want to be applied to DOOM2.EXE. For example if you wanted to apply HELLO.DEH, this would convert it to HELLO.EXE

3) You then just type "hello.exe -file example.wad" to run it

 

It's so, so much faster than manually loading up DEHACKED.EXE and applying patches by hand. For this reason having wads and dehs in a subdirectory is my recommendation. Just copy whatever wad and deh you want to to play in that moment to your main dir, use dehmake to patch it in a flash, and load as normal.

 

If you have loads of wads and dehs, using the DIR command "dir > listmyfolder.txt" will output a textfile with the full contents which can be easily referenced. A GUI for DOS that automates this process even further would be swell, but I think the majority of people looking for something that easy are probably going to flock to GZDoom, or Chocolate if they still care about compatibility stuff.

 

Other than throwing up a cursory warning when you do stuff manually, DeHackEd doesn’t actually “care” if the checksum of the EXE doesn’t match - it’ll just let you know that’s the case.

 

Edit: Just to be ultra-clear for you and any other future readers, the process is the same with a Doom32.exe that’s been renamed to Doom2.exe

[Redneckerz]

17 minutes ago, Doomkid said:

I can confirm that if you rename Doom32.exe to Doom2.exe, it will work perfectly with DeHackEd even on Windows 98! The trick is just renaming it, as far as I can tell.

Interesting detail. So basically VULD can use Doom32 if it is renamed, so one could make a custom DoomHack build with the DEH patch built in - and yet been able to use all that Doom32 provides.

 

I am actually surprised DeHacked cares so little about it - So a Doom32 version of DoomHack is definitely possible, if a bit obtuse.

[taufan99]

21 minutes ago, Doomkid said:

I can confirm that if you rename Doom32.exe to Doom2.exe, it will work perfectly with DeHackEd even on Windows 98! The trick is just renaming it, as far as I can tell.

May I know if this works for Doom128 as well?

[WH-Wilou84]

FDA on Z1M9 : https://www.dropbox.com/s/64rhndywtetm094/KDiKDiZDZ1M9-fda-wh.zip?dl=1
(DSDA Doom on UV)

YouTube video :
 

Forcefields, warping flesh and liquids, and now rain... Just how many animated textures are in there ? :)
 

[Doomkid]

The DoomWiki page says that Doom128 is incompatible with DeHackEd so I assume it has been tested… I’m not at my PC presently but when I am, I’ll be sure to double check.

 

And following up Rednecker’s post, yep, Doom32 is fully compatible. I usually use it in place of Doom2.exe for most any mods, just to get around those rare-but-still-present moments where a mostly-vanilla wad accidentally hits 129 visplanes!

[Redneckerz]

42 minutes ago, taufan99 said:

May I know if this works for Doom128 as well?

Gibbon tested it and it doesn't - Mind you, Doom128 is based of Gamesrc-recreation, a reverse engineered duplicate of Doom2.exe.

Whereas Doom32 is based off Doom2-plus, which is a expanded version of the original Doom2.exe.

 

37 minutes ago, Doomkid said:

The DoomWiki page says that Doom128 is incompatible with DeHackEd so I assume it has been tested… I’m not at my PC presently but when I am, I’ll be sure to double check.

Yes, please do.

37 minutes ago, Doomkid said:

 

And following up Rednecker’s post, yep, Doom32 is fully compatible. I usually use it in place of Doom2.exe for most any mods, just to get around those rare-but-still-present moments where a mostly-vanilla wad accidentally hits 129 visplanes!

With that said, i have edited the relevant wiki pages to denote that DeHacked can use Doom32, but also use it to make Doom32-compatible DoomHack executables.

[GarrettChan]

4:12, there's an odd Cacodemon who is set to ambush, not sure whether it's intentional

I feel the whole map in general has way too many normal Armors. There are like 4 or even more? I guess you don't really have enough health to deplete all those lol.

[baja blast rd.]

50 minutes ago, GarrettChan said:

has way too many normal Armors. There are like 4 or even more? I guess you don't really have enough health to deplete all those lol.

Keep them to make a wardrobe. 

 

Spoiler

 

[Thelokk]

1 minute ago, baja blast rd. said:

Keep them to make a wardrobe. 

 

  Hide contents

 

 

There is, or rather, there was a Waldo in that wardrobe.