DelphiDoom 2.0.7.735 - UDMF + UMAPINFO + MBF21 (May 1, 2022)

5 hours ago, TruthInFiction said:

This build seems to have introduced a bug.  I started playing E4M1 and got this:

Thank you so much for that. The bug involved erronous rendering of lines that contained the (0, 0) point in map.  Fixed in 2.0.7.732:

DelphiDoom: https://sourceforge.net/projects/delphidoom/files/DelphiDoom 2.0.7/delphi-doom-2.0.7.732-win32.zip/download

DelphiHeretic: https://sourceforge.net/projects/delphidoom/files/DelphiDoom 2.0.7/delphi-heretic-2.0.7.732-win32.zip/download

DelphiHexen: https://sourceforge.net/projects/delphidoom/files/DelphiDoom 2.0.7/delphi-hexen-2.0.7.732-win32.zip/download

DelphiStrife: https://sourceforge.net/projects/delphidoom/files/DelphiDoom 2.0.7/delphi-strife-2.0.7.732-win32.zip/download

5 hours ago, TruthInFiction said:

I also noticed that the plasma gun tanks the fps in both this build and the previous build, and the closer you are to where the plasma balls are exploding the harder it hits, bottoming out at 14 fps for me when I'm right up against a wall and just holding down the fire button.  The following screenshot was taken from the 730 build:

Unfortunatelly, firing the plasma gun in a close distance target produces a lot of sprites that cover big portion of the screen. It's inevidable to drain huge CPU power to draw all these sprites, there are million of pixels that must be drawned over and over again to complete the frame. But the biggest slowdown comes from the light effects: You can double or tripple the fps by disabling the lightmap (Options/Display/Advanced/Lightmap). I 'll try to take another look at this, but already  the engine utilizes multiple cores for completing the task, so what it needs is a different algorithm since there is not much room for improvment for the current one.

17 hours ago, jval said:

 

Thank you so much for that. The bug involved erronous rendering of lines that contained the (0, 0) point in map.  Fixed in 2.0.7.732:

DelphiDoom: https://sourceforge.net/projects/delphidoom/files/DelphiDoom 2.0.7/delphi-doom-2.0.7.732-win32.zip/download

DelphiHeretic: https://sourceforge.net/projects/delphidoom/files/DelphiDoom 2.0.7/delphi-heretic-2.0.7.732-win32.zip/download

DelphiHexen: https://sourceforge.net/projects/delphidoom/files/DelphiDoom 2.0.7/delphi-hexen-2.0.7.732-win32.zip/download

DelphiStrife: https://sourceforge.net/projects/delphidoom/files/DelphiDoom 2.0.7/delphi-strife-2.0.7.732-win32.zip/download

 

Unfortunatelly, firing the plasma gun in a close distance target produces a lot of sprites that cover big portion of the screen. It's inevidable to drain huge CPU power to draw all these sprites, there are million of pixels that must be drawned over and over again to complete the frame. But the biggest slowdown comes from the light effects: You can double or tripple the fps by disabling the lightmap (Options/Display/Advanced/Lightmap). I 'll try to take another look at this, but already  the engine utilizes multiple cores for completing the task, so what it needs is a different algorithm since there is not much room for improvment for the current one.

Awesome, can confirm that the bug has been squashed.  That's unfortunate about the plasma rifle, but hopefully you can think of a solution to improve it.

Sorry for th bump : I would like to study the source code. Since it's written in Delphi the only way is to install Embarcadero RAD Studio 11 Community Edition ? 

1 hour ago, LuciferSam86 said:

Sorry for th bump : I would like to study the source code. Since it's written in Delphi the only way is to install Embarcadero RAD Studio 11 Community Edition ? 

DelphiDoom is compatible with older versions of Delphi (6, 7, Turbo Delphi, BDS Studio 2006, etc). I have tried it with RAD studio some time ago, but Embarcadero had dropped support for for old objects (used by the texture library). If you want to use RAD studio (the free community edition will work fine) you must manually convert some portions of the code (and hopefully make a pull request on Github). 

On the other hand I suggest to start with DoomXS code (compatible with RAD & FPC/Lazarus, less than 65k lines of code) or with FPCDoom (compatible with old Delphi versions & FPC/Lazarus, ~135k lines of code). DelphiDoom's repository is more that one million lines of source code and much more complicated than DoomXS/FPCDoom.

On mercredi 2 mars 2022 at 11:08 AM, jval said:

Official UDMF support, a feature that actually had been left unfinished for more than 6 years, since ver. 1.1.600  (31 Dec, 2015).

Hey, do you have a custom namespace documented somewhere or is it just the "vanilla" Doom, Heretic, Hexen, Strife namespaces from the UDMF specs?

26 minutes ago, Gez said:

Hey, do you have a custom namespace documented somewhere or is it just the "vanilla" Doom, Heretic, Hexen, Strife namespaces from the UDMF specs?

The UDMF namespace for DelphiDoom is "DelphiDoom", "DelphiHeretic", "DelphiHexen" & "DelphiStrife", depending on branch. I hope I'll write some specs soon with the extra features.

The "Doom", 'Heretic", "Hexen" & "Strife" namespaces are also supported (assuming vanilla line specials). Accidental presence of additional/DelphiDoom features in vanilla namespace will be processed.

DelphiDoom will also load maps in "ZDOOMTRANSLATED" namespace (all features may not supported).

Version 2.0.7.733 is out.

Downloads on github:

DelphiDoom: https://github.com/jval1972/DelphiDoom/releases/download/2.0.7.733/delphi-doom-2.0.7.733-win32.zip

DelphiHeretic: https://github.com/jval1972/DelphiDoom/releases/download/2.0.7.733/delphi-heretic-2.0.7.733-win32.zip

DelphiHexen: https://github.com/jval1972/DelphiDoom/releases/download/2.0.7.733/delphi-hexen-2.0.7.733-win32.zip

DelphiStrife: https://github.com/jval1972/DelphiDoom/releases/download/2.0.7.733/delphi-strife-2.0.7.733-win32.zip

Sourceforge mirror: https://sourceforge.net/projects/delphidoom/files/DelphiDoom 2.0.7/

What's new:

• More speed optimizations in software rendering
• Status bar proper aspect ratio in widescreen modes (Doom branch)
• Proper windowed mode (Software & OpenGL)
• The player can choose to use CAPS LOCK for autorun
• New menu for uncapped framerate (Options/Display/Advanced/Uncapped FrameRate)
• Configurable voxel lightmap accuracy
• etc

Complete change log since previous release:

Screenshots:

A new update (2.0.7.734) is available:  https://github.com/jval1972/DelphiDoom/releases/tag/2.0.7.734

What's new:

• Faster startup, now it loads at about half the time compared to previous versions.
• Improved ZDoom compatibility in VOXEL declaration (VOXELDEF lump).
• Display correct quit messages depending on game,  vulgar messages will be displayed only if the vulgarquitmessages console variable is set to true.
• Proper menu stretch in widescreen mode.
• Added option to use mouse for player movement (back and forward). It can be accessed from the Menu ("Options/Contols/Y Mouse axis").
• Look up/down is disabled by default (Doom branch).
• Crosshairs are disabled by default.
• etc...

Dumb question, but is this port demo-compatible?

24 minutes ago, Sr_Ludicolo said:

Dumb question, but is this port demo-compatible?

DelphiDoom can play without desync most of the 1.9 vanilla demos (all official Doom IWAD demos play without desync). In addition it can record demos in it's own format and has backward demo playback compatibility with demos recorded with previous official releases. Backward demo compatibility is not guaranteed in demos recorded with WIP versions. Heretic, Hexen & Strife branches are demo compatible only with the internal demo format, not vanilla.

Appreciated as always @jval.

Since it was a while, updated DelphiDoom and author pages with your new contributions (ACCP, Mars3D) on DoomWiki.

Also added DD_Examples to the DelphiDoom page because they are great examples.

8 hours ago, jval said:

 

DelphiDoom can play without desync most of the 1.9 vanilla demos (all official Doom IWAD demos play without desync). In addition it can record demos in it's own format and has backward demo playback compatibility with demos recorded with previous official releases. Backward demo compatibility is not guaranteed in demos recorded with WIP versions. Heretic, Hexen & Strife branches are demo compatible only with the internal demo format, not vanilla.

Still very impressive nontheless!!

Hi, I came across a bug with handling relative paths when launching.

I use the following structure to organize my stuff:

Doom
├───delphi-doom-2.0.7.734-win32
├───doomretro-4.4.10-win64
├───dsda-doom
├───Eternity_Engine
├───prboom-plus-2.5.1.5
├───Woof-9.0.0-win32
│
├───wads
│
├───some_pwad.bat
├───other_pwad.bat
...

A top-level dir contains a bunch of ports, one place for iwads/pwads and .bat files for launching.

A typical .bat file looks like this: dsda-doom\dsda-doom.exe -iwad wads\DOOM2.WAD -file wads\sunlust.wad -complevel 9

This works fine with all ports above except DelphiDoom. When launched in a similar way (e.g. "delphi-doom-2.0.7.734-win32\GLDoom32.exe -iwad wads\DOOM2.WAD"), it creates/uses DATA folder on the top level and crashes with a log like this:

Doom32.swd, among others, is not created on any level (top or .exe directory). If already present, it is not detected.

It works only if I launch stuff from the same location as exe, e.g. put a .bat file next to exe with "GLDoom32.exe -iwad ..\wads\DOOM2.WAD".

1 hour ago, Doomy__Doom said:

Hi, I came across a bug with handling relative paths when launching.

 

I use the following structure to organize my stuff:

Doom
├───delphi-doom-2.0.7.734-win32
├───doomretro-4.4.10-win64
├───dsda-doom
├───Eternity_Engine
├───prboom-plus-2.5.1.5
├───Woof-9.0.0-win32
│
├───wads
│
├───some_pwad.bat
├───other_pwad.bat
...

A top-level dir contains a bunch of ports, one place for iwads/pwads and .bat files for launching.

A typical .bat file looks like this: dsda-doom\dsda-doom.exe -iwad wads\DOOM2.WAD -file wads\sunlust.wad -complevel 9

 

This works fine with all ports above except DelphiDoom. When launched in a similar way (e.g. "delphi-doom-2.0.7.734-win32\GLDoom32.exe -iwad wads\DOOM2.WAD"), it creates/uses DATA folder on the top level and crashes with a log like this:

   Hide contents

I_Warning: D_AddSystemWAD(): System WAD Doom32.swd not found.
I_Warning: DEH_ParseLumpName(): GAMEDEF lump not found, using defaults.
I_Error: W_GetNumForName(): FOGMAP not found!

Thanks for reporting, I'll look at this. In the meantime, you can put an extra cd command in your bat/cmd file in order to have the bat/cmd file in your doom folder, e.g.:

cd delphi-doom-2.0.7.734-win32
GLDoom32.exe -iwad ..\wads\DOOM2.WAD

1 hour ago, Doomy__Doom said:

Doom32.swd, among others, is not created on any level (top or .exe directory). If already present, it is not detected.

It works only if I launch stuff from the same location as exe, e.g. put a .bat file next to exe with "GLDoom32.exe -iwad ..\wads\DOOM2.WAD".

Doom32.swd is the system wad and it must be in the same folder as Doom32.exe & GLDoom32.exe. The Doom32.swd file is inside the download zip that contains Doom32.exe & GLDoom32.exe.

16 hours ago, Doomy__Doom said:

Hi, I came across a bug with handling relative paths when launching.

Fixed to the repository. The changes will available in next update.

You're on fire with the new releases, jval!

Using 2.0.7.734, getting consistent crashes when opening the automap. Tried some changes to settings like player trace distance, but couldn't find anything that helped.

6 hours ago, Khorus said:

You're on fire with the new releases, jval!

 

Using 2.0.7.734, getting consistent crashes when opening the automap. Tried some changes to settings like player trace distance, but couldn't find anything that helped.

I can not replicate the crash. Can you give me some more info? What WAD/MAP, or if it is possible a saved game? OpenGL or software rendering exe?

3 hours ago, jval said:

 

I can not replicate the crash. Can you give me some more info? What WAD/MAP, or if it is possible a saved game? OpenGL or software rendering exe?

Sorry for not adding more details! It happens for me using either Ultimate Doom or Doom 2 with just the IWAD, no other wads loaded. I figured out the exact setting causing it for me, it's the resolution option "720x576". Starting in E1M1 or Map01 and trying the automap straight away while in software mode regardless of the detail setting. OpenGL doesn't seem to have the issue.

A small feature request if it's not too much to ask, is it possible to have a toggle in the Automap options to display a Kills/Items/Secrets tracker? Thanks a bunch! :)

Issues reported by @Doomy__Doom & @Khorus has been addressed in v.2.0.7.735

What's new:

• Fix problem when starting from different folder than the executable. 
• Fixed crash when enter automap mode in certain screen resolutions. 
• Fixed drawing problem in OpenGL mode when changing screen resolution.
• Improved overlay drawing accuracy in hi-res.
• Displays statistics in automap.
   

Automap stats screenshot:

Crash bug in automap work-arround:

I'm back with some MBF21-related stuff.

First on the plate is Judgement, with Fallen (dehacked enemy) having trouble waking up. It appears they can't see down, and only wake up if you shoot or get on the same height as them. On other ports (e.g. dsda, woof) they just wake up normally on sight. They seem to function correctly once awakened, other custom monsters don't have any wake-up problems as far as I can tell.

Some example placements:

MAP 02: these are not only blind, but also stuck in geometry once they do wake up.

MAP 04: these are just blind, they'll wake up as you go upstairs and meet their eyes provided you don't shoot.

Judgement though was me testing that mbf21 works at all on a known wad, since I've bumped into bigger issues with my own map.

What is supposed to be (everything works as intended on dsda/woof):

1) Barons of Hell get a new projectile (salvaged some frames from decorations, no extended dehacked frames used). Looks like a Mancubus fireball (works in DelphiDoom), deals custom bonus splash damage via A_RadiusDamage (does not work in DelphiDoom).

2) Different projectile group between Baron and HK - works in DelphiDoom.

3) Custom Shadow Arch-Vile - replacement of Wolfenstein guy + a few more salvaged frames, has no attack, initial bits = SOLID+SHADOW+COUNTKILL (does not work in DelphiDoom), uses A_HealChase as resurrecting codepointer, when resurrecting uses A_AddFlags and A_RemoveFlags to make it SHOOTABLE and not SHADOW during resurrection, and reverse after resurrection animation is over (any resurrection attempt immediately crashes DelphiDoom).

For testing purposes, barons can be found behind teleporters numbered 2, 4, 7, 8, 9. Shadow Arch-Vile "tutorial encounter" with convinient zombies to res is behind teleporter number 8.

I've left some comments in DEHACKED lump where possible, but don't hesitate to ask if you need some more clarifications on how that mess is supposed to work.

Thank you for reporting!

Quote

 

  

What is supposed to be (everything works as intended on dsda/woof):

1) Barons of Hell get a new projectile (salvaged some frames from decorations, no extended dehacked frames used). Looks like a Mancubus fireball (works in DelphiDoom), deals custom bonus splash damage via A_RadiusDamage (does not work in DelphiDoom).

I checked how A_RadiusDamage() works in Woof and it seems to works a bit differently than DelphiDoom, when calculating damage. I suspect that DelphiDoom calcs damage=0, I'll try to confirm it and fix it.  

Quote

 2) Different projectile group between Baron and HK - works in DelphiDoom.

DelphiDoom already had other mechanics involving infighting and inheritance (flags like +DONTHURTSPECIES & +MISSILEHURTSPECIES) and custom damage types (eg projectiles with the +FLAMEDAMAGE can not hurt actors with the +NOFLAMEDAMAGE flag). The projectile and infighting groups of MBF21 made things more complicated (from the developer side of view).  I'm glad it works!

Quote

3) Custom Shadow Arch-Vile - replacement of Wolfenstein guy + a few more salvaged frames, has no attack, initial bits = SOLID+SHADOW+COUNTKILL (does not work in DelphiDoom), uses A_HealChase as resurrecting codepointer, when resurrecting uses A_AddFlags and A_RemoveFlags to make it SHOOTABLE and not SHADOW during resurrection, and reverse after resurrection animation is over (any resurrection attempt immediately crashes DelphiDoom).

Unfortunately the resurrection causes an infinite recursive call to DelphiDoom, since it lacks the checking for not setting in the same frame/tic the same state again (as Woof/dsda or even prboom+).  The crash occurs while calling the A_HealChase() on the "far attack frame" (736) of the new vile, which recursively ends up setting the vile to the "far attack frame" again and again, causing an infinite loop. Since DelphiDoom does not stop the recursion (as woof/dsda) the crash occurs. 

The fix to the problem is trivial (just a few lines of code, already done for testing) but the bad thing is that DelphiDoom deliberately allows recursive calls, since passing again of the same state in the same tic for the same actor is an absolutely acceptable behavior in case of:

• States with randomized tics, when the random range includes 0 tics (i.e. repeat the action at the state if the tics of the state set by random number generator equals zero)
• Actions with parametrized variables, which they are calculated on the fly, every time the function executes and change the flow dynamically e.g. A_RandomGoTo(label1; label2; etc...)
• Repeated calling of scripts until a condition/countdown is satisfied

At the moment of writing this post I feel desperate for a proper solution in order to maintain both behaviors, at least without sacrificing valuable CPU time to make rough checks in each state change.  :( :( 

I really don't know what to do... The easiest thing is to detect an MBF21 dehacked and disallow recursive calls maybe.... ? since MBF21 ports behave like that? Ohhh, what a nightmare!

Quote

For testing purposes, barons can be found behind teleporters numbered 2, 4, 7, 8, 9. Shadow Arch-Vile "tutorial encounter" with convinient zombies to res is behind teleporter number 8.

I've left some comments in DEHACKED lump where possible, but don't hesitate to ask if you need some more clarifications on how that mess is supposed to work.

Thanks again for the detailed and helpful feedback!

1 hour ago, jval said:

The crash occurs while calling the A_HealChase() on the "far attack frame" (736) of the new vile

Uhhh that sounds really odd. 736 should go to 737 (does so originally anyway, so no need to specify "next frame") or in case of healchase jump to 740. Now my 735 didn't go to 736, but fixing that doesn't change the crash, as that just made the chase loop shorter as the default is 735->728.

I'm not sure I see why 736 should loop on itself. Is there maybe some artifact of it being a WolfGuy frame that I missed? I did specify 0 as "far attack frame" for the vile. Should have only Spawn, Walk, Pain and Death states.

This is how my understanding of the loops is:

Look loop:
726->727 
727->726

Chase loop:
728->755 2t 				 - set shadow
755->729 0t 				 - unset shootable
729->730-> ... ->739->728 2t - A_HealChase jump to 740

Resurrection:
740->756 0t  - set shootable
756->741 0t  - set shadow
741->742 15t - do nothing, just anim
742->728 15t - anim end and goto set shadow

Also the Vile being visible initially seems definitely wrong given an initial SHADOW bit.

1 hour ago, jval said:

I checked how A_RadiusDamage() works in Woof and it seems to works a bit differently than DelphiDoom, when calculating damage. I suspect that DelphiDoom calcs damage=0, I'll try to confirm it and fix it. 

Could be it. That splash should produce very low numbers. One of those odd moments where the formula isn't part of spec, so implementation differences may happen.

8 hours ago, Doomy__Doom said:

Uhhh that sounds really odd. 736 should go to 737 (does so originally anyway, so no need to specify "next frame") or in case of healchase jump to 740. Now my 735 didn't go to 736, but fixing that doesn't change the crash, as that just made the chase loop shorter as the default is 735->728.

I'm not sure I see why 736 should loop on itself. Is there maybe some artifact of it being a WolfGuy frame that I missed? I did specify 0 as "far attack frame" for the vile. Should have only Spawn, Walk, Pain and Death states.

  

This is how my understanding of the loops is:

Look loop:
726->727 
727->726

Chase loop:
728->755 2t 				 - set shadow
755->729 0t 				 - unset shootable
729->730-> ... ->739->728 2t - A_HealChase jump to 740

Resurrection:
740->756 0t  - set shootable
756->741 0t  - set shadow
741->742 15t - do nothing, just anim
742->728 15t - anim end and goto set shadow

Also the Vile being visible initially seems definitely wrong given an initial SHADOW bit.

 

Ohhh, I thing I've found what's wrong. Stupid me, I should have check the error log: It's the "Pain Frame" which causes all the damage.... As far as I can tell it should be "Injury frame" not "Pain frame". I removed the line from the Dehacked and it worked (there is already an "Injury frame" line).

Do other source ports actually work with "Pain Frame"?   I can easily put an alias for it.

Work-around: DelphiDoom since it finds an unknown keyword ignores the next lines until it finds another "group" keyword, thus it does not register the next lines until the line with the "Frame 726". As a result, it does not set the "Far attack frame" equals 0, and also it does not set the initial bits. The A_HealChase() when it fails to find a corpse to resurrect, it calls A_Chase() which can set the actor to a non zero ""Far attack frame", calling A_HealChase() again and again....

I hope during week-end to find some time to look at the other issues too....

Oof, I have no idea how Pain frame got in there. This dehacked was only partly generated by Whacked, and then heavily hand-edited, so it's likely a me problem. Removing it indeed fixes everything.

I guess other ports ignore the broken keyword itself, which does sound like a sane way to handle that error to me. "Pain frame" is definitely not a thing in dsda's *deh_mobjinfo_fields[] (line 1114). Ditto woof or Eternity's dehacked reference.

@jval

delphidoom seems to support voxels....

is it done in the same way as in GZDoom?

could you tell me how to use voxels in a WAD?

I haven't been able to figure out how to use VX_START and VX_END markers....

I can use voxels when using the PK3 format in GZDoom, but not when using the WAD format

EDIT

I actually got it to work in a WAD file, but I had to use decorate and I have no control of the z offset... However I am still interested in hearing more about voxels in delphidoom

On 6/26/2022 at 12:37 PM, CBM said:

@jval

delphidoom seems to support voxels....

is it done in the same way as in GZDoom?

 

could you tell me how to use voxels in a WAD?

I haven't been able to figure out how to use VX_START and VX_END markers....

I can use voxels when using the PK3 format in GZDoom, but not when using the WAD format

 

EDIT

 

I actually got it to work in a WAD file, but I had to use decorate and I have no control of the z offset... However I am still interested in hearing more about voxels in delphidoom

Voxel handling it's a bit different than GZDoom. DelphiDoom uses voxels as a sprite replacement (multiple voxels can be assigned to a single sprite). 

eg

voxeldef "PMAPA.kvx" {
	droppedspin = 25
	placedspin = 25
	replaces sprite "PMAPA"
}

Sprite string can be 4 or 5 chars long. A 4 character declaration replaces all the frames of the sprite.

Z axis Offset is not supported for voxels in software rendering, only in OpenGL mode ("offset" keyword).

@jval

That sounds very nice

I've heard that GZDoom is very inefficient in the way it handles voxels. Is DelphiDoom more efficient in this area since it 'views it' as sprites?

I've found voxel packs for both (G)ZDoom and DephiDoom, but never used them because in GZDoom objects both look and perform better than voxels

When running in software mode all sprites are fullbright.

also midtextures become fullbright on and off as you move, seemingly at random.

Hi jval

I'm new to this port, and using it for the first time (I plan to stream voxel mods of Conrad GRAU (and other authors, for example Cheello) in software renderer with this port), so I have questions:

1) How to start it for the first time exactly in windowed mode? Most of the ports (for example zdoom) are starting in fullscreen, breaking my win10 desktop layout at all and forcing me to reboot PC, and then creating config file, so I can select windowed mode in ingame options or in config after. Is it a way in DelphiDoom to use autoexec.cfg or command line commands, to force windowed mode during first launch of the port?

2) Conrad GRAU told me, that DelphiDoom has support of decorate. Is it true? Is it possible to run for example this https://doomwiki.org/wiki/Masters_of_Chaos and this https://doomwiki.org/wiki/Day_of_the_Acolyte pwads in DelphiDoom and play as intended?

15 hours ago, theleo_ua said:

1) How to start it for the first time exactly in windowed mode? Most of the ports (for example zdoom) are starting in fullscreen, breaking my win10 desktop layout at all and forcing me to reboot PC, and then creating config file, so I can select windowed mode in ingame options or in config after. Is it a way in DelphiDoom to use autoexec.cfg or command line commands, to force windowed mode during first launch of the port?

You can start doom32.exe (software renderer executable) with:

• "-fullscreen" command line option. This will open in fullscreen, but in shared fullscreen mode (i.e. it will not mess your desktop). Shared full screen is available only in software rendering mode and may cause performance drop (depending on you VGA card).
• "-nofullscreen" or "-windowed" command line options to start in windowed mode.

Quote

2) Conrad GRAU told me, that DelphiDoom has support of decorate. Is it true? Is it possible to run for example this https://doomwiki.org/wiki/Masters_of_Chaos and this https://doomwiki.org/wiki/Day_of_the_Acolyte pwads in DelphiDoom and play as intended? 

DelphiDoom uses ACTORDEF scripting, which is quite similar to DECORATE. It will try to parse DECORATE lumps. There is a common base with ZDoom DECORATE, i.e. you can write DECORATE scripts compatible with both ports, but DelphiDoom is not 100% compatible with ZDoom features and vise versa.

A lot of examples can be found at https://sourceforge.net/projects/delphidoom/files/Tools%2C maps and examples/

A good resource is the DD_MONSTERS pack, an old conversion of some of the monsters found in  667realm site.

Other/newer examples use more complex ACTORDEF (also PascalScript & ACS) scripting.