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

On 3/26/2020 at 5:31 PM, GRAU said:

any way to implement it? may be there is a way to process hud voxels with some different logics?

Both requests (dynamic shadows and hud voxels) are in my todo list.

Currently I'm working on a new engine using DelphiDoom code as base, so DelphiDoom itself will not be my number one priority for the next couple of months. Small updates will come, but the dyn shadows and hud voxels may need some time. Any improvements of the new engine that can fit the Doom games philosophy will be back-ported to all DelphiDoom branches.

The new engine will be used to:

1) Create a port of another 90's game

2) Offer the ability to create new levels for this other game using the classic Doom editing tools

2 hours ago, jval said:

 

Both requests (dynamic shadows and hud voxels) are in my todo list.

 

Currently I'm working on a new engine using DelphiDoom code as base, so DelphiDoom itself will not be my number one priority for the next couple of months. Small updates will come, but the dyn shadows and hud voxels may need some time. Any improvements of the new engine that can fit the Doom games philosophy will be back-ported to all DelphiDoom branches.

 

The new engine will be used to:

1) Create a port of another 90's game

2) Offer the ability to create new levels for this other game using the classic Doom editing tools

Sounds perfect! What is this game, you're creating a sourceport for? Isn't it build-based something? or may be it is Killing Time?))) Actually is there a way to create a sourceport for Ion Fury, that will run on xp?

Good luck to you in your work. And i am thinking about another interesting feature, for DD_Voxel may be. Look. I could create really nice animated voxels, if i had an ability to attach voxel hands, legs, bodies, etc. to the bones. So imagine - a skeleton wich actualy handles by pivots static voxeled parts. Is it real at all? 

By the way! I have started a letsplay of Khorus.wad on Delphidoom!

3 hours ago, GRAU said:

a skeleton wich actualy handles by pivots static voxeled parts. Is it real at all?

skeletal animation and ragdolls.

On 3/28/2020 at 12:16 PM, GRAU said:

 

Sounds perfect! What is this game, you're creating a sourceport for? Isn't it build-based something? or may be it is Killing Time?))) Actually is there a way to create a sourceport for Ion Fury, that will run on xp?

No, it's neither a Build Engine game remake, nor a Wolf3d Engine game remake. I'm working in the engine for about 2 months and it is in very good progress. Most remained work is scripting (use ACTOPDEF to recreate all the game objects). I hope for an alpha release during April or May.

On 3/28/2020 at 12:16 PM, GRAU said:

Good luck to you in your work. And i am thinking about another interesting feature, for DD_Voxel may be. Look. I could create really nice animated voxels, if i had an ability to attach voxel hands, legs, bodies, etc. to the bones. So imagine - a skeleton wich actualy handles by pivots static voxeled parts. Is it real at all? 

This can fit with the existing feature of DelphiDoom that multiple voxels can be assigned to each mobj state. Small parts can be animated (to save memory), while big parts remain static.

What is not currently supported is different sets of voxels all in one state, i.e. a state can have 2 or more voxels, but they are all displayed on every tic that the state lasts. What we need is multiple sets of voxels that can be changed at each tic during the state of the object.

One problem I see is that DD_VOXEL editor may need up to 256 MB of ram for each voxel to edit (much more than the memory that DelphiDoom needs to handle dozens of voxels since DelphiDoom uses compressed internal representation).   So editing an animation with DD_VOXEL will be "hard". Of course there is no problem to edit one frame at the time, and with the usage of PascalScript within DD_VOXEL you have an extra tool to help with automated animations.

On 3/28/2020 at 12:16 PM, GRAU said:

By the way! I have started a letsplay of Khorus.wad on Delphidoom!

 

Nice video! Too bad I can't speak Russian and can not understand the narration. What CPU did you use?

Version 2.0.5.725 is available.

What's new:

• Smoother interpolation in uncapped framerate. The fix has to do with the z axis interpolation, that was using faulty logic to interpolate.
• Added DEH_PrintActordef command, print current info of all objects as ACTORDEF declaration.
• Added DEH_SaveActordef command, save current info of all objects as ACTORDEF file definition.
• More flexible flags parsing in ACTORDEF lumps. Will recognize +MF_***, +MF_EX_*** etc syntax.
• Added MF3_EX_NOMAXMOVE mobj flag, when set it will not limit momx & momy to 30 map units per tic (as vanilla original behavior).
• Added MF3_EX_NOCRUSH mobj flag, when set, an object can not be crushed by a moving sector.
• Added A_GlowLight ACTORDEF function, change the glowing light effect at runtime (32 bit color only, both software and OpenGL rendering)
• Added angle extra parameter to A_ThrustXY ACTORDEF function
• States can have random tics in ACTORDEF lumps. Example can be downloaded here.

Downloads:

   DelphiDoom: https://sourceforge.net/projects/delphidoom/files/DelphiDoom%202.0.5/delphi-doom-2.0.5.725-win32.zip/download

   DelphiHeretic: https://sourceforge.net/projects/delphidoom/files/DelphiDoom%202.0.5/delphi-heretic-2.0.5.725-win32.zip/download

   DelphiHexen: https://sourceforge.net/projects/delphidoom/files/DelphiDoom%202.0.5/delphi-hexen-2.0.5.725-win32.zip/download

   DelphiStrife: https://sourceforge.net/projects/delphidoom/files/DelphiDoom%202.0.5/delphi-strife-2.0.5.725-win32.zip/download

   DD_IDE tool: https://sourceforge.net/projects/delphidoom/files/DelphiDoom%202.0.5/dd-ide-2.0.5.725-win32.zip/download

   Source code: https://sourceforge.net/projects/delphidoom/files/DelphiDoom%202.0.5/delphi-doom-src-2.0.5.725.zip/download

On 3/30/2020 at 10:56 AM, jval said:

So editing an animation with DD_VOXEL will be "hard"

Well, i belive you could make some optimizations in future. Neverless i love old hardware, i still belive 256mb is not too much today, i could spent up to 4gb for editing if needed. But i think you did not understand the core idea. I belive this can be even a new format, something like vector bones wich handle ROTATIONS in all 3 axis for each voxel part (so I could set a rotation for each part of hand in each tic), and not only positioning static voxels, but may be grouping them up into a skeleton (like model skeleton animation), and then in future we cou;ld add ragdoll animation for corpses using this technology. Just think about it!

May be i have allready asked about this, but - is there a way to apply dynamic lights to the voxels (the same way it is done with sprites)? And offcourse i would like to see an option for that - "dynamic light affect voxels" (off/on/advanced) advanced here is a dream, where voxel would be lit only from one direction, depth-sensitive, but i understand - it may be a heavy load for cpu. but slab6 lughts voxels in different ways (R and T buttons)

On 4/28/2020 at 1:06 AM, GRAU said:

May be i have allready asked about this, but - is there a way to apply dynamic lights to the voxels (the same way it is done with sprites)? And offcourse i would like to see an option for that - "dynamic light affect voxels" (off/on/advanced) advanced here is a dream, where voxel would be lit only from one direction, depth-sensitive, but i understand - it may be a heavy load for cpu. but slab6 lughts voxels in different ways (R and T buttons) 

 

This will require the voxels to be rendered to the z-buffer (and also some hard ray-tracing math), something that the engine does not do at the time. Also the core mechanics of lighting should change: The dyn-lights are rendered before objects (sprites and voxels) and do not affect them. To light the objects, all the objects  must be rendered first with z-buffer check-write and then apply the light effects, not only with depth check, but also with ray-trace check (since voxels have depth). In FPCDoom (high quality setting) I render sprites in z-buffer (FPCDoom does not support voxels) and apply the light effect with depth check only and this gives severe performance issues (20-40% less fps, an i7 CPU is struggling at 1920x1080 to render vanilla complexity maps with sprites close to "eye").

One intermediate step could be to use the FPCDoom technique, by rendering the voxels (and sprites) to the z-buffer and then apply the light without ray-tracing, meaning that voxel pixels do not block light and illuminate surfaces that should be in shadow. Even that will affect performance a lot, as I explained above.

On 4/28/2020 at 1:06 AM, GRAU said:

(the same way it is done with sprites)

DelphiDoom does not apply lights to sprites.

On 4/29/2020 at 6:49 AM, jval said:

DelphiDoom does not apply lights to sprites.

Oh my.. i was sure it does. Is it difficult, to make it apply light to sprites, then? As for voxels - but may be there is a way to apply just a kind of color-translation and increase a light for WHOLE voxel? without precise calculations. the same goes to sprites - calculate the distance between light source and object, and increase the brightness, translate the colors of whole sprite/voxel, that would be enough i belive. Also this is not needed to things which are further then 1024px (or even make this parameter configurable in options), and not needed to things that are not rendered at all. Software renderer with ray-tracing sounds great but i understand - this will take much more time to implement and fatally drop the fps, especially on low end cpus. so think please only about increment of whole sprite/voxel brightness, and about translating the colors to the dynlight color. this will be enough for software.

BTW here is what actualy does QZDoom with sprites:

Looks great i think. I was thinking delphidoom does the same.

On 5/5/2020 at 10:53 AM, GRAU said:

 

Oh my.. i was sure it does. Is it difficult, to make it apply light to sprites, then?

Yes and no.

No, because it's something I've already done in FPCDoom, and yes because DelphiDoom's renderer is much more complex.

To be honest it's not that difficult, because I know exactly what I must do.

On 5/5/2020 at 10:53 AM, GRAU said:

As for voxels - but may be there is a way to apply just a kind of color-translation and increase a light for WHOLE voxel? without precise calculations. the same goes to sprites - calculate the distance between light source and object, and increase the brightness, translate the colors of whole sprite/voxel, that would be enough i belive.

Definitely for voxels or maybe in per column basis for voxels too, but not in per pixel basis. Or probably in a mipmaped version of the rendered voxel (DelphiDoom generate mipmaps of voxels at loading time to use them for rendering the voxels in far distances).

On 5/5/2020 at 10:53 AM, GRAU said:

Also this is not needed to things which are further then 1024px (or even make this parameter configurable in options), and not needed to things that are not rendered at all. Software renderer with ray-tracing sounds great but i understand - this will take much more time to implement and fatally drop the fps, especially on low end cpus. so think please only about increment of whole sprite/voxel brightness, and about translating the colors to the dynlight color. this will be enough for software.

The distance does not matter so much. It's probably meaningless, since the performance problem are the sprites near to the eye (they take so much screen space). Far sprites have very little number of pixels to draw to worry about them.

Software ray-tracing will also require so much development that when finished, a threadripper that will be required to run it, will be consider a low end CPU :)

Version 2.0.5.726 is available.

What's new:

• Fixed ACTORDEF parsing fail with RANDOM function. It was working only when the parameters were constant numbers, not another function (eg RANDOM(RANDOM(10), 20) triggered errors)
• Fixed typo in camera menu. ("Chase Camera XY postion" changed to "Chase Camera XY position")
• Z-buffer warnings are displayed only in debug mode.
• Avoid crash in P_RecursiveSound when line has false ML_TWOSIDED flag.
• Secret area message on BOOM secret masked sectors.
• Added A_TraceNearestPlayer() ACTORDEF function.
• Ignore illegal characters from content definition lumps.
• True 3d collisions for players.
• Warning when include file not found in content definition lumps.
• Fixed include files depth detection.
• Zero mass warning fix. The message now includes newline (\n) at the end.
• Added dd_getactordef_xxxx export functions in script DLL.
• I_Error in TEvalFunction.Value() function displays function name.
• Warning in TEvalFunction.Value() function displays function name.
• Fixed FRANDOM parameters parsing. It was failing to recognize 2 parameters(range) and was working only with the first parameter.
• ACTORDEF parsing improvements. The parser detects the absence of STOP keyword at the last defined state and does not require it anymore.
• The engine detects missing sprite frames and displays warning.
• Summon and Spawnmobj console commands refuze to work during demo playback/recording and when we have a net game.
• Avoid repeating I_Warning messages when a state has errors in parameter list.
• Decimal separator is forced to be "." to avoid parsing problems when is it set to a different character in locale settings of the OS.
• Lightmap cast light to slopes.
• Fixed interpolation problem: Didn't interpolated player position and angle.

Downloads:

• DelphiDoom: https://sourceforge.net/projects/delphidoom/files/DelphiDoom%202.0.5/delphi-doom-2.0.5.726-win32.zip/download
• DelphiHeretic: https://sourceforge.net/projects/delphidoom/files/DelphiDoom%202.0.5/delphi-heretic-2.0.5.726-win32.zip/download
• DelphiHexen: https://sourceforge.net/projects/delphidoom/files/DelphiDoom%202.0.5/delphi-hexen-2.0.5.726-win32.zip/download
• DelphiStrife: https://sourceforge.net/projects/delphidoom/files/DelphiDoom%202.0.5/delphi-strife-2.0.5.726-win32.zip/download
• DD_IDE tool: https://sourceforge.net/projects/delphidoom/files/DelphiDoom%202.0.5/dd-ide-2.0.5.726-win32.zip/download
• Source code: https://sourceforge.net/projects/delphidoom/files/DelphiDoom%202.0.5/delphi-doom-src-2.0.5.726.zip/download
• Repository: https://github.com/jval1972/DelphiDoom/tree/5327181966fa978750c685c507e2dd5eb40fbd49

On 3/28/2020 at 8:48 AM, jval said:

Currently I'm working on a new engine using DelphiDoom code as base, so DelphiDoom itself will not be my number one priority for the next couple of months.

On 3/30/2020 at 9:56 AM, jval said:

I hope for an alpha release during April or May.

As much as i like DelphiDoom's philosophy (I really fail to see why this is not getting more traction because it has so many high end features), what's the status on this? And what's the engine name? :)

5 hours ago, Redneckerz said:

I really fail to see why this is not getting more traction because it has so many high end features

because it needs its own site, and heavy PR. people here on DW most of the time already chose their set of sourceports. and newcomers usually takes what is popular.

but having less users is not so bad: you can leave alot of bugs for a long time, and nobody'll complain.

Congratulations on the new release, jval! The gameplay on software mode is smooth as f*ck again, unlike the previous two versions (in my experience)! The uncapped framerate is flawless now.

20 hours ago, Redneckerz said:

 

As much as i like DelphiDoom's philosophy (I really fail to see why this is not getting more traction because it has so many high end features), what's the status on this? And what's the engine name? :)

Thanks!

The status is early beta and the name is RAD,

it's already out, but I have a lot of features to add.

14 hours ago, ketmar said:

because it needs its own site, and heavy PR. people here on DW most of the time already chose their set of sourceports. and newcomers usually takes what is popular.

 

but having less users is not so bad: you can leave alot of bugs for a long time, and nobody'll complain.

That's true. But also if you have a lot of users you get more feedback and, why not, opportunities for collaboration. It would be priceless for DelphiDoom to have just one another developer, especially with knowledge of OpenGL/Vulkan, since I'm definitely not a professional game programmer but a COBOL and database developer.

7 minutes ago, slayermbm said:

Congratulations on the new release, jval! The gameplay on software mode is smooth as f*ck again, unlike the previous two versions (in my experience)! The uncapped framerate is flawless now.

Thanks! The uncapped framerate problem was a careless mistake (wasn't interpolating the player's position and angle), and appeared in WIP 20200107 release in January 2020. Now I'm really very happy that it's fixed!

48 minutes ago, jval said:

 

Thanks!

The status is early beta and the name is RAD,

it's already out, but I have a lot of features to add.

That sounds rather.... rad ;)

Good to hear the thing is already out in the wild and i am rather excited what this is going to do, given it uses DelphiDoom as a base. Ill edit this detail in on the Wiki page for DelphiDoom.

Edit: Oooh, its an engine remake for Radix: Beyond the Void! How neat!

@jvalJust a notification: This has now been edited in on the DelphiDoom wiki page. When RAD (the engine) gains features, ill make a seperate page for it.

10 hours ago, jval said:

It would be priceless for DelphiDoom to have just one another developer, especially with knowledge of OpenGL/Vulkan

nononono. i will steal them from you for k8vavoom! ;-)

tbh, i'd like to help (i used Delphi and then FreePascal for more than a decade), but this will leave k8vavoom without any active coders at all. ;-)

Goodnight JVAL! I would like to ask you, if possible about one important feature, as well as a fix related to this feature.

- Feature: Could you make it possible to choose the prefered sound output device (i mean audo card)  in options, and a setting for midi processing device too? Midi setting is extremely needed.

- Fix Needed: the volume on Creative sound cards does not works adequately. I collect and also use them, and here is the list of cards on which I tried to change ingame midi the volume: Sound Blaster Live CT4870, SB0220, SB0570, SB0410, SB0100, Auidigy SB1394 - None of them worked correct. the volume on any of them always plays at maximum level, or may be at level, which is set in windows by default for midi.

May be i could make demonstration video if it is needed.

18 hours ago, GRAU said:

 

Goodnight JVAL! I would like to ask you, if possible about one important feature, as well as a fix related to this feature.

 

- Feature: Could you make it possible to choose the prefered sound output device (i mean audo card)  in options, and a setting for midi processing device too? Midi setting is extremely needed.

For midi DelphiDoom is using MIDI MAPPER as it's output device. For sound effects is using DirectSound. In my PC I only have one soundcard and even if I manage to make an option for multiple output devices it's impossible to test it. For midi I can enumerate the midi devices (actually in my system I only get only MIDI_MAPPER as the only valid midi output device) but I don't even know how this can be done in DirectSound :(

I'll try it for midi, but I don't thing that I can do it for DirectSound.

18 hours ago, GRAU said:

- Fix Needed: the volume on Creative sound cards does not works adequately. I collect and also use them, and here is the list of cards on which I tried to change ingame midi the volume: Sound Blaster Live CT4870, SB0220, SB0570, SB0410, SB0100, Auidigy SB1394 - None of them worked correct. the volume on any of them always plays at maximum level, or may be at level, which is set in windows by default for midi.

  

May be i could make demonstration video if it is needed.

What OS are you running? To adjust midi volume I use 2 different methods for Windows Vista or newer and another for Windows XP. Both methods are tested (the first method in Windows 7 & Windows 10 and the second method in Windows XP virtual machine) and the midi volume works fine.

19 hours ago, GRAU said:

 Midi setting is extremely needed.

If made a test build that can use different midi output devices, the link is:

https://sourceforge.net/projects/delphidoom/files/WIP_BUILDS/WIP_Doom_20200630.zip/download (Doom branch/Software rendering only)

In order to speed up things, inside the above link I've included a test application (midi_helper.exe) that will detect all midi output devices and will run DelphiDoom with the appropriate command line parameter to use the selected device.

Please, test this version if you have multiple midi output devices to make sure that the core mechanics are working, unfortunately I can not test it since in my PC it reports only one output device (midi mapper).

Helper application source code: https://sourceforge.net/projects/delphidoom/files/WIP_BUILDS/MIDI_HELPER_src.zip/download

This is the helper application main window:

Oh, thanks for that! i will try it today!

<2 hours later>

Well i found a strange, fatal performance drop. I found that it comes first in Delphidoom 2.0.5.726, or may be in some WIP version between 725 and 726 - if they exist. Here are screenshots from the same place in basic doom demo1 (Delphidoom 2.0.5.724, 2.0.5.725, and 2.0.5.726, running on Pentium Dual e6500 @3.2ghz with RDDVOX 0.40 alpha - look at difference in FPS counter. The settings and other files are the same:

6 hours ago, GRAU said:

Oh, thanks for that! i will try it today!

 

<2 hours later>

 

Well i found a strange, fatal performance drop. I found that it comes first in Delphidoom 2.0.5.726, or may be in some WIP version between 725 and 726 - if they exist. Here are screenshots from the same place in basic doom demo1 (Delphidoom 2.0.5.724, 2.0.5.725, and 2.0.5.726, running on Pentium Dual e6500 @3.2ghz with RDDVOX 0.40 alpha - look at difference in FPS counter. The settings and other files are the same:

 

  Reveal hidden contents

 

https://ibb.co/2WkTdzx
https://ibb.co/hDGt2Zq
https://ibb.co/mcBLLW4

 

 

 

 

I've tested v 0.39RC (I can't find any download link for 0.40) in a mid-high range laptop I don't see any performance drop. The only thing that could possibly think for such a performance drop is that the auto-fix memory stall is disabled  (Options/Display/Advanced) or a problem with shared-exclusive full screen mode. (Options/Display/Detail). Can you check that you run with the same settings the 3 versions you mention? Are there any error messages in the error log (Folder Data/LOGS/Doom32_stderr.txt) ?

Well, RDDVOX 0.40 is still in development, but there is no difference what revision of  RDDVOX to use - i may do the same tests without RDDVOX at all - i belive the FPS will increase prorortionaly. I mean - it is some changes in engine may be? Here is a link for current RDDVOX:

RDDVOX-0.40A.zip

I will try the option for auto fix memory stall.

Added later

Strange thing! I reinstalled the windows 7 today after that test. i had a strange process working in backgroung. And now i installed 726, and then even last WIP - it first caused those performance loses. But no FPS drops anymore! And thanx for fixing midi volume - at least on Sound Blaster Audigy it works fine now. I will test more on windows XP when will port last changes from RDVOX to RDDVOX. Sorry for false report((

Hi it's me again. Does the Decorate function A_CustomMissile supported now in delphi doom?

https://zdoom.org/wiki/A_CustomMissile

Or may be some replacement?

I am trying to run new blood code on delphidoom, i found how blood (blood splat) is named in delphidoom, but i still see the usual doom blood splats.... no changes.

Actually - is default doom Blood Splat replaceable?

15 minutes ago, GRAU said:

Hi it's me again. Does the Decorate function A_CustomMissile supported now in delphi doom?

 

https://zdoom.org/wiki/A_CustomMissile

 

Or may be some replacement?

The function is supported since version 0.8.311 (Released 12th September 2007)

A_CustomMissile(missiletype: string, [height: integer], [offset: integer], [angle: integer], [aimmode: integer], [pitch: integer])

Thanks, i have allready understood that it is supported, and looks like i just can not replace default blood splat for some reasons. I added the code in previous post under he spoiler

At first glance:

• The CMF_AIMDIRECTION constant is absent, must be replaced by the number 1.
• The ALLOWPARTICLES flag is not supported (but I doubt if this makes more trouble than a simple warning message).
• A_ChangeFlag() function is not supported. It can be easily recreated with PascalScript
•  "Goto OnAir" on actor RD_Blood is not needed.

Corrected script (with PascalScript function for changing the MF_NOCLIP flag):  test.zip

Am i doing wrong something? They are still default blood actors ingame. Here is the pack. New blood code in actors/vpblood.txt

RDDVOX-bloodissue.zip

Tell me please if you know - why even your fixed code do not work. it looks like the replacement does not work at all for blood actor

Sorry, didn't noticed earlier:

• There is a problem with the "EMPT A 0"  in RD_BloodStarter ACTOR declaration. First state can not have 0 tics. Please change it to "EMPT A 1" or remove it.
• Also the A_CustomMissile() function will fire a missile only if the calling ACTOR has a target, since RD_BloodStarter has not a target it will not spawn the missile. If it is absolutely necessary to use A_CustomMissile() instead of A_SpawnItemEx() I've added a small script to work around: vpblood.zip