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

[GRAU]

3 hours ago, jval said:

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)

do you mean clipping of real object geometry (i mean - you scale real sizes too?) or you mean under clipping - the collision of scaled graphics with floors? sorry, im not too good at english. But anyway ill test today how scale works , nice to see you added it so far!

 

3 hours ago, jval said:

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

 

oh.. i have a feeling that i will need a lot of time for that. Pity - i haven't too much but ill try step by step.. Would be nice to see more practical examples of doomscript at work, especially primitive scripts for map (i remember there was something in 3d floor example, that is nice to start i think) - i used ACS before for creating of complicated map sequences and so on. And another question is - how more cpu resources requires for example for this scripted blue torch if we compare it with actordef-based only (but using only integer Random() function, like i did for compatibility? is one using pascalscript cases much more cpu load? and one more question - may i take your script for my voxelpack, as base (ill also try to make the same functions for green and red ones, and maybe somewhere more in future)

Optimization is always important to me.

 

3 hours ago, jval said:

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.

yes, 8bit but look at that screenshot - till the translucent objects not far from player translucency is fine. Then why does is stop working at all when object goes further then 200-300 px from player? look at it please. if you need the pack i used to get thet screenshot - i add the version of RDDVOX where it appears, and RDVXTEST.zip ,contenting testmap map01 where this effect is easy to repeat. I thing Delphidoom have to work nice especially in 8bit software - that one is closest to original doom style, but at the same time translucency tah we have in cloce distance looks really nice. just look 

 

i circled with orange where smoke looks untranslucent at all and a bit closer to (camera)player we get the same smoke but looking much, much better. Just tru to find - why does normal translucency disable when far from camera. There is no the same effect in add or sub translucency, only usual.

RDDVOX.zip

RDVXTEST.zip

 

Added new WIP:

 

I got this error when trying to pick up a replacement soulsphere:

 

 

here is this sphere's code:

 

ACTOR VP_Soulsphere : Soulsphere replaces Soulsphere //HIRES Soulsphere implementation into Delphidoom by GRAU on 05.12.2019
{
    Scale 0.25
    States
    {
    Spawn:
        SOUS ABCDCB 6 Bright
        Loop
    }
}

 

What is the core of this problem?

 

And more. Scale works fine BUT in software sprites now are somehow streched a lot when they are higher then camera (players eyes, i know that is not camera.. viewplane may be :) )I look normal:

I jumped (and got a bit higher then the fire)

 

I look normal in GL:

 

 

i think GL shows the true height of the flame - so may you fix height-related distortion of sprites in soft?

Edited December 6, 2019 by GRAU : Added more info

[jval]

10 hours ago, GRAU said:

do you mean clipping of real object geometry (i mean - you scale real sizes too?) or you mean under clipping - the collision of scaled graphics with floors? sorry, im not too good at english. But anyway ill test today how scale works , nice to see you added it so far!

 

I mean the rendering clipping, ie the tasks that the rendering engine must do to perform drawing. Scale does not affect the movement clipping, movement clipping is affected by the radius field (DelphiDoom also accept the width keyword alias for radius)

 

Quote

 

oh.. i have a feeling that i will need a lot of time for that. Pity - i haven't too much but ill try step by step.. Would be nice to see more practical examples of doomscript at work, especially primitive scripts for map (i remember there was something in 3d floor example, that is nice to start i think) - i used ACS before for creating of complicated map sequences and so on. And another question is - how more cpu resources requires for example for this scripted blue torch if we compare it with actordef-based only (but using only integer Random() function, like i did for compatibility? is one using pascalscript cases much more cpu load?

 

 

You can find the examples at https://sourceforge.net/projects/delphidoom/files/Tools%2C%20maps%20and%20examples/ , Most of the v2_EXAMPLE_xxxxxx.zip files contain scripting examples (both map scripts and actor scripts). Map scripts contain code that is executed when a specific event is taking place (eg event OnCrossLine() is executed when an actor cross a line that has the "Trigger PascalScript" setting enabled), and actor scripts are executed via the A_RunScript codepointer.

PascalScript compiles the source script and creates an intermediate representation , i.e. an optimized struct containing information for running the script. It is not as fast as machine code, but not as slow as an interpreter. For heavily scripted actions, there is the possibility to use external dll's (dynamic link libraries) to take advantage of the execution speed of native code. DLL's can be inside a pk3/zip/pak/wad file as lumps. However the maximum performance for float random in the blue-torch can be achieved with a function equivalent with Random  that takes 2 float values as parameters and return a float value (eg FloatRandom). Both the evaluation of complicated expressions as parameters, and the call of script can cause a (probably unnoticeable) performance loss, but with a new function like FloatRandom there will be no need for run-time expression evaluations or script execution.

 

Quote

and one more question - may i take your script for my voxelpack, as base (ill also try to make the same functions for green and red ones, and maybe somewhere more in future)

Optimization is always important to me.

 

Of course you can use the script of the blue-torch, or any piece of code from the examples and re-use it in your mod.

 

 

Quote

 

yes, 8bit but look at that screenshot - till the translucent objects not far from player translucency is fine. Then why does is stop working at all when object goes further then 200-300 px from player? look at it please. if you need the pack i used to get thet screenshot - i add the version of RDDVOX where it appears, and RDVXTEST.zip ,contenting testmap map01 where this effect is easy to repeat. I thing Delphidoom have to work nice especially in 8bit software - that one is closest to original doom style, but at the same time translucency tah we have in cloce distance looks really nice. just look

 

I've test it and confirmed the problem. I suspect what causes this: The accuracy of transparency in 8 bit mode is limited, to save memory and resources (pre-calculated tables that map transparency). In far distances, due to the light diminishing effect, there is little room to accurate calculations (colors tend to be black or gray). I'll try to make sure that this is the problem and work around it.  The problem is eliminated when we enable the "Diher 8-bit transparency" from options/advanced, so probably it is the accuracy: 

 

 

 

Quote

 

I got this error when trying to pick up a replacement soulsphere:

 

 

 

here is this sphere's code:

 

ACTOR VP_Soulsphere : Soulsphere replaces Soulsphere //HIRES Soulsphere implementation into Delphidoom by GRAU on 05.12.2019
{
    Scale 0.25
    States
    {
    Spawn:
        SOUS ABCDCB 6 Bright
        Loop
    }
}

 

What is the core of this problem?

 

You get the "Unknown gettable think" I_Error because the doom engine checks the sprite name for special thinks. This is the vanilla behaviour. Since you provided a new sprite, the engine raises an I_Error. I've added this to to-do list to solve the problem

 

Quote

And more. Scale works fine BUT in software sprites now are somehow streched a lot when they are higher then camera (players eyes, i know that is not camera.. viewplane may be :) )I look normal: 

 

I jumped (and got a bit higher then the fire)

 

I look normal in GL:

 

i think GL shows the true height of the flame - so may you fix height-related distortion of sprites in soft?

 

 

As I've said:

12 hours ago, jval said:

Scale is in good progress,

.....

Needs testing though to see if it works properly in all cases (at least the floorclip and the 3d-floors clipping). 

The scale is in good progress but not finished. Nice catch! This is a miss-positioning problem. I'll solve this ASAP.

 

 

 

 

 

[jval]

WIP 20191206

 

• Fixed scaled sprites positioning in software rendering mode and transparency in 8 bit color mode as mentioned by @GRAU
• Corrected enemies that continued shooting at you, even when out of sight as mentioned by @slayermbm
• Resent changes were made available also in Heretic, Hexen & Strife branch.

 

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

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

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

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

 

Repository: https://github.com/jval1972/DelphiDoom/tree/705bac22ec937484f01cb4e3b10dbbf6b15f9058

 

Screenshot with fixed sprite transparency in 8 bit color mode:

[slayermbm]

Just tested the latest WIP, enemy sight working as intended, didn't see any abnormalities. 

 

Good job, man.

[GRAU]

Tried put the new WIP version. Great work! Now normap alpha works as it has to. Look's like i may continue working over graphics pack. And thanks for explaining the problematic of error. I'll try to make a temporary version using an old sprite but loading a hires version from wad in the pack and new object using scale parameter.

 

ADDED later:

 

Added new plasmagun voxel today to the rddvox pack.

 

 

added randomization of Plasma Cell (+20 energycell itemk)graphics - we now get original-style with all 5 green dots(those are LEDs may be), and anotherone that has one of them a bit "used" - it is orange allready. bu still gives us 20 energy. But another strange thing i got during testing of how A_Jump works. It ALWAYS gives the same result on the same object. For example if we have there on demomap 7 cell pickups - then those 3 spawned to the left in 8 of 8 game restarts apeared with orange LED and other 4 always with green:

 

 

So the problem is in this fake randomising. Wht is it so? i aslo tested how looks Sub translucency.. Well, i liked it - it is really usefull for smokes (i still don't know if i like more translucent or Sub tlyed smoke:

 

 

now, when understanding what was the problem with soulsphere i fixed it. Still found a little problem with sprites, which was not seen in zdooms bit i think ill fix it with some sprite borders reprocessing (the same was with rubbish pixels in torch flames)

 

If You want to test the latest RDDVOX - get a WIP DelphiDoom version and wellcome!

 

RDDVOX-0.37a.zip

Edited December 7, 2019 by GRAU

[jval]

WIP 20191208 

 

• Key bindings for weapon change as suggested by @Khorus
• You are able to change OpenGL texture filtering from the menu (Options/Display/OpenGL/Texture filtering).
• Change the OpenGL voxel optimization method from the menu (Options/Display/OpenGL/Voxels).
• Fixed problems with A_SpawnItem & A_SpawnItemEx ACTORDEF functions. This eliminates problems with RDDVOX mod by @GRAU
• Added A_ScaleVelocity & A_ChangeVelocity ACTORDEF functions (zDoom compatibility).

 

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

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

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

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

 

Repository: https://github.com/jval1972/DelphiDoom/commit/9e6457c3a643cd906f3b4577e3326271d7a139be

 

Screenshot at 8 bit color with the RDDVOX add-on:

[Gez]

On samedi 7 décembre 2019 at 6:55 AM, GRAU said:

But another strange thing i got during testing of how A_Jump works. It ALWAYS gives the same result on the same object. For example if we have there on demomap 7 cell pickups - then those 3 spawned to the left in 8 of 8 game restarts apeared with orange LED and other 4 always with green:

 

 

So the problem is in this fake randomising. Wht is it so?

Doom is not really random. This video can explain the details. Since the item spawns happen before the player makes a first input, the start will always be identical.

[GRAU]

Downloaded new WIP. So, FloatRandom is the same to Random and can be used in for example A_SpawnItemEx? How many other functions like A_CustomMissile can use it as parameter?

Edited December 8, 2019 by GRAU

[Gez]

Presumably, Random gives a random integer while FloatRandom gives a random floating point number. You'll want to use FloatRandom for parameters that take floating point values and Random for parameters that take integer values.

[GRAU]

I tried FloatRandom instead of Random in torches. Got problems. May be functions like A_SpawnItemEx can not accept float values for offsets and speed?

 

I found a problem in default doom decorations - they are non-solid to monster fireballs and player rockets (but they have to be). Modified torches in RDVX are solid so i didn't detect that earlier. 

Edited December 8, 2019 by GRAU

[jval]

4 hours ago, GRAU said:

I tried FloatRandom instead of Random in torches. Got problems. May be functions like A_SpawnItemEx can not accept float values for offsets and speed?

 

I found a problem in default doom decorations - they are non-solid to monster fireballs and player rockets (but they have to be). Modified torches in RDVX are solid so i didn't detect that earlier. 

 

Floatrandom will be available in the next WIP. Sorry, I had to solve issues with A_SpawnItem & A_SpawnItemEx  first.

A_SpawnItemEx & A_SpawnItem accepts float values as offsets.

Also: The random, even if can get integer parameters, can return a float value if the parameter is float. The return value of random depends on the type of parameter. Eg for A_SpawnItemEx , it will return a float value for xofs field, but it will return an integer value for flags field.

About your decorations that are non-solid to missiles, it's because you had altered the height. For example, the "TallBlueTorch" has original (vanilla) height of 16 but you 've change it to 64. So the clipping code detects a collision due to height.

 

6 hours ago, GRAU said:

Downloaded new WIP. So, FloatRandom is the same to Random and can be used in for example A_SpawnItemEx? How many other functions like A_CustomMissile can use it as parameter?

 

Floatrandom will be available for every function.

[GRAU]

Nice then! so i still may use Random in next version, but it will return float for offsets. that is great idea, i think. then why is FloatRandom needed, when Random anyway will return Float values, when available?

 

Looks like i found another interesting bug. look WHERE are the smokes spawned, when fireball is above a lower floor:

 

 

But anything nice untill it flies on the same height as launched. Try yourself, i got this effect using RDDVOX and RDVXtest, just after andding a height-difference to the demomap.

 

RDDVOX.zip

RDVXTEST.zip

Edited December 9, 2019 by GRAU

[jval]

7 minutes ago, GRAU said:

Nice then! so i still may use Random in next version, but it will return float for offsets. that is great idea, i think.

 

The random already behaves this way, even from older versions.For example in VP_BlueTorch the parameter 'random(-3,3)' for A_SpawnItemEx xpos returns a float value between -3 and 3

 

[GRAU]

Good but i am worried a lot with those object - spawning (or may be sprite-ofsetting?) problems - post above =(

[jval]

55 minutes ago, GRAU said:

Good but i am worried a lot with those object - spawning (or may be sprite-ofsetting?) problems - post above =(

 

What WIP version is that? Seems like WIP 20191206 or before that. The WIP 20191208 solves this problem. (That was the problem with A_SpawnItemEx & A_SpawnItem).

Note that the executable names of the WIP 2091208 that solves the problem are Doom32_WIP_20191208.exe & GLDoom32_WIP_20191208.exe (not Doom32.exe & GLDoom32.exe).

 

Also in VP_ExploPart & VP_ExpSpark definition, the gravity keyword is not supported. You can use the LOWGRAVITY & MEDIUMGRAVITY flags instead:

 

VP_ExploPart

Gravity 0.2 --> LOWGRAVITY

 

VP_ExpSpark

Gravity 0.5 --> MEDIUMGRAVITY

 

Gravity can be set in a sector basis with PascalScript, and currently is not supported by individual actors.

 

These are screenshots from the WIP 20191208 version, without the offset problem:

 

[GRAU]

Re-downlkoaded the last wip, found problem on file replacment:

 

You named executables as usual in previous 2 WIP's so i forget to check their filenames. But after this, the fire trail became nice, but strange - i still experience problems with smoke trail offset 0_o

Looks like the problem apears ONLY when projectile is over the 3D floor in WIP from 08

 

Edited December 9, 2019 by GRAU

[jval]

1 hour ago, GRAU said:

You named executables as usual in previous 2 WIP's so i forget to check their filenames. But after this, the fire trail became nice, but strange - i still experience problems with smoke trail offset 0_o

 

 

I changed the names, in order to indicate the WIP version.

I've noticed the problem, it seems to me that the miss-placement appears only when the smoke is spawned above the 3d floor.

Also I must re-work the 3d-floor clipping for transparent sprites.

[GRAU]

Looks like. Because additive are rendered well-placed.

May you tell a little - how long were you studing pascal/delphi at all? I understand code logics, i used to code some scripts, and even some primitive programms during school times (Quick basic, Turbo Pascal), but I never had enough patience to learn high-level programming, something like you do, but at the same time, I always dreamed of writing my 3D engine  :D

 

I found another problem in renderer. In some voxels (i had this in key cards untill added an extra pixel from the top) the renderer loses one of the layers. Here i got it afain in Shell box:

 

In delphidoom

 

 

in qzdoom

 

 

So you see - the last layer from the left is missing. Will it be difficult to fix? Looks like to me that it appears when voxel is of the one of next values in some dimension: 8,16,32 and so on (it appeared with top pixel on keys when those were 16 height, and now here - the width of model is 32 layers)

Edited December 9, 2019 by GRAU

[jval]

12 hours ago, GRAU said:

Looks like. Because additive are rendered well-placed.

May you tell a little - how long were you studing pascal/delphi at all? I understand code logics, i used to code some scripts, and even some primitive programms during school times (Quick basic, Turbo Pascal), but I never had enough patience to learn high-level programming, something like you do, but at the same time, I always dreamed of writing my 3D engine  :D

I was programming in Pascal before Doom 1 release.

 

Quote

I found another problem in renderer. In some voxels (i had this in key cards untill added an extra pixel from the top) the renderer loses one of the layers. Here i got it afain in Shell box:

 

Can you upload the voxel file to test it?

 

The problems with the 3dfloors will be solved soon, I'm in good progress.

 

 

[GRAU]

Here are voxels, which lose one of their layers (top horizontal layer for keycards, one of the sides of shellbox)

 

problems voxels.zip

 

and rdvox files - to see how it looks on map:

 

RDDVOX.zip - Pack

RDVXTEST.zip - Demo map01

 

The keycards in THIS rdvox are allready fixed by adding one more layer fgrom top (added just a LED-looking 2pixels, and the bug disappeared. But this has to be fixed - not any voxel can be fixed by adding an extra layer, not every modder would like to apply such "fixes".

[jval]

WIP 20191210 

• Added FloatRandom function in parameters of ACTORDEF functions.
• Bug fix: Players can now spawned on 3d floors when the "On middle Floor" flag is set.
• Bug fix: Solved issue with A_SpawnItem & A_SpawnItemEx in sectors with 3d floors.
• Eliminated problems with voxel frames without a corresponding sprite in the wad. Now we do not have to provide a sprite with each voxel. Note that we still must define the voxel inside the VOXELDEF lump.
• Fixed problem with KVX voxels in software rendering mode.
• Eliminated problems with transparent drawing when the software renderer activates dephtbuffer (3d floors).

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

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

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

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

 

 

13 hours ago, GRAU said:

Here are voxels, which lose one of their layers (top horizontal layer for keycards, one of the sides of shellbox)

 

problems voxels.zip

Thanks for uploading this, helped a lot. Now kvx voxels work OK!

 

Screenshots:

 

Fixed problem with KVX voxels:

 

Fixed clipping of transparent sprites when the software renderer "touches" a 3d floor.

 

A_SpawnItem & A_SpawnItemEx are working properly when the spawned item is on a sector with 3d-floor:

 

Edited December 10, 2019 by jval

[GRAU]

Good work! Voxels now look really nice. But there is still a litle problem - translucent sprites are rendered IN FRONT of all other (even above the cacodemon, which is closer to me, and so on they are drawn like the smoke is closer to me then the fireball ,but that is false - the fireball is closer too!)

 

 

And another little problem - when JPG screenshots are selected - looks like all work nice, but when i choose PNG - it writes both PNG and JPEG (but not TGA)

The request - how about custom cheats in console? Freeze command for pausing the game (but not the player) - would help to get the prefered scene for demonstrating something, bugreport or feature, noclip - may be, usefull for testing own maps, as far as fly command - for levitation. may be something more. spawn[class_name] command - for spawning any thing you need, monsters or decoration you would like to test. Think about it. I would easily get a needed scene to demonstrate if i found another bug)

 

 

 

[jval]

1 hour ago, GRAU said:

Good work! Voxels now look really nice. But there is still a litle problem - translucent sprites are rendered IN FRONT of all other (even above the cacodemon, which is closer to me, and so on they are drawn like the smoke is closer to me then the fireball ,but that is false - the fireball is closer too!)

 

Oops, indeed! Thanks! How careless of me! I forgot to change the render order of translucent  sprites in 8 bit color mode. I've already fixed it (I hope), changes will be  available in next WIP after more tests:

 

 

Quote

And another little problem - when JPG screenshots are selected - looks like all work nice, but when i choose PNG - it writes both PNG and JPEG (but not TGA)

 

The mirrorjpgsshot console variable is set to true. Type ~ to bring down the console, and type "mirrorjpgsshot off" (without the quotes) to fix this. I've already changed it's default value to false.

 

[jval]

15 hours ago, GRAU said:

The request - how about custom cheats in console? Freeze command for pausing the game (but not the player) - would help to get the prefered scene for demonstrating something, bugreport or feature, noclip - may be, usefull for testing own maps, as far as fly command - for levitation. may be something more. spawn[class_name] command - for spawning any thing you need, monsters or decoration you would like to test. Think about it. I would easily get a needed scene to demonstrate if i found another bug)

 

 

• There are the stopthinkers & startthinkers console commands, but they do no work with add-ons, also the actor's momentum is maintained (e.g. missiles will continue flying). I'll work around it.
• idclip & idspispopd console commands (can by typed as cheats also)
• There is the lowgravity console command. You must hit the jump key for a couple of times to go up (when the lowgravity is enabled you can also thrust the player up with the jump key, even when the player is not on floor).                                                                                                                                                                                                 
• There is the spawnmobj console command. It takes 5 parameters: x, y, z, angle and actortype. Actortype can be the name or the editor number of the actor you want to spawn. E.g "spawnmobj 0 0 0 90 imp"

 

Combination of lowgravity with chase camera:

 

 

To avoid typing again and again console commands, you can place them in a text file with the *.con extension and use the exec console command.

To try it yourseft:

• Donwload  test1.zip  (contains the test1.con file, which is a text file and can be edited with notepad)
• Unzip the test1.con file in the same folder as the executable.
• start the game (with -iwad doom.wad)
• start e1m1
• type ~ to bring down the console
• type "dir *.con" (without the quotes) to see the con files in current directory (the console has the old dos dir command, also ls works)
• type "exec test1" (without the quotes) to run the console script

 

 

[GRAU]

Hi there! I have a question - is there any progress in copying dynamic lights code from fpc doom to delphidoom, especially i would like to see this feature in 8bit software, if posible. And the second is about the UDMF map format - do you have it in plans? Mapping in doom2-style format makes me feel limited a lot, for example setting sector color within map editor,  or making offsets for floor/ceiling just in 3d mode of doombuilder2. UDMF is another thing which could make high interest for mappers/modders in delphidoom.

[jval]

Porting the dynamic lights code from FPCDoom to DelphiDoom requires (for technical reasons) save-load game changes, thus it is scheduled after the tasks that do not require such changes.

DelphiDoom will attempt to load a UDMF map, as an experimental feature, since version 1.1.5.600, but this feature is not supported officially and also it does not work properly. It is something that I want to support thou.

 

Currently I'm working to support expressions in ACTORDEF functions parameters. I hope to have a stable WIP soon.

[jval]

On 12/7/2019 at 7:55 AM, GRAU said:

added randomization of Plasma Cell (+20 energycell itemk)graphics - we now get original-style with all 5 green dots(those are LEDs may be), and anotherone that has one of them a bit "used" - it is orange allready. bu still gives us 20 energy. But another strange thing i got during testing of how A_Jump works. It ALWAYS gives the same result on the same object. For example if we have there on demomap 7 cell pickups - then those 3 spawned to the left in 8 of 8 game restarts apeared with orange LED and other 4 always with green: 

 

On 12/8/2019 at 8:19 PM, Gez said:

Doom is not really random

 

I was thinking about randomization variety. DelphiDoom already creates a random seed outside the scope of internal random tables, depending on system time and the compiler's runtime library. It is used for random monster spawning, so that running again and again the game (when the spawnrandommonsters option enabled) will spawn different monsters. This seed is preserved in demo recording.

So, I can create a new random function (I accept suggestions, eg "sysrand" or whatever...) that will reproduce a unique random sequence every time you play the level.

Then, after implementing the A_JumpIf() ACTORDEF function (in next WIP version) you can replace:

A_Jump(128, 2)

with

A_JumpIf(sysrand(0,255) < 128, 2)  

or even without using the A_JumpIf()

A_Jump(sysrand(0,255), 2)

 

Edited December 15, 2019 by jval

[jval]

WIP 20191215

 

• Changed mirrorjpgsshot console variable default value to false.
• Corrected color overflow in renderstyle add (32 bit color software rendering).
• Shared or exclusive full-screen mode for the software renderer (as suggested by @Khorus).

• Function parameters in ACTORDEF evaluate expressions using C style operators.

• Added "freeze" console command, as suggested by @GRAU .Freezes the game, stop all thinkers, stop all scripts. Allow only the players to move. Players can also spawn missiles (unmovable) or pick up ammo and bonus. Attention: Player can still die (eg damaging floor). It has no effect while demo playback/record.

• Added A_JumpIf ACTORDEF function.

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

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

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

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

 

Repository: https://github.com/jval1972/DelphiDoom/tree/3c42eeb107c816b75fc0b7c0ed202ef5256b2909

 

ACTORDEF expression evaluation has been made following the guidelines of DECORATE syntax, i.e. C style expressions, 0-360 degrees for trigonometry functions etc.

The expression evaluator is case insensitive. In some cases, some Pascal language extensions have been added. E.g. the not equals can be written both as "!=" (C style) and "<>" (Pascal style).

 

So far I've added support for:

 

Operators:

• C style operators:  +, -, *, /, |, &, ^, !=, ==, <, > .  The || and && will be added in near future (the | and & operators work also as || and &&, depending on the operands - both operands must be of the same type - bool or int) . i.e. for bools | works as || but for integers works as |.
• Pascal style operators: AND, OR, XOR, NOT, <>

 

Math Functions:

• ABS
• MIN
• MAX
• EXP
• LOG
• LOG10
• LOG2
• CEIL
• FLOOR
• ROUND
• TRUNC
• INT
• SQR
• SQRT
• FRAC
• POWER

 

Trigonometry Functions

• SIN
• COS
• TAN
• ASIN
• ACOS
• ATAN
• SINH
• COSH
• TANH
• ATAN2
• VECTORANGLE

 

Flow

• IF(bool condition; whentrue; whenfalse)
• IFF (alias for IF)

 

Random functions

• RAND
• RANDOM
• RANDOM2
• FLOATRANDOM
• FRANDOM (alias for FLOATRANDOM)
• RANDOMPICK
• FRANDOMPICK
• SYSRAND (uses random seed from sytem's clock, Doom, Heretic & Strife branch only). The seed is preserved while demo recording.

 

Actor position and movement

• X
• Y
• Z
• MOMX
• VELX
• MOMY
• VELY
• MOMZ
• VELZ
• FLOORZ
• CEILINGZ
• ANGLE

 

Actor properties

• RADIUS
• HEIGHT
• ALPHA
• HEALTH
• REACTIONTIME
• THRESHOLD
• FASTCHASETICS
• KEY (Unique mobj key - DelphiDoom specific)
• FLOORCLIP

Pascalscript map & world variables (PascalScript communication - DelphiDoom specific)

• MAPSTR
• WORLDSTR
• MAPINT
• WORLDINT
• MAPFLOAT
• WORLDFLOAT

 

Custom params (Custom integer variables on per instance basis)

• CUSTOMPARAM
• PARAM
• TARGETCUSTOMPARAM
• TARGETPARAM

 

States (of the calling Actor)

• SPAWN
• SEE
• MELEE
• MISSILE
• PAIN
• DEATH
• XDEATH
• HEAL
• CRASH
• INTERACT
• RAISE

 

Screenshots:

 

Shared FullScreen mode (default)

 

 

"True" random generator:

Fixing the random cell problem mentioned by @GRAU

 

ACTORDEF SCRIPT:

ACTOR VP_Cell : "ENERGY CELL" replaces "ENERGY CELL" 
{
	States
	{
	Spawn:
		CELL B 1  
		CELL B 1  A_JumpIf(sysrand(0,255) < 128, 2)
		CELL B -1
		CELL A -1
                stop
	}
}

 

 

Freeze console command: (sorry, no time to write a script to make a matrix - bullet time - effect, maybe in the future)

 

 

 

Edited December 15, 2019 by jval

[GRAU]

16 hours ago, jval said:

 

 

I was thinking about randomization variety. DelphiDoom already creates a random seed outside the scope of internal random tables, depending on system time and the compiler's runtime library. It is used for random monster spawning, so that running again and again the game (when the spawnrandommonsters option enabled) will spawn different monsters. This seed is preserved in demo recording.

So, I can create a new random function (I accept suggestions, eg "sysrand" or whatever...) that will reproduce a unique random sequence every time you play the level.

Then, after implementing the A_JumpIf() ACTORDEF function (in next WIP version) you can replace:

A_Jump(128, 2)

with

A_JumpIf(sysrand(0,255) < 128, 2)  

or even without using the A_JumpIf()

A_Jump(sysrand(0,255), 2)

 

Why not just replacing A_Jump logics to get this advanced random for allready done weapon mods from zdoom etc?

But anyway the alternative random function is a nice sollution for making my own projects here! Thanks a lot!

About dynlights in software - so there is no way to make something at least looking like dynamic lights in 8bit renderer? May be some other logics? I understand that it is not primary objective now, but i hope one day this feature will apear. and may be at least you may add something like those semi-lights from 32bit mode to 8bit? Just with color paremeters - they look nice enough. But i would like to understand how to define this thing. Lets name them glows or coronas. So these coronas are not round for torches, but ellipsoid-shape. How did you do it? for candle i would like to make this corona effect of another color, more saturated, more yellow-orange maybe.

Anyway great improvements, ill test new randomization soon.

 

ADDED:

 

Sorry may be i  cant reach needed WIP version( And the adviced by site Last version looks like not the thing i need)

 

Edited December 16, 2019 by GRAU

[jval]

 

5 hours ago, GRAU said:

 

Why not just replacing A_Jump logics to get this advanced random for allready done weapon mods from zdoom etc?

But anyway the alternative random function is a nice sollution for making my own projects here! Thanks a lot!

You can use sysrand inside the parameters of A_Jump, i.e. A_Jump(sysrand(0,255), 2)

 

Quote

About dynlights in software - so there is no way to make something at least looking like dynamic lights in 8bit renderer? May be some other logics? I understand that it is not primary objective now, but i hope one day this feature will apear. and may be at least you may add something like those semi-lights from 32bit mode to 8bit? Just with color paremeters - they look nice enough. But i would like to understand how to define this thing. Lets name them glows or coronas. So these coronas are not round for torches, but ellipsoid-shape. How did you do it? for candle i would like to make this corona effect of another color, more saturated, more yellow-orange maybe.

Anyway great improvements, ill test new randomization soon.

The lights are drown according to the shape of the sprite. They are defined with the GREENLIGHT, BLUELIGHT, REDLIGHT, YELLOWLIGHT and WHITELIGHT actor flags.  I don't think these definitions have reason to expand, since the new light code will be implemented (hopefully in near future).

 

Quote

Sorry may be i  cant reach needed WIP version( And the adviced by site Last version looks like not the thing i need)

Sorry, fixed link: https://sourceforge.net/projects/delphidoom/files/WIP_BUILDS/WIP_Doom_20191215.zip/download
The version proposed by the site is the last official release, not WIP releases.