Jump to content

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


jval

Recommended Posts

On 2/15/2022 at 2:25 PM, GRAU said:

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:

SSHOT_Doom_20220215_140623421.png.603bf498007d6ace861296322c8dd03f.png

 

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

 

SSHOT_Doom_20220215_140635500.png.b7eb6caaba0aca53feb6fd746e0d50a7.png

 

 

 

Sorry for taking a bit to replay, I'm very busy these days....
The problem appears only in 8 bit mode, not in 32 bit color.

Solution and work-around:

The transparency tables for sprites in 8 bit color are calculated depending on the first palette, not for the additional palettes, or additional gamma corrections. This technique works fine with the build in palette, or any palette, that it has got "linear" differences with each  other.

Where the problem occurs: The precalculated transparency tables hold information like: if we apply a transformation between color index C1 (background) with color index C2 (sprite) and alpha value A what color index do we get?  (Transformation stands for a function, like add or subtract or translucency)

Now, in Doom palette, the calculation result if the same for the same C1, C2 & A, regardless the palette index you're using (blood, rad suit, etc). This does not apply to some of RDDVOX's palette indexes.
I've created a new palette using a tool I've developed some time ago, and works fine, you can try it if you like:

DOOMPAL3.zip

 

Screenshot of the new palette without the problem (this is a pre.2.0.7 version, but it will work the same with the latest official 2.0.6, or any of the latest WIP versions):

Spoiler

SSHOT-Doom-20220217-182352009.png

 

 

Now, if the new palette does not fit, we can discuss other options.

Share this post


Link to post
  • well, that is not the thing i expected to hear, but i will try your palete and compare it tio my own  - interesting what actualy had changed

But for me the better sollution would be to change a bit the logic of radsuit. for example to calculate the picture under radsuit in 32bit and then - convert the result back into paleted color. Actually this effect appears only on radsuin and item pickup moments, but the blue colors become broken those moments.

Another question - do i need colormap at all for delphidoom? do i need to generate damage effect subtables?

Edited by GRAU

Share this post


Link to post
On mardi 15 février 2022 at 1:25 PM, GRAU said:

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:

 

1 hour ago, GRAU said:

But for me the better sollution would be to change a bit the logic of radsuit. for example to calculate the picture under radsuit in 32bit and then - convert the result back into paleted color. Actually this effect appears only on radsuin and item pickup moments, but the blue colors become broken those moments.

Just to clarify things: the radsuit effect is not a colormap. Colormap is used only for light levels and invincibility. Instead, the greenish tint from the radsuit is achieved with a palette swap.

 

The PLAYPAL lump does not contain just one palette, it contains a whole 14 distinct palettes. The first palette is the base palette, but then you have progressively redder palettes (used for when you take damage and the screen flashes red, as well as for the berserk effect), progressively yellower palettes (used for when you pick up items and the screen flashes gold), and a greenish palette for when wearing the radsuit.

Share this post


Link to post
2 hours ago, GRAU said:

But for me the better sollution would be to change a bit the logic of radsuit. for example to calculate the picture under radsuit in 32bit and then - convert the result back into paleted color.

No, it will be catastrophic for the CPU to make all calculations in 32 bit and then make more calculations to change back to 8 bit.

 

2 hours ago, GRAU said:

Actually this effect appears only on radsuin and item pickup moments, but the blue colors become broken those moments. 

These are the palettes with the problem I described.

 

2 hours ago, GRAU said:

Another question - do i need colormap at all for delphidoom? do i need to generate damage effect subtables? 

Probably the OpenGL could work without them, since all the color change effects are emulated, but there are some rare cases they are used (eg in the console). But you need them in software mode, even some (pre-)calculated tables are limited to the first palette only, or in some cases in 32 bit, the effects are calculated algorithmically. On the other hand, I can provide mechanics to generate them at runtime, it won't be a problem.

Share this post


Link to post
19 hours ago, jval said:

No, it will be catastrophic for the CPU to make all calculations in 32 bit and then make more calculations to change back to 8 bit.

 

These are the palettes with the problem I described.

 

Probably the OpenGL could work without them, since all the color change effects are emulated, but there are some rare cases they are used (eg in the console). But you need them in software mode, even some (pre-)calculated tables are limited to the first palette only, or in some cases in 32 bit, the effects are calculated algorithmically. On the other hand, I can provide mechanics to generate them at runtime, it won't be a problem. 

 

No i don't think it is really needed. But i am interested - what actually changed in that "doompal3.pal"? I compared the colors in main table and found no differences in blue or any others. Did you generated some extra tables or what? please tell me that so i could make those things in right way too. And yes - the pal works fine, that looks enough. As for subtable auto generating on launch - i think it will take extra few seconds of launchtime - from one side, and disable some colormap tricks - from other, so better dont waste time for subtable autogeneration, please. The modder who wants custom tables could use your utility - actually where can i get that?

Share this post


Link to post
3 hours ago, GRAU said:

 

No i don't think it is really needed. But i am interested - what actually changed in that "doompal3.pal"? I compared the colors in main table and found no differences in blue or any others. Did you generated some extra tables or what? please tell me that so i could make those things in right way too.

I used the first palette and I generated the other palettes and the colormap using the algorithm described at the wiki. I didn't generate any extra tables.

 

3 hours ago, GRAU said:

And yes - the pal works fine, that looks enough.

Nice!

 

3 hours ago, GRAU said:

As for subtable auto generating on launch - i think it will take extra few seconds of launchtime - from one side, and disable some colormap tricks - from other, so better dont waste time for subtable autogeneration, please.

Too late :) , already done :D

It's a directive to the global text preprocessor for text defined content, and can be placed almost anywhere (VOXELDEF, ACTORDEF, LIGHTDEF, etc)

Just start a line with #CREATEPALETTE and optionally provide the base palette lump (if you don't want to use the PLAYPAL as base palette).

 

3 hours ago, GRAU said:

The modder who wants custom tables could use your utility - actually where can i get that?

The utility is based on dcolors.c of the Doom Utilities, with a fix for Carmack's typo, and an option to support the 28 palettes of Hexen. The user interface is very basic to make it public, but I hope I'll find some time to fix this soon.

 

Share this post


Link to post
  • 2 weeks later...

Delphi Doom is looking pretty good, and it's clear you're putting a lot of work into it, so thanks for that.  Here's a few requests/things of note:

 

Under the control options, you misspelled Use Joystick as "Use Joystic".

 

Also regarding controls, would it be possible for you to implement the binding of mouse buttons in the menu, and to add bindings for next/previous weapon?  Being able to switch weapons with the mouse wheel would be a huge qol improvement.

 

Delphi does not seem to like loading pk3 files that have more than eight characters in the filename.  There is a workaround for this by simply adding a period into the filename, for example:  Sacrifice.pk3 will not work and Delphi returns an error stating that the base filename is greater than eight characters.  On the other hand, Sacrific.e.pk3 will load just fine.  This oddity does not seem to apply to wads, which can have longer filenames.

 

I like that different liquids have different sounds When you enter them.  I don't think I've seen that in another port.  The blood pools seem to have been left out though, like what you see in E3M1.  I also think that being able to look left and right is pretty unique, and if Delphi ever gets to the point that vehicles can be added in I think that feature would be very useful for something like a tank or a mech with a rotating torso.

 

From what I've seen, Delphi does not feature the ability to load custom textures and flats from pk3 files, i.e from addons like the above mentioned sacrifice.pk3.  Is that something you intend to implement in the future?  I'm asking this one more out of curiosity than anything, as I imagine that would be more technical than the other things I've mentioned and would probably take time away from higher priority features.

Share this post


Link to post

for some reason loading wads doesn't seem to work, I tried loading grove.wad, which failed, then I tried auger;zenith which also failed, with the error message saying something about the AASHITTY texture

Share this post


Link to post
2 hours ago, jeremieh said:

for some reason loading wads doesn't seem to work, I tried loading grove.wad, which failed, then I tried auger;zenith which also failed, with the error message saying something about the AASHITTY texture

 

First question is how are you trying to go about loading these wads?  I haven't had any trouble loading levels myself, either through Delphi's own launcher or through ZDoom Launcher.

 

Second question is what sort of levels are they?  Are they meant for certain source ports?  If they're made with GZDoom in mind for instance, they may require features that Delphi just doesn't have.

Share this post


Link to post
11 hours ago, jeremieh said:

for some reason loading wads doesn't seem to work, I tried loading grove.wad, which failed, then I tried auger;zenith which also failed, with the error message saying something about the AASHITTY texture

 

I tried both GROVE.wad & DBP37_AUGZEN.wad and I had no problems loading them. I've only got a waring message while parsing UMAPINFO lump in DBP37_AUGZEN.wad which I've already fixed, besides that no other problems occured. How do you load the wads? Try not using the launcher (it's still buggy and it is destributed upon request). Try instead to drag the wads over the executable (Doom32.exe or GLDoom32.exe).

Share this post


Link to post
On 3/2/2022 at 12:08 PM, jval said:

Major new features:

  • Official UDMF support, a feature that actually had been left unfinished for more than 6 years, since ver. 1.1.600  (31 Dec, 2015).
  • Polyobjects in all branches.
  • ACS script (compiled or plain source) in all branches with a new ACS command line compiler tool based on Hexen's ACC compiler 1.10 by Ben Gokey.
  • Full UMAPINFO support for Doom and Heretic branches (with some small extensions/additions), limited support for Strife branch.
  • Full MBF21 support for Doom branch, good support with some missing features for Heretic, Hexen & Strife branches.
  • The software renderer casts dynamic lights to sprites, voxels and masked middle textures.
  • Crouching in all branches.
  • Fog sectors in all branches.
  • Crosshair in all branches.
  • Support for 426x200 widescreen assets of Unity Doom source port. (You must use the Unity Port IWAD).
  • WAV, OGG, FLAC, OGA, AU, VOC & SND sound files can be loaded directly from PK3 files without the need for a WAD equivalent.
  • XMI (Extended midi), CMF (Creative music file) & SOP (Sopepos) music support.
  • Individual upper, lower and middle texture offsets for sidedefs.
  • Simple dialogs for Doom, Heretic and Hexen (without the full mechanics of Strife branch).
  • Added support for Mars3D in DelphiDoom script IDE (DD-IDE tool).

 

 

Oh yeah, man! You are unbelievable cool! Let me try now to port my mod to delphidoom... What about multiple 3d floors per sector?

Share this post


Link to post

Actualy - what about Mod, XM or S3M module (tracker) support? do you have that in plans. Now i am ready to stat converting "Oneday" to DD. But i compose music in MOD because that is hi-tech of HI-TECHes from early 2000)))) Small files and cool music in the singla bottle.

Edited by GRAU

Share this post


Link to post
39 minutes ago, GRAU said:

 

Oh yeah, man! You are unbelievable cool! Let me try now to port my mod to delphidoom... What about multiple 3d floors per sector?

Thanks!

Multiple 3D floors are in my wishlist too, but still needs a lot of preparation to figure out how they could be implemented to the engine. The software rendering conserns me a lot since I must figure out how to avoid overdraw (something that DelphiDoom does with the single 3d floors, maybe not perfectly but at a good degree). Also the physics/collisions could be tricky. The only thing that doesn't concern me is the OpenGL rendering :)

 

35 minutes ago, GRAU said:

Actualy - what about Mod, XM or S3M module (tracker) support? do you have that in plans. Now i am ready to stat converting "Oneday" to DD. But i compose music in MOD because that is hi-tech of HI-TECHes from early 2000)))) Small files and cool music in the singla bottle.

DelphiDoom has MOD, XM, S3M and IT track music support since ver. 2.0.6.729. 

XMI, CMF & SOP support added in lastest ver. 2.0.7.730.

The music files must be in a WAD file to be detected. It doesn't detect them in a pk3 (but this is in TODO list).

Share this post


Link to post
2 hours ago, jval said:

DelphiDoom has MOD, XM, S3M and IT track music support since ver. 2.0.6.729. 

 

Great!

 

2 hours ago, jval said:

Multiple 3D floors are in my wishlist too, but still needs a lot of preparation to figure out how

 

 

ok, i will wait. Another thing - do i have to split all my textures into flats and patches, ort can i use em from a zip/pk3/textures folder directly? i use 32bit png, and any zdooms in UDMF mode just load them as textures - no difference - i can use them for both floors or for walls without adding the image names to texture or any other lumps.

 

image.png.85560d8a3663d2c0bba46575758927fc.png

 

Can i do the same on delphidoom> As for ZDoom - it calculates colors and lights iin 32bit i feel, and trasforms final picture into palete. That is becauser of coloured light (sector colour) - does Delphidoom apply sector color in udmf?

Share this post


Link to post
2 minutes ago, GRAU said:

ok, i will wait. Another thing - do i have to split all my textures into flats and patches, ort can i use em from a zip/pk3/textures folder directly? i use 32bit png, and any zdooms in UDMF mode just load them as textures - no difference - i can use them for both floors or for walls without adding the image names to texture or any other lumps.

  

PNGs (and other image formats as well) can be used in a pk3 file as a replacement only to an existing texture or flat, i.e. you must have an equivalent entry in TEXTURE1/TEXTURE2/TEXTURE3 lump, or a flat. 

 

2 minutes ago, GRAU said:

 

Can i do the same on delphidoom> As for ZDoom - it calculates colors and lights iin 32bit i feel, and trasforms final picture into palete. That is becauser of coloured light (sector colour) - does Delphidoom apply sector color in udmf?

DelphiDoom can have only the simple colored lighting used in Boom.

Share this post


Link to post
1 minute ago, GRAU said:

Can i use flats for walls in udmf?

 

No, you can't. But you can have a single PNG in pk3 and a flat and a texture in WAD with the same name, they will both map to the same pk3 png.

Share this post


Link to post

i really hate an idea of usege dffer5ent texturres for walls and flats. If it is real - try to makedirect load for png from :"textures" folder - as flats andd then - the support for  applyiong flat images to wals. But have in mind that those"flats" can be not only of 64 x 64 res but larger or smaller too. I may send you a mod - that is really usefull and lots of udmf map authors just load textures from png (NOT replacing the existing paleted ones). That is one of udmf's main advantages in zdoom. I know you ve done a lot changes to delphidoom and i really love those dynlights on voxels. Thats marked as 11 of 10)))

Share this post


Link to post
Just now, jval said:

 

No, you can't. But you can have a single PNG in pk3 and a flat and a texture in WAD with the same name, they will both map to the same pk3 png. 

then may you automatize somehow that creation of virtual flats and textures from a single png in zip?

Share this post


Link to post

no matter now how accurate that will be done, will that use double ammount of ram or not. The main thing now is to start converting maps from zdoom to dd with its own cpecifics, understanding the fact that limitation to a singkle 3d floor is not forever but trying to decrease multi 3d floor ammount. Actualy - does DD supports PHYSICAL (walcable) middle textures? i would replace tonns of 3d floors with that.

Share this post


Link to post
3 minutes ago, GRAU said:

then may you automatize somehow that creation of virtual flats and textures from a single png in zip?

 

I have no objection to use plain PNGs (or jpegs or bmp, or pcx or tiff or etc... picture format) directly from pk3 without the need for defining these to wad, but with the some limitations to the size, eg I'm not sure if I can make the engine handle non 64x64, 128x128, 256x256 etc flats, or how the engine will work with non power of 2 tiled vertically textures. 

 

6 minutes ago, GRAU said:

Actualy - does DD supports PHYSICAL (walcable) middle textures? i would replace tonns of 3d floors with that.

Do you mean tiled vertcally middle textures? No it does not support such a feature, but... RAD does! It would not be a problem. Can you give me an example screenshot or wad to look?

Share this post


Link to post
Just now, jval said:

 

I have no objection to use plain PNGs (or jpegs or bmp, or pcx or tiff or etc... picture format) directly from pk3 without the need for defining these to wad, but with the some limitations to the size, eg I'm not sure if I can make the engine handle non 64x64, 128x128, 256x256 etc flats, or how the engine will work with non power of 2 tiled vertically textures.  

 

Do you mean tiled vertcally middle textures? No it does not support such a feature, but... RAD does! It would not be a problem. Can you give me an example screenshot or wad to look?

 

not a tiled vertically (but that is used sonmewhere too). I can give you my wad i create for zdoom. there i use tiled middle tex on the map d2m01 in the center of the steps section, for grilled (with transparency) wall. But i said about an abilitu to create for example a rail that in facct is ony the single (not tiled verticaly) middle texture, but the player can stand on it likie on 3d floor, so it is a middle texture thathas a physical/collision model depending to its height. That can be used instead of a real 3d floor sometimes. As for using a dir with pmgs - that is simply usefull - you do not need to define texture lumo, you do not need to store a paleted copy of texturer into wad doubling the mod size. You just have an image, and you can apply it wherever you wish. That is one of the main ideas of udmf, like texture or flat offsets and rotations of flats, etc

Share this post


Link to post

I made 2 screens with options from udmf. First one - the option which enables infinite height (V-tiling) for a midle texture, but gives no physic or collision changes.

 

739066503_tiledinfiniteheightmiddletex.png.c086c5460879344536df59ede9a0f25f.png

 

another one enables height-senstive collision. It was used for walkable pipes under the ceiling or walkable railings withut 3d floors (middle floors) - i did not use it yet but if there will be no way to use 203 middle flors one above another - that gets some sense:

 

497439761_singlemiddletexturewithheitsensitivecollision.png.26d6f817892cd5d62a19adafdefb6ea5.png

 

As for usage of unifed texture iomages direct from zip/pk3 - that saves some place in project, that is usefull - i give you a libnk and you can look at ma wad - some textures there a used for both walls and ceiling. F_metal4 for black metal elements, some bricks and others, woden door frames.

 

ftp://rdw.xp3.biz@rdw.xp3.biz/Archive/1Day.zip

 

 

But you will need zdoom 2.8 or lzdoom of any revision to look it. I have another one but f you wish i will show it in PM because that is a bit secret one. This one is a tech demo now where i will test new weapons and enemies.

Edited by GRAU

Share this post


Link to post
27 minutes ago, GRAU said:

But you will need zdoom 2.8 or lzdoom of any revision to look it. I have another one but f you wish i will show it in PM because that is a bit secret one. This one is a tech demo now where i will test new weapons and enemies.

 

OK, thanks. I'll look at them.

Share this post


Link to post
13 minutes ago, jval said:

 

OK, thanks. I'll look at them.

i woukld advice to use LZDoom 3.87b or higher. It has dynlights in soft too. I decided not to hurry at porting - now there are too much things that are diffenent to zdoom's, but i wont leave that idea, just i'll wait for some changes, and focus on voxelpacks that time. I like how dynlights look now in DD. Dat thing is really sexy, and now DD is the only port that affects voxels with Dynlights in soft mode.

Edited by GRAU

Share this post


Link to post
On 3/10/2022 at 8:11 PM, GRAU said:

i woukld advixe to use LZDoom 3.87b or higher. It has dynlights in soft too.

Thanks, I have the latest version 3.88b so I'm OK :)

 

Quote

I decided to wait a little with porting - now there are too much things that a diffenetn to zdooms but i wont leave that idea, just i'll wait for some changes, and work on voxelpacks that time.

By supporting UDMF does not mean that the engine inherits ZDoom UDMF features. DelphiDoom has it's own namespace and it's own line specials. Yes, there is a lot of common base, i.e. all the Hexen specials, fields for slopes (without line specials), texture offset and flat rotation, but a lot of things works differently, e.g. all Doom format specials still exist in "DelphiDoom" UDMF namespace. Also generalized lines work in UDMF, despite the fact that the UDMF line specials with parameters makes a lot of them obsolete; I just didn't see the reason to disallow them from the UDMF format. It's like ACTORDEF & DECORATE: There is a minimum common base, but each has it's own distinct features.

 

On 3/10/2022 at 8:11 PM, GRAU said:

and now DD is the only port that affects voxels with Dynlights in soft mode.

 

On 3/27/2021 at 4:33 PM, GRAU said:

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. 

Also I should mention that soft lights affects voxels in a per pixel accuracy, since it was discussed an option to use constant depth. While developing I found out that there is not actual performance gain to use constant depth. Since the voxels are already rendered in software mode in non constant depth (that's why the... look like voxels, not like sprites), I used the already calculated depth to write to z-buffer.

 

Edited by jval

Share this post


Link to post
On 3/9/2022 at 3:47 AM, jval said:

 

I tried both GROVE.wad & DBP37_AUGZEN.wad and I had no problems loading them. I've only got a waring message while parsing UMAPINFO lump in DBP37_AUGZEN.wad which I've already fixed, besides that no other problems occured. How do you load the wads? Try not using the launcher (it's still buggy and it is destributed upon request). Try instead to drag the wads over the executable (Doom32.exe or GLDoom32.exe).

I redownloaded it and it seemed to work, oddly enough

Share this post


Link to post

A small update is available:

 

What's new:

  • Added -pistolstart command line parameter for DelphiDoom and -wandstart for DelphiHeretic.
  • Key bindings for the AUTOMAP functions.
  • Default sound channels raised to 32, maximum sound channels raised to 64.
  • Speed optimizations in software rendering, improved performance especially in heavy maps with tons of sprites.
  • Added support for tall patches in PNG format (tested with up to 1024px height, but should work higher)

Fixes:

  • Fixed crosshair drawing in OpenGL mode.
  • Fixed 3d colissions of actors moving up or down other actors.
  • Fixed misspelled of "joystick" in the menus.
  • Fixed UMAPINFO possible warning message when parsing multi-strings.

Downloads:

  • *** Removed ***
Edited by jval
Removed obsolete download links

Share this post


Link to post

This build seems to have introduced a bug.  I started playing E4M1 and got this:

 

SSHOT_Doom_20220317_184645231.png.fe5fc41478d078b4d6128670d4466cfb.png

 

This is the shotgunner alcove that is on the far side from the red skull key door.  It only looks like this when you are looking out from certain angles.

 

 

 

SSHOT_Doom_20220317_184725560.png.3bfd1fb2f863c4d0ec8f3786c85b3c92.png

 

 

Below is what you see if you're looking straight out of the alcove.

 

SSHOT_Doom_20220317_184710420.png.3521914e3557c5cefcc10bc23a4a8b14.png

 

This does not happen when you're in the alcove that is next to the red skull key door no matter which angle you are looking out from.  I went back and checked the same location in the previous build and the bug did not occur.  I also noticed that the plasma gun tanks the fps in both this build and the previous build, and the closer you are to where the plasma balls are exploding the harder it hits, bottoming out at 14 fps for me when I'm right up against a wall and just holding down the fire button.  The following screenshot was taken from the 730 build:

 

SSHOT_Doom_20220317_190033516.png.070746edc60a7a8694bbe5fdf91daac3.png

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...