jval

FPCDoom is a source port of Doom developed in Free Pascal / Lazarus. Downloads: version 1.14.18.134 (April 10, 2022 - source code tested with Lazarus 2.0.10 ) version 1.13.17.133 ( January 10, 2021 - source code tested with Lazarus 2.0.10 ) version 1.13.16.128 ( December 28, 2020 - source code tested with Lazarus 1.6.2 and 2.0.4 ) version 1.12.6.127 ( June 30, 2020 - source code tested with Lazarus 1.6.2 and 2.0.4 ) version 1.12.6.126 ( April 5, 2020 - source code tested with Lazarus 1.6.2 and 2.0.4 ) version 1.12.6.125 ( February 2, 2020 - source code tested with Lazarus 1.6.2 and 2.0.4 ) version 1.12.6.124 ( January 24, 2020 - source code tested with Lazarus 1.6.2 and 2.0.4 ) version 1.12.5.121 ( December 30, 2019 - source code tested with Lazarus 1.6.2 and 2.0.4 ) version 1.12.5.120 ( December 17, 2019 - source code tested with Lazarus 1.6.2 and 2.0.4 ) version 1.12.4.118 ( December 3, 2019 - source code tested with Lazarus 1.6.2 and 2.0.4 ) version 1.12.4.117 ( December 2, 2019 - source code tested with Lazarus 1.6.2 and 2.0.4 ) version 1.12.4.116 ( December 1, 2019 - source code tested with Lazarus 1.6.2 and 2.0.4 ) version 1.12.4.115 ( November 24, 2019 - source code tested with Lazarus 1.6.2 and 2.0.4 ) version 1.12.3.114 ( November 22, 2019 - source code tested with Lazarus 1.6.2 and 2.0.4 ) version 1.12.2.100 ( November 12, 2019 - source code tested with Lazarus 1.6.2 and 2.0.4 ) version 1.12.1.76 ( October 29, 2019 - source code tested with Lazarus 1.6.2 and 2.0.4 ) version 1.11.2.38 ( January 28, 2018 - source code tested with Lazarus 1.6.2 and 1.8 ) version 1.11.1.18 ( January 14, 2018 - source code tested with Lazarus 1.6.2 and 1.8 ) Source code repository https://github.com/jval1972/FPCDoom Features: High screen resolutions with accurate software rendering True color software rendering with optional usage of external textures (pk3 files containing png, tga or bmp images) Dynamic lights Mirror mode with demo compatibility Palette post processing effects (grayscale & standard palettes) Multiple CPU cores utilization Uncapped framerate Automap rotation and overlay DEH/BEX support Raised vanilla static limits The purpose of the project: Provide a solid code-base of Doom in the popular (among Pascal programmers) Free Pascal Compiler. Provide a true color software renderer without the complexity of it's bigger brother (DelphiDoom). Fix bugs of vanilla source code.

Latest version 1.0.6 is out: Download: https://sourceforge.net/projects/doomxs/files/DoomXS_1.0/DoomXS_1.0.6.142_bin.zip/download What's new: Uncapped framerate! Can be turned on-off from launcher. The autorun mode can be turned on/off with CAPS-LOCK key while playing. Default sound channels raised to 32. Fixed some drawing glitches. Corrected segments light level. About this release: Despite the fact that the focus of this project is the extra small (executable and source code) size, I was very tempted to "add some spice" and make Dooming with it more enjoyable. So I added uncapped framerate and the autorun on/off with less than 300 lines of code. You are welcome to download the extra small and extra smooth DoomXS! Updated launcer screenshot:

Indeed, it was an attempt I made before releasing the v. 1.1.4.580. In fact, it was my first attempt to render the voxels in software rendering: Each voxel column was converted to a sprite. It was a naive solution, since no special care was needed to render the voxels properly, it was just a re-use of the sprite code. Unfortunatelly with a couple of voxels the number of vissprites raised so rappidly that it was totally unplayable. The bottleneck was the clipping code, which it had to be calculated for each voxel column. On the other hand, the clipping was 100% accurate, even for overlapping voxels.

This is a great idea! I tried the map and I was impressed by the fact that you're using only a few extra lines. This will also be faster to software rasterizers, since voxel rendering is CPU-hungry. As for converting voxels in texture slices, many voxel editors strip the inside of the voxel, so that only the outer layer is actually present in data, so an automatic converter instead of will produce this: and then it must take the necessary steps to "fill" the gaps. Obviously, moving objects will be limited to move into a line, with some work in texture scrolling and anims. So, you've used the front view as a depth guide, and the side view a a buffer. That works good for convex objects, but not with non convex objects. Still, it's impressive work, reminds me a paper I've read some time ago about depth buffer based voxelization (http://graphics.cs.aueb.gr/graphics/docs/papers/voxeliser.pdf), but I never tried to implement it due to the non convex limitation. This was my first attempt to render voxels in DelphiDoom (software rendering), I used 1 px sprites for each voxel column. The results were very good, the clipping was perfect, but unfortunatelly it was too slow and I descarted the idea. Quick tested in Eternity, Doom-Retro, 3DGE, DelphiDoom & K8Vavoom and works OK.

int main(int argc, char* argv[]) { int i; float x=0.0004F,y; double d; i=0x5F3759DF-(*(int*)&x>>1); y=*(float*)&i; y*=(3.0F-(x*y*y)); d=y/2.0F-6755399441055744.0F; printf("I am %d years old!\n", (*(int*)&d=-*(int*)&d)); }

Actually, there are the DROPPEDSPIN & PLACEDSPIN fields in VOXELDEF lumps than can spin a voxel item.

Voxels are also expensive in SW rendering, their drawing complexity is one order of magnitude greater than their sprite equivalent.

Check the sprite offsets in SLADE3.

Yes. This is how the rotation is defined. Look also at zdoom wiki for more info about sprite rotations.

Are the sprite names HLTNA0, GLMPA0 or HLTNA, GLMPA?

I couldn't replicate the crash but I made a work arround that may solve the issue, you can download it at https://sourceforge.net/projects/xgreed/files/xGreed 1.1/xGreed_1.1.12.55_bin.zip/download (ver 1.1.23 - build 55) What's changed: I flaged the memory manager to assume that this is a multithreaded app. xGreed does not utilize multiple threads, but I can not be sure for BASS.DLL (third party sound library). Maybe this is the cause of the crash. I 've added safeguard checks that they will display an error message when the app exceeds the internal static limits. This will not solve the problem, but it will be a helpfull tool to locate a possible cause of crash. Raised the static limit of maximum sprites (from 700 to 4096).

Tested and worked fine in most cases, I had keyboard problems running it in my ASUS gaming laptop (keyboard is not responding at all, only with Alt+F4 I can close it), in other PCs it works OK. All systems are with Windows 10. Performance is good even with my potato N2808 laptop with build-in Intel GPU. Some ideas: Support for DOOMWADDIR/DOOMWADPATH & Steam & GoG installed games. DPI awareness for Windows 8/10/11 Wipe effect Remove color from spectres maybe?

Thank you so much for that. The bug involved erronous rendering of lines that contained the (0, 0) point in map. Fixed in 2.0.7.732: DelphiDoom: https://sourceforge.net/projects/delphidoom/files/DelphiDoom 2.0.7/delphi-doom-2.0.7.732-win32.zip/download DelphiHeretic: https://sourceforge.net/projects/delphidoom/files/DelphiDoom 2.0.7/delphi-heretic-2.0.7.732-win32.zip/download DelphiHexen: https://sourceforge.net/projects/delphidoom/files/DelphiDoom 2.0.7/delphi-hexen-2.0.7.732-win32.zip/download DelphiStrife: https://sourceforge.net/projects/delphidoom/files/DelphiDoom 2.0.7/delphi-strife-2.0.7.732-win32.zip/download Unfortunatelly, firing the plasma gun in a close distance target produces a lot of sprites that cover big portion of the screen. It's inevidable to drain huge CPU power to draw all these sprites, there are million of pixels that must be drawned over and over again to complete the frame. But the biggest slowdown comes from the light effects: You can double or tripple the fps by disabling the lightmap (Options/Display/Advanced/Lightmap). I 'll try to take another look at this, but already the engine utilizes multiple cores for completing the task, so what it needs is a different algorithm since there is not much room for improvment for the current one.

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

Thanks fot the screenshot, from the error address it seems that the problem is when xGreed is trying to free memory. I suspect that this has to do with the memory manager. I'll try to replicate the problem to see where excactly the problem is.

Good to see progress in voxel rendering! In DelphiDoom using one quad for each visible voxel side is the worst case scenario, i.e. there is not even one voxel element with a neighbor with the same color in the same plane (x/y/z).

WAD Painter is a simple paint program that can be used to combine textures from WAD & PK3 resources. Actually, it's a strip-off of the DD_TERRAIN tool, that keeps only the "texture painting" mechanics. It was created in order to have a separate development path for possible future functionalities that could not fit the parent project. Downloads: (version 1.1.3.27 - 20220103) Executable (win32): https://sourceforge.net/projects/wad-painter/files/WADPAINT_1.1/WADPAINT_1.1.3.27_win32.zip/download Source code: https://sourceforge.net/projects/wad-painter/files/WADPAINT_1.1/WADPAINT_1.1.3.27_src.zip/download Repository: https://github.com/jval1972/WADPaint How to use: You can select a WAD, PK3 or a directory from the texture manager and use the paint tools to draw the texture. There are 3 paint tools: Rectangle, Circle & rounded circle. You can change the opacity and scale from the appropriate sliders. Finally, use the File/Export menu to save the texture as image to disk. Screenshot:

No that's not possible. There are performance issues.

In which level did the crash happen? Is there a way to replicate the crash?

DD_TERRAIN works only with 256x256, 512x512, 1024x1024 & 2048x2048 textures and 5x5, 9x9, 17x17, 33x33 & 65x65 heightmaps. The whole idea is to create a mesh and then import it (and copy/paste it) to DoomBuilder. What excactly do you mean with target output? Do you mean the texture ? You can use WADPAINT instead, in WADPAINT you can have any texture size up to 2048x2048 and compine textures from WAD or PK3 source.

Thanks, I have the latest version 3.88b so I'm OK :) 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. 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.

OK, this is not a problem, as long as this is a built with full optimizations enabled.

The size of the binary files is huge, do they contain debug info? Can we have a "release" build?

OK, thanks. I'll look at them.

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?