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

DelphiDoom 2.0.5.726 (Updated May 8, 2020)

Recommended Posts

I have allready tried FPCDoom.Actually i thought it will runRDVOX like Delphidoom does. But it couldn't that time. This was in december 2019. I didn't like a lot R4G4B4 there - looks worse then the predefined 256 indexes.

Anyway, i belive - you know what to do) I always wish to see as low sys requirements as it is possible, ZDoom based ports had that. But they have some strange problems when applying voxels to some classic/prboom wads, problems with scene z-sorting. I belive in delphidoom. The last release had nice performance. the only serious issue was that green color everywhere :D So i hope you will found a way to optimize delphidoom even for singlecore CPU's. BTW i collect some old cpu's, run doom sourceports sometimes on them, and not only. However, the 2-core processors that I usually use are now considered obsolete too. I think i gonna try Delphidoom on Pentium 2 for Slot1 with 320-512mb SDRAM as soon as i will find a compatible hdd for that =)

Share this post


Link to post

Hello. I have got a request. Implement please a smart palete-replacement algorithm into delphidoom. For example. I load RDVOX to play it with doom 2. And the normal blue indexes are somehow shifted in RDVOX to get more colors for advanced blue lights. And i have to reload water and some other textures into RDVOX just to have them translated nice to new palete instead of having darker or lighter colors ingame.

So can you make the engine to transform ALL THE RESOURCES with different paletes (loaded from doom/doom2 itself too)on the runtime into the last loaded palete? Then i will have not to add new textures to compatibility wad each time someone wants to play a custom boom or vanila wad that includes some new blue textures with RDVOX. This will save a lot of my time, nerves and improve picture in lots of pwads played with my mod, and may be not only my.

 

For example remove from rdvox's PAL3PTCH.WAD all resources excluding PLAYPAL and COLORMAP and try map02 of doom2. Look at water. Look an blue door sides...
 

Spoiler

 

I allready have such a report. There one man uses zdoom for this. And i thought - we need this function in Delphidoom - zdoom hasn't it ha-ha!

He uses some wad i didnt played but the picture has to be:

Screenshot-Doom-20200124-234112.png.6b9d6764fa54a617a40a172e414d5d5c.png

 

but gets this instead. The night changes to sime kind of winter morning %)

 

Screenshot-Doom-20200124-233739.png.ab78a4ab92830fa1c291599879894e61.png

 

 

Edited by GRAU

Share this post


Link to post
5 hours ago, GRAU said:

Hello. I have got a request. Implement please a smart palete-replacement algorithm into delphidoom. For example. I load RDVOX to play it with doom 2. And the normal blue indexes are somehow shifted in RDVOX to get more colors for advanced blue lights. And i have to reload water and some other textures into RDVOX just to have them translated nice to new palete instead of having darker or lighter colors ingame.

So can you make the engine to transform ALL THE RESOURCES with different paletes (loaded from doom/doom2 itself too)on the runtime into the last loaded palete?

 

How can this be done? I do not think this is something that should/could be done automatically.

The way to do something like this is to use a global translation lump that will work with all the assets of the game but not with light effects or a definition lump that will remap textures to translation lumps?

 

 

Share this post


Link to post

And how do voxels with different from ingame palete work? How are lights rendered in 8bit? nearest color. They look as they have to evemn when they have different palete?we have to find on runtime(or may be better when map loads - less resources to process each time) the nearest color from one palete to every color in another palete. So we generate a lump of autoreplacement. And then replace the indexes in all resources we load. Or may be we need to load all resources on runtime as TRUECOLOR (apply the colors from previous loaded palete to indexes and get normal rgb images) and then conver them into new palete like it work with png 32bit sprites or just render as truecolor data. ofcourse we dont need to have in memory original data - only modified copies)

 

Could you do that?  Is it difficult?

Share this post


Link to post
On 1/25/2020 at 3:48 AM, GRAU said:

And how do voxels with different from ingame palete work? How are lights rendered in 8bit? nearest color. They look as they have to evemn when they have different palete?we have to find on runtime(or may be better when map loads - less resources to process each time) the nearest color from one palete to every color in another palete. So we generate a lump of autoreplacement. And then replace the indexes in all resources we load. Or may be we need to load all resources on runtime as TRUECOLOR (apply the colors from previous loaded palete to indexes and get normal rgb images) and then conver them into new palete like it work with png 32bit sprites or just render as truecolor data. ofcourse we dont need to have in memory original data - only modified copies) 

 

Could you do that?  Is it difficult?

 

The best way for this is to implement a content definition lump and declare for each texture a translation map, that will map the texture palette indexes to new ones. This lump could be used also to declare new textures in a scripted way, just like TEXTURES or HIRESTEX of zDoom. A content definition lump for textures is in my to-do list, but never thought about translation lumps for textures. Also any true color texture will be unaffected by the effect.

 

Share this post


Link to post

It will take tonns of time to declare twenty-thirty indexes for each texture, and this lump will be needed to do for each texture in each mod i want to play. I will never do this. It is useless. The only useful way is to make automatic palete exchangement algorithm for textures loaded before the mod that changes palete. For example:

 

we load all textures and sprites from doom2.wad. Then we load RDVOX and find a playpal lump. In thius moment the engine compares the new palete and the old one, and creates translation lump, by finding nearest colours in old palete to new one. Then engine applies this lump to allready loaded textures.

 

Only this method will be usefull. If not - then the translation lump will give nothing in this case. The main idea is to make compatibility between mods with different paletes, but if this have to be done manualy - then add please COMMON translation function which will be applied to all textures in all wad extending the wad contsining it. For example 

translateall 34- 38

translateall 35-37

...

 

this will give me an abil;ity to create a translation table manualy, i will do that, but i need it to be applied to all resources in the wad, or i will beter create compatibility patches for my own use, by loading all the new blue-containing textures to a patch with new palete (XWE transforms the palete of textures to a new one in smart way, and does it nice, as nice as i would like to see in algorithm i i am asking about). But i cant create a patch containing textures and sprites of each mode that someone creates - every year lots of wads with custom textures appear. This is why i ask about this feature.

Any way - how far is new WIP release?)

Edited by GRAU

Share this post


Link to post

WIP 20200127

 

What's new:

  • WASD keyboard preset uses the "E" key for jumping.
  • Support for tall textures in software rendering.
  • Added MF2_EX_JUMPUP flag. When set the actor will often (about 92% chance) decide to jump up (up to 56 units) to pursue target. Default for friendly monsters.
  • Support for extended help screens (HELP01 thru HELP99). See also this post.
  • Automap can now handle big maps without glitches.
  • Speed optimizations to the OpenGL renderer.
  • Fixed some glitches of the OpenGL rendering.

 

Fixes:

  • Sigmoid function curve of light effects fixed.
  • Precalc 8 bit color light tables at start-up.

 

Donwloads:

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

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

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

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

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

 

Screenshots:

Spoiler

Tall sprites and textures:

 

SSHOT-Doom-20200122-212506519.png

 

 

Share this post


Link to post

Well, man, i really love the way you improved the software renderer. Lights are rendered now quick and the colors are precise. Good work. Looks like you forgot to write about it in "What's new" - the true3D gameplay is also done, i see, but with small issues - when jumping on an object the player continue moving with some speed he got on the landing moment. I tried to stop a few times but could not do it while was standind on an object. I ask you to fix in future releases please - implement some friction when being standing on an object or something like that so a player could fix his position on an objected crate or barrel - this will be needed in some user mods i belive) 

Anyway you did your best, i belive, nice work, now i will start Khorus on Delphidoom oh yeah! 

 

So cute lights now:

SSHOT_Doom_20200128_012629015.jpg

SSHOT_Doom_20200128_012459171.jpg

Share this post


Link to post
17 hours ago, GRAU said:

Well, man, i really love the way you improved the software renderer. Lights are rendered now quick and the colors are precise. Good work. Looks like you forgot to write about it in "What's new" - the true3D gameplay is also done, i see, but with small issues - when jumping on an object the player continue moving with some speed he got on the landing moment. I tried to stop a few times but could not do it while was standind on an object. I ask you to fix in future releases please - implement some friction when being standing on an object or something like that so a player could fix his position on an objected crate or barrel - this will be needed in some user mods i belive) 

Anyway you did your best, i belive, nice work, now i will start Khorus on Delphidoom oh yeah!

 

Thanks @GRAU.

 

Indeed, there are some good speed optimizations to the light code, not only in 8 bit color mode but in 32 bit color mode also.

I'm working on the no friction problem when the player is standing on an object and I hope that this is going to be fixed soon.

 

 

Share this post


Link to post

Hello, jval, i was looking at delphidoom resource (doom32.swd) and got a few questions. 

1) What are those colormaps for:

 

DelphidoomMAPS.png.caed194af857a27ba928983de8a4d1fb.png

 

Does new software render uses them? 

 

2) What DOG resources for? where are they used? Is there a type of built-in mod giving a dog buddy?

Share this post


Link to post
4 hours ago, GRAU said:

Hello, jval, i was looking at delphidoom resource (doom32.swd) and got a few questions. 

1) What are those colormaps for:

 

 

 

Does new software render uses them? 

These are custom colormaps for BOOM line 242. Example map:  TEST_242.zip

 

Quote

2) What DOG resources for? where are they used? Is there a type of built-in mod giving a dog buddy?

 

They are for MBF helper dogs (Menu/Compatibility). A.I. is not ready yet, they are very aggressive :)

Edited by jval

Share this post


Link to post

Interesting, i have never heard about custom colormaps in boom. Those are looking like lightcolor. BTW do you plan custom #RRGGBB color defining for sectors in Delphidoom? It is used in UDMF? I like a lot this feature. 

 

And another one question - what editor is used to create those colormaps? I have some things to fix manualy in rdvox but XWE abilities are too limited.

Share this post


Link to post
17 minutes ago, GRAU said:

Interesting, i have never heard about custom colormaps in boom. Those are looking like lightcolor. BTW do you plan custom #RRGGBB color defining for sectors in Delphidoom? It is used in UDMF? I like a lot this feature. 

 

Line 242 can also make effects like that:  test_colormaps.zip

Custom color in sector can be replicated with custom colomaps, in this case (by defining the RGB value), the engine could generate them on demand, instead of providing a custom colormap lump inside wad. In classic (no UDMF) mapping probably instead of using the colormap lump name in control lines you could enter #RRGGBB (i.e. with the # character as a prefix). In UDMF (or PascalScript) you could have a custom defined field.

 

17 minutes ago, GRAU said:

And another one question - what editor is used to create those colormaps? I have some things to fix manualy in rdvox but XWE abilities are too limited. 

 

I do not know. If I'd wanted something like that the obvious way (for me) to create one would be to write a program to do this. I do not know if there is a tool to create it.

Share this post


Link to post

And could you write a program with minimum graphics, just to have 2 ways to create cologmaps 1) create gradient (start color in table, end color in table, target color to fade), and the second is to just replace a one pixel in manual mode. to choose color and to paint a colormap like a usual image. And import/export to png or bmp

this will be enough

and it would be interesting to me to see how does it work at all (source), but i understand you have limited time. SO make it only of you have some time for.

Share this post


Link to post

Version 2.0.5.721 has been released!

 

After 3 months of intense development a new official version is out!

Special thanks to all the community members that provided valuable feedback to make this version possible.

 

Downloads:

 

Notable new features since latest official release:

  • Advanced dynamic lights in software rendering mode.
  • Expression evaluation of ACTORDEF function parameters.  (C-style & Pascal-style operators).
  • Improved ACTOR definition compatibility with ZDoom syntax, many new ACTORDEF functions.
  • Content definition lumps now support the #include directive.
  • Many fixes to the automap.
  • Support for tall sprites (more than 256px) and tall wall textures (more than 128px).
  • Many fixes to rendering (both in software and OpenGL mode).
  • Support for MUSINFO lump.
  • Pushfactor, scale and gravity properties for map objects.
  • Wipe effect and ENDOOM support for the OpenGL branches.
  • Key bindings for player control and weapon change.
  • 3d gameplay improvements.
  • Screen resolution can be changed from the menu.
  • Png screenshot format.
  • Separate downloads for each game branch.

Detailed changes:

Spoiler

Added VSpeed and PushFactor fields to the mobjinfo PascalScript runtime class.
New ACTORDEF functions:
  A_Recoil
  A_SetSolid
  A_UnSetSolid
  A_SetFloat
  A_UnSetFloat
  A_SetHealth
  A_ResetTargetHealth
  A_SetTargetHealth
Mouse sensitivity for X & Y mouses axis can be configured thru the menus (Controls/Mouse sensitivity).
Added option for textured menu background.
Added menubackgroundflat console variable.
In multithreading mode the visplanes initialization is done in a separate thread while running the logic to improve performance (software renderer).
Added -keyboardmode command line parameter. Usage is:
  1) "-keyboardmode ARROWS" -> use arrows to navigate
  2) "-keyboardmode WASD" -> use WASD to navigate
  3) "-keyboardmode ESDF" -> use ESDF to navigate
Key bindings menu to customize keyboard player control.
Menu beautificiations.
Support for DOOMWADPATH enviroment variable.
Search for installed steam applications to find wad files.
Openings are dynamically allocated, depending on screen resolution.
Screen resolution can be changed from the menu.
Intermission screens are displayed with correct aspect ratio when the "widescreensupport" console variable is set to true.
Automap fixes:
 -Marks are displayed correctly.
 -In OpenGL mode uses hardware acceleration to draw the automap instead of using the same code with software rendering version.
 -Fixed automap grid rotation.
 -Added automapgrid console variable.
Support for the C-style #include and Pascal-style {$INCLUDE} directives inside all content definition lumps (ACTORDEF, MODELDEF, VOXELDEF?, LIGHTDEF & SNDINFO).
 -Recursive include calls are detected to avoid infinite loop.
 -Maximum include depth set to 32.
 -Also added support the #include_all and {$INCLUDE_ALL} directives, that parse all the pk3 entries with the same name.
Added png screenshot format (default). The mirrorjpgsshot console variable is set to false by default. It can be changed from the menu (Options/System)
Fullscreen menu item moved from Options/Display Options/Advanced to Options/Detail/Set Video Mode menu.
Added Ascpect Ratio & Camera menus (Display Options/Advanced).
Fixed bug with string to float conversion when the system's decimal separator was comma.
Will recognize the '+CANPASS' alias for 'PASSMOBJ' flag in ACTORDEF definitions (as well as 'CANPASS').
Will load kvx voxels from pk3/zip/pak files without the kvx extention, if they are placed inside voxels\*. directory
Corrected the behaviour of Actordef keyword "replaces".
In ACTORDEF lumps when a flag specified with the "-" character, it will be removed from the actor declaration (usefull with inherited objects)
"Funny rotations" generate an I_Warning, not an I_Error.
When entering ENDOOM screen, stops the music.
ENDOOM screen in OpenGL branch.
Wipe effect in OpenGL branch.
Support for renderstyle ADD & renderstyle SUBTRACT. The new renderstyles can be defined in ACTOR (BEX/ACTORDEF) definitions.
Speed optimizations to 8 bit color mode by using more CPU threads in final step (blit to the screen buffer).
Added new actor flag MF2_EX_SEEINVISIBLE, when set allows monsters to clearly see invisible player.
Added the "ACTORALIAS" ACTORDEF command, defines actor name aliases. Usage is: ACTORALIAS name1 name2.
Added the "DEH_PARSE" & "DEH_PARSE_ALL" ACTORDEF commands, will parse the specified dehacked/bex file. Usage is DEH_PARSE/DEH_PARSE_ALL file1 [file2 ....].
Added new actor flag MF2_EX_MISSILEHURTSPECIES, when set, the actor can hurt with missile attack actors of the same species.
Added showmessageboxonmodified console variable. When set to true and a modified game is detected, there will be displayed a messagebox. Default is FALSE.
Added DEH_SaveMobjInfoCSV console command. Save the current mobjinfo table in a csv file.
Fixed music volume control. Now changing the music volume does not affect the sxf volume.
Fixed non working plats & ceilings (thanks to slayermbm - https://www.doomworld.com/forum/topic/98789-fpcdoom-1124117-updated-dec-2-2019/?do=findComment&comment=2050845)
Added showfullhdlogo console variable. When set to true and current display mode is 1920x1080 displays the FullDH logo on TITLE screen. Default is FALSE.
File system will process WAD files inside pk3/zip/pak files.
Will parse GLDEFS lumps/pk3 entries for dynamic light definitions (alongside with LIGHTDEF) if the gldefs_as_lightdef console variable is set to true.
Added scale ACTOR field in ACTORDEF lumps.
Corrected enemies that continued shooting at you, even when out of sight - reported by slayermbm (https://www.doomworld.com/forum/topic/92113-delphidoom-204720-updated-oct-12-2019/?do=findComment&comment=2051252)
Fixed transparency in 8 bit color mode - reported by GRAU (https://www.doomworld.com/forum/topic/92113-delphidoom-204720-updated-oct-12-2019/?do=findComment&comment=2051725)
Default keyboard player movement changed to WASD.
Key bindings for weapon change as suggested by Khorus.
Change OpenGL texture filtering from the menu.
Change the OpenGL voxel optimization method from the menu.
Fixed problems with A_SpawnItem & A_SpawnItemEx actordef functions.
Added A_ScaleVelocity & A_ChangeVelocity ACTORDEF functions.
Added FloatRandom function in parameters of ACTORDEF functions.
Bug fix: Players can now spawned on 3d floors when the "On middle Floor" flag is set.
Bug fix: Solved issue with A_SpawnItem & A_SpawnItemEx in sectors with 3d floors.
Eliminated problems with voxel frames without a corresponding sprite in the wad.
Fixed problem with KVX voxels in software rendering mode.
Eliminated problems with transparent drawing when the software renderer activates dephtbuffer (3d floors).
Changed mirrorjpgsshot console variable default value to false.
Corrected color overflow in renderstyle add (32 bit color software rendering).
Shared or exclusive fullscreen mode (as suggested by @khorus).
Function parameters in ACTORDEF evaluate expressions using C style operators.
  Supported operators:
     +, -, *, /, |, &, ^
  Supported functions:
  // Math Functions
     ABS MIN MAX EXP LOG LOG10 LOG2 CEIL FLOOR ROUND TRUNC INT SQR SQRT FRAC POWER
  // Trigonometry Functions
     SIN COS TAN ASIN ACOS ATAN SINH COSH TANH ATAN2 VECTORANGLE
  // Flow
     IF(bool condition; whentrue; whenfalse) IFF (alias for IF)
  // Random functions
     RAND RANDOM RANDOM2 FLOATRANDOM FRANDOM (alias for FLOATRANDOM) RANDOMPICK FRANDOMPICK SYSRAND(uses random seed from system's clock)
  // Actor position and movement
     X Y Z MOMX VELX MOMY VELY MOMZ VELZ FLOORZ CEILINGZ ANGLE
  // Actor properties
     RADIUS HEIGHT ALPHA HEALTH REACTIONTIME THRESHOLD FASTCHASETICS KEY (Unique mobj key) FLOORCLIP
  // Pascalscript map & world variables (PascalScript communication)
     MAPSTR WORLDSTR MAPINT WORLDINT MAPFLOAT WORLDFLOAT
  // Custom params (Custom integer variables on per instance basis)
     CUSTOMPARAM PARAM TARGETCUSTOMPARAM TARGETPARAM
  // States
     SPAWN SEE MELEE MISSILE PAIN DEATH XDEATH HEAL CRASH INTERACT (Doom and Strife branch only) RAISE
Added "freeze" console command, freezes the game, stop all thinkers, stop all scripts. Allow only the players to move. It has no effect while demo playback/record.
Added A_JumpIf ACTORDEF function.
Dynamic lights in software rendering (using LIGHTDEF lump).
Indivitual entries in the defaults file for OpenGL & software screen size.
Added r_uselightmaps, lightmapcolorintensity and lightwidthfactor console variables.
If an unknown map thing is detected it will not exit with I_Error, it will generate a warning instead and will spawn a questionmark.
Support for MUSINFO lump.
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 sprites.
Added 'INITIAL BULLETS' and 'BFG CELLS/SHOT' dehacked fields.
PUSHFACTOR, SCALE and GRAVITY fields for actor instances.
 PascalScript new functions:
  - PS_GetActorPushFactor & PS_SetActorPushFactor
  - PS_GetActorScale & PS_SetActorScale
  - PS_GetActorGravity & PS_SetActorGravity
 ACTORDEF evaluates in function parameters the fields pushfactor, scale and gravity.
 ACTORDEF new functions:
  - A_SetPushFactor
  - A_SetScale
  - A_SetGravity
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.
Fixed clipping problems on voxels and models in OpenGL mode.
Support for Doom2 BFG Edition.
Added r_fakecontrast console variable. When true (default) it will add contrast to perpendicular lines.
Speed optimizations to the upcapped framerate subsystem by processing only the mobjs that the renderer touched.
Texture width is not requiered 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 framerate. Default is true.
Fixed glitch in sky drawing, it was ignoring visplanes with 1 px height.
Fixed some glitches with high walls in software rendering.
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.
Added dogs and dog_jumping console variables.
Added MF2_EX_FRIEND flag (friendly monsters).
Fixed ghost bug of resurrected bodies.
Masked textures can have columns without patches.
WASD keyboard preset uses the "E" key for jumping.
Support for tall textures in software rendering.
Added MF2_EX_JUMPUP flag. When set the actor will often (about 92% chance) decide to jump up (up to 56 units) to pursue target. Default for friendly monsters.
Support for extended help screens (HELP01 thru HELP99). See also this post
Automap can now handle big maps without glitches.
Speed optimizations to the OpenGL renderer.
Fixed some glitches of the OpenGL rendering.
Added MF2_EX_DONTBLOCKPLAYER flag, when set a solid object does not block players.
Fixes to 3d gameplay.

 

 

Share this post


Link to post

Congratulations! I think Delphidoom now needs an oficial download page or something like that. May i create a page dedicated to delphidoom on my website?

I would like to give some description there and a link to this thread and to the sourceforge last ofocoal (and may be last WIP too) release. And a few screenshots also.

Share this post


Link to post

Hey @jval , congratulations on the newest release!

 

Does the .721 version changes something in the uncapped game setting? I feel like the game is a little "slower" than usual, compared to the older releases. It's especially noticeable when moving the mouse very fast, seems like the game is in a state between uncapped and capped framerate, if that makes any sense. Is vsync on or something? Is there an option to disable it? Not sure if that's the problem.   

 

Edit: I'm using the software render, didn't test the OpenGL one.

Edited by slayermbm

Share this post


Link to post
1 hour ago, GRAU said:

Congratulations! I think Delphidoom now needs an oficial download page or something like that. May i create a page dedicated to delphidoom on my website?

I would like to give some description there and a link to this thread and to the sourceforge last ofocoal (and may be last WIP too) release. And a few screenshots also.

 

Thanks @GRAU! Yes, you can, it would be nice with some DelphiDoom screenshots of RDDVOX!

 

19 minutes ago, slayermbm said:

Hey @jval , congratulations on the newest release!

 

Does the .721 version changes something in the uncapped game setting? I feel like the game is a little "slower" than usual, compared to the older releases. It's especially notable when moving the mouse very fast, seems like the game is in a state between uncapped and capped framerate, if that makes any sense. Is vsync on or something? Is there an option to disable it? Not sure if that's the problem.   

 

Edit: I'm using the software render, didn't test the OpenGL one.

 

Thanks @slayermbm!

 

The uncapped framerate calculation has been changed in many ways since 2.0.4:

  • There is an option for synchonous or asynchonous DirectX blit (Options/Display/Advanced/Asynchronous DirectX blit, or console variable 'r_bltasync'). Default is asynchronous blit.
  • The capped framerate also has changed, by default renders interpolated frames in capped framerate also (controlled by 'interpolateoncapped' console variable) but limits the frame-rate to 35 fps.
  • The interpolation fraction is calculating according to the msecs passed from the time before the engine runs the logic (was calculating the msecs passed after the logic).
  • It will always interpolate between two continuous frames. Previous versions were interpolating between current and last render frame (which was wrong), current version interpolates between current and previous frame.

Also vsync is always off in software rendering, without an option to enable it.

Both OpenGL and software rendering shares the same logic regarding capped and uncapped framerate, with the exception that the OpenGL renderer can be configured to limit the framerate to the monitor refresh rate (Options/Display/OpenGL/Limit framerate to screen sync).

Share this post


Link to post

Does any of the changes impact performance too much? Rapid mouse movement, camera changes and frame rendering have taken an impact on my laptop. Compared to uncapped crispy doom and prboom+, its noticeably slower.

 

My hardware is pretty old and underpowered, i5-3210M @2.50ghz.

Edited by slayermbm

Share this post


Link to post

It is slower yes. But it has advantages like realtime lighting or voxels instead. What CPU is on your laptop? i tried delphidoom on celeron 420 1,6 GHz (core2 architecture, single core), and on Pentium 4 from 478 socket - it runs nice in 600*800 there. Actualy i am interested hov slow will it run on Pentium M or Caleron M. But i talk about software now. If your laptop has an opengl accelerator then use a GLDoom32 instead - it uses less cputhen software renderer

Share this post


Link to post
9 hours ago, slayermbm said:

Does any of the changes impact performance too much? Rapid mouse movement, camera changes and frame rendering have taken an impact on my laptop. Compared to uncapped crispy doom and prboom+, its noticeably slower.

 

My hardware is pretty old and underpowered, i5-3210M @2.50ghz.

 

What screen resolution do you use? What maps?
Crispy and PrBoom+ have better performance since they render the scene in 8 bit color depth, not 32 (i.e. 4 times more data processing per frame). It is expected to have better performance. Even in 8 bit color mode DelphiDoom uses a 32 bit blit buffer, so 8 bit color mode does not offer much gain in performance terms.

 

I've just tested 2.0.4 & 2.0.5 in my old i5-480M laptop at 1360x768 (which is at least 30% slower than i5-3210M, both are 2 core/4 threads) and the performance seems decent for a 9 years old laptop (vanilla complexity maps). Of course 2.0.5 is slower due to light effects. In scenes with many light sources the performance loss will be noticeable.

 

One other thing that affects performance in v.2.0.5 is  the shared fullscreen mode. (Options/Display/Detail/Set Video Mode). If the shared fullscreen mode is on (default), it will not change your desktop resolution to the rendering resolution, but instead it will stretch the rendering buffer to your screen desktop. Stretching is costly in computational terms (even it is performed by your GPU hardware). Try to change the fullscreen mode to exclusive, this may give a good performance boost. All previous versions were using exclusive fullscreen mode.
 

Edited by jval : spelling

Share this post


Link to post

Well, man, i use 775 socket, i told many times about it - and i even can record delphidoom with a bandicam using dual cpu for both encoding andgame in 1024*768 (or less in demos), but it runs nice. Even Pentium 4 runs it nice - 35-70fps without recording

Share this post


Link to post

Maybe it's just a problem with my computer, I don't know. I even disabled the light effects, glowing and transparency for a  more pure vanilla experience. Also, yes, I changed the fullscreen mode to exclusive, and there was no worthy performance difference at all. I actually prefer exclusive mode because it doesn't stretch the UI. Also, did the changes in DelphiDoom made it to FPCDoom? The latter does not "lag" at all. 32-bit mode made no difference in the old versions, changing to 8-bit does not change the overall performance.  

 

Edit: I use 640x480 resolution, so I believe that's not the problem.

 

Edit 2: I'm playing the original Doom2 maps, so I believe that's not the problem either.

Edited by slayermbm

Share this post


Link to post
10 hours ago, slayermbm said:

Maybe it's just a problem with my computer, I don't know. I even disabled the light effects, glowing and transparency for a  more pure vanilla experience. Also, yes, I changed the fullscreen mode to exclusive, and there was no worthy performance difference at all. I actually prefer exclusive mode because it doesn't stretch the UI. Also, did the changes in DelphiDoom made it to FPCDoom? The latter does not "lag" at all. 32-bit mode made no difference in the old versions, changing to 8-bit does not change the overall performance.  

 

Edit: I use 640x480 resolution, so I believe that's not the problem.

 

Edit 2: I'm playing the original Doom2 maps, so I believe that's not the problem either.

 

The only thing that was ported to FPCDoom from the new uncapped framerate logic is the faulty calculation between the last render frame with the current frame (which created problems only when you had less than 35 fps and the uncapped framerate was enabled). In 640x480 you should get at least 200 fps in vanilla maps and probably a lot more (at 640x480 I take more than 500 fps and in some occasions more than 1000 frames per second when using an i5-3570 3.4 GHz and an i5-4570 - 3.2 GHz which are not top CPUs). I'll make all options of the uncapped framerate configurable thru the menu to solve any issues (how to calc the fraction of time for each interpolated frame, I can also add an option to predict the time to render the frame and make more precise time fraction calculation, and if it will use interpolation even in uncapped framerate).

 

Screenshot with 1226 fps at 640x480 running in i5-4570 - 3.20 GHz:

Spoiler

SSHOT-Doom-20200202-093004355.png

 

 

Share this post


Link to post

Had two crashes when I tested delphidoom with my 64kb wad - both the gl version and the other. Where do I find the error log?

Share this post


Link to post

What kind of crash? Was there an error message? While playing or while loading?

Did you try to open a savegame from a WIP version? (it will crash)

Was an I_Error message?

After a system crash, it saves the log in Doom32_stdout.cachedbuffer.txt (or GLDoom32_stdout.cachedbuffer.txt  in OpenGL).

Also in data/logs/Doom32_stderr.txt (GLDoom32_stderr.txt for OpenGL) is the error log file.

Share this post


Link to post
On 2/1/2020 at 8:57 AM, jval said:

Even in 8 bit color mode DelphiDoom uses a 32 bit blit buffer, so 8 bit color mode does not offer much gain in performance terms.

 

Even Chocolate Doom uses an intermediate 32-bit blit buffer, because you cannot use hardware based scaling with a paletted frame buffer. 

Share this post


Link to post
29 minutes ago, fabian said:

 

Even Chocolate Doom uses an intermediate 32-bit blit buffer, because you cannot use hardware based scaling with a paletted frame buffer. 

 

Sorry, maybe I wasn't precise in my expression, also English is not my mother tongue and is a bit difficult to use it some times. I thing that choco and PrBoom+ uses hardware acceleration to set palette in an 8 bit surface that is drawn in a 32 bit screen. In DelphiDoom I'm using the CPU in each frame to convert the 8 bit buffer output of the renderer to a 32 bit buffer attached to a (32 bit) DirectDraw surface (that is drawn in a 32 bit screen).

Share this post


Link to post

This is a fixed version that tries to solve the problems with uncapped framerate reported by @slayermbm

 

What's new:

  • Fixes to uncapped framerate calculation, runs smoother. The difference is noticeable especially in big maps with high CPU requirements (Tested with Sunder and  Lost Civilization).
  • You are able to change the interpolateoncapped console variable from the menu (Options/Display/Advanced/Interpolate on capped). When true even in capped framerate it looks smoother by rendering interpolated frames depending on the actual time the frame is drawn.
  • Added interpolateprecise console variable. When true it will try to make more accurate interpolation in uncapped framerate by taking by accound the time needed to render the frame.

 

Downloads:

Share this post


Link to post
9 hours ago, jval said:

What kind of crash? Was there an error message? While playing or while loading?

Did you try to open a savegame from a WIP version? (it will crash)

Was an I_Error message?

After a system crash, it saves the log in Doom32_stdout.cachedbuffer.txt (or GLDoom32_stdout.cachedbuffer.txt  in OpenGL).

Also in data/logs/Doom32_stderr.txt (GLDoom32_stderr.txt for OpenGL) is the error log file.

Delphidoom just closed while playing the wad. Both times. No nothing.

 

The little I saw looked great though.

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
×