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

[GRAU]

18 hours ago, jval said:

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

 

Well, looks like i could code none of them fithout someone's help. Mey be i just didn't tried? Well i'll have to dive in coding once, looks so, but not yet. Now the best thing i coded - some scripts in my project. So, yes, i am impressed of people who code a sourceport from the start.

 

18 hours ago, jval said:

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.

 

Ok. Better then Nothing)

 

13 hours ago, ketmar said:

ut 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

 

That is the way i thoughtthis feature have to work. It uses less memory and cpu then z-buffer and integrating sprites into scene. May be You may try to implement this method? BTW zdoom does so and looks well.

[GRAU]

12 hours ago, jval said:

 

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.

  Reveal hidden contents

 

 

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

please dont. Z-buffer will slowdown a lot, i belive. But if you have time ofc you may try them both. may be i dont understand enough to calculate cpu load in different ways of implementation. But the wery important that one object could light up another one or some others nearby, to get nice lighted with a fireball imps in the dark or just to make a "flashlight" item for player.

[GRAU]

Hello, Jval, is delphidoom still alive? i mean, i am working on converting my last version of RDVOX to DelphiDoom, i prefer to belive - this is alive sourceport) I still would like to see there voxels and sprites, affected by dynamic lights. But, i also understand if you have no free time for that

[jval]

On 8/27/2021 at 5:16 PM, GRAU said:

Hello, Jval, is delphidoom still alive? i mean, i am working on converting my last version of RDVOX to DelphiDoom, i prefer to belive - this is alive sourceport) I still would like to see there voxels and sprites, affected by dynamic lights. But, i also understand if you have no free time for that

 

DelphiDoom is alive, me too :).

New updates will come soon.

 

[GRAU]

Good news, man! I feel - i must finish RDDVOX 0.41 as fast as possible.

[GRAU]

Good day, i have found some issues for god mod in 32 bit software rendering. Here, the healthbonus, which uses translucent voxel as graphics - becomes totally black in 32bit (so called normal detail), and another strange thing - we have too opaque light "GLOW" effect for classic doom light sources. Ofc - i can disable this glow in options, but may be would be better to autodisable all glow effects when GODMOD is on.

 

Spoiler

 

And another thing (lower). Translucent sprites... There are no translucent sprites at all in godmode if we use MEDIUM DETAIL (8bit mode) or we have those sprites with wrong alpha if we use NORMAL DETAIL (32bit). If there is no direct sollution for this issue, may be we need aflag that will ENABLE those sprites without alpha (but with translucent "color") for 8bit and 32 bit, and disable at all if there is no flag. For example large fogs and smokes without translucency at all will totally decreace visibility for player, so we need them to be off at all in godmode. But we need to see something on the BLURSPHERE place in 8bit, so it have to be at least totally visible (now it has variable alpha in RDDVOX so becomes invisible at all in 8bit) - i think if you couldnt fix alpha's in godmode, val, then you need to implement the "GODVISIBLE" flag or something like that.

 

[jval]

Version 2.0.6 build 729 is out!

 

Downloads:

DelphiDoom: https://sourceforge.net/projects/delphidoom/files/DelphiDoom%202.0.6/delphi-doom-2.0.6.729-win32.zip/download

DelphiHeretic: https://sourceforge.net/projects/delphidoom/files/DelphiDoom%202.0.6/delphi-heretic-2.0.6.729-win32.zip/download

DelphiHexen: https://sourceforge.net/projects/delphidoom/files/DelphiDoom%202.0.6/delphi-hexen-2.0.6.729-win32.zip/download

DelphiStrife: https://sourceforge.net/projects/delphidoom/files/DelphiDoom%202.0.6/delphi-strife-2.0.6.729-win32.zip/download

DD_IDE tool: https://sourceforge.net/projects/delphidoom/files/DelphiDoom%202.0.6/dd-ide-2.0.6.729-win32.zip/download

Launcher: https://sourceforge.net/projects/delphidoom/files/DelphiDoom%202.0.6/dd-launcher-2.0.6.729-win32.zip/download

Source code: https://sourceforge.net/projects/delphidoom/files/DelphiDoom%202.0.6/delphi-doom-src-2.0.6.729.zip/download

 

Most important new features:

• Allow MODELDEF declarations without texture.
• Added MOD, S3M, IT & XM track music format support.
• Overlay functions as mobj codepointers
• Support for "IDFA Armor", "IDFA Armor Class", "IDKFA Armor", "IDKFA Armor Class" & "MAX SOULSPHERE" names in Dehacked.
• Friction field can be controlled in ACTORDEF, Dehacked & PascalScript.
• FastMM upgrated to ver. 4.993.
• Added uselightboostgodmode console variable. When true (default) the glow lights are drawn in invulnerability mode.

 

Fixes:

• Does not load twice default state names in case of missing STATEDEF lump.
• Fixed UTF16 loading problem
• Fixed ddmodel rendering when the game is paused
• Fixed potential memory corruption problem in R_MakeSpans() in 4k software rendering resolution
• Fixed potential doublicate mobj key while loading saved game
• Corrected transparent voxel & sprite software rendering in invulnerability mode as reported by @GRAU.
   

[GRAU]

Great news, man! I really like the fact you HEAR the feedback for bugs. I like to believe yoiu will once implement dynamic light affecting on sprites and voxels in SW. And some kind of UDMF-style flat texture alignment, at least. OFC i want to see true udmf in delphidoom, even if it will be named DDMF and have a lot of differences, but multiple [translucent] 3d floors in SW  for sector and texture/floor alignment are on the first place for me. I really would like to go to delphidoom in my projects, due to some problems of LZDoom future releases i believe, and the need of more advanced behavior logics.(we have doomscript in z-ports, but i like pascalscript a bit more)

So, thank you, dude! I will test new release as far as possible.

[Biz!]

Does anybody know how to unbind in delfidoom? im setting it up and im having trouble with keyboard layouts

[jval]

5 hours ago, Redoom said:

Does anybody know how to unbind in delfidoom? im setting it up and im having trouble with keyboard layouts 

 

You can not unbind a key.  A key must be always bound. Double bindings are not allowed.

 

You can either choose between presets (WASD, arrows)

 

 

or configure each key individually from the Key Bindings menu:

 

 

Press ENTER to change the key and then press the new key you want to assign. If your new key is already taken it swaps places with the old key, eg:

Move forward is W and Move backward is S. You press ENTER and then press S to change the forward move key to S.  Since the S key is already assigned to Move backward, the Move backward key switches to the last value of Key forward (W), it is neither unbounded, nor bounded to the same key.

 

With the arrows you go to the next key bindings screen (weapons):

 

In DelphiDoom there are two key bindings screens. Other branches may have more (eg 3 screens in DelphiStrife).

 

 

 

[GRAU]

Hello Jval! Any plans for decals? Another (old enough) idea - may we use voxels for switches? for ezample some kind of script that creates a special object each time it find a texture (defined in "switchdefs"?). This is not a usual object but just a voxel having an offset by X and Y for a specified texturename (or a patchname?) , and may be - has some light effect on it - this would be a cool one thing! But here we need to remember that some of switch textures are usually set for platform sides/moving ceiling sides, and the texture itself if moving up and down too...

[GRAU]

I have a question for delphidoom launch optimization. How much sprite angles does delphidoom generate for each non-existing sprite frame in voxeldef? 1? 8? or even 16? I see that delphidoom does something over a minute when launching with current rddvox on my notebook. if it creates tonns of sprites - i would like to have an option for that - create a 2x2 dummy sprite for each voxel frame, create only 1 true frame (like med1a0) but without rotations, and the last - create 8 angle sprites.

 

Actually 8 rotation sprites are really not needed for voxeled virtual frames - if someone launches a mod based on voxels - he may be want to see voxels, and he does not need all those sprite generations on game launch. But if there is a person who preferes sprites created from voxels - then he has an option for that.

[GRAU]

I got heavy issues in porting gib system from rdvox 0.41 to delphidoom. It rins. it works, it is fun a bit but it is far from perfect and i do not know what to do with those:

 

1) Why do sounds defined in sndinfo not work? What action do i need to use instead of A_PlaySound or A_PlaySoundEx?

2) Where can i find the original code of the actors in delphidoom? i looked at SWD file - there are only water and lava splashes there(((

3) What does this error means?

 

 

It sometimes appears on map03 (or any other map where chainguys are, i feel, but it always appears on demomap rdvxtest, when entering a subsection with zombiemans (to the right from spawn square room, cross the bridge over lava, - you allready see it, near the green torch). I add the files.

 

RDDVOX-0.41.7.zip

 

RDVXTEST.zip

 

I want to finish it till 31dec2021, BUT! some kind of satanaclaus does nt want this thing happen!

Edited December 28, 2021 by GRAU

[jval]

On 12/28/2021 at 12:16 PM, GRAU said:

I got heavy issues in porting gib system from rdvox 0.41 to delphidoom. It rins. it works, it is fun a bit but it is far from perfect and i do not know what to do with those:

 

1) Why do sounds defined in sndinfo not work? What action do i need to use instead of A_PlaySound or A_PlaySoundEx?

2) Where can i find the original code of the actors in delphidoom? i looked at SWD file - there are only water and lava splashes there((( 

3) What does this error means?

 

 

I

 

 

 

 

1) Probably because the sounds are only in the pk3 filesystem, not in the wad filesystem. I'll check and correct the issue. For random sounds you can also try A_RandomSound(sound1, sound2, ....)

 

2) The DelphiDoom actor definitions are inside the Doom32.swd wad file. Most of the actors are defined in the "GAMEDEF" lump which is an extended DEHACKED lump. Some other minor actors (like easyslope items, easyangle items, musicchanger etx) are in the ACTORDEF lump.

To get the ACTORDEF declaration of all current actors use the SAVEACTORDEF console command

 

3) For infinite states try changing the death state tics from 0 to 1 in VP_SHead1 & VP_CHead1, when jumping from to a state that has 0 tics and its next state is NULL infinite circle happens :

 

actor VP_SHead1 : VP_Gib1  //ShotGay head
{
    Scale 0.9
    States
    {
    Spawn:
        SZHD AAAAAAAAAAAAAAAA 2 A_SpawnItemEx("RD_BloodTrail", 0, 0, 0, 0, 0, 1, 128)
        SZHD B 120 A_CheckSight(1)
        Goto Spawn+16
    Death:
        RBLD A 1  // JVAL - Changed to 1
        Stop
    }
}

actor VP_CHead1 : VP_Gib1  //ChainGay head
{
    Scale 0.9
    States
    {
    Spawn:
        CZHD AAAAAAAAAAAAAAAA 2 A_SpawnItemEx("RD_BloodTrail", 0, 0, 0, 0, 0, 1, 128)
        CZHD B 120 A_CheckSight(1)
        Goto Spawn+16
    Death:
        RBLD A 1 // JVAL - Changed to 1
        Stop
    }
}

 

Also I've found some opening brackets missing in VP_ImpHead2, VP_ImpHead3 & VP_ImpHead4 (not critical)

Also you must change the RBLD 1 0 in VP_ImpXplode last state since it references a sprite frame "1" instead of "A".

 

Quote

I want to finish it till 31dec2021, BUT! some kind of satanaclaus does nt want this thing happen!

 

I also hopped for ver 2.0.7 until the December 31st but due to other projects development I 'll schedule for a latter release.

 

Edited December 29, 2021 by jval

[jval]

On 12/28/2021 at 10:54 AM, GRAU said:

I have a question for delphidoom launch optimization. How much sprite angles does delphidoom generate for each non-existing sprite frame in voxeldef? 1? 8? or even 16? I see that delphidoom does something over a minute when launching with current rddvox on my notebook. if it creates tonns of sprites - i would like to have an option for that - create a 2x2 dummy sprite for each voxel frame, create only 1 true frame (like med1a0) but without rotations, and the last - create 8 angle sprites. 

 

Actually 8 rotation sprites are really not needed for voxeled virtual frames - if someone launches a mod based on voxels - he may be want to see voxels, and he does not need all those sprite generations on game launch. But if there is a person who preferes sprites created from voxels - then he has an option for that.

 

It generates 1 rotation for each sprite. There is the r_generatespritesfromvoxels console variable (default is true), you can set it to false to generate a stub patch instead with no time consuming operation. I don't see any noticeable slowdown in a low-mid range CPU (i7700HQ mobile) and SSD drive.

[jval]

On 12/28/2021 at 12:16 PM, GRAU said:

I got heavy issues in porting gib system from rdvox 0.41 to delphidoom. It rins. it works, it is fun a bit but it is far from perfect and i do not know what to do with those:

 

1) Why do sounds defined in sndinfo not work? What action do i need to use instead of A_PlaySound or A_PlaySoundEx?

 

 

The sounds "gore/gibs1" & "gore/gibs2" sounds are not defined in SNDINFO.txt, the sounds that are defined are "rdw/gibs1" & "rdw/gibs2"...

 

[GRAU]

3 minutes ago, jval said:

It generates 1 rotation for each sprite. There is the r_generatespritesfromvoxels console variable (default is true), you can set it to false to generate a stub patch instead with no time consuming operation. I don't see any noticeable slowdown in a low-mid range CPU (i7700HQ mobile) and SSD drive.

 

Hmm... Strange enough. There are not too much large voxels ib my pack. It has not to take a lot of time, i belive. What other operations are processor heavy? Ofc - you will never get slowdown on any i7, i belive, even of 1st generation. But the startup of delphidoom is now over 3 times longer then the startup of zdoom or lzdoom on single-core Pentium/Celron M Processors. It takes each time over 40-50 seconds, with rddvox only. However, i could check - how long does the startup take without any additional wads! May be RDDVOX doesnt slowdown it a lot.

Just now, jval said:

The sounds "gore/gibs1" & "gore/gibs2" sounds are not defined in SNDINFO.txt, the sounds that are defined are "rdw/gibs1" & "rdw/gibs2"...

 

Yes, they are, but before i renamed them to rdw/gibs they were gore/gibs but i still had no sound of meat explosion ingame. But i will check the sound defibition once more, thanks.

 

1 hour ago, jval said:

Probably because the sounds are only in the pk3 filesystem, not in the wad filesystem. I'll check and correct the issue. For random sounds you can also try A_RandomSound(sound1, sound2, ....)

Sounds Good! I'll check this func.

 

1 hour ago, jval said:

actor VP_SHead1 : VP_Gib1  //ShotGay head
{
    Scale 0.9
    States
    {
    Spawn:
        SZHD AAAAAAAAAAAAAAAA 2 A_SpawnItemEx("RD_BloodTrail", 0, 0, 0, 0, 0, 1, 128)
        SZHD B 120 A_CheckSight(1)
        Goto Spawn+16
    Death:
        RBLD A 1  // JVAL - Changed to 1
        Stop
    }
}

 

Interesting - i had no problems spawning shotguy heads nor Chainguy ones. Both spawned well after explosion. But this error appears in random moments when damaging chainguys.. But this is not 100% info, just my feelings. Thank you for advanced feedback, i have to go patch up my issuepack now)))

[GRAU]

3 hours ago, jval said:

2) The DelphiDoom actor definitions are inside the Doom32.swd wad file. Most of the actors are defined in the "GAMEDEF" lump which is an extended DEHACKED lump. Some other minor actors (like easyslope items, easyangle items, musicchanger etx) are in the ACTORDEF lump.

To get the ACTORDEF declaration of all current actors use the SAVEACTORDEF console command

 

Thanks, i'll check the "saveactordef" command!

[GRAU]

Well, what can i say... Thank you sensei! I have fixed the code the way you adviced - and that criticall error didn't appear anymore. I want to believe - we have defeated this error))

[ketmar]

On 12/29/2021 at 12:11 PM, jval said:

For infinite states

by the way, it would help to show at least the actor name in that error message (if showing the line is impossible).

[jval]

On 12/31/2020 at 11:39 PM, GRAU said:

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

It's still 2021 here:  https://github.com/jval1972/DelphiDoom/commit/3058f41ea50c891971955c1ac3ac7a251389de40

 

7 hours ago, ketmar said:

by the way, it would help to show at least the actor name in that error message (if showing the line is impossible).

 

https://github.com/jval1972/DelphiDoom/commit/dd278b0906d06db7a49f96e7275a941f5eb16ae9

 

[GRAU]

I found the interesting function: "ChangeActorRoll" -that is from ACS, GZDoom. That is what it does:

 

Spoiler

Then i thought - i have to request the improved version for delphidoom, but with support for software renderer. Could you make the function that can roll thecamera in the same flat? So i could immitate the alcohol or the leaning in Delphidoom? Would be nice to have both realizations - for Decorate (A_DCamRoll(horiz_pitch in degrees)) and a pascal script function DCameraRoll(Camera_tag,[pitch-parameter],[ roll parameter] and the same for player - PlayerID,[player pitch],[player_roll]

 

As for software renderer - this can be done easy by just rotating the allready renderer 2D framebuffer around the center of the screen when roll is different from 0

 

Another Thing i think about too often last months is support for some kind of UDMF for delphidoom - i really allready could start transforming my horror project to delphidoom if i got those in DelphiDoom:

- a) 3D floors, at least 4 3Dfloors per sector needed

- b) Sloped Ceiling/floor for normal sectors (done)

- c) Translucent 3Dfloors (at least 2 per sector)

- d) 3D swimmable watter (with % alpha)

- e) polyobject exciplit lines like in zdoom

- f) floor and ceiling separate transformable texture X,Y offset, X,Y SCALE, rotations

[jval]

 

Next version of DelphiDoom is in intense development, even though I've been destructed by other projects (Mars3D, xGreed & RAD). Since v. 2.0.6.729 that was released at Oct. 11th 2021, there is an impressive number of 666 commits with more than 100.000 lines of new code:

https://github.com/jval1972/DelphiDoom/graphs/contributors?from=2021-10-11&to=2022-01-29&type=c

Graph:

Spoiler

Of course if you take a closer look at the graph, you'll notice that there is only one contributor :(

 

8 hours ago, GRAU said:

I found the interesting function: "ChangeActorRoll" -that is from ACS, GZDoom. That is what it does:

 

  Reveal hidden contents

Then i thought - i have to request the improved version for delphidoom, but with support for software renderer. Could you make the function that can roll thecamera in the same flat? So i could immitate the alcohol or the leaning in Delphidoom? Would be nice to have both realizations - for Decorate (A_DCamRoll(horiz_pitch in degrees)) and a pascal script function DCameraRoll(Camera_tag,[pitch-parameter],[ roll parameter] and the same for player - PlayerID,[player pitch],[player_roll]

 

As for software renderer - this can be done easy by just rotating the allready renderer 2D framebuffer around the center of the screen when roll is different from 0

Tilt was/is in my todo list for RAD (to make the drone roll while turning), I had made a question in RAD topic about a Radix mod in GZDoom and I took an answer that GZDoom does this in OpenGL rendering:

I do not think that this is easy in software renderer, if we just use post-processing and rotate the buffer that is what we get:

Spoiler

 

In order to work properly we must render the scene outside the framebuffer, in a larger buffer, change fov according to some mysterious calculations and then make the rotating transformation step.

On the other hand, in OpenGL can be done very easily by modifying the modelview matrix:

Does GZDoom does it in classic software renderer? (not the polygon software renderer) If so I can try to study how it does it and try to port some code/algorithm to DelphiDoom.

 

8 hours ago, GRAU said:

- a) 3D floors, at least 4 3Dfloors per sector needed

If the number of 3d floors is going to be greater than 1, then any limit would be artificial, just to prevent abuse, it doesn't have any difference (from the developer's side of view) if  we have 2 or 200. But more than one, means new collision/physics code, new drawing routines, new overdraw prevent methods etc. It is 100% certain that the next version will not have more than one 3d floor per sector. Any attempt will be in future releases.

 

8 hours ago, GRAU said:

- b) Sloped Ceiling/floor for normal sectors (done)

Slopes work fine, and also can be manipulated dynamically at runtime with PascalScript since v.2.0.6, see the dynamic slopes example:

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

 

8 hours ago, GRAU said:

- c) Translucent 3Dfloors (at least 2 per sector)

Please define translucent: Color based? Or surface/texture based? No collisions?

 

8 hours ago, GRAU said:

- d) 3D swimmable watter (with % alpha)

It's something I consider since I've made the underwater effect for Mars3D. Mars3D works with silent teleport to the underwater area, but I 'm considering using the fake flat Boom method to define underwater swim-able area. See-throu the water level is a problem in the above cases, only opaque water surface can be done.

 

8 hours ago, GRAU said:

- e) polyobject exciplit lines like in zdoom

Support for all Hexen line specials in UDMF format are in todo list for next version. I'm still far from that, but at least UDMF has good progress lately.

 

8 hours ago, GRAU said:

- f) floor and ceiling separate transformable texture X,Y offset, X,Y SCALE, rotations

Floor and ceiling offsets works at full potential for Doom and Strife branches and can be controlled by PascalScript since the very first steps of v.2.0 of DelphiDoom. Later versions added more control line specials (291 -> Offset floor texture to vector & 292-> Offset ceiling texture to vector).

Example for floor and ceiling offsets: https://sourceforge.net/projects/delphidoom/files/Tools%2C maps and examples/v2_EXAMPLE_15_FLOOR_CEILING_OFFSETS.zip/download

Floor and ceiling rotation works from v.2.0.5.727.

Example for floor and ceiling rotation: https://sourceforge.net/projects/delphidoom/files/Tools%2C maps and examples/v2_EXAMPLE_18_FLOOR_CEILING_ANGLES.zip/download

 

Latest WIP version supports globally used UDMF sector fields for floor/ceiling offsets, rotation and slopes without the need for line controls:

•     xpanningfloor 
•     ypanningfloor 
•     xpanningceiling
•     ypanningceiling
•     rotationfloor 
•     rotationfloorx
•     rotationfloory
•     rotationceiling
•     rotationceilingx
•     rotationceilingy
•     ceilingplane_a
•     ceilingplane_b
•     ceilingplane_c
•     ceilingplane_d
•     floorplane_a
•     floorplane_b
•     floorplane_c
•     floorplane_d

For flat scale there is limited support with the FLATINFO lump, eg

flat FLAT1

{
   SIZE 128
}

If the FLAT1 flat is a 256x256 flat image with the above FLATINFO definition it will be drawned in 128 x 128 px area. Note that FLATINFO lump controls the flat texture, not the actual floor & ceiling texture scale. Valid SIZE values are 64, 128, 256, 512, 1024, 2048 & 4096.

 

For testing purposes you can try latest WIP version:

https://sourceforge.net/projects/delphidoom/files/WIP_BUILDS/

 

Also WIP DoomBuilder coonfig file for UDMF:

DelphiDoom_udmf_WIP_20220129.zip

 

Please not: The UDMF is not ready, it's not even close to the release specs, at least for the line specials. All the line specials are the Doom classic specials, Hexen specials with args (including polyobjs) are not implemented at the time.

[ketmar]

58 minutes ago, jval said:

and I took an answer that GZDoom does this in OpenGL rendering

yes, GZDoom simply adds roll angle to camera matrices.

it is slightly more harder than that, tho, because clipper should know that it has an "unusual" screen size to work with.

 

1 hour ago, jval said:

On the other hand, in OpenGL can be done very easily by modifying the modelview matrix

it also depends on how you're doing aspect ratio correction. GZDoom adds aspect multiplier to camera transformation matrix, for example, and in k8vavoom i'm doing it in projection matrix. k8vavoom way of doing things is "physically correct", but rotated image is distorted heavily (because aspect ratio always works with rendered pixels, and it is always strictly vertical). yet adding aspect coefficients in view matrix breaks the clipper (and some other parts of the code).

 

so implementing proper roll angle is not as easy as it seems. ;-)

[jval]

16 minutes ago, ketmar said:

yes, GZDoom simply adds roll angle to camera matrices.

it is slightly more harder than that, tho, because clipper should know that it has an "unusual" screen size to work with.

 

it also depends on how you're doing aspect ratio correction. GZDoom adds aspect multiplier to camera transformation matrix, for example, and in k8vavoom i'm doing it in projection matrix. k8vavoom way of doing things is "physically correct", but rotated image is distorted heavily (because aspect ratio always works with rendered pixels, and it is always strictly vertical). yet adding aspect coefficients in view matrix breaks the clipper (and some other parts of the code).

 

so implementing proper roll angle is not as easy as it seems. ;-)

I haven't tested thoroughly, I've just added 1 line of code before rendering the scene :)

But it seems that if a wall is completely out in not tilted view, but a small fraction of it must been drawn in tilted view some problems are rising....since DelphiDoom's angle clipping depending on fov may miss. (it's a bit generous thou, it adds 2^o to fov left & right - origin in PRBoom+ clipper)

If the OpenGL solution gets complicated, imagine the soft renderer nightmare...

[ketmar]

1 hour ago, jval said:

But it seems that if a wall is completely out in not tilted view, but a small fraction of it must been drawn in tilted view some problems are rising....since DelphiDoom's angle clipping depending on fov may miss.

yeah, i had (actually, i have) the same problems with clipper ;-).

 

1 hour ago, jval said:

If the OpenGL solution gets complicated, imagine the soft renderer nightmare...

no, thank you. i am too old for such horrors. ;-)

 

p.s.: but i want to try what Unreal1 does for clipping. UE1 renders scene into the "background span buffer" (just filled polys w/o textures), and does per-pixel visibility checks. even most complex idTech1 geometry is relatively simple by today's standards, so i may use the same approach for BSP rendering. it should greatly reduce overdraws for complex maps, where current 1D clipper cannot clip away anything due to missing height info.

[Gez]

6 hours ago, jval said:

Does GZDoom does it in classic software renderer?

No, that renderer is really not meant for such things. I think the only way it could be implemented would be to cheat by using the classic renderer only when view pitch and roll is 0, and silently switching to softpoly otherwise.

 

4 hours ago, jval said:

But it seems that if a wall is completely out in not tilted view, but a small fraction of it must been drawn in tilted view some problems are rising....since DelphiDoom's angle clipping depending on fov may miss. (it's a bit generous thou, it adds 2° to fov left & right - origin in PRBoom+ clipper)

Just looking up and down can be enough to cause problems to appear. I think this issue is still present in GZDoom.

[ketmar]

1 hour ago, Gez said:

I think this issue is still present in GZDoom.

yeah, it's still there. slightly harder to hit now, but it wasn't fully solved ever (it is virtually impossible without rewriting the clipper). in k8vavoom i'm artificially expanding FOV for frustum in extreme cases, which avoids such glitch, but causes massive overdraws instead. 1D clipper is not really suited for anything except "looking straight forward".

[GRAU]

Hi, Jval! I got a new old issue with palete - the sprite itself is a 32bit png, and unless there are no changes to player subcolormap - all looks good. But when i get the hazmat suit and colormap shifts to the green one - i see really lots of problems with additive 32bit sprites comming:

 

Hazmat suit on - looks like the sprite of plasma is rendered using OLD original dooms colormap but with RDDVOX PALETE - that is why this appears, i think:

 

And here the HAZMAT has worn off, and regular colormap from RDVOX is used again.

 

 

The interesting fact is that i generated all the colormaps in rdvox, for the new palete:

 

 

I also add a RC version of RDDVOX 0.41.7 i used to make this screen - check it if needed.

RDDVOX-0.41.7.zip

[GRAU]

On 1/29/2022 at 9:45 AM, jval said:

imagine the soft renderer nightmare...

 

If this functional requires too much overdrawal - may be that is not as needed function as i imagined... Actua;lly there are tonns of MORE needed things, like multiple 3d floors per sector, portals, and so on.