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

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

Recommended Posts

Well, in ZDoom A_SpawnItemEx caused spawning item in not relative but absolute coordinates, if in delphidoom a spawn item ex will spawn in relative - no problem. Thanks for explanations, i am writing it to text file each time you explain mee some specific things about delphidoom and its decorate interpreter - may be once i will create documentation for all specifics in delphidoom, based on your explanations))), i will take a look at your improvements now.

 

TRIED

 

And now i really have nearly the same question. How much basic blood objrcts in delphidoom? here is a video - i defined an ammo box instead of "Blood Splat" to see if the replacement works at all. And what did i see? nearly 50% of hits still were another blood objects and a half was my replacement object. What is that another blood object say me please? how can i replace it???

 

https://drive.google.com/file/d/1Ey8wtr_8HSxQVCv0m5kpGzb3G7t0noRM/view

Edited by GRAU

Share this post


Link to post
8 hours ago, GRAU said:

Well, in ZDoom A_SpawnItemEx caused spawning item in not relative but absolute coordinates, if in delphidoom a spawn item ex will spawn in relative - no problem. Thanks for explanations, i am writing it to text file each time you explain mee some specific things about delphidoom and its decorate interpreter - may be once i will create documentation for all specifics in delphidoom, based on your explanations))), i will take a look at your improvements now.

 

A_SpawnItemEx is works in relative coordinates, unless you specify the as flags (9th parameter) the number "2" (or SIXF_ABSOLUTEPOSITION  in ZDoom).

 

8 hours ago, GRAU said:

TRIED

 

And now i really have nearly the same question. How much basic blood objrcts in delphidoom? here is a video - i defined an ammo box instead of "Blood Splat" to see if the replacement works at all. And what did i see? nearly 50% of hits still were another blood objects and a half was my replacement object. What is that another blood object say me please? how can i replace it???

 

https://drive.google.com/file/d/1Ey8wtr_8HSxQVCv0m5kpGzb3G7t0noRM/view

 

Ooohh, it's the Doom engine that, depending on the damage, sets the new spawned blood ACTOR to a new state. If damage is 8 or less sets the state to S_BLOOD3 and if the damage is from 9 to 12 sets the state to S_BLOOD2. So in your video only when damage is 13 or greater you see the new replacement ACTOR. The replaces keyword creates all new states for the ACTOR but the old states are intact (they can be changed only with DEHACKED script), so when the damage is 12 or less it switches to the old states. Give me a couple of days to think about it, I'll probably add a flag to prevent the state changes of blood spawning.

 

 

Share this post


Link to post

May be i have to add states S_Blood3 and S_Blood2? It would bve interesting to create duifferent blood effecrs even for that if it is possible. I will wait for your sollution anyway, thanks)

Share this post


Link to post

Good evening, jval! I thought a ot abiut blood changes you may be plan or not plan to make. So i decided to show you 2 properties that might be useful to implement once and forever if you will change blood spawniung algorithm somehow. They both taken from zdoom wiki:

Spoiler

 

"BloodColor color

Sets the actor's blood color. There can be up to 256 different custom blood colors at the same time. color is either specified as 3 integers, a string "rr gg bb" or a string containing one of the special color names."

 - here i think we speak about translation of default blood sprites. In zdoom there are also blood particles (may be spawned instead or with actors) and automatic blood decals on walls - they are too affected with this property 

 

"BloodType replaceblood [, replacebloodsplatter [, replacebloodaxe]]

Tells ZDoom what class to spawn when the actor is hit with a weapon, replacing the standard blood. If only one type is specified it will be used for all 3 blood actors." - the ability to set own "blood" actor for monster of player class. I belive none comments needed here.

 

But i still would like to have specific states that i could use in any custom blood actor, something like default blood uses - for example BSize1: (default, used for low damage) BSize2: (used for medium damage) and BSize3 (used for large damage)

 

 

Share this post


Link to post
9 hours ago, GRAU said:

Good evening, jval! I thought a ot abiut blood changes you may be plan or not plan to make. So i decided to show you 2 properties that might be useful to implement once and forever if you will change blood spawniung algorithm somehow. They both taken from zdoom wiki:

  Hide contents

 

"BloodColor color

Sets the actor's blood color. There can be up to 256 different custom blood colors at the same time. color is either specified as 3 integers, a string "rr gg bb" or a string containing one of the special color names."

 - here i think we speak about translation of default blood sprites. In zdoom there are also blood particles (may be spawned instead or with actors) and automatic blood decals on walls - they are too affected with this property 

 

"BloodType replaceblood [, replacebloodsplatter [, replacebloodaxe]]

Tells ZDoom what class to spawn when the actor is hit with a weapon, replacing the standard blood. If only one type is specified it will be used for all 3 blood actors." - the ability to set own "blood" actor for monster of player class. I belive none comments needed here.

 

But i still would like to have specific states that i could use in any custom blood actor, something like default blood uses - for example BSize1: (default, used for low damage) BSize2: (used for medium damage) and BSize3 (used for large damage)

 

 

 

I've added a flag to prevent blood state changes (BLOODIGNOREDAMAGE) and also I've made some improvements to the dehacked subsystem. The changes are already in the source code repository but I need to make some tests before I make a WIP release. The BLOODIGNOREDAMAGE flag prevents the engine from changing the blood states depending on damage and the dehacked improvents will allow to define the next state/frame of a state/frame using labels/aliases instead of absolute numbering.

For blood color there are the GREENBLOOD and BLUEBLOOD flags but no other handling for blood color. Extra specific states are not a problem but still some a lot of thing will still be hard-coded (eg 3 different states, the damage range to use each of them etc - also Strife uses 4 different blood states not 3).

I also have an idea working in my mind which could give unlimited freedom to modders not only for blood but other assets/mechanics of the game (eg puff spawning). I'm thinking of the possibility to redefine hardcoded engine functions using PascalScript. With such a feature you could easily handle eg blood splats changing the number of different states, the damage range for each state etc with a small script. Unfortunatelly such a feature requires not trivial changes to the engine, so it can not be implemented in just a couple of days.

Anyway, I hope until weekend I 'll have a WIP with the BLOODIGNOREDAMAGE and the dehacked changes I've mentioned in the first paragraph of this post along with appropriate examples.

Share this post


Link to post

Well done! I like your idea. Nobody hurries you up, and i belive you will get good results. I left the blood actor as it works now - with chanсу ~40-50% to spawn new graphics. It will be easy to patch with new flag after new wip release.

Share this post


Link to post

WIP 20200712 is available.

 

What's new (since latest official release 2.0.5.726):

  • Corrections to ACTORDEF export procedure (DEH_PrintActordef/DEH_SaveActordef console commands).
  • Run earthquake effect code only when needed.
  • Fixes to 3d floors drawing in software rendering mode.
  • RandomRange() function in PascalScript.
  • Support for ANIMDEFS lump.
  • Line specials 291 & 292, set floor and ceiling texture offsets.
  • Prevent crash in lines with invalid sides.
  • Corrected issues with voxel clipping.
  • Fixed problems when installed in a directory that it's name contained spaces.
  • Added -mididevice command line parameter.
  • Added MF3_EX_BLOODIGNOREDAMAGE mobj flag.
  • Dehacked export saves the state name as comment.
  • Dehacked "NEXT FRAME" keyword will accept global state names as value.
  • Custom ACTORDEF labels can be accessed with [mobjname]::[label] by dehacked fields and other actions involving state names.
  • Added A_ChangeFlag ACTORDEF function.

 

Downloads:

   DelphiDoom: https://sourceforge.net/projects/delphidoom/files/WIP_BUILDS/WIP_Doom_20200712.zip/download

   DelphiHeretic: https://sourceforge.net/projects/delphidoom/files/WIP_BUILDS/WIP_Heretic_20200712.zip/download

   DelphiHexen: https://sourceforge.net/projects/delphidoom/files/WIP_BUILDS/WIP_Hexen_20200712.zip/download

   DelphiStrife: https://sourceforge.net/projects/delphidoom/files/WIP_BUILDS/WIP_Strife_20200712.zip/download

 

Share this post


Link to post

I like the changes you implemented, Jval!

But i have something amout mididevice. despite i have 2 soundcards in my system, there is only one midi device alvays in launcher you wrote. it detects only the default windows midi output, that one from direct sound, looks like, not the hardware devices. and i still get problem with changing volume of midi on all creative cards on win xp( when i set the volume to the minimal value in Delphidoom - midi stops playing, but when i set it at least at first grade - the volume switches to full. So it works. But on Audigy 1394, on windows 7 - anything works fine.

How can i help you to find the source of this problem with volume?

Share this post


Link to post
On 7/15/2020 at 10:13 PM, GRAU said:

I like the changes you implemented, Jval!

But i have something amout mididevice. despite i have 2 soundcards in my system, there is only one midi device alvays in launcher you wrote. it detects only the default windows midi output, that one from direct sound, looks like, not the hardware devices. and i still get problem with changing volume of midi on all creative cards on win xp( when i set the volume to the minimal value in Delphidoom - midi stops playing, but when i set it at least at first grade - the volume switches to full. So it works. But on Audigy 1394, on windows 7 - anything works fine.

How can i help you to find the source of this problem with volume?

 

Unfortunately I can't reproduce the problem (tried in in Windows XP virtual machine and the midi volume  change works fine).

 

This is the control panel of my VM:

Spoiler

image.png.bc3f8c0770e1ee7a1546d6cd5ec814f4.png

 

Share this post


Link to post

Yes, i understood. You couldn't reproduce this problem without Sound Blaster Live card or emulator if it exists. On XP with Realtek anything works fine.. 

 

This Is how it defined in my sistem:

This is why i wanted the setup of midi utput device in delphidom. But your midi defining tool does not detect all devices.

 

 

MIDI Devices.png

Edited by GRAU

Share this post


Link to post

jval, does delphidoompupports multiple "middle floors" (3d floors) per sector?how canioffset textureson floor and ceiling?

Share this post


Link to post

Jval, is there any way to set non-cubuc voxel size in your voxel editor? i am actualy making  a model of pinky and expiring problems with importing the sprite- the sprite is not square, but it is streched into square after import(((

Edited by GRAU

Share this post


Link to post

Version 2.0.5.727 is available. 

 

What's new (since latest official release 2.0.5.726): 

  • Corrections to ACTORDEF export procedure.
  • Run earthquake effect code only when needed.
  • Fixes to 3d floors drawing in software rendering mode.
  • RandomRange() function in PascalScript.
  • Support for ANIMDEFS lump.
  • Line specials 291 & 292, set floor and ceiling texture offsets.
  • Prevent crash in lines with invalid sides.
  • Corrected issues with voxel clipping.
  • Fixed problems when installed in a directory that it's name contained spaces.
  • Added -mididevice command line parameter.
  • Added MF3_EX_BLOODIGNOREDAMAGE mobj flag.
  • Dehacked export saves the state name as comment.
  • Dehacked "NEXT FRAME" keyword will accept global state names as value.
  • Custom ACTORDEF labels can be accessed with [mobjname]::[label] by dehacked fields and other actions involving state names.
  • Added A_ChangeFlag ACTORDEF function.
  • Added PrintActordef console command alias for DEH_PrintActordef.
  • Added SaveActordef console command alias for DEH_SaveActordef.
  • Small improvements to multi-threading tasks.
  • Corrected dehacked parsing of the "CODEP FRAME" keyword.
  • Prevent infinite loop for erroneous A_Chase() placement.
  • DD_IDE tool also supports RAD

 

Downloads

 

 

Share this post


Link to post

Nice! I like that you are still at work, man! I'll try this version soon, i belive.

Share this post


Link to post

Happy 2021 Year, i hope this project will get a few updates, and may be even voxels will one day be affected by dynlights))

Share this post


Link to post

Version 2.0.6 build 728 is out!

 

Downloads

DelphiDoom: https://sourceforge.net/projects/delphidoom/files/DelphiDoom 2.0.6/delphi-doom-2.0.6.728-win32.zip/download

DelphiHeretic: https://sourceforge.net/projects/delphidoom/files/DelphiDoom 2.0.6/delphi-heretic-2.0.6.728-win32.zip/download

DelphiHexen: https://sourceforge.net/projects/delphidoom/files/DelphiDoom 2.0.6/delphi-hexen-2.0.6.728-win32.zip/download

DelphiStrife: https://sourceforge.net/projects/delphidoom/files/DelphiDoom 2.0.6/delphi-strife-2.0.6.728-win32.zip/download

DD_IDE tool: https://sourceforge.net/projects/delphidoom/files/DelphiDoom 2.0.6/dd-ide-2.0.6.728-win32.zip/download

Launcher: https://sourceforge.net/projects/delphidoom/files/DelphiDoom 2.0.6/dd-launcher-2.0.6.728-win32.zip/download

Source code: https://sourceforge.net/projects/delphidoom/files/DelphiDoom 2.0.6/delphi-doom-src-2.0.6.728.zip/download

 

This is a major release with many new features and improvements.

 

The most important new features are:

  • Easyslope items to easily create sloped floors and ceilings.
  • Dynamic slopes can be controled by PascalScript.
  • Support for flats up to 4096x4096 px.
  • FLATINFO lump with information regarding flat definitions.
  • Maximum map size raised up to 65536x65536 px from 32768x32768 px
  • Key bindings can now accept SHIFT & CTRL.
  • Floor and ceiling texture rotation. Texture rotation can be easily defined by the new easyangle items, or dynamically using PascalScript.
  • Save/Load menu screenshot.
  • Save slots are not longer shared between different PWADs/IWADs. (Doom & Heretic branches only)
  • PascalScript can access keyboard, mouse keys and joystick keys.
  • Many additions to the Overlay() class (PascalScript)
  • Dozens of new codepointers, improved compatibility with custom actors created with DECORATE .
  • Support for DEHEXTRA
  • Improved vanilla demo playback compatibility.
  • Flac and ogg sound effects

Complete change log (Doom branch):

Spoiler
  • Fixed diskbuzy height calculation in OpenGL mode. (Could crash the engine in case of a missing diskbuzy patch from WAD)
  • Fixed memory corruption problem in I_ReverseScreen().
  • Corrected lump name character case for runtime loading.
  • Changed traverse order of mobjinfo table.
  • Easyslope item to easily create slopes.
  • Support for flats up to 4096x4096 px.
  • FLATINFO lump with information regarding flat definitions.
  • Fixed bug in erronous width & height screen dimentions input when the -geom command line parameter is specified.
  • Speed improvements in maps with high number of slopes.
  • Optimizations to slope rendering in sofware mode.
  • Corrections to Doom patch detection algorithm.
  • Now can theoretically handle maps up to 65536x65536 px.
  • Fixed serious bug while deallocating thinkers.
  • Fixed problem with dehacked file loading (-deh parameter).
  • Key bindings can now accept SHIFT & CTRL.
  • Floor and ceiling texture rotation.
  • Displays a warning if no player start found.
  • Screenshot in Save/Load menu.
  • PascalScript can access keyboard, mouse keys and joystick keys. The feature is intentionally dormant in demo recording/playback and in netgame.
  • Added Overlay.DrawRect & OverlayDrawRect PascalScript functions. params -> (const ticks: Integer; const red, green, blue: byte; const x1, y1, x2, y2: Integer)
  • Added overlaydrawrect console command. Usage is overlaydrawrect [ticks] [x1] [y1] [x2] [y2] [red] [green] [blue].
  • Dynamic slopes controled by PascalScript. (SetFloorSlope & SetCeilingSlope functions).
  • Floor texture offsets are displayed in textured automap.
  • Added A_CheckFloor & A_CheckCeiling ACTORDEF functions.
  • Added A_StopSound ACTORDEF function.
  • Added A_JumpIfTargetOutsideMeleeRange & A_JumpIfTargetInsideMeleeRange ACTORDEF functions.
  • Added A_JumpIfTracerCloser ACTORDEF function.
  • Save target & tracer in saved games.
  • Mass, args and special fields for mobjs.
  • Added MF3_EX_NORENDERINTERPOLATION mobj flag. When set to true, the renderer does not interpolate the mobj.
  • A lot of new ACTORDEF functions to improve ZDoom compatibility:
  •   - A_SetMass(mass: integer)
  •   - A_SetTargetMass(mass: integer)
  •   - A_SetTracerMass(mass: integer)
  •   - A_SetMasterMass(mass: integer)
  •   - A_CheckSight(offset: integer)
  •   - A_CheckSightOrRange(distance: float, offset: integer, [twodi: boolean=false])
  •   - A_CheckRange(distance: float, offset: integer, [twodi: boolean=false])
  •   - A_CountdownArg(arg: integer, offset: integer)
  •   - A_SetArg(arg: integer, value: integer)
  •   - A_SetSpecial(special: integer, [arg1, arg2, arg3, arg4, arg5: integer])
  •   - A_CheckFlag(flag: string, offset: integer, [aaprt: AAPTR])
  •   - A_SetAngle(angle: integer, [flags: integer], [aaprt: AAPTR])
  •   - A_SetUserVar(varname: string, value: integer)
  •   - A_SetUserArray(varname: string, index: integer, value: integer)
  •   - A_SetTics(tics: integer)
  •   - A_DropItem(spawntype: string, amount: integer, chance: integer)
  •   - A_DamageSelf(actor: Pmobj_t)
  •   - A_DamageTarget(const damage: integer)
  •   - A_DamageTracer(const damage: integer)
  •   - A_DamageMaster(const damage: integer)
  •   - A_KillTarget
  •   - A_KillTracer
  •   - A_KillMaster
  •   - A_RemoveTarget([flags: integer])
  •   - A_RemoveTracer([flags: integer])
  •   - A_Remove(aaprt: AAPTR, [flags: integer])
  •   - A_SetFloatBobPhase(bob: integer)
  •   - A_Detonate
  •   - A_Mushroom
  •   - A_BetaSkullAttack
  •   - A_CustomMeleeAttack
  •   - A_CustomComboAttack
  •   - A_SetRenderStyle
  •   - A_FadeTo
  •   - A_SetSize
  •   - A_RaiseMaster
  •   - A_RaiseChildren
  •   - A_RaiseSiblings
  •   - A_HealThing
  •   - A_RemoveMaster
  •   - A_BasicAttack
  •   - A_SetMasterArg(arg: integer; value: integer)
  •   - A_SetTargetArg(arg: integer; value: integer)
  •   - A_SetTracerArg(arg: integer; value: integer)
  •   - A_Tracer2
  •   - A_MonsterRefire(prob: integer, offset: state_t)
  •   - A_RearrangePointers(ptr_target: integer, ptr_master: integer, ptr_tracer: integer, flags: integer)
  •   - A_TransferPointer(ptr_source: integer, ptr_recipient: integer, ptr_sourcefield: integer, [ptr_recipientfield: integer], [flags: integer])
  •   - A_AlertMonsters(maxdist: integer, flags: integer)
  •   - A_RemoveChildren([flags: integer])
  •   - A_RemoveSiblings([flags: integer])
  •   - A_KillChildren
  •   - A_KillSiblings
  •   - A_Weave(xyspeed: integer, zspeed: integer, xydist: float, zdist: float)
  • Support for DEHEXTRA.
  • Multiple DEHACKED files inside WAD and PK3.
  • DEHACKED export will add a comment with command line parameters.
  • No delay to return to desktop when finished.
  • Extra sounds for Dehacked FRE000-FREE199 (indexed at 500-699).
  • Does not play menu sound on end screen.
  • Corrected DEHACKED export to ACTORDEF (renderstyle field).
  • Added A_Spawn, A_Face, A_Scratch, A_RandomJump & A_LineEffect functions.
  • Fixed DEHEXTRA/DEHACKED conflict with demo playback.
  • Avoid crash in OpenGL mode if sprite frames are missing.
  • Added new flag MF3_EX_FLIPSPRITE, when set it flips the mobj sprite.
  • ACTORDEF functions for flipping sprite: A_FlipSprite(), A_NoFlipSprite(), A_RandomFlipSprite() &A_RandomNoFlipSprite().
  • Support for various sound file formats using libsndfile, libflac, libvorbis & libogg.
  • Added Overlay.DrawLine & OverlayDrawLine PascalScript functions. params -> (const ticks: Integer; const red, green, blue: byte; const x1, y1, x2, y2: Integer)
  • Added overlaydrawline console command. Usage is overlaydrawline [ticks] [x1] [y1] [x2] [y2] [red] [green] [blue].
  • Fixed problem with Overlay display after changing screen dimentions.
  • Added overlaydrawpatch console command, usage is "overlaydrawpatch [ticks] [x] [y] [patch]".
  • Added Overlay.DrawPatchStretched & OverlayDrawPatchStretched PascalScript functions. params -> (const ticks: Integer; const patchname: string; const x1, y1, x2, y2: Integer)
  • Added overlaydrawpatchstretched console command. Usage is overlaydrawpatchstretched [ticks] [x1] [y1] [x2] [y2] [patch].
  • Boom generalized lines constants available in PascalScript.
  • Default jump key is "E" (WASD).
  • Added MF3_EX_MISSILEMORE & MF3_EX_MISSILEEVENMORE mobj flags.
  • Added minmissilechance mobjinfo field.
  • MAXCEILINGS changed to 128 from 30.
  • Improved vanilla demo compatibility.
  • Check overflow of animated lines. (limit is 1024).
  • Improved vanilla demo playback compatibility.
  • Save elevator data to saved game.
  • Fixed potential memory corruption problem when allocating custom colormaps.
  • Intermission screen graphics load consistancy.
  • Check for 1-sided lines as doors.
  • Sound org of sfx_oof sound when trying to open a locked door with key is the player.
  • If the wrong side of door is pushed, play the sfx_oof sound.
  • Check if a door is actually a door in T_VerticaDoor.
  • Added floatspeed, normalspeed & fastspeed mobjinfo fields.
  • A_Jump() ACTORDEF function can take multiple labels as parameters.
  • A_JumpIf() ACTORDEF function can take multiple labels as parameters.
  • Added obituaries and gender to mobjinfo fields.
  • Default value of "gldefs_as_lightdef" console variable changed to true.
  • Added decorate_as_actordef console variable, default value is true.
  • Added MeleeRange mobjinfo field.
  • Added MF3_EX_STRIFEDAMAGE mobj flag.
  • Added MF3_EX_MELEECHECKZ mobj flag, when set checks z values for melee attack.
  • Corrected A_PlayerMessage bug.
  • Dehacked parsing speed optimizations.
  • gldefs_as_lightdef & decorate_as_actordef can be configured from the Compatibility Menu. Needs restart for the changes to take effect.
  • show_obituaries console variable can be configured from the Menu (Option/Display/Appearence).
  • Added MF3_EX_NOTIMEFREEZE mobj flag. When it's set, the actor continues on freeze console command.
  • Added MF3_EX_CAUSEFEAR & MF3_EX_NOFEAR flags.
  • Added MF3_EX_SLIDE mobj flag.
  • Added MF3_EX_THRUACTORS mobj flag, no actor collision.
  • Added MF3_EX_THRUSPECIES mobj flag, no collision with same species (also inheritance).
  • Added MF3_EX_NOBLOCKMONST mobj flag, mobj can cross ML_BLOCKMONSTERS lines.
  • Green and blood blood for vanilla monsters, can be configured with the p_confcoloredblood console variable.
  • Fixed map title bug for maps outside the range of standard names.
  • Added MF3_EX_NOTAUTOAIMED mobj flag, do not subject actor to player autoaim.
  • Added maxstepheight & maxdropoffheight mobjinfo fields.
  • Added A_SinglePainAttack() & A_DualPainAttack() ACTORDEF functions.
  • Added GibHealth mobjinfo field.
  • Added MaxTargetRange mobjinfo field.
  • Added A_Quake() & A_LocalEarthQuake() ACTORDEF functions.
  • Doom2 BFG correction - For missing level MAP33 but with secret exit in MAP02.
  • Savegame directories depending on IWAD/PWAD.
  • Added GetActorWeaveIndexXY, SetActorWeaveIndexXY, GetActorWeaveIndexZ, SetActorWeaveIndexZ, GetMobjInfoWeaveIndexXY & GetMobjInfoWeaveIndexZ PascalScript functions.
  • Added A_SetWeaveIndexXY(), A_SetWeaveIndexZ() & A_SetWeaveIndexes ACTORDEF functions.
  • Added A_SetHeight() ACTORDEF function.

 

New editing examples:

 

Updated DoomBuilder configuration files: https://sourceforge.net/projects/delphidoom/files/Tools%2C%20maps%20and%20examples/DoomBuilder_Configuration_v2.0.6.zip/download

 

Screenshots

New Menu Save/Load layout:

Spoiler

SSHOT-Doom-20210219-221432232.png

 

Dynamic slopes example:

Spoiler

SSHOT-Doom-20210219-211316888.png

 

 

HD Vanilla demo playback videos

Plutonia - DEMO1

Spoiler

 

 

Plutonia - DEMO2

Spoiler

 

 

 

Plutonia - DEMO3

Spoiler

 

 

 

Share this post


Link to post

Added a new example:

 

Arkanoid game - Download

 

The example demonstrates advanced PascalScript usage with Overlay() class. The example is a MAP01 replacement.

 

Screenshot:

Spoiler

SSHOT-Doom-20210308-171507088.png

 

Share this post


Link to post

Hi JVAL, i like the way you develop Delphidoom, but i didn't actually understood the target of Plutonia demos - didn't plutonia work on Delphidoom before? I thought it did... And the arkanoid game on pascalscript looks really cool - you are genius at coding, for my oppinion. But i am waiting for another wery needed feature - the effect from dynamic lighting on sprites and voxels in software renderer. Are you planning to implement that? I dont talk about precise light applying on voxels, but at least common colour and light changes for whole voxel, and the same for sprites, so i could light them up with a dynlight based flashlight. Another question is about UDMF? Is it still in plans, or are you planning to develop your own map format?

Share this post


Link to post

Messig around with a map for it, so this port is like a extended version of PrBoom, right?

Looks like it have a lots of cool options, some useful some other are pretty weird.

SSHOT-Doom-20210325-214737816.png

Exit textes are... pretty vulgar and edgy, isn't it? However, looks pretty cool, awesome job!

Share this post


Link to post
3 hours ago, Walter confetti said:

Messig around with a map for it, so this port is like a extended version of PrBoom, right?

i'd say that it is in the same league as other advanced sourceports: it can do most tricks other advanced sourceports can (including slopes and such), has unique look up/down implementation for software renderer (not a simple shearing!), full-featured programming language to script it, multithreaded renderer... so it is much more than "extended PrBoom".

Share this post


Link to post
23 hours ago, GRAU said:

Hi JVAL, i like the way you develop Delphidoom, but i didn't actually understood the target of Plutonia demos - didn't plutonia work on Delphidoom before? I thought it did...

 

Plutonia DEMO3 was desynced in previous versions, ver 2.0.6 has got much better vanilla demo playback compatibility.

 

Quote

And the arkanoid game on pascalscript looks really cool - you are genius at coding, for my oppinion.

 

Thanks, but OK, you exaggerate a little, an arkanoid game is a school project in terms of complexity. You can also check my Doom snake game too, it's a bit more advanced :)

 

Quote

But i am waiting for another wery needed feature - the effect from dynamic lighting on sprites and voxels in software renderer. Are you planning to implement that? I dont talk about precise light applying on voxels, but at least common colour and light changes for whole voxel, and the same for sprites, so i could light them up with a dynlight based flashlight.

It's in my todo list. The problem is that, especially in voxels, it will be very difficult to maintain performance with dynamic lights. FPCDoom can apply dyn lights to sprites (FPCDoom does not support voxels) but with a significant FPS drop. In voxels the FPS drop will be even worse. I want to figure out a different, more efficient, method for DelphiDoom instead of re-using the techniques used in FPCDoom.

 

Quote

Another question is about UDMF? Is it still in plans, or are you planning to develop your own map format?

UDMF actually works, but only with standard map features. I have solved some issues in the latests releases, but it is still far from complete.

 

I've made a small UDMF example, it is tested with DelphiDoom v. 2.0.6 (probably will work with previous versions):

Download: https://sourceforge.net/projects/delphidoom/files/Tools%2C maps and examples/test_udmf1.zip/download

 

Full support is in my todo list, but first I have to solve the nodes builder problem. DelphiDoom uses glbsp as its internal node builder, which does not support UDMF.

My own map format is out of my agenda.

 

13 hours ago, Walter confetti said:

Messig around with a map for it, so this port is like a extended version of PrBoom, right?

Despite the fact that DelphiDoom shares a lot of things with PrBoom (most notable example is that the OpenGL renderer of DelphiDoom is based on the GLBoom/GLBoom+ renderer), it has very different philosophy, it supports  Heretic, Hexen and Strife, has many more features, but lacks PrBoom's excellent vanilla and boom demo compatibility.

 

Quote

Looks like it have a lots of cool options, some useful some other are pretty weird.

OK, I'll reveal the feature that I consider the most weird in my DelphiDoom project:

Spoiler

And the winner is.....

 

 

 

Support for 32 sprite angles!

Yes, this feature is IMHO the most weird feature of DelphiDoom. 

A lot of ports support 16 angles, but 32?

Which artist is going to create a sprite with 32 rotations?

The only real world scenario is to use the DD_VOXEL editor to export a voxel as a sprite with 32 angles, but if you have the voxel why bother making a sprite with 32 angles? The most logical is to export the voxel to 8 (or even 16) angles for source ports without voxel support.

 

Quote

Exit textes are... pretty vulgar and edgy, isn't it? However, looks pretty cool, awesome job!

These are the original  extra quit messages (https://doomwiki.org/wiki/Quit_messages)

 

10 hours ago, ketmar said:

i'd say that it is in the same league as other advanced sourceports: it can do most tricks other advanced sourceports can (including slopes and such), has unique look up/down implementation for software renderer (not a simple shearing!), full-featured programming language to script it, multithreaded renderer... so it is much more than "extended PrBoom".

 

Plus 3d floors, voxels, true color software rendering with external texture support etc. The only thing it lacks is a dedicated developer without other projects :)

Edited by jval

Share this post


Link to post
58 minutes ago, jval said:

I want to figure out a different, more efficient, method for DelphiDoom instead of re-using the techniques used in FPCDoom.

maybe just collect all light colors in one rgb value, then build custom palette translation, and cache it? chances are, most lights will be heavily reused between frames, so most of the time your paltrans will be already there. or you can use only 5 bits of each color component, and create a color cube -- it will have only 32K entries, and can be used for very fast rgb->palette lookups (this is what k8vavoom does for palette translations, for example). this is, of course, if you want to keep "paletized" look at all.

 

and to collect light sources, you can use blockmap. casting a ray via blockmap is freakin' fast (especially if you already have plane equations for walls and flats, then it boils down to several dot products and one division per wall/flat ;-).

 

in k8vavoom, each subsector has a list of light sources that can potentially touch it (just a distance check), and renderer marks those lights as "should be checked" on BSP traversal. this way i don't have to loop over all possible lights in map on each frame. then to calculate ambient light for sprite, i simply perform a distance check, and then a raycast to each visible light source from each visible sprite.

 

for majority of maps this is surprisingly fast, because you usually don't see alot of light sources at once, even 10-15 is rare. so one additional small loop per sprite is unnoticeable.

 

sorry if you already doing something like this, i didn't looked at the code. ;-)

 

58 minutes ago, jval said:

Plus 3d floors, voxels, true color software rendering with external texture support etc.

yeah, i simply didn't want to paste the whole feature list there. ;-)

Share this post


Link to post
8 minutes ago, ketmar said:

maybe just collect all light colors in one rgb value, then build custom palette translation, and cache it? chances are, most lights will be heavily reused between frames, so most of the time your paltrans will be already there. or you can use only 5 bits of each color component, and create a color cube -- it will have only 32K entries, and can be used for very fast rgb->palette lookups (this is what k8vavoom does for palette translations, for example). this is, of course, if you want to keep "paletized" look at all.

 

and to collect light sources, you can use blockmap. casting a ray via blockmap is freakin' fast (especially if you already have plane equations for walls and flats ;-).

 

in k8vavoom, each subsector has a list of light sources that can potentially touch it (just a distance check), and renderer marks those lights as "should be checked" on BSP traversal. this way i don't have to loop over all possible lights in map on each frame. then to calculate ambient light for sprite, i simply perform a distance check, and then a raycast to each visible light source from each visible sprite.

 

for majority of maps this is surprisingly fast, because you usually don't see alot of light sources at once, even 10-15 is already rare. so one additional small loop per sprite is unnoticeable.

 

sorry if you already doing something like this, i didn't looked at the code. ;-)

 

The problem is not the actual rendering of the lights, all the things you mention are done in one way or another (I mark the lights during bsp traversal, I use pre-calculated tables for both 8 bit and 32 bit rendering, I use blockmap to collect light sources etc).

In software rendering the problem is not the amount of light sources or the actual rendering of the light. I have explained here how the soft lights work for FPCDoom. They work about the same way for DelphiDoom.
 

Spoiler

Here is how FPCDoom works when the lights do not affect sprites:

  • Render BSP (collect information)
  • Render WALLS to screen
  • Render FLATS  to screen
  • Render WALLS to depthbuffer
  • Render FLATS to depthbuffer
  • Render LIGHTS to screen
  • Render SPRITES to screen

Here is how FPCDoom works when the lights affect sprites:

  • Render BSP (collect information)
  • Render WALLS to screen
  • Render FLATS  to screen
  • Render SPRITES to screen
  • Render WALLS to depthbuffer
  • Render FLATS to depthbuffer
  • Render SPRITES to depthbuffer
  • Render LIGHTS to screen

And here is how DelphiDoom works (no option for lights to affect sprites/voxels)

  • Render BSP (collect information)
  • Render WALLS to screen & depthbuffer
  • Render FLATS  to screen & depthbuffer
  • Render 3D FLOORS
  • Render LIGHTS to screen
  • Render THINGS/VOXELS to screen

To iluminate sprite/voxels, the engine must render the lights after sprite/voxels and it must render the sprite/voxels to the depthbuffer.

The problem is that I must render the things/objects/voxels to the depthbuffer, Rendering a voxel, near the eye, in software rendering is a big task for the CPU. Rendering it back to the depthbuffer is even worse. As a bonus, the light now has to be calculated probably for more pixels in screen, since the voxel/sprite probably occupy screen space that could be far enough for the light to affect.

Share this post


Link to post
2 hours ago, jval said:

Despite the fact that DelphiDoom shares a lot of things with PrBoom (most notable example is that the OpenGL renderer of DelphiDoom is based on the GLBoom/GLBoom+ renderer), it has very different philosophy, it supports  Heretic, Hexen and Strife, has many more features, but lacks PrBoom's excellent vanilla and boom demo compatibility.

 

Oh, i see...

Share this post


Link to post
2 hours ago, jval said:

To iluminate sprite/voxels, the engine must render the lights after sprite/voxels and it must render the sprite/voxels to the depthbuffer.

but why? i didn't meant "proper" lighting, i.e. light parts of the sprite and so on. what i understood from GRAU writing is that sprites and voxel objects aren't affected by dynamic lights at all. sure, to properly lit them you will need to "integrate" them into the rendered scene first. but what if you will imagine that the sprite is just a "virtual point", and the whole sprite is lit uniformly if there is an unobstructed LOS between its center and a light source? this way you can simply blend the whole sprite with accumulated light color, just as if it was affected by colored sector lighting. this is basically what k8vavoom does, for example. not the best way to do it, but it is better than nothing, and it is cheap -- no massive changes to renderer required.

 

sorry if i didn't understood you again: i have some problems with Wine, so i cannot check what DelphiDoom actually does at the moment, and simply speculating here.

Share this post


Link to post
45 minutes ago, ketmar said:

but why? i didn't meant "proper" lighting, i.e. light parts of the sprite and so on. what i understood from GRAU writing is that sprites and voxel objects aren't affected by dynamic lights at all. sure, to properly lit them you will need to "integrate" them into the rendered scene first. but what if you will imagine that the sprite is just a "virtual point", and the whole sprite is lit uniformly if there is an unobstructed LOS between its center and a light source? this way you can simply blend the whole sprite with accumulated light color, just as if it was affected by colored sector lighting. this is basically what k8vavoom does, for example. not the best way to do it, but it is better than nothing, and it is cheap -- no massive changes to renderer required.

 

An alternative could be the method I use for "glow" lights (which are cheap in computational terms) to be self-applied for the dyn-lights, this could work in some degree for self-light sources (light source is the same object, not another object), due to the way the "glow" lights work.

Spoiler

SSHOT-Doom-20210309-183517215.png

 

 

Another idea that I have is that, since the sprites/voxels will write to depthbuffer, why not use this information (for opaque things) to reduce overdraw to gain some performance ? That needs the sprites to be rendered before walls/flats, can this be done? I don't know... Or at least render the sprites from front to back, not back to front to avoid some sprite overdraw....
 

Share this post


Link to post
1 hour ago, jval said:

Another idea that I have is that, since the sprites/voxels will write to depthbuffer, why not use this information (for opaque things) to reduce overdraw to gain some performance ? That needs the sprites to be rendered before walls/flats, can this be done?

i don't think that you will get alot of speedup from this. i bet that most of your BSP rendering code is something span-based, and doesn't read depth buffer values, only writes there, right? if you'll add depth buffer reading, any speed gain you may get will be destroyed by additional memory reads, i believe. and for GPU it doesn't worth the efforts at all (i tried that, and got even less FPS due to all additional work needed to collect and sort sprites ;-).

 

rendering sprites from back to front may help, tho. with proper sort routine you may almost completely avoid checking depth buffer if you're doing sprite rendering by vertical spans -- it is enough to check if solid vertical span can clip the sprite once, i think, and then simply write the data. if you will turn your sceen by 90 degrees to get better cache locality with vertical spans, it may be of great help.

 

anyway, i prolly talking about things you already thought about, and tried. just couldn't resist the temptation to talk about some deeply technical aspects of idTech1. ;-)

Share this post


Link to post
2 hours ago, ketmar said:

i don't think that you will get alot of speedup from this. i bet that most of your BSP rendering code is something span-based, and doesn't read depth buffer values, only writes there, right? if you'll add depth buffer reading, any speed gain you may get will be destroyed by additional memory reads, i believe. and for GPU it doesn't worth the efforts at all (i tried that, and got even less FPS due to all additional work needed to collect and sort sprites ;-).

The bsp collects data, then the rendering starts (in order to use multithread). It's logical in a GPU not to gain much, but in software rendering maybe the gain would be better (can't tell until I try).

 

2 hours ago, ketmar said:

rendering sprites from back to front may help, tho. with proper sort routine you may almost completely avoid checking depth buffer if you're doing sprite rendering by vertical spans -- it is enough to check if solid vertical span can clip the sprite once, i think, and then simply write the data. if you will turn your sceen by 90 degrees to get better cache locality with vertical spans, it may be of great help.

The sprites are rendered in semi-horizontal spans when the same patch column occupies more than one screen vertical line. Rotating a 1920x1080x4 = 8MB buffer each frame is a lot of work (never tried it to be sure, just it looks like a lot of work).

 

2 hours ago, ketmar said:

anyway, i prolly talking about things you already thought about, and tried. just couldn't resist the temptation to talk about some deeply technical aspects of idTech1. ;-)

Cool :)

 

I spend a couple of hours observing the lighmap code (it's more than a year since I've wrote it) and it looks a bit obscure. It's much more complicated than FPCDoom. Probably it wouldn't be hard to implement the main idea, but it would be hard to optimize it (without breaking something else).  I do not worry that much for the sprites (also sprites have constant depth in all their surface due to face-player rotation, so it is cheaper to write them to depthbuffer) but for the voxels (not constant depth, i.e. more CPU to write them to depth-buffer) . Or, what if I use a constant depth for all the voxel surface (?).

Probably this could also be a good chance to implement multithreading to voxel rendering, which is the only part of the actual sceen-write procedure that still works in a single thread.

Share this post


Link to post
39 minutes ago, jval said:

Rotating a 1920x1080x4 = 8MB buffer each frame is a lot of work (never tried it to be sure, just it looks like a lot of work)

it will help if you're rendering with vertical spans, as vanilla does. then you will have to rotate it only once (after you finish all rendering), but will get ALOT better cache locality. if you're doing rasterisation by horizontal spans, it won't help alot, of course.

 

41 minutes ago, jval said:

I spend a couple of hours observing the lighmap code (it's more than a year since I've wrote it) and it looks a bit obscure.

ah, i know that feeling! i'm looking at the code that creates surfaces for 3d floors now, and... the only thing i can say about it is: "wtf?! what the hell all this mess should do?!" ;-) (and it doesn't even work right)

 

43 minutes ago, jval said:

Or, what if I use a constant depth for all the voxel surface (?).

great idea! you prolly can get away with this in most cases. as voxel objects usually substitute sprites, it may work. you can add a flag like "render this voxel with full depth buffer info", so people could mark some complex voxels with it. small glitches from voxel interpenetration should be neglible, i believe. after all, the whole idTech1 is about smart cheating! ;-)

 

47 minutes ago, jval said:

The bsp collects data, then the rendering starts (in order to use multithread). It's logical in a GPU not to gain much, but in software rendering maybe the gain would be better (can't tell until I try).

still, you have all the data already depth-sorted for you, so you can render it front-to-back with zero overdraw (mostly). k8vavoom collects all surfaces too, because i need to sort them by texture and shader -- this gives MUCH bigger speedup that depth sorting, because texture and shader changes are expensive, and GPU can cope with overdraw. i am also rendering transparent (not translucent) walls in the same pass, but with software renderer it is prolly better to render them in a separate pass, in back-to-front order (or with full depth buffer checking).

 

Vavoom software rasterizer did it that way. only it was fully polygon-based (think Quake1 here, horizontal spans), not column-based. as with Quake, it could render solid walls with zero overdraw, and then it draws sprites and transparent walls, with the same routine (because there is no difference for polygonal renderer anyway). sure, it is slower than column-based rendering, but hey, free camera!

 

as you support OpenGL anyway, you can do the same, simply using GLNODES to get polygons for software rasterizer. and you can split the screen to tiles, and use several threads to render each tile too. a huge change, of course, but free freelook (oops ;-) may worth it.

 

another great thing Vavoom did is storing plane equations with any surface (walls and flats). this simplified alot of various checks, because most of them could be simplified to "signed point-to-plane distance", which is a simple dot product (and a subtraction). the whole LOS checking is heavily cheating using this: first, it collects all walls along the 2d line (sorted by the distance from the starting point), and then it is guaranteed that if intersection time with sector floor or ceiling lies between two walls, then we hit a corresponding flat. this seamlessly extends to sloped surfaces, and to 3d floors (it doesn't matter how many non-vertical planes we have to check, as long as their `normal.z` is not zero, we're in business ;-). and it nicely extends to moving 3d polyobjects too -- it is still all about sorted lines. so no more BSP traversing for LOS checks -- blockmap method is MUCH faster.

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
×