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

I'm a bit confused, this is meant to be doom2.exe compatible?  Therefore it should be able to run on any gzdoom version, yet when I try to load it on an older gz I get "version mismatch, 4.8.0 expected but only 3.5.1 supported script error - kdizd_a.wad zscript line 1"

I was hopeful that I can try it on an older machine because someone in another friend mentioned it bogging down a pentium 4 in dos, and I don't really have such a machine under dos that I can really use... iirc I'd need sound card drivers, then there's having too much memory in the machine, etc.

On 11/26/2022 at 3:42 PM, Woolie Wool said:

And I never expected to see a vanilla mapset make framerates drop on my 1733 MHz Athlon rig (I used doom2-plus under PC-DOS 7).

Athlon xp 2100, socket 462?  Did you boot pc dos 7 off of a usb stick?  I have a heap of machines between this era, right up to core 2 duos and I want to try it on each machine until I find one that can handle the wad fine.  But I really don't want to install dos and sound drivers on every single one, so I'm hoping I can boot off of usb.  EDIT: ran it on zdoom on a p2-450 laptop and I didn't come across any areas that slowed down, not at 800x600 at least.

10 minutes ago, invictius said:

I'm a bit confused, this is meant to be doom2.exe compatible?  Therefore it should be able to run on any gzdoom version, yet when I try to load it on an older gz I get "version mismatch, 4.8.0 expected but only 3.5.1 supported script error - kdizd_a.wad zscript line 1"

GZDoom is actually the one port that can't run the mod natively, due to how far removed it is from the original engine. To supplement this, zscript is provided as a compatibility stopgap to work around it's physics and dehacked incompatibilities. Zscript files are not backwards compatible, so if you're stuck with that version of GZDoom, you'll have to instead pick an different source port.

I remember this from over a decade ago. Played through this on my IBM power9.

haven't downloaded a custom wad in probably the same amount of time.

I wish the "flare gun" was a hitscan rifle instead like the original kdizd.

I've noticed a couple of strange bugs I'm having trouble pinning down.

Playing the latest stable release of Eternity Engine. 

• Sometimes the map will begin with severely reduced items. Not all items, but most weapons, health and armour are gone. I noticed this in map 15.
• During one run, monsters seemed to disappear on death. As in, they wouldn't leave a corpse, they'd just vanish.

Is anyone else experiencing this?

13 minutes ago, nobleflame said:

I've noticed a couple of strange bugs I'm having trouble pinning down.

 

Playing the latest stable release of Eternity Engine. 

• Sometimes the map will begin with severely reduced items. Not all items, but most weapons, health and armour are gone. I noticed this in map 15.
• During one run, monsters seemed to disappear on death. As in, they wouldn't leave a corpse, they'd just vanish.

Is anyone else experiencing this?

If I remember right, there was a dehacked bug in some builds of Eternity that could cause this. It’s fixed in the latest drdteam builds.

3 hours ago, esselfortium said:

If I remember right, there was a dehacked bug in some builds of Eternity that could cause this. It’s fixed in the latest drdteam builds.

Nice, I've upgraded and haven't had any issues since. Thanks for getting back to me :)

I am still highly interested how this runs on a geniune DOS machine. @invictius @viti95 any progress on that?

In fact, Knee Deep in KDIZD seems like a perfect benchmark to test this out on different hardware... From 486 DX2 to AMD Elan to Cyrix with Xpressgraphics IGP.

2 hours ago, Redneckerz said:

I am still highly interested how this runs on a geniune DOS machine. @invictius @viti95 any progress on that?

 

In fact, Knee Deep in KDIZD seems like a perfect benchmark to test this out on different hardware... From 486 DX2 to AMD Elan to Cyrix with Xpressgraphics IGP.

Still no, haven't finished yet my moving so I have pretty much no time available for projects. I hope next weeks will be more productive.

On 2/6/2023 at 4:54 PM, Redneckerz said:

I am still highly interested how this runs on a geniune DOS machine. @invictius @viti95 any progress on that?

 

In fact, Knee Deep in KDIZD seems like a perfect benchmark to test this out on different hardware... From 486 DX2 to AMD Elan to Cyrix with Xpressgraphics IGP.

I had issues with a dos port running it, however if zdoom can run it under windows me on a p2-450 laptop with ati rage 128, I don't see why the performance would be any less on dos.  Can you suggest a level that taxes performance?  I may have another go at this under dos but until I know what will stress the machine, there's not much point trying.

36 minutes ago, invictius said:

 

I had issues with a dos port running it, however if zdoom can run it under windows me on a p2-450 laptop with ati rage 128, I don't see why the performance would be any less on dos.  Can you suggest a level that taxes performance?  I may have another go at this under dos but until I know what will stress the machine, there's not much point trying.

That would be the level that uses transparencies. Reason being that VGA/UniVBE cards handle this on a case by case basis? I am not considering this a fact but i do know that VGA cards of that era do find translucency and transparencies difficult. The name forfeits me at the moment, but it is this screenie (Also the room with the reflective floors.)

20 hours ago, Redneckerz said:

That would be the level that uses transparencies. Reason being that VGA/UniVBE cards handle this on a case by case basis? I am not considering this a fact but i do know that VGA cards of that era do find translucency and transparencies difficult. The name forfeits me at the moment, but it is this screenie (Also the room with the reflective floors.)

A bit disappointed, I thought it was going to have something to do with more than just one room. 

21 hours ago, Redneckerz said:

That would be the level that uses transparencies. Reason being that VGA/UniVBE cards handle this on a case by case basis? I am not considering this a fact but i do know that VGA cards of that era do find translucency and transparencies difficult. The name forfeits me at the moment, but it is this screenie (Also the room with the reflective floors.)

You do understand that this is neither transparency nor a reflection, right? Esselfortium is good but she didn't magic new rendering features into the engine, especially ones that would somehow depend on hardware extensions by your context.

10 hours ago, invictius said:

A bit disappointed, I thought it was going to have something to do with more than just one room. 

It is likely more than one level. I was just describing two scenes.

9 hours ago, Edward850 said:

You do understand that this is neither transparency nor a reflection, right? Esselfortium is good but she didn't magic new rendering features into the engine, especially ones that would somehow depend on hardware extensions by your context.

Yes, i know. I am just using incorrect phrasing. Its a shit habit and it just confuses people, especially considering i added the correct explanation on the wiki.

However i do remain curious how old VGA cards deal with the trickery at play.

28 minutes ago, Redneckerz said:

However i do remain curious how old VGA cards deal with the trickery at play.

Given the CPU is the thing doing the rendering, you know because Doom is software rendered, It's an irrelevant inquiry as the graphics card isn't involved in that. The only relevance the graphics card has is the bandwidth available to upload the scene, the map itself plays no part.

1 minute ago, Edward850 said:

It's a completely irrelevant inquiry as the graphics card isn't doing any of the rendering.

At the risk of sounding completely stupid: Doom does do transfers of data to a VGA card to get a picture, right? I get that the CPU does the actual rendering, but the VGA has to do something considering its effects in FastDoom.

1 minute ago, Edward850 said:

Surely you should remember that Doom is software rendered, right? The only relevance the graphics card has is the bandwidth available to upload the scene, the map itself plays absolutely no part.

Yeah that's basically what i am at.

My apologies for sounding more dumb than usual: I have caught a rather severe case of cold so my brain is kind of... mush. It doesn't excuse the stupidity on display though.

20 minutes ago, Redneckerz said:

At the risk of sounding completely stupid: Doom does do transfers of data to a VGA card to get a picture, right? I get that the CPU does the actual rendering, but the VGA has to do something considering its effects in FastDoom.

The effect (which is just a bunch of mid textures drawn at offset in the floor) is already rendered into the buffer by the time the graphics card gets the scene.

Edit: though that may not be entirely true, if the screen is being allocated to the video memory instead of to DRAM (which I can't check). In which case the VGA card does partially play a part in the ongoing drawing, but in the case here only as much as any overdrawing already does in Doom, basically it's simply only a case of memory speed. If mid textures somehow have notable performance loss of a specific card, this will be no different.

16 hours ago, Edward850 said:

The effect (which is just a bunch of mid textures drawn at offset in the floor) is already rendered into the buffer by the time the graphics card gets the scene.

 

Edit: though that may not be entirely true, if the screen is being allocated to the video memory instead of to DRAM (which I can't check). In which case the VGA card does partially play a part in the ongoing drawing, but in the case here only as much as any overdrawing already does in Doom, basically it's simply only a case of memory speed. If mid textures somehow have notable performance loss of a specific card, this will be no different.

What stresses the cpu more than the gpu in levels on opengl-accelerated ports?  I have a newish cpu with an unlocked multiplier, and I was going to underclock it to find out the answer to this myself, but I'm having trouble finding the pc it's in.  If someone could just say "Sidedefs stress it", it would save me a lot of having to dig around a dingy basement in the hope of finding it.

1 hour ago, invictius said:

What stresses the cpu more than the gpu in levels on opengl-accelerated ports?

All thinker work will be 100% CPU, so actors actors actors and more actors.

For pure rendering tasks, the answer will vary with implementation, but generally if you have a very large open space with a lot of detail in it and next to no BSP-based culling possible (in other words: no single-sided lines obscuring the view), that should do the trick. It's not that a visplane, a visseg or a vissprite is, by itself, particularly stressful; it's more that you have a whole lot of them to process so it builds up.

On 2/6/2023 at 4:54 PM, Redneckerz said:

I am still highly interested how this runs on a geniune DOS machine. @invictius @viti95 any progress on that?

 

In fact, Knee Deep in KDIZD seems like a perfect benchmark to test this out on different hardware... From 486 DX2 to AMD Elan to Cyrix with Xpressgraphics IGP.

I already mentioned what I consider as recommended hardware requirements way back in the sixth page.

Honestly, KDiKDiZD is far from the first choice for benchmarking older PCs - the TAS UV-Max of hr2final MAP32 is still the best benchmark that I know of when it comes to vanilla.

On 2/7/2023 at 11:40 PM, Redneckerz said:

That would be the level that uses transparencies. Reason being that VGA/UniVBE cards handle this on a case by case basis? I am not considering this a fact but i do know that VGA cards of that era do find translucency and transparencies difficult. The name forfeits me at the moment, but it is this screenie (Also the room with the reflective floors.)

A better map within KDiKDiZD for testing midtexes would be the starting area of Z1M2 as some angles can cause a noticeable performance drop on a 486 DX4-100, or Z1M3 for an overall benchmark when considering vanilla's 8MB memory heap size restriction, as noted during beta testing.

On 2/10/2023 at 2:45 PM, deathz0r said:

Honestly, KDiKDiZD is far from the first choice for benchmarking older PCs - the TAS UV-Max of hr2final MAP32 is still the best benchmark that I know of when it comes to vanilla.

Does the cpu not being able to keep up in vanilla, manifest itself in the same way as, say, a gpu bottleneck in gzdoom?  I'm tempted to buy a cpu with an unlocked multiplier and underclock it until I get performance equal to what I would on a system with older architecture.  But if I can just crank the scale factor up in gzdoom until I get a slow framerate, will the slowdown/jerkiness feel the same as if I were using a slower legacy cpu or slower architecture?  It would be much easier to just adjust the scale factor than try everything on another pc, underclock, benchmark, underclock again, etc.  (Btw on my system I get around 60fps constant on hr2 map 32)

On 2/10/2023 at 4:45 AM, deathz0r said:

I already mentioned what I consider as recommended hardware requirements way back in the sixth page.

I appreciate that one, and it gives a good baseline. What i am looking for is various kinds of performance on comparable rigs and processors.

On 11/13/2022 at 9:10 PM, esselfortium said:

Thanks!

 

The use of the nonexistent line special 1023 is a workaround I did for ZokumBSP's odd behavior with self-referencing sectors. My understanding is that applying a special keeps the lines from being pruned from the blockmap, and thus keeps the player from falling through them.

That's correct. Zennode had a piece of code that made it not generate segs from such walls. I extended it to also apply to not adding these lines to the blockmap. I didn't consider the self ref sector breaking, and the tagging is a bit clunky. I will add some sort of fix for a new version. I have a few ideas...

The iwads are full of these lines, and most likely many of the pwads out there are as well, so it was a decent optimization, but it slightly breaks self-ref sectors which there aren't any of in Doom and Doom 2, which I mostly use for testing, alongside av.wad

How do you load this in actual Chocolate DOOM? When I try `chocolate-doom.exe -file KDiKDi_A.wad -file KDiKDi_B.wad`, I get a really weird palette and then a crash when I start New Game. 

You only use one -file parameter with both wads.

What he said. Also, be sure to -deh kdikdizd.deh

On 12/26/2022 at 2:33 PM, esselfortium said:

Thank you! I will probably package up a release for idgames soon.

Has this happened without me catching it?

Whoops, it hasn't. Thanks for the reminder!

Okay, I've uploaded it to idgames, and also fixed the widescreen CREDIT lump name so it should work correctly. Version is now 1.7.1, nothing else is changed besides that widescreen lump. Will update the thread again once it's approved on idgames.