DelphiDoom 1.1.4 - built 550

[jval]

The newest version of DelphiDoom 1.1.4.550 is available:

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

Most significant changes since last official release are:
-Multithreading software rendering (both paletted and true color)
-Software rendering speed optimizations, good performance in true color mode in FULL-HD resolution with external textures (DHTP) when using modern hardware (vanilla complexity maps)
-Widescreen support
-Support for Chex Quest, Chex Quest 2 and Hacx
-Detailed changes log is inside the readme.txt file

Here are some screenshots (all are with the software renderer in true color mode with DHTP*, fps values are in a Core-i5 laptop in 1920x1080 resulution)

(*I used the DoomsDay engine pack - deng-dhtp-20121229.pk3 - whitch is almost, but not 100%, compatible with DelphiDoom)


free image hosting


host images


online photo storage


image


online photo sharing

[Springy]

This looks absolutely fantastic! Great to see another Linux source port, will there be support for Strife and Hexen?

[DaniJ]

I'm very impressed with the quality of those screenshots. Its easily the best output I've seen from any software rendered DOOM port. Kudos.

[jval]

Thanks guys!

@Springy
This is a Windows port only. There is also support for Heretic and Hexen, but not Strife, at least not yet :)

@DaniJ
The output quality of the software renderer hasn't changed much since version 0.8.4 (October 2008), what has changed is that in current version software rendering is much more optimized even in non-multithreding enviroments.


Making some recent tests I managed to emulate deep water effects (BOOM linedef 242) in 32 bit external textures, in fact the renderer now is able to change at runtime a 32 bit color texture to fit any custom colormap.

Some screenshots from BOOMEDIT.WAD (sample wad of BOOM), both are in 32 bit color software rendering mode with hi-res external textures:

(ORIGINAL - USING BLUMAP)


(CHANGED - USING LAVAMAP)


Translucency also works now without TRANSMAP:

[Gez]

jval said:

in fact the renderer now is able to change at runtime a 32 bit color texture to fit any custom colormap.

Even colormap hacks?

[jval]

Gez said:

Even colormap hacks?

The true color renderer ignores by default COLORMAPS #1 thru 32 and only uses COLORMAP #0. Then insdead of using COLORMAPS #1 thru #31 for brightness, it calculates the lightlevel in a more linear way (no ugly transactions for brightness changing in the z-depth axis) and instead of COLORMAP #32 it calculates the inverse color.

If 'forcecolormaps' console variable is set to true (default is false - Menu command: Options/Display/32 bit rendering/"Use 32 bit colormaps"), in some cases uses the colormaps, but mostly "hacks" the lightlevel to emulate the light transactions of the 8 bit renderer.

What it does so far is transforming a true color texture to match the changes that a custom colormap makes to a paletted patch.

The algorythm I used is the following:

For each custom colormap I create a 3 dimentional array <long LUT[X][X][X]> where X is a N power of 2 (N=4 or N=5 bits are OK to work with, i.e. X=16 or 32).
Each dimention of the LUT array represents a value of RGB color, eg if LUT[10][8][7] stores the new color for RGB(10<<(8-N),8<<(8-N),7<<(8-N)) after applying the colormap transformation.
The number of significant bits does not affect rendering performance, only memory usage and loading time (the time-consuming calculations of the "transformation" occur only the first time the colormaps are loaded)

When a custom colormap is in use, the renderer transforms each pixel of an external texture using the above LUT.
For example, if we have a 4 bits precision LUT and the color of current pixel is RGB(BINARY{00111101},BINARY{01101011},BINARY{01001010}) the transformed color will be LUT[BINARY{0011}[BINARY{0110}][BINARY{0100}] without the time consuming calculations of colormap transformation.
After that we can decide if we will use the new color unchanged (so far that's what I do), or apply any precision corrections (eg average with next LUT items), that depends on the huppy medium between performance/quality. Even if we use precision corrections we avoid the time-consuming calculations of colormap remap in 32 bit texture. A LUT of 5 BITS precision gives very good results for the naked eye without using any corrections. In fact many colormaps are using just a single color, for example BLUMAP uses only blue color values, so even with a 3 BITS precision LUT we can achieve 512 different color remap table, more than the 256 distinct blue tints that RGB color representation can hold.

This technique can also be applied to COLORMAPS #1 thru #32 if they don't "obey" the default "laws" of DOOM engine, if someone can give me a download link of such mod will be greatly appreciated.