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

FPCDoom 1.12.2.100 (Updated Nov 12, 2019)

Recommended Posts

On 1/16/2018 at 12:21 AM, Khorus said:

Awesome! Will test my limit removing projects and let you know if anything crops up.  :)

 

Thanks.

 

This is the table with the current FPCDoom raised limits:

 

image.png.eb4ec13184bda248a8ef3267d337dfe8.png

 

Edited by jval : Update lost images

Share this post


Link to post

Version 1.12.1.76 (Updated Oct 30, 2019) is available.

 

FPCDoom is a source port of Doom developed in Free Pascal / Lazarus.

 

Donwloads:

 

New features since latest release:

 

Rendering:

  • Improved dynamic lights (using ZDoom light definitions)
  • Multiple CPU cores utilization
  • Palette post processing effects (grayscale modes & standard palettes)
  • Mirror mode with demo compatibility

Add-On content:

  • Fixes to the PNG texture loading (re-using code from DelphiDoom)
  • Better support for midi files (re-using code from DelphiDoom)

User Interface:

  • X-Axis & Y-Axis mouse sensitivity
  • Key bindings for player control
  • Menu improvements

 

 

Screenshots:

 

Dynamic lights:

LIGHTMAP_01.png.5f858917637ff96cf6a2416872aae876.png

 

Palette post processing - Standard palette RGB444:

PALETTE_4_4_4_01.png.1211f81acd6c35258316f55dea477453.png

 

Palette post processing - Standard palette RGB444:

PALETTE_4_4_4_02.png.b4d825d096ff7ed18936f811b4251abd.png

 

Palette post processing - Grayscale:

GRAYSCALE_01.png.2473a8641026f950ca40ce8a4132e208.png

 

Key bindings menu:

KEY_BINDINGS.png.4733df4f8018b27b111f74d375fa6381.png

 

Mirror modes:

MIRROR_MODES.gif.a3f2a443b1fad96c197212845c6c11a5.gif

Share this post


Link to post

Cool! How do you achieve dynamic lighting in a software renderer? Could you elaborate in a few sentences? 

Share this post


Link to post
6 hours ago, fabian said:

Cool! How do you achieve dynamic lighting in a software renderer? Could you elaborate in a few sentences? 

 

Thanks fabian!

 

The dynamic lights are defined inside LIGHTDEF lump at FPCDoom.wad. It's the same definition that DelphiDoom uses in OpenGL mode for lightmap, and originates at the light definitions of an old version of (G)ZDoom.

 

Each dynamic light affects one or more sprites and it is strictly emitted by a map object (mobj). There are not dynamic lights without a parent mobj. 

The parameters of a dynamic light are:

  • type of light (point, flicker, pulse)
  • color1 & color2 (r,g,b)  - change the color from color1 to color2 depending on color interval
  • offset1 & offset2 (x,y,z) - change randomly offset from offset1 to offset2
  • size1 & size2 - change size from size1 to size2 depending on size interval

In each frame we calculate the color, offset and size parameters of each dynamic light that will be (possibly) rendered.

 

The rendering has various steps, as described below. The actual step order may not in that particular order, but it's easier to visualize them this way:

 

Step 1 - Calculate the shape of the light

step1.png.0a14fe5ad6093242f9f09521989fc3fa.png

 

Step 2 - Calculate the color of the light

step2.png.04b578ec91a99b05237b1e9da582b1f5.png

 

Step 3 - Blending the light with background - no clipping so far.

step3.png.5ccc0b8a9cef4aa5b405b2f69330657e.png

 

Step 4 - Clip the lights

step4.png.8445eafd9bbb871c994bd7e05f1e8015.png

 

Step 5 - Use depthbuffer information to change the strength of the effect at the affected regions on screen

step5.png.cb8770493c42d1369b8dc50623935645.png

Edited by jval

Share this post


Link to post

Hmm, sadly doesn't seem to build on Linux :(

 

image.png.f8fac0275dda3e10b75912f1e7dabd14.png

 

Do you plan on publishing the source repo?

Share this post


Link to post
2 hours ago, chungy said:

Hmm, sadly doesn't seem to build on Linux :( 

 

Do you plan on publishing the source repo? 

 

To compile on Linux all the system specific calls (located at d_fpc.pas and i_xxxx.pas units) must be replaced with Linux equivelants (or maybe use SDL for multi-platform compile ?).

At the moment I don't even have access to a Linux enviroment (I don't know if running Linux on virtual machine will provide an appropriate solution). I'll try to get Lazarus in Linux and make  some efforts to this direction .

 

I've uploaded the repository at https://github.com/jval1972/FPCDoom

Share this post


Link to post
41 minutes ago, ketmar said:

@jval wow, very smart (almost?) screen-space solution! thanks for sharing. 

 

Thanks!

 

The first clipping is performed using the R_PointOnSegSide for each seg in the screen space the light occupy.

The second clipping and the and the blend factor (strength of the effect) are calculated using z-buffer values.

 

There are 4 different lightmap quality settings:

  • Low (Lightmap is calculated at 5x5 squares in screen space and depthbuffer in 1x5 rects in screen space)
  • Medium (Lightmap is calculated at 3x3 squares in screen space and depthbuffer in 1x3 rects in screen space)
  • High (Lightmap is calculated for each pixel in screen space and depthbuffer in 1x2 rects in screen space)
  • Very high and very slow (Lightmap and depth buffer are calculated for each pixel in screen space plus render lights on masked mid textures with accurate clipping)

Unfortunatelly this method needs lightmap and depth buffer to be calculated for each pixel in screen to avoid artifacts on masked mid textures.

 

Doom_20191030_091634323.png.90948a248e39a115b155d55cd5492f3c.png

Share this post


Link to post

Wow, thank you for the detailed reply! Sounds like a very sophisticated, but also rather ressource-hungry solution.

Share this post


Link to post
On 10/30/2019 at 1:16 PM, fabian said:

Wow, thank you for the detailed reply! Sounds like a very sophisticated, but also rather ressource-hungry solution.

 

It's indeed very CPU hungry, especially in high accuracy modes. Using multiple cpu cores offsets the fps-drop in low and medium lightmap accuracy.

I'm currently exploring possibilities to speed up the procedure on high accurasy modes. I'm focusing on finding a working solution that has variable accuracy depending on screen content.

Share this post


Link to post

maybe real lightmaps? k8vavoom does that, and even traces some dynamic lights in real-time to get shadows. but lights from static sources can be precalculated easily.

Share this post


Link to post
13 hours ago, ketmar said:

maybe real lightmaps? k8vavoom does that, and even traces some dynamic lights in real-time to get shadows. but lights from static sources can be precalculated easily.

 

Such an approach will work only with point-lights with unmovable, indestructible and unpickable parent mobjs, that casts in a static wall or floor.  Will not work for pulse or flicker lights, movable floor/ceilings/doors/stairs etc

This could be a good approach for wall/enviroment lights without a "parent" mobj.

 

7 hours ago, Shon_RT said:

What does lightmap specifically do?

 

Lightmaps is a (precalculated) structure that adds illumination content to a scene. This is a good solution for static light sources.

 

This is the lightmap:

lm_01.png.f233fb4313135c39da14aa3cc6e3d7e1.png

 

This is the scene without lights:

lm_02.png.58feaf4e2d829bf3036931dd20360ec0.png

 

This is the scene with lights:

lm_03.png.09b97dc4d0ea4556b56c2a12ade6860b.png

 

 

Share this post


Link to post
1 hour ago, jval said:

Such an approach will work only with point-lights with unmovable, indestructible and unpickable parent mobjs

why? you can cache lightmaps, like Quake does for its dynamic lights. k8vavoom does exactly that: it precalculates static lights, and builds dynamic lightmaps on the fly, using several atlas textures to cache them. depending on your texture mapper you can either use atlases too, or use something like pool allocator, with limited free space management/complete purging. you can even add raycasting to get shadows.

 

p.s.: and spotlights are easy too -- you just don't don't light anything that is out of the cone.

 

p.p.s.: you will prolly need GL nodes for that, because the easiest way is to use gl polys as base surfaces. you can subdivide big surfaces to keep your lightmaps manageable, and you can use BSP to find subsectors/walls affected by light sources (with optional 1D clipper to clip out subsectors light surely cannot see).

Edited by ketmar

Share this post


Link to post
On 11/1/2019 at 11:26 PM, ketmar said:

why? you can cache lightmaps, like Quake does for its dynamic lights. k8vavoom does exactly that: it precalculates static lights, and builds dynamic lightmaps on the fly, using several atlas textures to cache them. depending on your texture mapper you can either use atlases too, or use something like pool allocator, with limited free space management/complete purging. you can even add raycasting to get shadows. 

 

p.s.: and spotlights are easy too -- you just don't don't light anything that is out of the cone.

 

p.p.s.: you will prolly need GL nodes for that, because the easiest way is to use gl polys as base surfaces. you can subdivide big surfaces to keep your lightmaps manageable, and you can use BSP to find subsectors/walls affected by light sources (with optional 1D clipper to clip out subsectors light surely cannot see).

 

Caching lightmaps to a texture is somehow something that already the engine does, it uses precalculated texture with light intensity information and during draw adds the color (which can dynamically change to another color). GL-nodes are not necessary since the depthbuffer structure can hold information about floor and ceilings (actually the depthbuffer holds information about segs in screen space, so null segs are floors/ceilings).

 

I'm currently working on speed optimizations.  I'm focusing on a solution of variable depthbuffer resolution depending on screen content (only columns that are created from masked mid textures and have gaps must be calculated on a per column basis, plus screen columns that have more that one segs present). As a bonus this method also eliminates artifacts on low resolution. Also I've realized that the lighmap is pointless to be calculated for each pixel, since the engine will use dephtbuffer to do the appropriate adjustments. A new version will come soon with good speed optimizations.

 

Share this post


Link to post
17 minutes ago, jval said:

GL-nodes are not necessary since the depthbuffer structure can hold information about floor and ceilings

but this limits you to pure screen-space solutions, no? or you have to create enormous lightmap that covers the whole sector bounding box (to cache it), which is very wasteful.

 

17 minutes ago, jval said:

Also I've realized that the lighmap is pointless to be calculated for each pixel

actually, Quake (and Vavoom) maps one lightmap texel to 8*8 (or 16*16) texture texels. that's why i asked about texture mapper: such lightmaps must be filtered to produce lights without clearly visible jagged edges. there are several ways to do that, depending of textuing code.

 

still, your approach seems to be... somewhat unconventional, and i am very interested to see how far you'll be able to push it. after all, seeing people doing things the same way again and again is boring. ;-)

Share this post


Link to post

Good job! I really liked it. One thing, could you increase max mouse sensitivity? It's too low compared to what i'm used to. Thank you!

 

EDIT: Nevermind, I found what i was looking for! I was looking in the wrong place at first :P

Share this post


Link to post
1 hour ago, Demion said:

Good job! I really liked it. One thing, could you increase max mouse sensitivity? It's too low compared to what i'm used to. Thank you!

 

EDIT: Nevermind, I found what i was looking for! I was looking in the wrong place at first :P

 

Thanks!

Aside of the "General/Mouse sensitivity" menu item there are also the "Contols/Mouse x axis sensitivity"  & "Controls/Mouse y axis sensitivity". I'll group them under a new menu in next release.

Share this post


Link to post

Version 1.12.2.100 (Updated Nov 12, 2019) is available. 

 

FPCDoom is a source port of Doom developed in Free Pascal / Lazarus.

 

Donwloads:

Executable: https://sourceforge.net/projects/fpcdoom/files/FPCDoom_1.12.2.100/FPCDoom_1.12.2.100_bin.zip/download

Source code: https://sourceforge.net/projects/fpcdoom/files/FPCDoom_1.12.2.100/FPCDoom_1.12.2.100_src.zip/download

Source code Repository: https://github.com/jval1972/FPCDoom

  

New features since latest release:

 

Rendering

  • Speed optimizations to the light effects code.  This achieved, mostly, by complete changing the depth-buffer code (also new source file r_zbuffer.pas, replaced the old r_depthbuffer.pas).  The new method gives depth buffer accuracy for every pixel without the overwhelming for the CPU & memory method of processing each pixel. Instead it keeps an elegant structure built by spanfuncs & colfuncs.  For example at 1920x1080 full-hd resolution, the previous method had to process 1920x1080x12 =~ 23 MB (!) at each rendering frame at maximum accuracy. Now we only need to process a couple of  huntrend KBs.
  • Change screen resolution from the menu (Options/Display/Detail)

File paths

  • Support for DOOMWADPATH (besides DOOMWADDIR) enviroment variable.
  • Search for installed games to the Steam folder for WADs.

Screenshots

  • Screenshots now are saved in png format by default. We can change the format to bmp from the menu (Options/System/Screenshot format)

Automap

  • Fixed automap grid rotation. Grid on/off can now be enabled from the menu (Options/Display/Automap) and will be preserved in the defaults file.
  • Fixed problem with automap overlay when changed from the menu.

Doom Engine

  • Removed limit on intercepts. Now intercepts are allocated dynamically.
  • Fixed the "stairs create unknown sector types" bug (https://doomwiki.org/wiki/Stairs_create_unknown_sector_types)
  • Preserve target & tracer in saved games. Added loadtracerfromsavedgame & loadtargetfromsavedgame console variables (BOOL). We can enable or disable this feature from the menu (Menu/compatibility). Note that disabling affects only the load game procedure, it will still save both target & tracer while saving a game.

New wipe styles

  • Fade - Fades the screen (like strife)
  • Slide down - Slides the old screen down.
  • Fizzle - This effect originates at Wolf3d, code adapted from Fabien Sanglard's Website

You can change the wipe style from the menu (Options/Display/Appearence) and the setting will be preserved in the defaults file.

 

Menu

  • Mouse sensitivity removed from Options/General and moved along with individual x-axis & y-axis sensitivity to a new sub-menu under Options/Controls/Mouse sensitivity

 

 

 

Share this post


Link to post

just tried this port out. seems interesting and has that real classic delphidoom/legacy feel to it.

 

but performance doesnt seem very great. i barely hit 60 fps on vanilla doom1/2 maps (on medium 8-bit detail and no lighting effects) and my pc isnt very bad (CPU: Intel Pentium g4560 3.50Ghz)

 

turning down the resolution helps of course, but it makes alt-tabbing a real drag.

 

theres also a real noticable mouse lag going on too

 

i feel like this port would benefit from being able to change the rendering resolution down without having to turn the actual monitor resolution down, like how chocolate doom, crispy doom, doom retro, and gzdoom does

 

but aside from that this seems like a really nice port that id like to use more if it ran better.

Share this post


Link to post

Is there a way to turn off the disk loading icon?

 

Mouse x/y sensitivity settings don't get saved.

 

Is there a way to run in widescreen with a correct ratio HUD, title graphics etc?  Like with pillarboxed title graphics and either a floating-style statusbar or the gross PRBoom/ZDoom bordered statusbar?  Also the fullscreen HUD doesn't display any armor count for me, which makes it not so effective...  1280x720 is the only resolution I can get to actually display widescreen.  Setting resolution to 2560x1440 displays a 4:3 image with either compressed or correct sprites if widescreen support is set to off or on respectively.

 

Other than these, this is pretty cool and shows a lot of promise.  I could easily see myself using this regularly with a few minor(?) fixes.

 

Thanks

Share this post


Link to post

Thank you for your feedback!

 

@kaleb.
I will work next days on screen resolution/performance issues. In fact I had done some test on stretching a low-res screen on full/native screen resolution, but the results were not as expected (maybe performance problem with the built-in Intel GPU). I'm thinking of an extra option that will change the render quality, similar to vanilla low-res and will be probably implemented in next release.
If your fps is low (e.g. lower that 60) you could benefit from turning off the uncapped frame-rate from the "Options/Display/Advanced/Uncapped frame-rate" menu item. This also could eliminate the mouse lag you've noticed.
Current development and tests are performed in 4c/4t & 4c/8t CPUs. I have access to 2c/4t (like g4560) and 2c/2t CPUs and I will perform some tests to tune the multi-core rendering also.
Medium 8bit detail is not much benefit compared to 32bit according to my tests.
Post-processing effects like gray-scale mode & palette reduction (Options/Display/Colors menu) and mirror mode (Options/Display/Advanced menu) could also affect performance, especially if you enable more than one of these at the same time.

 

@okbuddy
Currently disk loading icon can not be turned off, I'll put an option to the next release.
Indeed, due to a naive error, the mouse x/y sensitivities are not saved correctly to the defaults file. This has been already corrected to the git repository, so there will be no problem in future releases.
For aspect ratio there are the "Options/Display/Advanced/Widescreen Support" and "Options/Display/Advanced/Player Sprites Stretch" menu commands. You can also use the "forcedaspect" console command (press "~" to activate the console). With this command you can force the aspect ratio to be in range from 1.0 to 2.0 (float values). Nice to mention this, I'll make a separate sub-menu that will encapsulate, in a user-friendly way, all the settings and probably enrich the options with more parameters (e.g. HUD aspect, intermission screen aspect etc).
I can make some presets for the full-screen HUD, or even add some config options (eg show ammo/armor/keys).
Currently 2560x1440 resolution is not supported. Maximum width and height resolution is 2048x1536. I suppose that in 2560x1440 the engine "goes" at 2048x1440 resolution. I'll raise the limits to 4K resolution, but I don't have access to a monitor with resolution higher than 1920x1080 to make some tests. But just with raising the upper static limits should work with no problem, since the engine already use, in critical tasks, 64 bit integer or even floating point arithmetic to correct fixed point artifacts in high resolutions.

Edited by jval

Share this post


Link to post
15 hours ago, jval said:

 

@okbuddy
Currently disk loading icon can not be turned off, I'll put an option to the next release.
Indeed, due to a naive error, the mouse x/y sensitivities are not saved correctly to the defaults file. This has been already corrected to the git repository, so there will be no problem in future releases.
For aspect ratio there are the "Options/Display/Advanced/Widescreen Support" and "Options/Display/Advanced/Player Sprites Stretch" menu commands. You can also use the "forcedaspect" console command (press "~" to activate the console). With this command you can force the aspect ratio to be in range from 1.0 to 2.0 (float values). Nice to mention this, I'll make a separate sub-menu that will encapsulate, in a user-friendly way, all the settings and probably enrich the options with more parameters (e.g. HUD aspect, intermission screen aspect etc).
I can make some presets for the full-screen HUD, or even add some config options (eg show ammo/armor/keys).
Currently 2560x1440 resolution is not supported. Maximum width and height resolution is 2048x1536. I suppose that in 2560x1440 the engine "goes" at 2048x1440 resolution. I'll raise the limits to 4K resolution, but I don't have access to a monitor with resolution higher than 1920x1080 to make some tests. But just with raising the upper static limits should work with no problem, since the engine already use, in critical tasks, 64 bit integer or even floating point arithmetic to correct fixed point artifacts in high resolutions.

 

Thank you for your feedback-feedback.  Looking forward to the next release!

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
×