DelphiDoom progress in 3d perspective in software mode, now with voxel support

Recommended Posts

DelphiDoom's fake3d emulation in software rendering mode was an old hack since early versions of the project.

Last days I'm rewriting the module trying to bring it closer to the real thing. Note that this is NOT a true 3d software renderer, all colfuncs and spanfuncs work in the background as always, it's just a post-processing step just before rendering the player sprites and hud.
Progress so far is much more promising compared to the old stuff, faster and better looking.

This is a comparison between latest tests and previous versions:

One good point of interest is screen buffer without the post processing step of 3d emulation, it looks like this:

The black triangles left and right are because the floorclip (when looking down is ceilingclip) tables are altered to avoid unnecessary drawing. Also the black horizontal lines appears because these particular spans are not drawned to the final output (only spans, not columns).

Share this post

Link to post

In software rendering mode voxels are rendered in a similar manner as sprite columns.
In OpenGL mode are converted to an optimized mesh, i.e. continuous voxel elements with same color are converted to a single polygon.

Here is a video demonstating how voxels look like in software rendering mode with fake3d enabled:

Share this post

Link to post

I am intensely interested in the voxel code, since as you may or may not know, Eternity's attempt at implementing was pre-empted very abruptly.

In software rendering mode DelphiDoom's approach follow the guidelines of ZDoom more or less, just instead of using directly the kvx data it creates at loadtime similar data (because can also use some other voxel custom formats), and split the vertical columns which create the voxel into fractions of same color:

These fractions are rendered with a "colorcolfunc", I thing the same does ZDoom.

Performance is marginal if 100 or more voxels are rendered simultaneously in fullhd resolution when using modern hardware (fps drops to TICRATE or below, 35 fps) in 32 bit color mode. In 8 bit color mode there is no significant gain since DelphiDoom even in 8 bit color mode uses 32 bit "blit" screen buffer, i.e. SCREENWIDTH * SCREENHEIGHT * 4 bytes screen proccesing in each frame regardless if we use 8 bit or 32 bit color depth.

On the other hand in OpenGL mode things are much better and faster since DelphiDoom merge neighboard voxels elements of the same color and create a low poly mesh and store it to a precompiled OpenGL list. What gave a huge speed boost was replacing calls to glColor with texture coordinates. A palette texture with size 512X512 is used. Each pixel of this texture is a different color. A 4096X4096 texture can give all the range of RGB color representation, but since the popular KVX voxel format uses a stantard 256 color pallette is needless, and also video ram consuming. A 512X512 texture has 262144 pixels / different colors, just because DelphiDoom supports custom voxel formats (made with DD_VOXEL tool) with true color depth. True color depth in custom voxel formats is going to be added soon in software renderer version.

Share this post

Link to post

It claims delphi doom is GNU GPL(which allows for profit use), but it then goes on to say you can use it as lond as it's NOT for profit.

A license that dissallows such use is not only not GPL'd but it also runs counter to the ideals of the free software movement the GPL was born out of, that the end user of the software has the FREEDOM to modify and run the software for any purpose.

Share this post

Link to post

It claims delphi doom is GNU GPL(which allows for profit use), but it then goes on to say you can use it as lond as it's NOT for profit.

A license that dissallows such use is not only not GPL'd but it also runs counter to the ideals of the free software movement the GPL was born out of, that the end user of the software has the FREEDOM to modify and run the software for any purpose.

These lines was written a lot of years ago.... Anyway these lines have been removed from the readme.txt file.

The basic idea is that what you can do with Doom source code as published by id-software and the Heretic and Hexen source code as published by Raven software the same you can do with DelphiDoom. When the project started the raven source code wasn't under GPL, but since both the Doom source code and the Raven source code re-released under the GPL (http://doom.wikia.com/wiki/Doom_Source_License , http://doomwiki.org/wiki/Raven_source_code_licensing) I thing that distributing DelphiDoom under GNU GPL is OK.

provided you're not including additional code from third parties you're correct. There'd be trouble if you had contributers prior to the switch who did not agree to the licensing change or assigned copyright over their contributions to you.

Share this post

Link to post

provided you're not including additional code from third parties you're correct. There'd be trouble if you had contributers prior to the switch who did not agree to the licensing change or assigned copyright over their contributions to you.

I've made a list of all third party libraries DelphiDoom uses as well as base source code from third party releases was used:

One of the voxel formats that DelphiDoom can read is the KVX files but does not use Build Engine code.
There are also a few mobj codepointers from zDoom modified to fit DelphiDoom specs/limitations. Oops, zDoom is not GPL but in sourceforge is registered as BSD ... this could be a problem.... right? On the other hand BSD is considered as GPL-compatible free software license (http://en.wikipedia.org/wiki/BSD_licenses)... ?
Custom actor definition and OpenGL light definitions are inspired from zDoom (ACTORDEF lumps that DelphiDoom uses for custom actor definition is a modified subset of zDoom DECORATE lumps and LIGHTDEF lump is quite identical) but no zDoom code is used to process them.

Share this post

Link to post

Extremely permissive license. Do you have the string "deflate 1.2.3 Copyright 1995-2005 Jean-loup Gailly." in the executable? If so, congratulations, you're following the terms of the license.

jval said:

There are also a few mobj codepointers from zDoom modified to fit DelphiDoom specs/limitations.

There's no problem using ZDoom's original code in a GPL program.

Generally, all you need to do (provided the licenses aren't incompatible) is to make sure the code under a different license from the rest of the project is clearly marked so. ZDoom itself uses a complex mix of licenses.

Share this post

Link to post

Extremely permissive license. Do you have the string "deflate 1.2.3 Copyright 1995-2005 Jean-loup Gailly." in the executable? If so, congratulations, you're following the terms of the license.

I don't.
I'm using version 1.2.5, obtained from http://www.base2ti.com/?id=delphi.zlib, this link is placed in zlib home site (zlib Delphi 5 interface). I've just checked the readme.txt file that comes with the package and that's all I've found:

this software is provided "as-is", without any express or implied warranty.
in no event will the authors be held liable for any damages arising from the
use of this software.

permission is granted to anyone to use this software for any purpose,
including commercial applications. please do not misrepresent the origin of
this software. if you use this software in a product, an acknowledgment in
the product documentation (readme, about box, help file, etc.) would be
appreciated but is not required.

Share this post

Link to post

I don't.
I'm using version 1.2.5, obtained from http://www.base2ti.com/?id=delphi.zlib, this link is placed in zlib home site (zlib Delphi 5 interface). I've just checked the readme.txt file that comes with the package and that's all I've found:

zlib is under a BSD-style license. It's sometimes called the "zlib" license but there's not a lot of practical difference.

Share this post

Link to post

Is supporting Voxels only obtainable by using BUILD engine's code? I am thinking about hacking in support for 3DGE but if it even uses a smidge of that I'm staying away from it like the plague..

Ken Silverman did actually describe the format in the readme file of another project of his called Slab6. So you can just use what he describes there without the need to tear apart the BUILD engine and use that license.

Share this post

Link to post

So what exactly (mathmatically) is "3d perspective"? How does it differ from standard software rendering?

Try looking up & down in ZDoom and then in GZDoom, and you'll realize ;-)

Doom's engine is NOT polygon based, so changing "camera position" can only be done with certain compromises. E.g. in Heretic and ZDoom's "freelook" floors are practically always rendered as if they were dead-horizontal, and walls are always rendered as if they were dead-vertical, at all viewing angles (it's just that they get so distorted that you don't realize it).

When you "look up or down", instead of the polygons making up the walls and floors being rotated, it's just the view window that gets shifted up or down, plus screen-edge distortion (in fact, in Heretic shifting view means recomputing the yslope table every time, and that results in quite a bit of distortion at higher angles.
Normally e.g. when you look up a tall column IRL or in a proper 3D engine, the column should also get a trapezoidal distortion near the top, and you should get to see more of its surroundings the highest you look. In Heretic-like "freelook", this does not happen: the column will appear to be the same (pixel) width from base to top.

What jval is trying to do, essentially, is to add "proper" polygon-like distortion to the rendering of walls and flats. I'm not sure if this is done by converting visuals to a full, proper polygon mesh each frame, or by hacking column and flat drawing functions to appear as if they are drawing proper polygons, without the engine actually being polygonal.