Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
jval

DelphiDoom 2.0.4.720 (Updated Oct 12, 2019)

Recommended Posts

WIP 20191230

 

What's new:

 

  • Added DONTSPLASH alias for NOHITFLOOR flag.
  • Added -noactordef command line parameter, when you run with this parameter it will not parse ACTORDEF lumps.
  • Support for fullscreen patches with resolution greater than 320x200.
  • Support for tall patches.
  • Added 'INITIAL BULLETS' and 'BFG CELLS/SHOT' dehacked fields.
  • PUSHFACTOR, SCALE and GRAVITY fields for actor instances.
  • Added r_lightmapfadeoutfunc console variable, change the fadeout function of software dynamic lights (linear, curved, persist, cosine and sigmoid). Can be set from the menu (Options/Display/Advanced/Lightmap).
  • Added r_bltasync console variable, when true (default) it will blit the frame to the DirectDrawBuffer asynchronously (software renderer). Can be configured from the Menu (Options/Display/Advanced)
  • Added DEH_SaveStatesCSV and BEX_SaveStatesCSV console commands, save states information to a csv file.
  • Added DEH_SaveSpritesCSV and BEX_SaveSpritesCSV console commands, save sprite names to a csv file.
  • Light definitions inside LIGHTDEF lump will overwrite previous light declarations.
  • Added r_generatespritesfromvoxels console variable. When true (default) it will generate sprites for voxels without a corresponding sprite.
  • Added allowvanillademos console variable, when true (default) will play vanilla demos.
  • Added VANILLA_DEMO_OFF directive. It can be placed in ACTORDEF, MODELDEF, VOXELDEF?, LIGHTDEF & SNDINFO lumps and will prevent the engine to play vanilla demos. The setting is not preserved in defaults file and the modders should use this if their mod breaks vanilla demo compatibility.
  • Fixed uncapped framerate glitch in teleporting monsters.
  • LIGHTDEF lumps now define lights in a per actor basis and not in a per sprite bases.

 

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_20191230.zip/download

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

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

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

 

Source Code: https://sourceforge.net/projects/delphidoom/files/Source%20Code%20Snapshots/DelphiDoomSrc_20191230.rar/download

Repository: https://github.com/jval1972/DelphiDoom/tree/ec17f04fee0027fc6cbae0a093492ac949ff6251

 

Screenshots:

 

Lightmap fadeout function (8 bit):

output-Jb-Sv-Td.gif

 

Lightmap fadeout function (32 bit):

output-mhq0-S1.gif

 

Sprites generated from voxels (using vechicle voxel pack):

output-Cxl-RJp.gif

 

 

Edited by jval

Share this post


Link to post

Nice work! Don't you think gismoid light type looks a bit smaller then others? may be you should use a bit higher radiusscale factor for that type?

Share this post


Link to post

I got a question or even a few.

1) Why can not i run under a cacodemon even when it is MUCH higher? only if a 3dfloor separates me from an enemy - i can do that but i can not jump above an enemy or even to jump onto a barrel. I think this is very inmortant for modding. Could you make infinite height an option or just disable at all?

SSHOT_Doom_20191231_134432609.jpg.bfc9a4762aa54091ac9f4175e3243d90.jpg

 

2) the similar question about collision between fireballs and default doom torches, candelabras and so on. why can fireballs freely pass through those decorations? They have not to. It breaks gameplay in some wads where a decoration like a body or torch is set on map to give player a place to hide from cyberdemon rockets (i've seen such in Alien Vendetta, and in hellfire reborn, may be much more wads that i didn't play yet)

 

3) Why can not i shoot into floor with a hitscan? it is targeted to nearest angle between a wall and a floor (or a wall and a ceiling, but never into a floor plane). Can you fix this? This is too a part of 3d gameplay, i think.

 

 

SSHOT_Doom_20191231_140828109.jpg

SSHOT_Doom_20191231_140833859.jpg

Share this post


Link to post
10 hours ago, GRAU said:

Nice work! Don't you think gismoid light type looks a bit smaller then others? may be you should use a bit higher radiusscale factor for that type?

 

Indeed, I'll fix this ASAP.

For reference this is the curve of light diminishing functions I've used, sigmoid seems to fade out fast....

 

lightfunc-software.png

 

I was wondering if there is any interest to give access to this function to the user (user defined diminishing curves?), and how can this be implemented....

Some other ideas I have is to add random noise to the curve.... I can't tell if the visual output will be noticeable improved though... (?)

 

 

1 hour ago, GRAU said:

 

I got a question or even a few.

1) Why can not i run under a cacodemon even when it is MUCH higher? only if a 3dfloor separates me from an enemy - i can do that but i can not jump above an enemy or even to jump onto a barrel. I think this is very inmortant for modding. Could you make infinite height an option or just disable at all?

 

When 2 actors are separated by a 3d floor can not collide, the engine detects such situations and make the appropriate calculations.

Now, if we want the player to be able to run under a cacodeamon, pain elementals etc, we can do this easily by setting the PASSMOBJ flag on.

Just add the following few lines inside an ACTORDEF lump:

ACTOR pass_player: player REPLACES player
{
  +PASSMOBJ
}

Download of the above the example: pass_player.zip

 

To make the player able to jump over a barrel we must alter the default barrel properties, eg:

ACTOR pass_barrel: barrel REPLACES barrel
{
  HEIGHT 32
  +PASSMOBJ
}

Download the above example: pass_barrel.zip

Note that we also alter the barrel's height to 32 (vanilla height is 42), so that the player can actually jump on it easily

 

 

 

1 hour ago, GRAU said:

 

2) the similar question about collision between fireballs and default doom torches, candelabras and so on. why can fireballs freely pass through those decorations? They have not to. It breaks gameplay in some wads where a decoration like a body or torch is set on map to give player a place to hide from cyberdemon rockets (i've seen such in Alien Vendetta, and in hellfire reborn, may be much more wads that i didn't play yet)

 

They freely pass because their height is defined at 16 units (i.e. they are too short). This is the vanilla height. Zdoom based ports may change this if not in compatibility mode.

 

 

 

1 hour ago, GRAU said:

3) Why can not i shoot into floor with a hitscan? it is targeted to nearest angle between a wall and a floor (or a wall and a ceiling, but never into a floor plane). Can you fix this? This is too a part of 3d gameplay, i think. 

 

 

DelphiDoom (and all Boom compatible source ports) extends the puff spawning to lower textures of linedefs, but not in floor/ceilings. I'll work around it ...

 

 

Share this post


Link to post

Maybe we can implement some type of compatibility modes too?

Adding passmnobj flag to all the objects will need the creation of a special mod, for those for want true 3d gameplay for vanilla maps. may be this flag may be set automaticaly by changing the compatlevel so heights of objects will raise and the needed flag given to all objects needing this?

 

I ask about this because Delphidoom now goes much further then boom, coming clother by functiomality to zdoom. so the compatibility mode is realy needed to be set as:

 

Auto - changes height and ppassmobj flags as in vanilla for vanilla and boom maps, sets true3d gameplay in delphidoom and udmf map formats 

True 3D - always true 3d gameplay, with higher torcher and longer hanged corpses

 Vanilla - Use vanilla gameplay even on maps with 3D floors (in delphidoom format, like it is done now)

Edited by GRAU

Share this post


Link to post

Hello! I got an idea of an interesting feature - what if we could use voxels not only for objects, but for some textures too? for example - we have a lot of skull or button switches in doom and not only in doom. And for exampe we have some door textures with metal bas-relief demon heads on them. I would like to have an ability to apply voxels for those textures too!

 

May be there is a way to make that feature? To define voxels for some of textures with some offsets. In future thgis might even be used for voxel textures (therefor in don't think this is a good idea, because of low performance when rendering voxels, but some people using i9 may like))

 

If yes 0 we have 2 types of textures for walls. Complete textures (compiled of a few patches sometimes) and patches themselves. The best one would be to have the way of defining both types - sometimes more usefull to set voxel to a patch like SW2_1 - SW2_8 in Doom. And sometimes we have a final texture needing some volume.

Share this post


Link to post
Posted (edited)
On 12/31/2019 at 8:54 PM, GRAU said:

Maybe we can implement some type of compatibility modes too?

Adding passmnobj flag to all the objects will need the creation of a special mod, for those for want true 3d gameplay for vanilla maps. may be this flag may be set automaticaly by changing the compatlevel so heights of objects will raise and the needed flag given to all objects needing this?

 

I ask about this because Delphidoom now goes much further then boom, coming clother by functiomality to zdoom. so the compatibility mode is realy needed to be set as:

 

Auto - changes height and ppassmobj flags as in vanilla for vanilla and boom maps, sets true3d gameplay in delphidoom and udmf map formats 

True 3D - always true 3d gameplay, with higher torcher and longer hanged corpses

 Vanilla - Use vanilla gameplay even on maps with 3D floors (in delphidoom format, like it is done now)

 

This is something that can be done, I'll think of something. What I have in mind is a console variable that holds information about collision mode, in combination with the expanding the AUTOEXEC lump  (works currently only for WADs, not PK3)

 

16 hours ago, GRAU said:

Hello! I got an idea of an interesting feature - what if we could use voxels not only for objects, but for some textures too? for example - we have a lot of skull or button switches in doom and not only in doom. And for exampe we have some door textures with metal bas-relief demon heads on them. I would like to have an ability to apply voxels for those textures too!

 

May be there is a way to make that feature? To define voxels for some of textures with some offsets. In future thgis might even be used for voxel textures (therefor in don't think this is a good idea, because of low performance when rendering voxels, but some people using i9 may like))

 

If yes 0 we have 2 types of textures for walls. Complete textures (compiled of a few patches sometimes) and patches themselves. The best one would be to have the way of defining both types - sometimes more usefull to set voxel to a patch like SW2_1 - SW2_8 in Doom. And sometimes we have a final texture needing some volume.

 

I see no problems for the OpenGL renderer to handle this, but it will be a major task for the software renderer.

 

The last few days I 'm stuck in a serious flow of the software renderer (does not handle correctly very tall walls) and development has been delayed. I lost 3 days working on an approach that wasn't fruitful and now I'm starting again. Adding new features must wait for some days, until I 'll solve this.

 

Spoiler

The problem seems to appear more often on higher screen resolutions:

 

Test map:  test_tall_wall.zip   - With red color is HOM detection:

SSHOT-Doom-20200104-172537256.png

 

Sunder map 16: No HOM effect but the floor is bleeding with the tall column at the left of the screen:

SSHOT-Doom-20200104-173026295.png

 

The strange thing is that FPCDoom, handles the test map correctly, without HOMs (of course FPCDoom can not handle BOOM maps, or big maps like sunder MAP16)

 

 

Edited by jval

Share this post


Link to post

 

I'm not trying to speedup your work. How tall were those wall, causing problems? in map px please. because i sometimes use height shifts up to 2048 map pixels in my mod. So i am somewhere interested in this. Therefor i think just adding a pivot for voxel spawning for some textures would be interesting to see in future. That also have to be defined in voxeldef, i think.

Share this post


Link to post
Posted (edited)
2 hours ago, GRAU said:

 

I'm not trying to speedup your work. How tall were those wall, causing problems? in map px please. because i sometimes use height shifts up to 2048 map pixels in my mod. So i am somewhere interested in this.

 

The problem appears in lower textures and double sided masked textures with more than 6000-7000 px height in high screen resolutions (bigger than 1280x800). So, a map with 2048 px heights is not affected. Also I'm in good progress, I hope to fix this soon.

 

Quote

Therefor i think just adding a pivot for voxel spawning for some textures would be interesting to see in future. That also have to be defined in voxeldef, i think.

 

Something like this (and imagine this animated!):

Spoiler

Image7.png

 

 

Edited by jval

Share this post


Link to post
1 hour ago, jval said:

Something like this (and imagine this animated!):

  Reveal hidden contents

 

May be too) Looks interesting. But usage of this technology on textures that cover big areas, wall that cave corners may cause problems on those corners. On short linedefs etc. So i would like to use it only for switches now. May be in future you should implement some trimming algorithms for short walls, so voxels would be trimmed if wider than the walls below

Share this post


Link to post

WIP 20200107

 

What's new:

  • Fixed clipping problems on voxels and models in OpenGL mode.
  • Support for Doom2 BFG Edition.
  • Added r_fakecontrast console variable. When true (default for Doom, Heretic & Strife branches) it will add contrast to perpendicular lines.
  • Speed optimizations to the uncapped frame-rate subsystem by processing only the mobjs that the renderer touched.
  • Texture width is not required to be power of 2 (software rendering).
  • Corrected issues with tall textures in OpenGL rendering.
  • Added interpolateoncapped console variable. It will smooth display in capped frame-rate. Default is true.
  • Fixed glitch in sky drawing, it was ignoring visplanes with 1 px height.
  • Fixed some problems with tall walls in software rendering.

Downloads:

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

Next days I 'll work to improve stability, to change the sigmoid curve of the dynamic lights diminishing, to make optional (default?) the 3d gameplay (pass throu objects) etc.

 

Share this post


Link to post
4 hours ago, jval said:

to make optional (default?) the 3d gameplay (pass throu objects) etc.

 

I think it has to be default, yes, at least for delphidoom map format. Also i wanted to ask for some changes to default config - please ENABLE translucent sprites, DISABLE dithering translucency in 8bit, and more.. I tested, and tested and got interesting observations. looks like Delphidoom needs changes in colour levels. I mean - look please at this 2 screenshots. QZdoom and Delphidoom. The same lights. The same sizes. Both sourceports use default light config (100% intensity)

 

QZDoom - the light looks darker, and much smoother, more natural. But not only light, i found. Look at color brightness levels. They are much smoother too. Looks like it has twice more lightlevels then delphidoom. (not divided by 8 brightness points but maximum by 4) I think that is the reason why picture in software and particulary lights look so smooth. It may mean that ZDoom-based ports ignore basic colormap, creating it's own, or something like that.

Screenshot_Doom_20200108_040015.png.6371339d98fad30967df2fcddc23de15.png

Delphidoom. I have one more idea why lights look worse. May be the reason is that delphidoom aplies lights by adding the ammount of color to the final picture it has AFTER rendering the whole scene scene without lights but with complete distant shadow(fog). What if you try to apply lights to unshaded textures before applying distant fog/shading? I think it may help. Another idea is using light dithering between the indexes, the same you do for translucency.

SSHOT_Doom_20200108_035205390.jpg.635ee6c0a138ceb39a280e107d008de5.jpg

 

I even tried to get nicer effect by adding color intensity up to 137% but it still was looking weak.Try to look at QZDoom 2.0.0 sources, why nit? may be you could understand - how does it get so smooth picture, using only 256colors?

 

Another one problem appears when i pickup something - looks like colours go out of palete in this moment:

 

SSHOT_Doom_20200108_035014781.jpg.118dd5353b22018fa1eee510200882af.jpg

 

Even more - there is no white in palete i use with RDDVOX, and there is no saturated, dark blue there, but i see them in the screenshot. May be delphidoom uses original doom palete in this moment? And even more - may be i am the only one who has this problem (it was from the moment of first run, and it appears on both PC's of my)

 

 

 

Share this post


Link to post

 

On 1/8/2020 at 4:34 AM, GRAU said:

Another one problem appears when i pickup something - looks like colours go out of palete in this moment:

 

Even more - there is no white in palete i use with RDDVOX, and there is no saturated, dark blue there, but i see them in the screenshot. May be delphidoom uses original doom palete in this moment? And even more - may be i am the only one who has this problem (it was from the moment of first run, and it appears on both PC's of my)

 

 

I found the source of the problem, DelphiDoom in 8 bit color mode uses pre-calculated tables with palette indexes to map the equation results of the light applied to background. All the calculations are limited to the 8 bit palette, resulting a great loss of color accuracy in the process. Also the pre-calculated tables were statically created at load time, using the default palette, that's why the white color when the player picks an item. I've already changed the sources to make the light calculations in RGB color space even when we use the 8 bit renderer (just like  it does in true color mode) and currently I'm applying speed optimizations. Changes will be soon available.

 

Spoiler

SSHOT-Doom-20200110-111908276.jpg

 

 

Share this post


Link to post

Wow! Now this really looks great! A little bit - and shall start to convert my mod from zdoom to delphidoom) Waiting for the next release)

 

I got an idea! You wrote above that 

've already changed the sources to make the light calculations in RGB color space even when we use the 8 bit renderer (just like  it does in true color mode)

May be you could add an option for that - Light calculations accuracy: (pre calculated tables (based on last palete loaded from pwads), r6g6b6, truecolor (r8g8b8a8))

I actualy do not know a lot about that but i think usage of lower bit depth calculations may give more performance. Or not? Another thing is that now lights do not effect on voxels in software mode. I think this is wrong. Voxels could be lit with dynlights like sprites (single light offset for whole model), or may be even side-orieted in future. I would like to see a precise lighting of voxels, depending on distance, direction, may be some normal-style calculations one day.

 

Another idea for voxeldef is fullbright color. For example we may define some index(or index range) and set them Fullbright or Fulldark for this object. This may be used for bright eyes or some areas on light sourcxes that use to be allways bright (lamp in a lightg source), or may be even we could define light multiplier for some indexes. for example:

    indexmultip [index in voxel palete], [ammount]

 

voxeldef "talltech.kvx" 
{
    replaces sprite "tlmpa"

 

    fullbrightindex 48 - will make color 48 always bright

    indexmultip 47, 1.6 - will increase by x1.6the brightness of all pixels using color with index 47

    indexmultip 68, 0.5 - will increase by 0.5 (in fact decrease twice) all pixel using color with index 68

}

 

i have much more ideas for future, but first of all i would like to see voxel affected with dynamic lighting, 3D water, translucent 3d floors, sector light colour and more advanced mapping format (for example like zdoom - doom in hexen or udmf) - to define all those things using GZDoom builder or doom builder 2.

Edited by GRAU

Share this post


Link to post
On 1/10/2020 at 5:10 PM, GRAU said:

Wow! Now this really looks great! A little bit - and shall start to convert my mod from zdoom to delphidoom) Waiting for the next release)

 

A little bit and you don't have, since there is forming a common base with some ZDoom features.

 

On 1/10/2020 at 5:10 PM, GRAU said:

I got an idea! You wrote above that 

May be you could add an option for that - Light calculations accuracy: (pre calculated tables (based on last palete loaded from pwads), r6g6b6, truecolor (r8g8b8a8))

I actualy do not know a lot about that but i think usage of lower bit depth calculations may give more performance. Or not?

 

No, the speed will not be affected. The true color lights are using the same calculations and are as fast as 8 bit with pre-calculated tables of palette indexes. Actually, in true color mode I still use pre-calculated tables, but they work for each R, G, B color channel, not for palette indexes. I've already optimized the 8 bit light code and the new method does not have any noticeable performance drop compared to the old buggy calculation.

 

 

On 1/10/2020 at 5:10 PM, GRAU said:

 

Another thing is that now lights do not effect on voxels in software mode. I think this is wrong. Voxels could be lit with dynlights like sprites (single light offset for whole model), or may be even side-orieted in future. I would like to see a precise lighting of voxels, depending on distance, direction, may be some normal-style calculations one day.

 

Another idea for voxeldef is fullbright color. For example we may define some index(or index range) and set them Fullbright or Fulldark for this object. This may be used for bright eyes or some areas on light sourcxes that use to be allways bright (lamp in a lightg source), or may be even we could define light multiplier for some indexes. for example:

    indexmultip [index in voxel palete], [ammount]

 

voxeldef "talltech.kvx" 
{
    replaces sprite "tlmpa" 

 

    fullbrightindex 48 - will make color 48 always bright 

    indexmultip 47, 1.6 - will increase by x1.6the brightness of all pixels using color with index 47

    indexmultip 68, 0.5 - will increase by 0.5 (in fact decrease twice) all pixel using color with index 68

}

 

Brightmaps for voxels? Wow! How can this work on true color voxels? Better a voxel with the same "mesh" information but with gray-scale values indicating brightness?

 

On 1/10/2020 at 5:10 PM, GRAU said:

i have much more ideas for future, but first of all i would like to see voxel affected with dynamic lighting, 3D water, translucent 3d floors, sector light colour and more advanced mapping format (for example like zdoom - doom in hexen or udmf) - to define all those things using GZDoom builder or doom builder 2. 

 

I was thinking of Hexen format, but I thing it's better to focus to UDMF. The basic problem is that, as far as I know only ZDBSP can build nodes for UDMF. In experimental mode DelphiDoom can read UDMF maps, but converts them to standard format just to build the nodes with glbsp.

Share this post


Link to post
1 hour ago, jval said:

Brightmaps for voxels? Wow! How can this work on true color voxels? Better a voxel with the same "mesh" information but with gray-scale values indicating brightness?

 

well grayscale voxels offcourse may be used too as brightmaps. An interesting idea, i saw something like that in some gzdoom pack for opengl only. Well, if we had this working in software, ill use it as much as it is possible. I like that there is no need in using the 6bit or table based calculations as option for lights.

 

1 hour ago, jval said:

but I thing it's better to focus to UDMF.

 

Absolute! We have doom in doom (usual delphidoom) for classic maps and prboom, and when i need advanced mapping i'll anyway prefer UDMF, because it has flat alignment, sector colors and many others i use often in my maps.

Share this post


Link to post

WIP 20200112

 

What's new:

  • Support for line specials 271 & 272 (transfer sky).
  • Dehacked strings will change sprite names. Strings must have length of 4 characters.
  • If an unknown texture is found in SWITCHES lump will not exit with I_Error, it will generate a warning message instead.
  • Support for MBF dogs. Dog's AI isn't finished.
  • Added dogs console variable.
  • Added MF2_EX_FRIEND flag (friendly monsters).
  • Fixed ghost bug of resurrected bodies.
  • Masked textures can have columns without patches.

 

Fixes:

  • Dynamic colors in 8 bit color mode.
  • Big masked textures & sprites (height bigger than 508 px) now are displayed correctly.

 

Donwloads:

 

ToDo:

Some issues left behind in order to improve overall stability and robustness (mostly for the software rendering). In next days I'll work to:

  • Fix the sigmoid curve (software rendering dynamic lights).
  • Fix dog's A.I.
  • Auto-apply the PASSMOBJ flag for true 3d gameplay.
  • Support for opaque textures with more than 128 px height.
  • Encapsulate new features in the menus.

 

Screenshots:

Spoiler

Sunder MAP17 (corrected issues)

SSHOT-Doom-20200112-215237894.png

 

RDDVOX in 8 bit color mode (light calculation in RGB color even when the renderer is in 8 bit color mode):
SSHOT-Doom-20200112-215539361.png

 

 

Edited by jval

Share this post


Link to post

Houston we have problems!

 

 

I tried last WIP - in software renderer we have heavy fps drop on every item or powerup pickup, takin damage or any other palete-based effects( Mat be would be better if you returned the precalculated colormaps for those things. Just use that one included in last loaded wad - i have one in RDVOX, doom 2 and every game has a colormap with subtables for damage, invulnerability and pickups.

I dreamed to start a letsplay from this release but looks like i couldn't. Even using twice more powerfull cpu will not solve this problem - it looks like a microfreeze on video, but it 

interrupts gameplay. Tried on Core2Duo e8400 and Pentium D945. BTW this problem does not appear in truecolor mode. Only 8bit. I think you could solve it easy.

 

Another issue appears in GL renderer.

 

Spoiler

SSHOT_Doom_20200113_075058484.jpg.3cc92e07a233046406ea42f6ceeaf599.jpgSSHOT_Doom_20200113_075111281.jpg.83da362de0cebdba80fed2fcf0ecd94a.jpg

 

The additive translucency looks strange, all black areas from sprites are rendered as non translucent at all. The translucency is ON in options.

I removed as muck black borders from sprites as it is possible, that thin black-looking area in screenshot is not black actualy - i checked. Do something with all this, please.

 

 

Edited by GRAU

Share this post


Link to post

WIP 20200113

 

Fixes:

  • Speed optimization to the 8 bit color software rendering.

This is a fast solution to fix the problem mentioned be @GRAU

 

Work-around:

 

Small changes have been made to ensure higher speed execution during the calculation of the tables that the 8 bit renderer uses for light effects:

  • The calculations are executed in separate thread (when we have a multi-core PC) while the engine performs other tasks.
  • Compiler/asm code generation - side optimizations
  • Narrowed the overall calculations to what is "absolutely" needed.

Please test this version to ensure that there is not performance drop in low - end CPUs.

In a few days I will take special care to eliminate the calculations during gameplay to zero (the engine will precalc everything at start - up), just no time to implement this right now.

 

Donwloads:

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

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

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

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

 

 

Quote

Houston we have problems!

 

I tried last WIP - in software renderer we have heavy fps drop on every item or powerup pickup, takin damage or any other palete-based effects( Mat be would be better if you returned the precalculated colormaps for those things. Just use that one included in last loaded wad - i have one in RDVOX, doom 2 and every game has a colormap with subtables for damage, invulnerability and pickups.

I dreamed to start a letsplay from this release but looks like i couldn't. Even using twice more powerfull cpu will not solve this problem - it looks like a microfreeze on video, but it 

interrupts gameplay. Tried on Core2Duo e8400 and Pentium D945. BTW this problem does not appear in truecolor mode. Only 8bit. I think you could solve it easy.

 

 

 

Quote

Another issue appears in GL renderer.

 

  Reveal hidden contents

SSHOT_Doom_20200113_075058484.jpg.3cc92e07a233046406ea42f6ceeaf599.jpgSSHOT_Doom_20200113_075111281.jpg.83da362de0cebdba80fed2fcf0ecd94a.jpg

 

The additive translucency looks strange, all black areas from sprites are rendered as non translucent at all. The translucency is ON in options.

I removed as muck black borders from sprites as it is possible, that thin black-looking area in screenshot is not black actualy - i checked. Do something with all this, please.

 

 

 

I'm aware of the the OpenGL rendering issues, although I 'm quite positive that I've coded everything "by the book", the issues unfortunately remain.

 

Share this post


Link to post

Tested. Thank you a lot! Works fine.. Looks like now i can start the letsplay)

 

edited later:

 

I tried to record using this version. Anything was looking nice until music restarted. It restarts with a full volume. This kicks ass a lot when recording a letsplay. May you fix that? Another thing i could like is selection of midi (or may be wave audio too!) output device. And an ability to disable music at all.

And another problem. I trapped into an imp and game freezed and then bailed out when i tried to shoot.

 

 

Looks like i have to wait some more time till recording khorus. I'll wait until you finish true 3d gameplay options, enable shooting with a hitscan into a floor, and fiz music, no matter how long this will take)

 

About attacking being too close to an enemy. Sometimes i see how arachnotron attacks mancubus. When they are too close (on a demo map), and projectiles are physicaly spawned inside another minster - the particles of a shot cannot fly apart in horizontal, but only can be pushed out vertically. Do i need a specific flag for those part-actors?

 

 

Edited by GRAU

Share this post


Link to post

Music volume fixed....

The engine liked the song and wanted to play it at full volume.

Just kidding, it was just a midi problem. I 'm the one who likes the song :)

Also khorus.wad has opaque wall textures with height bigger than 128 px, support for tall wall textures is not ready yet in software rendering mode.

 

 

Share this post


Link to post

The song is good, but i think this wad needs more scary ambient, more suspense. But songs themselves are realy good. I didn't know about tall textures. Didn't think about that. How heavy is this problem? may it cause crashes?

Share this post


Link to post
9 hours ago, GRAU said:

The song is good, but i think this wad needs more scary ambient, more suspense. But songs themselves are realy good. I didn't know about tall textures. Didn't think about that. How heavy is this problem? may it cause crashes?

 

The issue is not severe, just it will use only the first 128 px and warp around them in columns (opaque walls) with bigger height.

Edited by jval

Share this post


Link to post

That is not a problem. But i got another one. You said i jneed a flag +passmobj and a lower then 30 height to jump over a barrel. I did it. Just look what i got:

 

 

When i try to jump over a barrel - anything is nice. But when i try to jump ON a barrel - can. But i cant move there. I cant walk over a barrel. I set the height to 20 and radius up to 32 to show this. Both player and barrel has +passmobj flag. If i jump on a barrel - i can stay but trying to walk or to run, allready staying on an object looks imposible. The inimation is looking like the player is running all the time i stay on the barrel. But when i try to jump out - it pushes me out with a great speed. Like all the movement i had to do is stored somewhere untill i stay on a barrel and thei is given momentaly to a player!

 

I added the files lower

 

RDDVOX.zip

RDVXTEST.zip

 

Share this post


Link to post

I got strange experience during redefining dynlights in new version. 8bit renderer drags nearly any yellow/softyellow dynlight color to green colors fromn palete. I even looked how qzdoom does this. But there is no such effect.


    color 1 0.7 0.3
    color 1 0.6 0.1
    color 1 0.5 0.2  (even 1 0.5 0 and 1.0 0.6. 0)  - all those colors have not to look as green. We have lots of brown, orange, even some yellow-red in palete, i even tried to add some more yellow... but why do i see this:

 

1 0.7 0.3 - Column (light column)

Delphidoom

SSHOT_Doom_20200114_214821843.jpg.74f26f4b744c40e29d0cebf83677aba0.jpg

QZDOOM

Screenshot_Doom_20200114_214445.png.81cd96342db062b27e20f84a19329bd4.png
 

Candelier,  color 1 0.6 0.1

Delphidoom

SSHOT_Doom_20200114_214755937.jpg.da11795894082d5e5587fa234ed40acb.jpg

QZDOOM

Screenshot_Doom_20200114_214437.png.94a613bf6dd5c7f0666ac23e105fecb1.png

 

Candle, color 1.0 0.5 0.2 and even torch that is nearly red - 1.0 0.4 0.1 - we have pinc colors, we have orange - why border is green?

Delphidoom

SSHOT_Doom_20200114_161748312.jpg.9ebf8b74ae0dce075dd35a396a442488.jpg

 

QZDOOMScreenshot_Doom_20200114_214431.png.20d5d40fb78bc00de548d75048c5f188.png

 

Please try to do something with this, may be add some menu for changing color-preference logic.. we need more experiments i think. I want to see delphidoom as a best sourceport, at least for playing classics with some lights and voxels)

SSHOT_Doom_20200114_215045203.jpg

Share this post


Link to post
On 1/14/2020 at 12:00 PM, GRAU said:

That is not a problem. But i got another one. You said i jneed a flag +passmobj and a lower then 30 height to jump over a barrel. I did it. Just look what i got:

 

When i try to jump over a barrel - anything is nice. But when i try to jump ON a barrel - can. But i cant move there. I cant walk over a barrel. I set the height to 20 and radius up to 32 to show this. Both player and barrel has +passmobj flag. If i jump on a barrel - i can stay but trying to walk or to run, allready staying on an object looks imposible. The inimation is looking like the player is running all the time i stay on the barrel. But when i try to jump out - it pushes me out with a great speed. Like all the movement i had to do is stored somewhere untill i stay on a barrel and thei is given momentaly to a player!

 

 

I'm making efforts to change this, after some changes tests the player does not get trapped anymore.

 

20 hours ago, GRAU said:

I got strange experience during redefining dynlights in new version. 8bit renderer drags nearly any yellow/softyellow dynlight color to green colors fromn palete. I even looked how qzdoom does this. But there is no such effect.


    color 1 0.7 0.3
    color 1 0.6 0.1
    color 1 0.5 0.2  (even 1 0.5 0 and 1.0 0.6. 0)  - all those colors have not to look as green. We have lots of brown, orange, even some yellow-red in palete, i even tried to add some more yellow... but why do i see this:

 

1 0.7 0.3 - Column (light column)

Delphidoom

 

QZDOOM


 

Candelier,  color 1 0.6 0.1

Delphidoom

 

QZDOOM

 

 

Candle, color 1.0 0.5 0.2 and even torch that is nearly red - 1.0 0.4 0.1 - we have pinc colors, we have orange - why border is green?

Delphidoom

 

 

QZDOOM

 

Please try to do something with this, may be add some menu for changing color-preference logic.. we need more experiments i think. I want to see delphidoom as a best sourceport, at least for playing classics with some lights and voxels)

 

 

I've located the source of the problem, it is the conversion from RGB color space (where the light calculations take place) to the 8 bit palette. In order to be correct I must enlarge the pre-calculated tables that the engine creates in every palette change, it's a simple task, but in lower-end CPUs will bring back the lag in every pickup, so I'll make a release that fix that when I set-up all the calculations at start-up:

On 1/13/2020 at 5:50 PM, jval said:

In a few days I will take special care to eliminate the calculations during gameplay to zero (the engine will precalc everything at start - up), just no time to implement this right now.

 

Here are two screenshots with fast/incorrect (latest WIP) and slower/correct (upcoming release) light calculations:

Spoiler

Fast but not correct:

SSHOT-Doom-20200115-181059779-old.png

 

Slower but correct:

SSHOT-Doom-20200115-181007968-correct.pn

 

 

Share this post


Link to post

Isn't there a way just to precalculate all those damage red-faded tables and pickup yellow-faded tables? why do we need to do it realtime while the engine may do all those calculations using the LAST LOADED CUSTOM palete once at runtime?? Another idea, if previous is not working is not to  make "fixed but slow" and "unfixed but fast" releases but to do it as an option. Can not you?

Edited by GRAU

Share this post


Link to post
9 minutes ago, GRAU said:

Isn't there a way just to precalculate all those damage red-faded tables and pickup yellow-faded tables? why do we need to do it realtime? 

 

I'm working on this :)

Quote

In a few days I will take special care to eliminate the calculations during gameplay to zero (the engine will precalc everything at start - up), just no time to implement this right now.

 

 

Share this post


Link to post

I am asking myself another thing. if you plan udmf, and it has custom sector color (lightcolor) parameter - will that need enlarging of colormap twice for each next sectorcolor? or we make easier by just calculating anything in sector color  BEFORE translation to 8bit palete? Imagine that we need just to render whole scene in rgb, applying sector colors, applying damage or pickup fades. As usual in 32bit. And only then we translate to final 8bit palete. Isn/t it a way to solve? Or this is cpu-heavy way?

Share this post


Link to post
On 1/16/2020 at 9:37 AM, GRAU said:

I am asking myself another thing. if you plan udmf, and it has custom sector color (lightcolor) parameter - will that need enlarging of colormap twice for each next sectorcolor? or we make easier by just calculating anything in sector color  BEFORE translation to 8bit palete? Imagine that we need just to render whole scene in rgb, applying sector colors, applying damage or pickup fades. As usual in 32bit. And only then we translate to final 8bit palete. Isn/t it a way to solve? Or this is cpu-heavy way? 

 

Do you mean rendering in RGB true color and then applying palette?

This is similar to what I do in FPCDoom, (post-processing effect that reduces the color range and applying standard palettes - eg RGB444):

It's an extra load for the CPU, mainly because it requires an extra step at the end of the rendering. The extra step can work nice and fast in multi-core CPUs without noticeable performance loss (post processing scales nice in multiple core) but in 1 core CPUs (or 1 core/2 threads with hyperthreading) may introduce performance issues. Also requires rendering in RGB true color which is probably a bit slower that 8 bit color rendering in some cases.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×