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

[GRAU]

20 hours ago, jval said:

 

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

 

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).

 

Yes, if you plan this - dont waste you time for those glow sprites. But in the same time they are cute! Which method is used to draw them at all? may be it can be used for sprite-based effects? for example as an alternative to add transparency - add2 or something like that?

[jval]

15 hours ago, GRAU said:

 

Yes, if you plan this - dont waste you time for those glow sprites. But in the same time they are cute! Which method is used to draw them at all? may be it can be used for sprite-based effects? for example as an alternative to add transparency - add2 or something like that? 

 

The lights in software renderer use a pre-calculated 2d array (like let's say an image) but instead of color value it holds a factor multiplier that is applied to individual RGB color components (of course clamps the RGB value to 255).

It's more like a RENDERSTYLE MULTIPLY applied to individual RGB color components.

E.g. GREENLIGHT flag applies the effect only to green color component (of the background), YELLOWLIGHT flag applies the effect to green and red color components, WHITELIGHT flag applies the effect to all RGB color components (R, G & B). When the player has the invulnerability power-up, the effect is applied to all RGB color components regardless the color that the flag indicates.

 

The 2d array is recalculated every time we change the lightboostfactor console variable (acceptable values are from 16 to 1024, default is 128). Higher the values mean stronger effect.

 

You can visualize the 2d array as an image:

 

Black color corresponds to multiply color by 1.0 (actually, the rendering engine skips these values since it has no effect). The white value corresponds  to (1.0 + lightboostfactor / 256) and gray values are between 1.0 and (1.0 + lightboostfactor / 256) .

 

[GRAU]

I tried using YELLOWLIGHT for vp_candle but i found the strange thing - all those lights when used with custom actors, are rendered ROUND and placed somewhere under the ceiling:

 

 

But when i disable my mod:

 

 

They look much better (but still under the ceiling :(( )

May be you could add params for them, used in gldefs?

For example:

glowfactor R G B (0-255 each)

glowscale (0-255) 

glowoffset (x,y,z integer in mappix)

 

btw this technix may be used for even more interesting effect of flashlite! We use the different sprite like that

 

 

(or default round spot)

 

So we get the first software sourceport with true flashlight in software)))

Edited December 17, 2019 by GRAU

[jval]

21 hours ago, GRAU said:

I tried using YELLOWLIGHT for vp_candle but i found the strange thing - all those lights when used with custom actors, are rendered ROUND and placed somewhere under the ceiling:

 

It's an issue that affects voxels without a sprite. I'm aware of this, I know what has to be done to fix this but I want to focus on porting the dynamic lights code from FPCDoom right now.

 

Quote

They look much better (but still under the ceiling :(( )

May be you could add params for them, used in gldefs?

For example:

glowfactor R G B (0-255 each)

glowscale (0-255) 

glowoffset (x,y,z integer in mappix)

 

I thing I should not use GLDEFS for than king of definition, since GLDEFS is a ZDoom lump and I want to stay compatible with it. That's why I used LIGHTDEF lump for the GLDEFS equivalent (and also that's why I use ACTORDEF lump and not DECORATE). Since this effect is an actor effect and not a sprite effect the best place to put it is in actor definition.

 

Quote

 

btw this technix may be used for even more interesting effect of flashlite! We use the different sprite like that

 

(or default round spot)

 

So we get the first software sourceport with true flashlight in software)))

 

I'm not sure that I understand what you mean, do you mean something like lens flare effect?

[GRAU]

14 minutes ago, jval said:

 

It's an issue that affects voxels without a sprite. I'm aware of this, I know what has to be done to fix this but I want to focus on porting the dynamic lights code from FPCDoom right now.

 

That's your right, i just ask for this feature for future. No mater for me how should it be defined - via LIGHTDEF, or via GLDEFS or any other)

 

16 minutes ago, jval said:

 

I'm not sure that I understand what you mean, do you mean something like lens flare effect?

 

No, not lens flare. Since delphidoom can multiply colours using some image as mask - we can make the doom3 style flashlight effect, by fixing this multiplying image in front of player or just on hud. For single - player this idea seems to be cool, but i still - in multiplayer nobody, excepting you can see your flashlite affect. I could make a demo of this just after you add an advanced definition for this semi-light effect as i asked above

[jval]

 

Quote

 

No, not lens flare. Since delphidoom can multiply colours using some image as mask - we can make the doom3 style flashlight effect, by fixing this multiplying image in front of player or just on hud. For single - player this idea seems to be cool, but i still - in multiplayer nobody, excepting you can see your flashlite affect. I could make a demo of this just after you add an advanced definition for this semi-light effect as i asked above

 

I remember ...dreaming to make something like this in very early versions of the project. Great!

 

 

 

 

[GRAU]

I have finished version 0.37 of my RDVOX mod. Full compatibility with latest WIP release:

 

RDDVOX-0.37.zip - Delphidoom version

 

RDVXTEST.zip - latest demomap to use with this mod.

 

My favourite object in this update is this guy:

 

 

[Khorus]

Good voxel pack, really suits the medium quality software setting nicely. The shortened barrel explosion makes them feel more satisfying, wasn't expecting that. A bug on my end, there's no teleport sound. It's not on the engine as the sound works without the mod. The smoke effect on the imp fireball is pretty strong too. I also took the DOOMPAL+.wad out as I wasn't a fan of what the COLORMAP did to the stock textures.

 

Looking forward to seeing more voxels!

[GRAU]

well, may be i have to create a sepatated topic for discuting this mod. DOOMPAL+ was created especially to enable soft white-blue gradient. It is needed to render blue dynlights on gray textures in qzdoom and also may be needed in Delphidoom once jval will finish dynlights code in software

 

 

So untill there are no dynlights in delphidoom  DOOMPAL+ may look useless.

Ill look at telefog code, thanks for feedback. 

Jval, is delphidoom supporting A_PlaySound function?

Edited December 19, 2019 by GRAU

[jval]

9 hours ago, GRAU said:

Jval, is delphidoom supporting A_PlaySound function?

 

Yes, A_Playsound is supported.

 

[jval]

WIP 20191220

 

Working dynamic lights in software rendering (currently only in 32 bit color mode).

 

There are still things to be done:

• Currently not available in 8 bit color lights
• The effect can not be turned off (well, you can always edit the *.swd files and remove the LIGHTDEF lump)
• Parameters can not be adjusted
• Untested on slopes (but should work)
• Does not cast lights in middle 2s lines.
• Multi-threading and other speed optimizations.

 

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

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

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

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

 

Repository: https://github.com/jval1972/DelphiDoom/commit/e52f135f5ea8244d4cb76b40b478ee9ab4063cb1

 

Screenshots:

 

 

 

 

[GRAU]

Well, i like thge fact you added em at least in 32bit mode, but i couldn't say that it is looking good, dye to fact i dont like 32bit software at all. And they are not look as lights on those screens, further they are additive soapy decals. May you use color multiplying like in those glow-looking spritesm used to be in delphidoom 32bit before, but apply it to geometry, like you do now? Anyway i hope you plan to add them in 8bit.  So,  i like your work! continue it anyway, and concentrate on optimizations, may be you should try to use color translation tables for each light colour used in map. but it will look useless if you add colour sector lighting then (or is it supported allready?)

 

BTW!

On 12/19/2019 at 6:19 AM, Khorus said:

 I also took the DOOMPAL+.wad out as I wasn't a fan of what the COLORMAP did to the stock textures.

 

Looking forward to seeing more voxels!

 

i heard you opinion and spent over 2 hours yesterday night to solve a problem with some default blue textures, and fix some colors at all (lite-green,green, orange improved, needs to be tested, actualy i didnt mind out - which object and textudes in doom, excluding yellow skullkey, use the orange gradient at all!)

Try it please.

 

RDDVOX.zip

 

 

 

Edited December 20, 2019 by GRAU

[jval]

WIP 20191222

 

What's new:

 

• Dynamic lights in 8 bit software mode
• Multi-threading and speed optimizations for the new dynamic lights code.
• Added r_uselightmaps, lightmapcolorintensity and lightwidthfactor console variables to customize the new dynamic lights. Customization within menus will come soon.
• If an unknown map thing is detected it will not exit with I_Error, it will generate a warning instead.
• Indivitual entries in the defaults file for OpenGL & software screen size.
• Support for MUSINFO lump.

Please note you may not be able to load saved games from this version with later releases.

 

Downloads:

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

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

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

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

 

Repository: https://github.com/jval1972/DelphiDoom/tree/73d93c4af4aa44ab3d0301cc4cd81960d7bebcad

 

Screenshot demonstrating the dynamic lights in 32-bit (normal) and 8-bit (medium) color software rendering (using RDDVOX add-on):

 

[GRAU]

Nice work! but i got strange effect here:

 

 

Look at that squares over green armor. I think they are cased with those glow overriding sprites (like REDLIGHT etc). It appears in 8bit only. Did you make them generated automaticaly? May be you should disable then those glow effects for 8bit - i think that is the problem. Or what is that thing?

BTW i like nice performance now on Pentium 4 3.2GHz - that is what like in delphidoom. 

[GRAU]

 

After changing lightmapcolorintensity to 128 and then to 160  i got much,much closer to what_it_have_to_be, or what_it_is_in_qzdoom picture. So i advice you to set this parameter default by 128-192. but not 64, And more: it feels like lightmapcolorintensity 64 for 32bit looks the same as 128 for 8bit (look below). may be you should make at least doubled this parameter for 8bit by default?

 

lightmapcolorintensity 64:

 

\\

 

lightmapcolorintensity 128:

 

 

[jval]

No, it's not the glow lights effect, the glow lights are working only in 32 bit color. It's the level of accuracy and the limitation of the 256 color palette.

I've noticed that in 8 bit color palette very often the effect does not even change the background palette index, especially on the edges, so I've experimenting with the math, to get a different palette index more often (somehow forcing a different palette index).

 

I'll also check the lightmapcolorintensity variable to be sure that it works correctly.

 

This is the standard math (same as FPCDoom)

 

This is the version while tampering with the math (used by the uploaded version):

 

 

[GRAU]

Found another strange thing - until i deleted lightdef from doom32.swd - it was overriding the "gldefs" from the RDDVOX. this screenshot demonstrates strange thing - light on the floor is rendered nice but  something vertical, oval, above it is rendered, but sometimes seen only in ONE brithness level (further standing objects usualy), and so looking square. Check this, please!

 

 

Btw, before this WIP i used less saturated colors. and that worked nice in delphidoom GL or in qzdoom version (screenshots below) with the same palete and parameters:

 

 

May be you should inspect the colour index changing logic here and borrow something interresting algorithms for delphidoom?

 

qzdoom-q2.0.0.zip

 

 

 

Edited December 23, 2019 by GRAU

[Gez]

10 hours ago, jval said:

If an unknown map thing is detected it will not exit with I_Error, it will generate a warning instead.

You could do like ZDoom and spawn error markers in the map.

[Khorus]

Been playing a few maps in DelphiDoom today, this port is really shaping up to be something I could use frequently :) The software renderer has a really good aesthetic to it with the only problem that I have to play uncapped as capped gives a feeling of input lag and frame choppiness, like it's struggling to keep up with the cap.

 

On 12/21/2019 at 6:31 AM, GRAU said:

i heard you opinion and spent over 2 hours yesterday night to solve a problem with some default blue textures, and fix some colors at all (lite-green,green, orange improved, needs to be tested, actualy i didnt mind out - which object and textudes in doom, excluding yellow skullkey, use the orange gradient at all!)

Try it please.

 

RDDVOX.zip

 

I think it's a big improvement over the older one! I'd still be taking it out for my own use as textures in some WADs can be off, AV Map01's sky for example. I'm also very used to the original colormap and any change is weird to me so there's that too :P

 

Playing with your mod some more I noticed the rocket launcher trails were killing fps, and that the plasma balls were quite large and blocked a lot of view. Still really impressed with all of the voxels though, I'll be using them to help position things in my maps. :)

[GRAU]

Just now, Khorus said:

Playing with your mod some more I noticed the rocket launcher trails were killing fps, and that the plasma balls were quite large and blocked a lot of view. Still really impressed with all of the voxels though, I'll be using them to help position things in my maps. :)

 

If you need some of thgem - you may use em in your FREEWARE mods/maps, but add my nickname to the credits under the voxel list you use. If you plan some commerce - you should write me a private message)

 

As for fps loses - it is the same with imp smoke, and cased by multiple translucent sprites, but i dont like the idea of decreasing its lifetime or size, beside i plan some sprite changes/improvements for that, and the scale of plasma sprite will be improved soon as far as arachnatron plasma effect. New WIP builds make me thinking about reconfiguring fireball dynlight brightness/size because large dynlights itselves kill a lot of fps. But first i will wait till jval finish all the fixes/optimizations.

[jval]

14 hours ago, GRAU said:

Found another strange thing - until i deleted lightdef from doom32.swd - it was overriding the "gldefs" from the RDDVOX. this screenshot demonstrates strange thing - light on the floor is rendered nice but  something vertical, oval, above it is rendered, but sometimes seen only in ONE brithness level (further standing objects usualy), and so looking square. Check this, please!

 

Hmmm, actually, it registers both the LIGHTDEF lump from doom32.swd and the GLDEFS.txt from your RDDVOX.... so in the same sprite there are 2 lights assigned to it (and they are both rendered).  How does ZDoom handle such situations? (multiple GDEFS for the same object/sprite)

The vertical/oval is less noticeable when the default strength of the effect rises. As you mentioned above, I've changed the default value of lightmapcolorintensity to 128. Also I've already changed the experimental math I've mentioned yesterday.

 

11 hours ago, Gez said:

You could do like ZDoom and spawn error markers in the map.

Done, but needs some work with the sprite :)

 

 

 

8 hours ago, Khorus said:

Been playing a few maps in DelphiDoom today, this port is really shaping up to be something I could use frequently :) The software renderer has a really good aesthetic to it with the only problem that I have to play uncapped as capped gives a feeling of input lag and frame choppiness, like it's struggling to keep up with the cap.

 

I've noticed this too, also I've checked what's wrong but couldn't find out. I'll run all previous versions to see when the problem appeared and check the code to find out what possibly causes it.

 

8 hours ago, Khorus said:

Playing with your mod some more I noticed the rocket launcher trails were killing fps, and that the plasma balls were quite large and blocked a lot of view. Still really impressed with all of the voxels though, I'll be using them to help position things in my maps. :)

 

2 hours ago, GRAU said:

As for fps loses - it is the same with imp smoke, and cased by multiple translucent sprites, but i dont like the idea of decreasing its lifetime or size, beside i plan some sprite changes/improvements for that, and the scale of plasma sprite will be improved soon as far as arachnatron plasma effect. New WIP builds make me thinking about reconfiguring fireball dynlight brightness/size because large dynlights itselves kill a lot of fps. But first i will wait till jval finish all the fixes/optimizations.

 

In rocket launcher the fps drop is big because due to the first person view, the effect covers the majority of the screen, so a lot of overdraw is done.

There is some progress in speed optimization of the dynamic lights, but I have not finished yet.

 

[GRAU]

22 minutes ago, jval said:

Done, but needs some work with the sprite :)

 

may i help you?

 

How does ZDoom handle such situations? (multiple GDEFS for the same object/sprite)

 

It replaces ALL object definitions whis the later one loaded. When we use 3 wads and 1 and 2 has the same object A defined and 1 and 3 has object B defined - it will load all it finds from wad 1. when loading wad 2 it replacess at all the definition for object A. Replacess all for object B when loading wad 3. AND i advice remove dynamic light defining from lightdef - leave only delphidoom specific definitions there, and move the lights - to GLDEFS. it will increase compatibility for further mods with ZDoom. Or - remove gldefs lump at all - i dont think delphidoom will once be the same as zdoom. 

 

The vertical/oval is less noticeable when the default strength of the effect rises.

 

Can you remove this overlay effect at all? leave only usial light seen on walls/floors, this will save some fps and improve the view of scene in dark maps. If i will need glow for some objects i will use my own sprite spawned with actordef. As i mentioned - glow effect in software needs much more contrast sprite of the smaller size as a base, to look nice:

 

 

 

 

 

Edited December 23, 2019 by GRAU

[Gez]

57 minutes ago, jval said:

Hmmm, actually, it registers both the LIGHTDEF lump from doom32.swd and the GLDEFS.txt from your RDDVOX.... so in the same sprite there are 2 lights assigned to it (and they are both rendered).  How does ZDoom handle such situations? (multiple GDEFS for the same object/sprite)

Remove the previously-assigned light when encountering a new definition for the same object.

 

For example, if you changed the arachnotron projectiles to be purple, you'll want to attach purple lights to it, and you won't want the default yellow-green lights to remain attached. So new definitions have to replace the old.

[jval]

13 hours ago, Gez said:

Remove the previously-assigned light when encountering a new definition for the same object. 

 

 

Quote

 

It replaces ALL object definitions whis the later one loaded. When we use 3 wads and 1 and 2 has the same object A defined and 1 and 3 has object B defined - it will load all it finds from wad 1. when loading wad 2 it replacess at all the definition for object A. Replacess all for object B when loading wad 3.

 

 

Thanks, I'll fix this. Multiple lights for an object must be reside inside the same lump then, I assume.

 

Quote

AND i advice remove dynamic light defining from lightdef - leave only delphidoom specific definitions there, and move the lights - to GLDEFS. it will increase compatibility for further mods with ZDoom. Or - remove gldefs lump at all

 

 

I checked the ZDoom wiki and since the LIGHTDEF lump of DelphiDoom does not support all the features of the GLDEFS lump, I 'll stick to LIGHTDEF name and avoid parsing GLDEFS lump. If a mod has a GLDEFS lump compatible with DelphiDoom must include a LIGHTDEF lump with the following line of code:

 

#include_all "gldefs.txt"

With the #include_all directive, DelphiDoom searches for all gldefs.txt entries inside the pk3 filesystem.

 

The same logic is used for ACTORDEF lumps, there is a good common base with DECORATE lumps, but also significant differences.

 

In addition the different names of the ACTORDEF & LIGHTDEF lumps, offers the chance to freely evolve on their own way.

 

@GRAU

You must rename the GLDEFS.txt to LIGHTDEF.txt for RDDVOX to work with next releases, or include a LIGHTDEF.txt lump with the above line of code using the #include_all directive.

 

14 hours ago, GRAU said:

may i help you?

Of course, any help is welcome!

 

Quote

Can you remove this overlay effect at all? leave only usial light seen on walls/floors, this will save some fps and improve the view of scene in dark maps. If i will need glow for some objects i will use my own sprite spawned with actordef. As i mentioned - glow effect in software needs much more contrast sprite of the smaller size as a base, to look nice: 

I'll tune the curve of the effect to add more contrast and see if the results are better.

 

Edited December 24, 2019 by jval : grammar

[GRAU]

15 hours ago, jval said:

I checked the ZDoom wiki and since the LIGHTDEF lump of DelphiDoom does not support all the features of the GLDEFS lump, I 'll stick to LIGHTDEF name and avoid parsing GLDEFS lump. If a mod has a GLDEFS lump compatible with DelphiDoom must include a LIGHTDEF lump with the following line of code:

 

I agree with you here. If mod is compatible then we will at least have the LIGHTDEF with  #include "gldefs.txt" string in it. And if the mod is non-compatible (has maps in gzdoom standart) - it will anyway have problems running. So make the main and only lump - LIGHTDEF.

 

15 hours ago, jval said:

You must rename the GLDEFS.txt to LIGHTDEF.txt for RDDVOX to work with next releases,

 

Ok.

 

15 hours ago, jval said:

 

Of course, any help is welcome!

 

 I mean - what exactly you need to do with the sprite of undefined actor? or what else is actual now?

 

Some more improvementys done to orange gradient in doompal2 - it will improve the look of imp's fireball and some more dynlights like red torches, mancubus fires, and may be lostsouls. I recorded a small video demonstrating how it helps the engine to change the index, and show more saturated effects sometimes while using RDDVOX 0.38 Alpha:

 

 

the fixed effect of teleportation with sound but without gliches added)

Edited December 24, 2019 by GRAU

[jval]

On 12/23/2019 at 1:52 PM, Khorus said:

The software renderer has a really good aesthetic to it with the only problem that I have to play uncapped as capped gives a feeling of input lag and frame choppiness, like it's struggling to keep up with the cap.

 

I've managed to find out what is causing the problem: It's the shared full-screen option. Switching from the build-in Intel HD graphics to my NVidia GTX did't solve the problem. Does the problem remain to your PC in exclusive full-screen mode?

[Khorus]

It's strange, in exclusive mode with both uncapped and capped fps the mouse itself feels slower/sluggish and there is massive input lag. When in window/off mode it acts the same as shared. Tried turning multithreading to off, but it didn't change any results.

 

My system is Windows 10, Ryzen 1600 and a GTX 980ti

 

On 12/24/2019 at 1:23 AM, GRAU said:

 

If you need some of thgem - you may use em in your FREEWARE mods/maps, but add my nickname to the credits under the voxel list you use. If you plan some commerce - you should write me a private message)

 

 

I appreciate that, but I mean using it just on my end to check thing angles on decorations and items etc. on my maps for people who do might like to use such packs in their daily play. I have a k8vavoom setup using models for it too, but doing it in software is certainly nice :)

[GRAU]

Well, may be i don't understand right, but i don't feel any freeze or lag, at least without FPS limitation. But i still feel it walking too close from dynamic lights)

BTW!  I found a GREAT problem - gldefs(i think lightdef acts the same) - it applies dynlight to a sprite, but not to a frame of object. This is the reason why imp fireballs cause heavy fps loses. This is the code of  VP_ImpBalll:

 

ACTOR VP_ImpBall : IMPFIREBALL Replaces IMPFIREBALL
{

    Alpha 0.7
    renderstyle Add
    states
    {
    Spawn:
        IMPB AABB 1 bright A_SpawnItemEx("VP_ImpTrail", 0, 0, random(-2, 5), 0, 0, 0)
        loop
    Death:
        IMPB AAAAAAAA 0 bright A_SpawnItemEx("VP_ImpESPR", 0, 0, 0, random(-3, 3), random(-3, 3), random(-3, 3))
        IMPF ABC 3 bright A_FadeOut(0.2)
        stop
    }
}

 

Look at frames in death state - IMPF ABC. These IMPFA-IMPFC sprites. They are used by this object ONLY in death - you see. Remember it. And now the code of spawned fire trace:

 

ACTOR VP_ImpTrail
{ 
    Scale 1.2
    Alpha 0.6
    renderstyle add
    +NOCLIP
    +NOGRAVITY
    States
    {
        Spawn:
        IMPB B 2 BRIGHT A_FadeOut(0.07)
        IMPF A 2 BRIGHT A_FadeOut(0.07)
        IMPF B 2 BRIGHT A_SpawnItemEx("VP_ImpSmoke", 0, 0, 0, random(-1, 1), random(-1, 1), random(-1, 1))
        IMPF C 2 BRIGHT A_FadeOut(0.07) 
        Stop
    }
}

 

So it uses the same sprites and spawned all the way.

 

And now the GLDEFS code:

 

flickerlight VPIMPBALL
{
    color 1 0.5 0
    size 56
    secondarysize 64
    chance 0.8
}

pointlight VPIMPFIRE1
{
    color 1 0.5 0
    size 88
}

pointlight VPIMPFIRE2
{
    color 1 0.4 0
    size 72
}

pointlight VPIMPFIRE3
{
    color 1 0.3 0
    size 48
}

object VP_ImpBall
{
    frame IMPBA { light VPIMPBALL }
    frame IMPBB { light VPIMPBALL }
    frame IMPFA { light VPIMPFIRE1 }
    frame IMPFB { light VPIMPFIRE2 }
    frame IMPFC { light VPIMPFIRE3 }
}

 

As you see - it doesnt apply any lights to the object VP_ImpTrail. BUT in game we have the lights from impball aplied to the same sprites in imp trail.

To be sure i did this:

 

object VP_ImpBall
{
    frame IMPBA { light VPIMPBALL }
    frame IMPBB { light VPIMPBALL }
 //  frame IMPFA { light VPIMPFIRE1 }
 //   frame IMPFB { light VPIMPFIRE2 }
//    frame IMPFC { light VPIMPFIRE3 }
}

So i disabled in gldefs all frames that are used by the imp trail too. What did i got?

 

nice looking orange light (that even can be increased now! with nice color it had to have)

And if i enable those shared by two objects sprites i get this:

 

 

This increased size, overlit whitened color, and even prolonged form (look at the floor - it is seen that a few lights in a row are spawned!), and the worst - FPS loses - it is a problem. The problem with rocket launcher (Heavy fps loses) also was caused with this - rocket trail uses this IMPF sprites too! May you make light per object frame, but not per sprite? Some sprites can be used in multiple objects - somewhere the light needed somewhere - not.

I also add RDDVOX itself so you could check all those things.

RDDVOX.zip

Edited December 26, 2019 by GRAU

[jval]

18 hours ago, Khorus said:

It's strange, in exclusive mode with both uncapped and capped fps the mouse itself feels slower/sluggish and there is massive input lag. When in window/off mode it acts the same as shared. Tried turning multithreading to off, but it didn't change any results.

 

Hmmm, strange, in uncapped frame-rate it runs smooth for me, even with slower CPUs (i5-3570 & i7-7700HQ at 1920x1080). I 've already implement some improvements (more accurate timing in uncapped framerate by predicting the time the frame takes to render and an option for the DirectDraw blit mode - synchronous/asynchronous).  They will be available in next version.

Turning off multi-threading will slow down the  renderer, unless we have a pre-multi-core PC.
 

 

7 hours ago, GRAU said:

Well, may be i don't understand right, but i don't feel any freeze or lag, at least without FPS limitation. But i still feel it walking too close from dynamic lights)

BTW!  I found a GREAT problem - gldefs(i think lightdef acts the same) - it applies dynlight to a sprite, but not to a frame of object.

 

You're right, I do a per-sprite assignment and I completely ignore the OBJECT keywords inside LIGHTDEF (and GLDEFS) lumps. I'll change this ASAP.

 

 

7 hours ago, GRAU said:

I also add RDDVOX itself so you could check all those things.

RDDVOX.zip

 

I've tried it, the new palette gives far better results in 8 bit color! Also next version will have option to change the fade-out function of the effect (default will be the current hard-coded function).

[GRAU]

2 hours ago, jval said:

You're right, I do a per-sprite assignment and I completely ignore the OBJECT keywords inside LIGHTDEF (and GLDEFS) lumps. I'll change this ASAP.

 

Nice news! And i allready changed definition name to LIGHTDEF - i'm ready for update :D 

 

As soon as I found the cause of the FPS loses near fireballs and rockets - i disabled temporary those sprites which used with trail (and firebal death) effects. I use an old 3.4GHz Pentium D (dual Pentium 4) for tests and the result was incredibly high - now there sre no lags near a fireball or even 3 fireballs on this old CPU! At my calculations - there were from 3 to 5 lights at the same time processed for EACH fireball in scene! now all nice in 1024*768 on tis system,despite i inreased all lights for fireballs and torches. So ill wait for new light definition logic.

 

3 hours ago, jval said:

 

I've tried it, the new palette gives far better results in 8 bit color! Also next version will have option to change the fade-out function of the effect (default will be the current hard-coded function).

 

Could you also  make an option to DISABLE this strange oval glow-looking thing (red on the screenshot) and leave only normal light projections on walls and floor (green on screenshot) ??

 

 

I continue experiments with palete, but i am chained here - most of colors are used in tons of sprites and textures. So i can only improve a bit blue, yellow, orange-to-red and may be green colors to help renderer with lights. You can see those experiments in RDDVOX i added above in previous message. But i think i can do more here. Doom palete is a special topic - it is strange, logic less from one side, and somewhere genious from another, and the main difficulty is that it is used in most of pwads with the new textures and flats also.

 

I reprocessed the candelabra footer, so the ligght on those skulls look natural now)