jval Posted December 30, 2019 (edited) 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): Lightmap fadeout function (32 bit): Sprites generated from voxels (using vechicle voxel pack): Edited December 30, 2019 by jval 4 Share this post Link to post
GRAU Posted December 31, 2019 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? 1 Share this post Link to post
GRAU Posted December 31, 2019 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? 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. 1 Share this post Link to post
jval Posted December 31, 2019 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.... 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 ... 1 Share this post Link to post
GRAU Posted December 31, 2019 (edited) 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 December 31, 2019 by GRAU 0 Share this post Link to post
GRAU Posted January 3, 2020 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. 0 Share this post Link to post
jval Posted January 4, 2020 (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: Sunder map 16: No HOM effect but the floor is bleeding with the tall column at the left of the screen: 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 January 4, 2020 by jval 1 Share this post Link to post
GRAU Posted January 5, 2020 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. 0 Share this post Link to post
jval Posted January 5, 2020 (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 Edited January 5, 2020 by jval 1 Share this post Link to post
GRAU Posted January 5, 2020 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 0 Share this post Link to post
jval Posted January 7, 2020 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: Doom: https://sourceforge.net/projects/delphidoom/files/WIP_BUILDS/WIP_Doom_20200107.zip/download Heretic: https://sourceforge.net/projects/delphidoom/files/WIP_BUILDS/WIP_Heretic_20200107.zip/download Hexen: https://sourceforge.net/projects/delphidoom/files/WIP_BUILDS/WIP_Hexen_20200107.zip/download Strife: https://sourceforge.net/projects/delphidoom/files/WIP_BUILDS/WIP_Strife_20200107.zip/download 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. 2 Share this post Link to post
GRAU Posted January 8, 2020 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. 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. 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: 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) 1 Share this post Link to post
jval Posted January 10, 2020 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 2 Share this post Link to post
GRAU Posted January 10, 2020 (edited) 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 January 12, 2020 by GRAU 1 Share this post Link to post
jval Posted January 12, 2020 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. 1 Share this post Link to post
GRAU Posted January 12, 2020 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. 1 Share this post Link to post
jval Posted January 12, 2020 (edited) 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: Doom: https://sourceforge.net/projects/delphidoom/files/WIP_BUILDS/WIP_Doom_20200112.zip/download Heretic: https://sourceforge.net/projects/delphidoom/files/WIP_BUILDS/WIP_Heretic_20200112.zip/download Hexen: https://sourceforge.net/projects/delphidoom/files/WIP_BUILDS/WIP_Hexen_20200112.zip/download Strife: https://sourceforge.net/projects/delphidoom/files/WIP_BUILDS/WIP_Strife_20200112.zip/download Source code: https://sourceforge.net/projects/delphidoom/files/Source%20Code%20Snapshots/DelphiDoomSrc_20200112.rar/download 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) RDDVOX in 8 bit color mode (light calculation in RGB color even when the renderer is in 8 bit color mode): Edited January 13, 2020 by jval 2 Share this post Link to post
GRAU Posted January 13, 2020 (edited) 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 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 January 13, 2020 by GRAU 1 Share this post Link to post
jval Posted January 13, 2020 (edited) 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 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. 1 Share this post Link to post
GRAU Posted January 13, 2020 (edited) 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 January 13, 2020 by GRAU 1 Share this post Link to post
jval Posted January 13, 2020 (edited) 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. 1 Share this post Link to post
GRAU Posted January 13, 2020 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? 1 Share this post Link to post
jval Posted January 14, 2020 (edited) 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 January 14, 2020 by jval 0 Share this post Link to post
GRAU Posted January 14, 2020 (edited) 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 1 Share this post Link to post
GRAU Posted January 14, 2020 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) 1 Share this post Link to post
jval Posted January 15, 2020 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: Slower but correct: 1 Share this post Link to post
GRAU Posted January 16, 2020 (edited) 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 January 16, 2020 by GRAU 1 Share this post Link to post
jval Posted January 16, 2020 (edited) 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. 1 Share this post Link to post
GRAU Posted January 16, 2020 (edited) 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? 1 Share this post Link to post
jval Posted January 17, 2020 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. 1 Share this post Link to post