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

[GRAU]

12 hours ago, jval said:

 

.. Your post gives me motive to reuse some code from FPCDoom for dynamic lights (which fully supports them in software rendering).

 

 

 

 

Well this is what i would like a lot. i prefer software, and only software, so i liked QZDoom, and so i would like to use DelphiDoom at least as a sourceport to play classicand prboom wads with voxels, and may be even as a platform for one of my ideas in future.

 

About next version - that's okay, i dont hurry, first i have to reach an agreement of DooMAD of using voxels from teamhellspawn's pack for those items that i didn't replace yet, and make my own download sitepage at least (i already registered a free host for that), and will be nice to finish powerups too as fast as it's possible but lots of other things take alot of time( 

 

I work on a horror style project for z/qzdoom too, and i am the only man who has to do all the jobs) Btw i vety liked the breathing of doomguy in delphidoom - i just waqnted to do something tghe same there - it is very cool-loking feature for horror.

 

 

On 1/1/2017 at 2:39 AM, jval said:

I 've actually tried to make it some years ago but I could not make it work, so I left as an option the switch between WASD to Arrows. I don't like to make promises that I can not accomplish.

BTW! i had problems in configure too. okey, wasd is nice option, but using Space for jumps and E for "use"- is the usefull universal config, usualy used with wasd for movement. May you implement at least configuring use and jump to e and space for wasd preset?

 

I fixed it for myself by finding scancodes of those buttons and manualy corrected the doom32.ini the way i liked.But not everyone could do that!

 

Or may be you can make the standalone SETUP program for that? A program that just configures key settings. Is it real?

 

Well. I've just looked at voxeldef in teamhellspawn voxpack and understood what to do. That looks like the nice start of porting my pack to DelphiDoom =)

Oh, one more question. is there a way to disable writing of tga screenshots? or switch it to png (the best format to me)?

 

 

 

Edited November 24, 2019 by GRAU

[jval]

13 hours ago, GRAU said:

 

 Btw i vety liked the breathing of doomguy in delphidoom - i just waqnted to do something tghe same there - it is very cool-loking feature for horror.
 

 

Wow, I had forgot this! Yes, it is an experiment from the early days of development. Now it can be recreated with Pascalscript.

 

13 hours ago, GRAU said:

BTW! i had problems in configure too. okey, wasd is nice option, but using Space for jumps and E for "use"- is the usefull universal config, usualy used with wasd for movement. May you implement at least configuring use and jump to e and space for wasd preset?

 

I fixed it for myself by finding scancodes of those buttons and manualy corrected the doom32.ini the way i liked.But not everyone could do that! 

 

Or may be you can make the standalone SETUP program for that? A program that just configures key settings. Is it real?

 

 

Next version will have key bindings menu, to enable the user to configure the keys inside the game. It's already coded and tested.

 

13 hours ago, GRAU said:

Oh, one more question. is there a way to disable writing of tga screenshots? or switch it to png (the best format to me)?

 

 

Currently not. PNG screenshots are in to-do list for near future. Probably next release will have a png/tga/jpg screenshot format option.

 

Since you're interesting in voxels you can also check the DD_VOXEL editor.

 

 

 

Edited November 24, 2019 by jval

[GRAU]

8 hours ago, jval said:

 

 

Since you're interesting in voxels you can also check the DD_VOXEL editor.

 

I have allready) That was one of the main interesting things for me in DelphiDoom. But i didn't understandyet, are there any hotkeys, or how to copy-paste the whole layer of voxels.. Any documentation?

 

[jval]

11 hours ago, GRAU said:

 

I have allready) That was one of the main interesting things for me in DelphiDoom. But i didn't understandyet, are there any hotkeys, or how to copy-paste the whole layer of voxels.. Any documentation? 

 

 

Copy & paste are in a 2d-plane/layer level (2d image) and can be performed with Ctrl+C & Ctrl+V shortcuts. It works like a simple paint program, each time you select the working plane/layer and edit it as an image.

Edited November 25, 2019 by jval

[GRAU]

Oh, nice, thanks for that! Looks like it may help me in things i couldn't make in Slab6 (it just has no copy-paste at all, but all the other functions are usefull)

Another tool shall not interfer at work. But i have anyway to wait the release supporting #include options, so i could implement to delphidoom pack the code i use in RDVOX.

At last i would like to see my resourcepack working nice on both (q)zdoom and delphidoom sourceports, to interest more doomers in modern software renderers, using 3D objects and dynamic lights as well as gl do, but having than palette magic of original doom.

It seems to me that open gl is not for doom, imho)

 

It's pity but zdoom branch is dead. It's forks like GZDoom are too modern-graphics, vulcan-oriented, and they removed the support of windows xp (and i use xp,so...) Another shit thing for me is their virtual resolution, when i may set the size of window 1024*768 and have 320*240. Sounds not bad but really it have a lot of bugs and problems, and also i had problems with sound on last versions i was able to start. The only nice thing was QZDoom, but this branch is also closed, so... I belive Delphidoom will bring some new experience, still supporting nice old hardware and OS. 

Edited November 25, 2019 by GRAU

[drfrag]

8 hours ago, GRAU said:

It's forks like GZDoom are too modern-graphics, vulcan-oriented, and they removed the support of windows xp (and i use xp,so...)

 What about LZDoom? It still has the classic software backend and supports XP. But why are you still using XP?

[GRAU]

Don'tlike lzdoom for that virtual resolution. Clasic direct set of the resolution without any scale factor was much better. I use xp because none of newer windowss reacts so quickly to my actions. all of them use much more memory and do something strange with HDD sometimes. I dont like when OS averyday needs fucking udates and tells me what to do. I'm able to choose which drivers to install for my hardware, what process to close and what to run. I don't need superfetches instead of clean performance. It's a tool, and xp as a tool is best for me.

[drfrag]

 LZDoom has the old video code and you can still select the real resolution "directly", besides default scale factor is 1 and scaling doesn't even work on D3D. About XP...

Edited November 25, 2019 by drfrag

[GRAU]

I like the way QZDoom 2.0.0 does. What advantages has LZDoom? Why would it be better then QZDoom? Itried it - fps is a bit lower, voxels are rendered the same lame as in QZDoom when MODELS parameter is disabled and if i switch it to ON the palete of voxels looks damaged at all. So, I see no reason to update sourceport or operation system.

And i'm sure - this is OFFTOP here!

 

BTW, Jval, i added a few more voxels. What is about translucency for voxels, is it working? What is about adding "alpha"  parameter directly to voxeldef? And is the way to use my own 8-bit palete in DelphiDoom's software? I don't like 32bit software, actually. It loses the main advantage of doom's original software renderer - palete specific color "trembles"

Edited November 26, 2019 by GRAU

[jval]

10 hours ago, GRAU said:

BTW, Jval, i added a few more voxels. What is about translucency for voxels, is it working? What is about adding "alpha"  parameter directly to voxeldef? And is the way to use my own 8-bit palete in DelphiDoom's software? I don't like 32bit software, actually. It loses the main advantage of doom's original software renderer - palete specific color "trembles" 

 

 

Translucency can be set for each actor/map object statically or dynamically. It can not be set for voxels. A voxel can be rendered as translucent or not depending on the ALPHA value of an actor.

 

For example, this is how the translucency can be changed dynamically using the A_FadeOut() ACTORDEF function (which changes the ALPHA value):

actor SpiderImpHead 20048
{
    Health 15
    Radius 20
    Height 24
    Speed 12
    PainChance 200
    Mass 30
    MONSTER
    +NOGRAVITY
    SeeSound "impspid/see"
    PainSound "impspid/pain"
    DeathSound "impspid/death"
    ActiveSound "impspid/see"
    MeleeSound "impspid/atack"
    MeleeDamage 3
    States
    {
    Spawn:
        IMHD D 5 A_Look
        Loop
    See:
        IMHD A 0 
        IMHD A 3 A_Gravity
        IMHD ABBCC 3 A_Chase
        Loop
    Melee:
        IMHD D 8 A_FaceTarget
        IMHD E 6 A_MeleeAttack
        Goto See
    Pain:
        IMHD D 2 A_Pain
        Goto See
    Death:
        IMHD F 8 A_ScreamAndUnblock
        IMHD G 6
        IMHD G 1 A_FadeOut(0.1)
        IMHD G 1 A_FadeOut(0.1)
        IMHD H 1 A_FadeOut(0.1)
        IMHD H 1 A_FadeOut(0.1)
        IMHD H 1 A_FadeOut(0.1)
        IMHD H 1 A_FadeOut(0.1)
        IMHD H 1 A_FadeOut(0.1)
        IMHD H 1 A_FadeOut(0.1)
        IMHD H 1 A_FadeOut(0.1)
        IMHD H 1 A_FadeOut(0.1)
        Stop
    }
}

 

And this is how translucency can be defined statically (i.e. all states are translucent with constant alpha value):  (Using the RENDERSTYLE translucent & ALPHA keywords)

actor AfritBall
{
    Radius 6
    Height 8
    Speed 15
    RENDERSTYLE Translucent
    ALPHA 0.8
    SeeSound dsfirsht
    DeathSound dsfirxpl
    +NOGRAVITY
    +MISSILE
    +NOBLOCKMAP
    +DROPOFF
    States
    {
    Spawn:
        FRTM AB 5 Bright
        Loop
    Death:
        FRTM CD 6 Bright
        FRTM E 6 Bright A_Explode(24, 64)
        Stop
    }
}

 

Edited November 27, 2019 by jval

[GRAU]

Those are the derorate-type setting of translucency. I used that a lot in zdoom pack version. Well. I tried to add all my code from separated parts into a single actordef.txt and placed it into the root of zip pack. But it doesnt works. None of the doom objects replaced with my versions. Or  maybe REPLACES keyword is not working?

For example:

 

ACTOR VP_Candle replaces Candlestick
{
    Radius 8
    Height 10
    States
    {
    Spawn:
        CAND A 4 Bright  A_Jump(64, 1)
    loop
        CAND B 4 Bright    A_Jump(64, 1)
    loop
        CAND B 3 Bright
        CAND C 3 Bright    A_Jump(120, 1)
    loop
        CAND CDEF 2 Bright
    loop
  }
}
 

 

That have to replace the classical doom Candle(Candlestick class). But i see no changes.

Edited November 27, 2019 by GRAU

[jval]

@GRAU

• The "replaces" keyword, it is recognized by the ACTORDEF parser, but acts the same as "inheritsfrom" keyword. Probably a to-do entry has been forgotten for a long time:)
• The DelphiDoom name for this object is Candle, not Candlestick.

Anyway, I've already corrected the "replaces" keyword for the next version.

 

As for the loop keyword, it works only at the end of the state definition. You can use the  GoTo spawn command instead. I'll try to make it for next version, but the code seems a little obscure to make any sense at this point (these parts were coded over a decade ago).

 

To work/test with current version 2.0.4.720 you can use the next definition (assuming you will make a map with a thing with doom editor number 23034)

ACTOR VP_Candle inherits Candle  23034
{
    Radius 8
    Height 10
    States
    {
    Spawn:
        CAND A 4 Bright A_Jump(64, 1)
        GoTo Spawn
        CAND B 4 Bright A_Jump(64, 1)
        GoTo Spawn
        CAND B 3 Bright
        CAND C 3 Bright A_Jump(120, 1)
        GoTo Spawn
        CAND CDEF 2 Bright
        loop
  }
}

 

[GRAU]

oh no, that is not that. I don't want to add new things inheriting old things but with new numbers. "Inherit from" is inheritance of an actor code, but to add some cute sprite effects to the original things i need to replace the original spawnids. That is what "replaces" keyword for.

And another one request - can you make ADDITIVE renderstyle? This helps a lot in creation of fire-style effects, and if coding that right, that doesn't need to calculate alpha of the sprite, but just add the sprite colour values to the picture (absolutely black=absolutely translucent). Otherway i see no reason in trying to port for example my torches and many other nice fireball effects like that:

And as for difference in actordef and decirate - i think that isn't nice to have small differences in work, that interferes to create mods for DelphiDoom. For decorate we have ZDoom Wiki, and i see nothing bad in having full compatibility with this standard, but having some original code in renderer and other. But this is only my opinion anyway.

 

Edited November 29, 2019 by GRAU

[jval]

On 11/28/2019 at 11:36 PM, GRAU said:

oh no, that is not that. I don't want to add new things inheriting old things but with new numbers. "Inherit from" is inheritance of an actor code, but to add some cute sprite effects to the original things i need to replace the original spawnids. That is what "replaces" keyword for.

 

In the next version the replaces keyword will work properly. 

 

On 11/28/2019 at 11:36 PM, GRAU said:

And another one request - can you make ADDITIVE renderstyle?

 

Next version will have renderstyle ADD & renderstyle SUBTRACT.

 

On 11/28/2019 at 11:36 PM, GRAU said:

And as for difference in actordef and decirate - i think that isn't nice to have small differences in work, that interferes to create mods for DelphiDoom. For decorate we have ZDoom Wiki, and i see nothing bad in having full compatibility with this standard, but having some original code in renderer and other. But this is only my opinion anyway.

 

After supporting the #include keyword, there will be possible to organize ACTORS in separate lumps inside a PK3 file and use them both from ACTORDEF & DECORATE lumps. I'll try to offer better compatibility for the common features that ACTORDEF & DECORATE share.

 

 

 

Edited November 30, 2019 by jval

[GRAU]

On 11/30/2019 at 7:54 AM, jval said:

After supporting the #include keyword, there will be possible to organize ACTORS in separate lumps inside a PK3 file and use them both from ACTORDEF & DECORATE lumps. I'll try to offer better compatibility for the common features that ACTORDEF & DECORATE share.

 

Nice. Then i'll concentrate on recreating objects in voxel, and all the other - after next release. Thank you.

Edited December 2, 2019 by GRAU

[jval]

Since there are a lot of changes without release, I've created a WIP folder. In this folder you can find latest builds of the repository.

You can download the WIP versions at: https://sourceforge.net/projects/delphidoom/files/WIP_BUILDS/

Source code repository: https://github.com/jval1972/DelphiDoom

 

Also I've uploaded a new example: https://sourceforge.net/projects/delphidoom/files/Tools%2C%20maps%20and%20examples/v2_EXAMPLE_12_MODIFY_ACTORS.zip/download

Demonstrates actor inheritance, replaces keyword, renderstyle add (renderstyle subtract also works) and some new features that will help cross-port modding.

The above example works only with the WIP version, it does not work with latest official release 2.0.4.720.

 

 

Edited December 1, 2019 by jval

[GRAU]

i found out another two.. Differences, maybe... Well, i usually use custom pallete in my mods, and also add a wad with maps into a zip. I tried packing maps.wad(with maps and) and newpal.wad(custom playpal, colormap) into a single zip for delphidoom, but got none of them working

 

loadtest.zip

 

Edited later:

 

I,ve downloaded new WIP Version and actor replacement demo, and the question is: can you make the load of new voxels WITHOUT sprites? now i have to add new sprites, and if i add new actor code and voxeldef for non-existing sprites i get this strange object disappearing while all the frames loaded, and only then it starts to show normally, but still jumping somewhere to the side for 1 pixel. I checked voxel offsets - they are nice (i use the same voxels as in zdoom versions - they work there nice too), please look at the video till the end:

 

 

i dont't like the idea of adding dummy sprites for future voxel frames... this looks like a crutch for me.

The other actors do not work too - may be of the same reason - ill look later why. And i didn't try using #include in gldefs (or where there are lights defined) or any other definitions yet.

 

RDDVOX.zip  - here is it, may be you want to look at files...

 

Another question - can sprites be loaded directly from somewhere in zip/pk3 or they need to be loaded to wads anyway? I use PNG sprites, with alpha, they are hard to load without loses to WAD. 

At my oppinion the best structure for modern modmaking is to leave in wad files only maps(and may be playpal+colormap if they are present) and then add this maps.wad into a zip or pk3 with all other resources placed in their folders.

Edited December 2, 2019 by GRAU

[GRAU]

I looked at executable of delphidoom and got an idea. why is doom3 there?)) I tried to make something of delphi thematic - what do you think about an idea of new icon? may be you have some preferences for that? Or you like better current doom3-style icon?

 

or

 

And one more - where may i get full list of original doom2 actor names in delphidoom (to know which to replace)?

 

Edited December 2, 2019 by GRAU

[jval]

WAD files inside the pk3 file system currently are not supported, but since the WAD filesystem has already the mechanics to dynamically grow, it won't be a problem. I'll fix this ASAP.

 

About voxels without sprites: The easy way I had in mind is that sprites can be generated by voxels at run-time (only 1 front image as a default, or optionally 8, 16 or 32 angles).  So, when r_drawvoxels (or gl_drawvoxels) console variables are set to false, it will render the sprites. So, don't bother by making sprites from voxels, it is something that can be automated and also something I wanted to do since I've added the export sprite in DD_VOXEL. 

 

PNG (and BMP) Sprites in software rendering are only supported inside S_START/SS_START and S_END/SS_END wad lumps. External textures as sprites can be used only with the OpenGL renderer. I'll work around this....

 

As I can see from your file, the names after the replaces keywords are not the same with DelphiDoom's names (eg zDoom's "TeleportFog" is "Teleport Flash" in DelphiDoom). I'll have to make a predefined lump (e.g. zdoom_compatibility.h)  that will map zDoom's actor names with DelphiDoom's actor names (using the ACTORALIAS command).

 

GLDEFS.txt is not recognized for light definitions, the name that DelphiDoom uses is LIGHTDEF.txt . You can make a LITGHDEF.txt file and  write inside it   #include gldefs.txt

 

I like the icon, but I 'll keep mine :)  But I can add a custom command in ACTORDEF, so you can place the icon in title screen :)

 

 

 

[GRAU]

No no, i don't need custom icon, i placed my own to the desktop, that is enough for me, looks fine)

 

On 12/2/2019 at 11:48 PM, jval said:

About voxels without sprites: The easy way I had in mind is that sprites can be generated by voxels at run-time (only 1 front image as a default, or optionally 8, 16 or 32 angles).  So, when r_drawvoxels (or gl_drawvoxels) console variables are set to false, it will render the sprites. So, don't bother by making sprites from voxels, it is something that can be automated and also something I wanted to do since I've added the export sprite in DD_VOXEL. 

May be sprites will not bother in project where voxels come as additional packs, but for advanced voxel pack i see no reason in those compatibility sprites. I see novadays many people liked voxels and for example in zdoom they may be used instead of sprites - even for decorations the size of voxel file is not far larger then ONE sprite and even less then sprites for 8 rotations, and so - why do i have to add that extra megabytes to my mod, when i allready have all data in voxels? I know - we all now don't count extra megabytes, but another reason is that doom's future is in voxels, i think) Is this feature is difficult to implement - voxels as basic graphics for new objects, without sprites, without voxeldefs? just voxels named as frames: CANDB.kvx,CANDC.kvx etc?

And what am i do with that model jumping? I tried to load a wad wi9th same named sprites before my zip - nothing changed. and i cant include this wad into zip now - it doesn't loads. Do you know - why does it happen at all?

On 12/2/2019 at 11:48 PM, jval said:

GLDEFS.txt is not recognized for light definitions, the name that DelphiDoom uses is LIGHTDEF.txt . You can make a LITGHDEF.txt file and  write inside it   #include gldefs.txt

 

No, i don't want to create a single file for zdoom and delphidoom. I'm trying to create just a version of my graphics(voxel) pack for delphidoom and only, so i need some documentation may be, how is LIGHTDEF structured inside, which commands support (#include?) etc. So on with supported in ACTORDEF functions, and dhe differences from decorate. May be if i got it i would not ask stupid questions so oftenly, and may be more people in future would like to choose delphidoom for their modding. now it's hard enough to understand, it looks similar to zdoom but has a lot of small differences ang not too muck info in internet (like zdoom wiki).

I like the idea of independent sourceport, but i think - if you take decorate as base for actor defining language - why not to make it fully compatible and so on.

 

 

On 12/2/2019 at 11:48 PM, jval said:

PNG (and BMP) Sprites in software rendering are only supported inside S_START/SS_START and S_END/SS_END wad lumps. External textures as sprites can be used only with the OpenGL renderer. I'll work around this....

 

This will be important for me - i need PNG sprites supported in zip directly, i need them work in software. Otherwise there is no reason to continue this project-porting.  So i will wait for this in feature releases)

 May be once i will have all needed create something like this on delphidoom:

 

 

 

 

 

 

 

 

 

 

 

Edited December 4, 2019 by GRAU

[jval]

 

21 hours ago, jval said:

sprites can be generated by voxels at run-time

 

 

21 hours ago, GRAU said:

why do i have to add that extra megabytes to my mod, when i allready have all data in voxels? 

 

 

You don't have to add additional sprites for your voxels, since, as I have written, they will be generated at run-time (i.e. when the player disables them).

[jval]

WIP 20191203

• Fixed non working plats & ceilings (https://www.doomworld.com/forum/topic/98789-fpcdoom-1124117-updated-dec-2-2019/?do=findComment&comment=2050845)

• File system will process WAD files inside pk3/zip/pak files.

• Will parse GLDEFS lumps for dynamic lights (alongside with LIGHTDEF lumps). This feature currently works with the OpenGL renderer only.

Doom: https://sourceforge.net/projects/delphidoom/files/WIP_BUILDS/WIP_Doom_20191203.zip/download

Heretic: https://sourceforge.net/projects/delphidoom/files/WIP_BUILDS/WIP_Heretic_20191203.zip/download

Hexen: https://sourceforge.net/projects/delphidoom/files/WIP_BUILDS/WIP_Hexen_20191203.zip/download

Strife: https://sourceforge.net/projects/delphidoom/files/WIP_BUILDS/WIP_Strife_20191203.zip/download

 

Repository: https://github.com/jval1972/DelphiDoom/commit/48a980a807d1239bb2a30fc3aae2c350aa72418b

[GRAU]

4 hours ago, jval said:

You don't have to add additional sprites for your voxels, since, as I have written, they will be generated at run-time (i.e. when the player disables them).

Now i understood. So in future voxeld may be used without sprites.. But still required voxeldef for such objects? or not?

 

2 hours ago, jval said:

WIP 20191203

• Fixed non working plats & ceilings (https://www.doomworld.com/forum/topic/98789-fpcdoom-1124117-updated-dec-2-2019/?do=findComment&comment=2050845)

• File system will process WAD files inside pk3/zip/pak files.

• Will parse GLDEFS lumps for dynamic lights (alongside with LIGHTDEF lumps). This feature currently works with the OpenGL renderer only.

 

 

Great work. You are reacting really fast. GLDEF now supports #include?

And how is about nice dynamic light code in FPC doom? I mean - how difficul will be to ad it to Delphidoom? 

 

At that time i found a reason of candle voxel "jumping" - Can you belive - it was caused by 

fractional values of  offsets! May be you can fix it - small voxels sometimes require fractional offsets. Anyway now it is ok.

 

 

Other nice thing is that i recorded it on Pentium 4 3.36 GHz with DDR400 dual channel and it worked fine enough in 600x800 with bandicam encoding on CPU! It shows gteat performance of Delphidoom, this is one of the main advantages for me because i like retro hardware.

 

I also tested GL rendering. First is - where can i disable all kinds of bilinear or any other filtering - it makes textures too flattened and smooth, that is not as nice as pixelated for low resolution. Make an option to choose/disable filterings, please.

 

Gldefs also work with #include - i allready tested in gl mode my pack - candles work nice, but i got feeling that offsets work somehow wrong, or may be that is illusion beceuse of low resolution shadowmap. Added screenshots. May be you may check - why are all lights (not only my - the torches here are still not changed) so shifted (as well as shadows under voxels), and may be make an option of shadowmap resolution?

 

 

Edited December 3, 2019 by GRAU

[slayermbm]

@jval It's me again :)

 

I believe I found a problem in the enemy behavior in DelphiDoom. If you stay behind a column, or any piece of scenary at all, sometimes the enemy won't stop shooting at you, even when out of sight, and they remain like this until you enter their line of sight again, are damaged, or some other enemy interrupts them.

 

The most glaring example I could find are the Chaingunners in Doom2 Map03, they keep shooting even when the player lies behind other walls and obviously they miss, yet they continue, instead of walking towards doomguy. Also, maybe it's just me, but I think the enemies can hear you/are activated at a bigger distance in DelphiDoom, compared to other ports. 

 

The same behavior does not happen in FPCDoom, so maybe you should check what are the differences between both. 

 

Not sure If I could make myself clear. If necessary, I can record a video and send to you.

 

Edit: Also, I'm using the latest WIP you uploaded today.

 

   

Edited December 4, 2019 by slayermbm

[jval]

9 hours ago, GRAU said:

Now i understood. So in future voxeld may be used without sprites.. But still required voxeldef for such objects? or not?

 

VOXELDEF lump will be still required if you want to define scale, droppedspin, AngleOffset & placedspin parameters.

 

9 hours ago, GRAU said:

Great work. You are reacting really fast. GLDEF now supports #include?

And how is about nice dynamic light code in FPC doom? I mean - how difficul will be to ad it to Delphidoom?

 

GLDEFS lump supports the #include directive. Also the include files can have their own include files.

 

For example:

 

GLDEFS.txt :

#include myactor_gldefs.txt

myactor_gldefs.txt:

#include myactor_gldefs_lights.txt
#include myactor_gldefs_objdef.txt

 

myactor_gldefs_lights.txt

 

// Bullet puff
flickerlight BPUFF1
{
    color 0.5 0.5 0.0
    size 6
    secondarySize 8
    chance 0.8
}

flickerlight BPUFF2
{
    color 0.5 0.5 0.0
    size 3
    secondarySize 4
    chance 0.8
}

myactor_gldefs_objdef.txt

object BulletPuff
{
    frame PUFFA { light BPUFF1 }
    frame PUFFB { light BPUFF2 }
}

 

9 hours ago, GRAU said:

I also tested GL rendering. First is - where can i disable all kinds of bilinear or any other filtering - it makes textures too flattened and smooth, that is not as nice as pixelated for low resolution. Make an option to choose/disable filterings, please

 

 

Currently you can edit the Doom32.ini file, locate the gl_tex_filter=GL_LINEAR line and change it to gl_tex_filter=GL_NEAREST. I'll try to make possible to change this at runtime from the menu.

 

9 hours ago, GRAU said:

Added screenshots. May be you may check - why are all lights (not only my - the torches here are still not changed) so shifted (as well as shadows under voxels), and may be make an option of shadowmap resolution?

 

 

It's the lighmap resolution. I'll try to make an option to change the resolution in future releases.

 

 

6 hours ago, slayermbm said:

@jval It's me again :)

 

I believe I found a problem in the enemy behavior in DelphiDoom. If you stay behind a column, or any piece of scenary at all, sometimes the enemy won't stop shooting at you, even when out of sight, and they remain like this until you enter their line of sight again, are damaged, or some other enemy interrupts them.

 

The most glaring example I could find are the Chaingunners in Doom2 Map03, they keep shooting even when the player lies behind other walls and obviously they miss, yet they continue, instead of walking towards doomguy. Also, maybe it's just me, but I think the enemies can hear you/are activated at a bigger distance in DelphiDoom, compared to other ports. 

 

The same behavior does not happen in FPCDoom, so maybe you should check what are the differences between both. 

 

Not sure If I could make myself clear. If necessary, I can record a video and send to you.

 

Edit: Also, I'm using the latest WIP you uploaded today.

 

   

 

I suspect that this happens due to the sight checking code, and particularly the problem should have appeared when the P_CheckSight func changed due to the 3d floors addition. I'll work around this ASAP.

 

[Khorus]

Thanks for fixing the music and sound volume being tied together, much appreciated! Hoping that the window scaling option from FPCDoom also comes over, that lets me run lower resolutions on my 4k monitor while looking crisp. The menu controls are great so thanks for implementing that, would it be possible to have weapon key bindings available?

 

One problem I've noticed running on software rendering is that when I have the 35 fps limiter on I get really bad input lag. The OpenGL renderer while limited is fine, though. 

[GRAU]

6 hours ago, jval said:

VOXELDEF lump will be still required if you want to define scale, droppedspin, AngleOffset & placedspin parameters.

 

I tested new frames without voxeldef - they are still not rendered at all. So i added a voxeldef - that in not the worst thing i found. I spent over half of hour while i guessed - how are basic doom torches named in delphidoom. And strange - i still couldn't guess how low green torch named - low blue is SmallBlueTorch, low red is SmallRedTorch, normal green torch is TallGreenTorch, logic says me that low green must be SmallGreenTorch, but using this name i still get this one dude:

 

 

As you see i found all other five names.

 

So - Please, write a namelist for classes in delphidoom (hexen,heretic,strife packs are also planed in future, but now i need a lot doom object names) so i could replace objects where needed.

The second problem is that parasite pixels on some of the sprites - what are they?

 

I use PNG sprites with alpha channel,  for zdoom i used to load them from the zip root/sprites folder, for Delphidoom i decided to load them into wad as raw data (because as you said - sprites in png format are not loaded from zip), and then loaded this wad into zip. The sprites are allready tested and they cause no problems in zdoom, but  in delphidoom - they cause those blue-white bixels (( May be the alpha of png is not fully supported? Or what is it?

 

The next question is how about adding full support for dynamic lights to 8-bit software renderer? may be you could borrow zdoom logic? It works fine in 8bit mode. Or you have better ideas?

 

And the third problem: complicated expressions do not work as parameters in A_SpawnItemEx.

I was surprised, i use the next code in zdoom version of torch fire:

 

        TBLU A 1 BRIGHT A_SpawnItemEx("VP_BlueBigFlame", (random(-5, 5)/2), (random(-5, 5)/2), 52, 0, 0, 1)

 

So, i get larger result after random function and then divide it by 2 to get more available results, it helps to make more varied spawnplace of fire parts. The same i use for speed sometimes, but in delphidoom i got VERY unexpected results - random works, but instead of dividing result, it uses this 2 as next argument, here is what i got:

 

 

So i had to modify codem losing smoothness of fire effect:

 

BLUT A 1 BRIGHT A_SpawnItemEx("VP_BlueBigFlame", random(-3,3), random(-3,3), 52, 0, 0, 1)

 

 I hope you will fix that, or may be ad at least some alternate randomizing for float values - it helps a lot when creating cute fire or smoke/water etc effects.

 

 

 

 

Edited December 4, 2019 by GRAU

[jval]

 

@Khorus

Key bindings for weapons will be no problem. For the Window scaling, it is possible for the software rendering, but need some work-around for the OpenGL version. 

 

I'll also check the lag in capped framerate, seems strange to happen only in software mode...

 

 

@GRAU

 

The small green torch name is "SMALL GR. TORCH", sorry for that, I use the same names as Dehacked :

 

Spoiler

Name            Id #
------------------------------------
"PLAYER"        -1
"TROOPER"        3004
"SARGEANT"        9
"ARCHVILE"        64
"ARCHVILE ATTACK"    -1
"REVENANT"        66
"REVENANT FIREBALL"    -1
"FIREBALL TRAIL"    -1
"MANCUBUS"        67
"MANCUBUS FIREBALL"    -1
"CHAINGUN SARGEANT"    65
"IMP"            3001
"DEMON"            3002
"SPECTRE"        58
"CACODEMON"        3005
"BARON OF HELL"        3003
"BARON FIREBALL"    -1
"HELL KNIGHT"        69
"LOST SOUL"        3006
"SPIDERDEMON"        7
"ARACHNOTRON"        68
"CYBERDEMON"        16
"PAIN ELEMENTAL"    71
"SS NAZI"        84
"COMMANDER KEEN"    72
"BIG BRAIN"        88
"DEMON SPAWNER"        89
"DEMON SPAWN SPOT"    87
"DEMON SPAWN CUBE"    -1
"DEMON SPAWN FIRE"    -1
"BARREL"        2035
"IMP FIREBALL"        -1
"CACO FIREBALL"        -1
"ROCKET"        -1
"PLASMA BULLET"        -1
"BFG SHOT"        -1
"ARACH. FIREBALL"    -1
"BULLET PUFF"        -1
"BLOOD SPLAT"        -1
"TELEPORT FLASH"    -1
"ITEM RESPAWN FOG"    -1
"TELEPORT EXIT"        14
"BFG HIT"        -1
"GREEN ARMOR"        2018
"BLUE ARMOR"        2019
"HEALTH POTION"        2014
"ARMOR HELMET"        2015
"BLUE KEYCARD"        5
"RED KEYCARD"        13
"YELLOW KEYCARD"    6
"YELLOW SKULL KEY"    39
"RED SKULL KEY"        38
"BLUE SKULL KEY"    40
"STIM PACK"        2011
"MEDICAL KIT"        2012
"SOUL SPHERE"        2013
"INVULNERABILITY"    2022
"BERSERK SPHERE"    2023
"BLUR SPHERE"        2024
"RADIATION SUIT"    2025
"COMPUTER MAP"        2026
"LITE AMP. VISOR"    2045
"MEGA SPHERE"        83
"AMMO CLIP"        2007
"BOX OF AMMO"        2048
"ROCKET AMMO"        2010
"BOX OF ROCKETS"    2046
"ENERGY CELL"        2047
"ENERGY PACK"        17
"SHELLS"        2008
"BOX OF SHELLS"        2049
"BACKPACK"        8
"BFG 9000"        2006
"CHAINGUN"        2002
"CHAINSAW"        2005
"ROCKET LAUNCHER"    2003
"PLASMA GUN"        2004
"SHOTGUN"        2001
"SUPER SHOTGUN"        82
"TALL LAMP"        85
"TALL LAMP 2"        86
"SHORT LAMP"        2028
"TALL GR. PILLAR"    30
"SHORT GR. PILLAR"    31
"TALL RED PILLAR"    32
"SHORT RED PILLAR"    33
"PILLAR W/SKULL"    37
"PILLAR W/HEART"    36
"EYE IN SYMBOL"        41
"FLAMING SKULLS"    42
"GREY TREE"        43
"TALL BLUE TORCH"    44
"TALL GREEN TORCH"    45
"TALL RED TORCH"    46
"SMALL BLUE TORCH"    55
"SMALL GR. TORCH"    56
"SMALL RED TORCH"    57
"BROWN STUB"        47
"TECHNICAL COLUMN"    48
"CANDLE"        34
"CANDELABRA"        35
"SWAYING BODY"        49
"HANGING ARMS OUT"    50
"ONE-LEGGED BODY"    51
"HANGING TORSO"        52
"HANGING LEG"        53
"HANGING ARMS OUT 2"    59
"HANGING TORSO 2"    60
"ONE-LEGGED BODY 2"    61
"HANGING LEG 2"        62
"SWAYING BODY 2"    63
"DEAD CACODEMON"    22
"DEAD MARINE"        15
"DEAD TROOPER"        18
"DEAD DEMON"        21
"DEAD LOST SOUL"    23
"DEAD IMP"        20
"DEAD SARGEANT"        19
"GUTS AND BONES"    10
"GUTS AND BONES 2"    12
"SKEWERED HEADS"    28
"POOL OF BLOOD"        24
"POLE WITH SKULL"    27
"PILE OF SKULLS"    29
"IMPALED BODY"        25
"TWITCHING BODY"    26
"LARGE TREE"        54
"FLAMING BARREL"    70
"HANGING BODY 1"    73
"HANGING BODY 2"    74
"HANGING BODY 3"    75
"HANGING BODY 4"    76
"HANGING BODY 5"    77
"HANGING BODY 6"    78
"POOL OF BLOOD 1"    79
"POOL OF BLOOD 2"    80
"BRAIN"            81
"SPLASH"        -1
"SPLASH 2"        -1
"LAVA SPLASH"        -1
"LAVA SMOKE"        -1
"SLUDGE CHUNK"        -1
"SLUDGE SPLASH"        -1
"NUKAGE CHUNK"        -1
"NUKAGE SPLASH"        -1
"GREEN BLOOD"        -1
"BLUE BLOOD"        -1
"PUSHER"        5001
"PULLER"        5002
"VP_CANDLE"        34
"PLASMAZOMBIE"        9600

 

 

Voxels without voxeldef are not yet implemented. It's something I have in mind but not yet coded.

 

Haven't figured out about the problematic pixels with sprites, maybe something with the palette. I'll check this.

 

Dynamic lights to 8 bit software will be implemented as long, as the lighting code from FPCDoom will be ported to DelphiDoom.

 

Evaluating expressions inside the ACTOR definition is not fully supported.  You do not even have to add parenthesis or commas at codepointer's parameters. When you put the RANDOM function as parameter, you simply must put 2 integers (low and high range) after that. Small expressions are calculated for the parameters that define a label in A_Jumpxxxxx, A_GoToxxxxx & A_RandomGoto functions.

For more complex or more customizable actions, you can use PascalScript, that can easily handle complex logic. You can write a script, and call it with the A_RunScript (or RunScript) codepointer.

 

This is an example, to mimic the random spawn positions with float values, using PascalScript:

bluetorch.zip

 

 

 

 

 

Edited December 4, 2019 by jval

[GRAU]

Oh ,at least! Thank for name table (btw i allready found a nice way to detect names - they often the same as in doom builder, but not always offcourse

11 hours ago, jval said:

Haven't figured out about the problematic pixels with sprites, maybe something with the palette. I'll check this.

 

I found - this goes somehow from those colours wich were in png BEFORE removing any colours at all (i use gimg, i add layer alpha channel and then delete all i dont need) so iu had a lot of work yesterday but finaly i found a way to fix torches. There is another much, much greater problem. Scale parameter in actordef doesn't work at all. And i use it a lot, for example i tried to load hires soulsphere sprites to the wad and just to replace the object with the same but with scale 0.5, 0.3 - none of them worked at all((. And one more. What is that problem with translucency in sprites on the distance. Look - here the same smoke in front of player is drewn nice, with translucency i set to it , but the same smoke a bit further looks like there is no translucency at all! Fix that please, or if this is a way you did optimization - make please default distance ar least 1000 map points , and even better remove it - that does not saves a lot of resource, and we have "translucent sprites" enable/disable it it will cause problems for someone. Here:

 

 

 

11 hours ago, jval said:

Evaluating expressions inside the ACTOR definition is not fully supported.  You do not even have to add parenthesis or commas at codepointer's parameters. When you put the RANDOM function as parameter, you simply must put 2 integers (low and high range) after that. Small expressions are calculated for the parameters that define a label in A_Jumpxxxxx, A_GoToxxxxx & A_RandomGoto functions.

For more complex or more customizable actions, you can use PascalScript, that can easily handle complex logic. You can write a script, and call it with the A_RunScript (or RunScript) codepointer.

 

Well, i didn't expect that to get a non-integer result from randomization i have to use pascalscript. Ok that is a heavy lose for compatibility, but i am ready to study pascalscript. Where can i get documentation for that? Thank you for bluetorch example.  But i still feel the weak documentation level of Delphidoom, and this fact interferes a lot because i have to experiment a lot each time to get an understanding - how this or that function works(. If i am missing something - please show me where am i wrong. The nice idea is to make something like zdoom wiki but i understand that it requires hosting and a lot of work. But anyway i am ready to help in documenting delphidoom actordef differences from zdoom's decorate. And i have an idea where i may host this documentation (and translate to russian) if you have no place for that. BTW - what is oficial site of delphidoom?

I created on free hosting my own site, i am planning to develop it and place there my projects, some manuals and links maybe too. Although Now it is a small download page for RDVOX (zdoom and delphidoom).

I wish more people would choose delphidoom in future, and documentation is on the first place for modders, if you are interested at that, of course.

Edited December 5, 2019 by GRAU

[jval]

 

11 hours ago, GRAU said:

Scale parameter in actordef doesn't work at all. And i use it a lot, for example i tried to load hires soulsphere sprites to the wad and just to replace the object with the same but with scale 0.5, 0.3 - none of them worked at all((.

 

And one more. What is that problem with translucency in sprites on the distance. Look - here the same smoke in front of player is drewn nice, with translucency i set to it , but the same smoke a bit further looks like there is no translucency at all! Fix that please, or if this is a way you did optimization - make please default distance ar least 1000 map points , and even better remove it - that does not saves a lot of resource, and we have "translucent sprites" enable/disable it it will cause problems for someone. Here:

 

 

 

WIP 20191205
 

Doom: https://sourceforge.net/projects/delphidoom/files/WIP_BUILDS/WIP_Doom_20191205.zip/download

 

Scale is in good progress, added support for the scale field in ACTORDEF (currently only in Doom branch) and also the rendering works for both OpenGL and software. Needs testing though to see if it works properly in all cases (at least the floorclip and the 3d-floors clipping).

 

The translucency problems are probably because of the 8 bit color mode. Does this problem appears also in 32 bit color software rendering? I have not any distance limit for such effects.

 

11 hours ago, GRAU said:

Ok that is a heavy lose for compatibility, but i am ready to study pascalscript. Where can i get documentation for that? Thank you for bluetorch example.  But i still feel the weak documentation level of Delphidoom, and this fact interferes a lot because i have to experiment a lot each time to get an understanding - how this or that function works(. If i am missing something - please show me where am i wrong. The nice idea is to make something like zdoom wiki but i understand that it requires hosting and a lot of work. But anyway i am ready to help in documenting delphidoom actordef differences from zdoom's decorate. And i have an idea where i may host this documentation (and translate to russian) if you have no place for that. BTW - what is oficial site of delphidoom?

I created on free hosting my own site, i am planning to develop it and place there my projects, some manuals and links maybe too. Although Now it is a small download page for RDVOX (zdoom and delphidoom).

 

To write script with Pascalscript you must first learn the basics of Pascal. A good beginners book can be found at http://bitsavers.informatik.uni-stuttgart.de/pdf/borland/turbo_pascal/Turbo_Pascal_Version_7.0_Language_Guide_1992.pdf . After learning the basics (eg functions, procedures, constants, variable declaration, for/while/repeat loops, case statement etc) you have to learn the built-in functions of PascalScript that helps you interact with almost everything in the map. These functions that can be found at the library tab of DD_IDE tool (located in the official binary releases)

 

Any help for documenting DelphiDoom is welcome! I'm very interesting myself in documenting all the assets of the engine, and offer help in any direction.

 

 

Unfortunately, there is no documentation about these functions, but at least the names of the functions are self-explanatory.

 

 

11 hours ago, GRAU said:

I wish more people would choose delphidoom in future, and documentation is on the first place for modders, if you are interested at that, of course.

 

Very often happens to think that without documentation all these features of DelphiDoom are untapped, it's a pity to add all these features and limit them to some examples I've built myself (I'm not a modder, or at least I'm not a good one). Hope that in near future to offer more about documentation.

 

 

Edited December 5, 2019 by jval