Developers — dengine Forums

3D bridges in Doom and Heretic using custom things

M_S — Wed, 26 Nov 2025 01:12:46 +0000

I discovered a technique that uses a DeHacked object that works as a bridge for ports that allow walking over and under things. And it works quite well in Doom using the Doomsday Engine, I know it would probably work in vanilla Heretic as well. The only issues are that AIs can't walk on top of it, that the bridge itself is invisible and Heretic Hack Editor being outdated.
Here's the map for context

Though with Doomsday and DDE it should be possible to set bridge parts as extra entities, like ZDoom, and then either set them to have a model that fits the theme of each game or make them blank boxes that can have a specific texture or flat on the fly. And they could be part of the of the built in PK3s to make them available directly at the map editor.

In summary, it's something that already can be done but it could also be more widespread as an official feature since DE doesn't support any other kind of 3D structure.

Linux fresh build of doomsday crashes

XavierH — Mon, 29 Jul 2024 16:07:37 +0000

Hi

Since Doomsday 2.3 does not run (and even not installs) on Ubuntu 24, I managed to build version 3.0 from source
I followed these instructions

git clone git@github.com:skyjake/Doomsday-Engine.git
doomsday/build/scripts/build_deps.py build
mkdir build
cd build/
cmake ../ -DCMAKE_INSTALL_PREFIX=/opt/doomsday
make -j 8
make install

At first I noticed that lib_Foundation.so and its symlinks are not copied by make install, I had to copy them manually from the source directory.

And then, when running Doomsday, I experience a failed assertion

[xavier@imladris doomsday]$ /opt/doomsday/bin/doomsday
[the_Foundation] version:1.8.2-v1.8.1-11-ge48ccd9 cstd:201112
[the_Foundation] locale: en_GB.UTF-8
[Thread] created thread ID 0x7a3c327ff6c0 (TimerScheduler)
[the_Foundation] locale: en_GB.UTF-8
[Thread] created thread ID 0x7a3c111fb6c0 (runAddressLookup_)
[Address] lookup thread started
[Thread] created thread ID 0x7a3c109fa6c0 (DatagramThread)
[Garbage] recycled 3 scope allocations
[Thread] created thread ID 0x7a3bfdffe6c0 (PooledThread)
[Thread] created thread ID 0x7a3bfd7fd6c0 (PooledThread)
[Thread] created thread ID 0x7a3bfcffc6c0 (PooledThread)
[Thread] created thread ID 0x7a3bf3fff6c0 (PooledThread)
[Thread] created thread ID 0x7a3bf37fe6c0 (PooledThread)
[Thread] created thread ID 0x7a3bf2ffd6c0 (PooledThread)
[Thread] created thread ID 0x7a3bf27fc6c0 (PooledThread)
[Thread] created thread ID 0x7a3bf1ffb6c0 (PooledThread)
[Thread] created thread ID 0x7a3bf17fa6c0 (PooledThread)
  0.106    (i) Application path: /opt/doomsday/bin/doomsday
  0.106    (i) Version: 3.0 (unstable build 4956)
  0.213 G      Display 0:
  0.270 G        2560 x 1440 @ 60 Hz (24-bit)
  0.270 G        1920 x 1080 @ 60 Hz (24-bit)
  0.270 G        1920 x 1080 @ 50 Hz (24-bit)
  0.270 G        1920 x 1080 @ 30 Hz (24-bit)
  0.270 G        1920 x 1080 @ 25 Hz (24-bit)
  0.270 G        1920 x 1080 @ 24 Hz (24-bit)
  0.270 G        1680 x 1050 @ 60 Hz (24-bit)
  0.270 G        1440 x 900 @ 60 Hz (24-bit)
  0.270 G        1440 x 576 @ 50 Hz (24-bit)
  0.270 G        1440 x 480 @ 60 Hz (24-bit)
  0.270 G        1280 x 1024 @ 75 Hz (24-bit)
  0.270 G        1280 x 1024 @ 60 Hz (24-bit)
  0.270 G        1280 x 960 @ 60 Hz (24-bit)
  0.270 G        1280 x 800 @ 60 Hz (24-bit)
  0.270 G        1280 x 720 @ 60 Hz (24-bit)
  0.270 G        1280 x 720 @ 50 Hz (24-bit)
  0.270 G        1152 x 864 @ 75 Hz (24-bit)
  0.270 G        1024 x 768 @ 75 Hz (24-bit)
  0.270 G        1024 x 768 @ 70 Hz (24-bit)
  0.270 G        1024 x 768 @ 60 Hz (24-bit)
  0.270 G        832 x 624 @ 75 Hz (24-bit)
  0.270 G        800 x 600 @ 75 Hz (24-bit)
  0.270 G        800 x 600 @ 72 Hz (24-bit)
  0.270 G        800 x 600 @ 60 Hz (24-bit)
  0.270 G        800 x 600 @ 56 Hz (24-bit)
  0.270 G        720 x 576 @ 50 Hz (24-bit)
  0.270 G        720 x 480 @ 60 Hz (24-bit)
  0.270 G        720 x 400 @ 70 Hz (24-bit)
  0.270 G        640 x 480 @ 75 Hz (24-bit)
  0.270 G        640 x 480 @ 67 Hz (24-bit)
  0.270 G        640 x 480 @ 60 Hz (24-bit)
  0.270 G      Display 1:
  0.320 G        1920 x 1080 @ 60 Hz (24-bit)
  0.320 G        1680 x 1050 @ 60 Hz (24-bit)
  0.320 G        1440 x 900 @ 60 Hz (24-bit)
  0.320 G        1280 x 1024 @ 60 Hz (24-bit)
  0.320 G        1280 x 800 @ 60 Hz (24-bit)
  0.320 G        1280 x 720 @ 60 Hz (24-bit)
  0.320 G        1024 x 768 @ 60 Hz (24-bit)
  0.320 G        800 x 600 @ 60 Hz (24-bit)
  0.320 G        640 x 480 @ 60 Hz (24-bit)
  0.586        Created a new 32.0 MB memory volume.
  0.879 S      [Config::read] Detected new build: 0 => 4956
  0.897 S                     Detected new release: [ 2, 3, 1, 0 ] => [ 3, 0, 0, 4956 ]
  0.897 R  (i) Clearing cached metadata due to version change
  0.935 R  (i) Using system WAD folder: /usr/share/games/doom
  0.935 R  (i) Using UnixInfo paths.iwaddir WAD folder: /usr/share/games/doom
  0.937 R  (i) Using user-selected package folder (including subfolders): ~/Games/WADs
  0.937 R  (i) Using user-selected package folder (including subfolders): ~/Games
doomsday: /home/xavier/Development/doomsday/build/doomsday/libs/core/src_filesys_turbo.cpp:2534: de::String de::toNative(const String&): Assertion `!strchr(cstr_String(s), '\r')' failed.
Aborted (core dumped)

Does someone know how it could be fixed ?
Thanks and regards,
Xavier

Invasion Mode

Spaikou — Thu, 17 Feb 2022 05:49:59 +0000

i was wondering if a possible Invasion Mode will be added in the future

Visual Studio 2019

usulthemouse — Tue, 31 Aug 2021 04:15:32 +0000

I have never used CMake. And the last time I used an IDE that was not from Microsoft was Borland C++ 4.5? or DJGPP. Are there any good tutorials on how to get Visual Studio to compile and run this? I don't mind following instructions (RTFM) or a video. I have been trying to get VS 2019 to compile this properly all night. I would prefer to keep using it. The tutorials on Microsoft's page have been less than helpful. Thank you.

Problems with recent commits

thesourcehim — Sat, 26 Dec 2020 13:19:44 +0000

I just tested commit 36e4f46 under linux and there are 2 problems:
1. doomsday can not find it's files unless I set /usr/share/doomsday as a working directory
2. Mod support is partially broken: box mod folders are no longer considered as mods but are scanned recursively instead adding each individual pk3 file as a separate entry to the mod list.

doosmday 3.0 issue ubuntu 20.10

KuriKai — Sun, 27 Dec 2020 01:36:39 +0000

apt install libcurl4-gnutls-dev libunistring-dev libsdl2-mixer-dev

doomsday/build/scripts/build_deps.py build

cd build
make clean

cmake ../ -D DE_ENABLE_GLOOM=yes -D DE_ENABLE_GLOOMED=yes -DCMAKE_INSTALL_PREFIX=/opt/doomsday

cmake ../ -D DE_ENABLE_GLOOM=yes -DCMAKE_INSTALL_PREFIX=/opt/doomsday

make -j6

make install

I'm getting the below after building doomsday3 with gloom enabled

1.642 (WRN) [Bank::Job] Failed to load "sky.morning" from source:
[NotFoundError] (in Folder::locate) "/home/sky-morning.jpg" was not found (in root folder)
3.841 G (i) Display mode has changed
model.skeletal.generic 0x5571747cf130
ModelRenderer: Program 0x5571747cf130 still has 1 users
[App::~Impl] destroying
3.904 R [PackageLoader] Unloading 7 packages
3.917 (i) Z_Shutdown: Used 1 volumes, total 33554432 bytes.
[App::~Impl] done
doomsday: /home/dave/1tbstorage/src/Doomsday-Engine/doomsday/apps/client/src/main_client.cpp:119: int main(int, char**): Assertion `de::Counted::totalCount == 0' failed.
Aborted (core dumped)

full output
https://pastebin.com/w7EPV0GB

glbinding is not installed properly

thesourcehim — Thu, 24 Dec 2020 11:10:29 +0000

Hello, I'm trying to use your new build system, unsuccessful so far. build_deps.py script first gave me error about cloning the_Foundation (permission denied, public key), I had to clone it manually using https link instead of ssh. But ok, after that the script built all 3 deps successfully. However, some file seem to be missing for glbinding installation, no files regarding that module are found in deps/products/lib/cmake. Thus cmake can not find glbinding package. Note that glbiding files are present in deps/products/include, so it's partially installed.

Some Ideas for Doomsday (sorry if wrong subforum)

WhiteMagicRaven — Sun, 15 Mar 2020 12:35:45 +0000

HeXen PlayStation have some interesting improvements among other 'degradations'

The First is Partially Lighted Sprites

The Second is Bright maps

If you wish to look into more hexen playstation screenshots go here
http://hexen-game.ru/forum/6-666-25333-16-1584274625

They have some odd diferences to PC DOS version, fun to look too.

Idea is to add Partial Light to Sprites and Bright maps for Doomsday.

[Suggestion] RPM/DEB: assimp external dependency

thesourcehim — Wed, 01 Jan 2020 12:32:50 +0000

Many distros (including Fedora 31) provide assimp as a package. If doomsday is built with embedded assimp, resulting RPM would conflict with system assimp package, so I build RPM for Fedora 31 using system provided assimp. That means that package should explicitly require assimp when installed. I modified doomsday/cmake/Packaging.cmake, added the following block after line 20:

if (DENG_ASSIMP_EMBEDDED STREQUAL OFF)
string (APPEND CPACK_RPM_PACKAGE_REQUIRES ", assimp")
endif ()

This ensures that assimp package will by automatically installed by dnf when you try to install doomsday RPM.
CPACK_DEBIAN_PACKAGE_DEPENDS should be modified in similar way, I just don't have debian to check proper name for assimp.

RPM: should not put system directories into spec

thesourcehim — Mon, 30 Dec 2019 06:46:50 +0000

Using lines like this:
%dir "/usr/share/icons"
in spec file causes conflict during installation (since this directory is already part of a system package), I think only files and dirs belonging to doomsday should be explicitly specified.

Tested in Fedora 31, RPM created from source using 'make package'

Building from source: terrible performance [CMAKE_BUILD_TYPE]

thesourcehim — Mon, 30 Dec 2019 07:13:55 +0000

I doing something wrong when building from source for linux. Because compared to flatpak version or RPM provided here, the performance is terrible (< 10 fps). I build like this (inside 'build' directory I create inside source directory):
ccmake -DDENG_BUILD=1234 ..
then set FMOD path, enable assimp importers, enable RPM, generate
make
make package
Then I install created RPM

How do I set build number when compiling from source?

thesourcehim — Sun, 29 Dec 2019 22:22:18 +0000

I successfully compiled doomsday from source, but it shows current day build number on launch. How do I set specific build number?

Server list question

bond — Mon, 04 Mar 2019 07:42:28 +0000

Hello
How can I get a list of servers and detailed information about servers without running the Doomsday Engine program? Is there request/response protocol of servers anywhere?

Attack of the Glitches

skyjake — Sun, 05 Mar 2006 10:05:00 +0000

This post was originally made by skyjake on the dengDevs blog. It was posted under the category: jHexen.

I now have jHexen up and running on the Mac with the latest code, but I'm experiencing a number of odd glitches.

Most (or even all) upper and lower wall textures are missing. They are simply not rendered at all. Clipping seems to work normally, though.

Enemies are invisible. Other mobjs seem to appear normal (sprites; I don't know about 3D models).

Sector light levels are wrapping over to black. E.g., in the first Hexen map with the flashes of lightning, some sectors become black during the flash. Probably caused by a byte variable overflowing somewhere (DMU?).

In some places, like the hall of the first Hexen map, clipping prevents visibility from one subsector to others, so that the player only seems the subsector he's currently in.

I'm unsure how many of these are caused by endianness issues and how many are bugs of some other kind, like DMU misuse. Danij, can you see if these also happen when running in Windows?

Status Update

dengine.net — Thu, 10 May 2018 09:49:50 +0000

Status Update

The spring months have been a little crazy with various Real Life time sinks preventing me from delving too deep into fun coding. Consequently, there has been little to no progress with the tasks o…

Read the full story here

A couple questions about new contributors

Scandalon — Wed, 20 Dec 2017 22:27:32 +0000

Not addressed in the https://manual.dengine.net/devel section or elsewhere that I could find:

1 - Is there a general overview of the code layout of what's where, general build process, etc? I assume if you're familiar with CMAKE much of that may be easy/obvious, but it would be nice to have a nicer introduction. (What targets are available? Is there an easy way to skip building all the game libraries if you're just focused on one...)

2 - Is cross compiling supported?

3 - For people attempting to address a particular issue, is it better to discuss it here, or on the issue tracker? (I'm thinking about both higher-level "hey, I'm going to use approach X, what do you think?" and lower level "It works, but only one tuesdays" type issues.) Perhaps each place is preferable for each type?

Thanks.

Anyone want to help troubleshoot compiling on MacOS?

Scandalon — Fri, 15 Dec 2017 00:35:10 +0000

(I'm not an experienced dev, but I can usually get stuff to compile...)

MacOSX 10.13.x, using latest stable branch. I got CMAKE to run fine, make fails with:

[  2%] Building CXX object sdk/libcore/CMakeFiles/libcore.dir/src/c_wrapper.cpp.o
error: trigraphs was enabled in PCH file but is currently disabled
1 error generated.
make[2]: *** [sdk/libcore/CMakeFiles/libcore.dir/src/c_wrapper.cpp.o] Error 1
make[1]: *** [sdk/libcore/CMakeFiles/libcore.dir/all] Error 2
make: *** [all] Error 2

I know this isn't a DE specific thing, probably a clang compiler setting/flag thing... (As I go through, I could write up some additions to the "how to compile" entry, as well.

Odds and ends

dengine.net — Sat, 01 Jul 2017 09:15:09 +0000

Odds and ends

I’ve been getting back into the swing of things with a set of smaller changes and improvements. I haven’t yet started work on the major focus of the 2.1 release, which is planned to be Multiplayer …

Read the full story here

The road to mobile

dengine.net — Sun, 28 May 2017 05:46:59 +0000

The road to mobile

I’ve spent the past couple of weeks experimenting with an iOS port of Doomsday. This is now at a proof-of-concept level and not playable yet. It isn’t quite the right time to continue m…

Read the full story here

Planning ahead for 2.1: multiplayer and OpenGL

dengine.net — Tue, 18 Apr 2017 15:59:34 +0000

Planning ahead for 2.1: multiplayer and OpenGL

The stable version 2.0 has been out for a bit over two weeks now. I hope you’ve been enjoying it! I have been busy working on bug fixes for 2.0.1, which is soon getting into shape for release…

Read the full story here

Website refresh

dengine.net — Mon, 27 Mar 2017 03:16:03 +0000

Website refresh

In preparation of the 2.0 release of Doomsday I have redesigned the dengine.net website from the ground up. The new design went live today. While the old design has been perfectly adequate during t…

Read the full story here

Doomsday 2.0 RC1

skyjake — Thu, 02 Mar 2017 11:16:07 +0000

This is a blog excerpt. http://dengine.net/blog/2017/03/doomsday-2-0-rc1/"; target="_blank">Read Full Article

Build 2250 is the first Release Candidate for 2.0.
The full release notes will be available later, but the short version is that 2.0 introduces two big changes in how Doomsday works:

The Snowberry front-end application has been replaced with a new Home screen within Doomsday itself.
Doomsday has gained more understanding of various data file formats, resource packs, and add-ons so that it can load them without assistance from a front-end app. This Packages system has wide effects inside the engine, influencing game session configuration, savegames, multiplayer games, and the UI.

The updated Readme covers most of the new stuff, so that is ...

Memory savings and metadata cache

skyjake — Thu, 16 Feb 2017 08:44:02 +0000

This is a blog excerpt. http://dengine.net/blog/2017/02/memory-savings-and-metadata-cache/"; target="_blank">Read Full Article

http://files.dengine.net/builds/build2237">Build 2237 introduces a number of changes aimed at making Doomsday launch faster and use less memory overall. It also fixes a couple of threading issues that were found with the help of http://clang.llvm.org/docs/ThreadSanitizer.html">Thread Sanitizer.

As part of preparing the stable 2.0 release, I've been looking at performance and memory optimizations.

Trimming memory use

I examined memory use in Instruments on macOS and identified a number of places for savings:

There is now a http://source.dengine.net/apidoc/sdk/classde_1_1_pointer_set.html">purpose-built class for keeping track of observer relationships between objects. There are hundreds of thousands of these being used in the engine, so using a class that is more optimal for the task saves both memory and improves performance.

Some objects had a lot of observers (20,000+) but worst of all, this was completely unnecessary because the observers were never being notified. These cases have now been removed.

Reduced memory used by Doomsday Script bindings for file system access by removing several unnecessary variables and replacing them with callable functions. This saves memory because functions can be stored in the class objects rather than in the objects themselves.

The file system caches uncompressed ZIP file contents in memory to avoid repeatedly decompressing them when the ZIP is being accessed. However, these cached contents were never released. Now ZIP caches are freed from memory whenever you return back to the Home screen.

After all these changes, Doomsday's memory use on my system was roughly halved (from 830 MB to 460 MB). In practice, though, this heavily depends on how many resource packs and other data files you have available.

Caching metadata

When Doomsday is starting up it indexes and quickly analyzes all the resource packs, add-ons and other data files that you may have available. This may take a while depending on the number of these files and how fast your hard drive is. Starting with build 2237, Doomsday is now able to cache this information for future use, so after the analysis has been done it doesn't have to repeated until the files change or new ones are added.

Improved UI for multiplayer

skyjake — Mon, 06 Feb 2017 10:49:51 +0000

This is a blog excerpt. http://dengine.net/blog/2017/02/improved-ui-for-multiplayer/"; target="_blank">Read Full Article

For the past two weeks I've been focusing on finishing the Home UI for 2.0. I've also been doing plenty of small improvements and bug fixes.

The final element that has been missing from the Home is the Multiplayer tab. That is now no longer the case: http://files.dengine.net/builds/build2227">build 2227 has a new UI for viewing server information, and a couple of important bug fixes for multiplayer servers.

Server info dialog

In the Multiplayer tab you can see more information about a server by right-clicking it or by clicking the […] button in the server description. This pops up the new dialog that can be seen in the screenshot above.

A direct connection to the server is automatically attempted so that you'll see the server's current status and to verify that the server is reachable. The status information includes the current map outline, just like in the Shell.

In addition to status information, the dialog has a “Join Game” button, a list of the packages loaded on the server (the client must load the exact same ones when it connects), and you can choose additional packages to load locally. These local packages are game-specific rather than server-specific and are remembered in the client configuration (part of persist.pack). The “Local Packages” button is disabled by default. It can be enabled in Network Settings.

Note that if you load additional local packages in multiplayer games, you must ensure that they don’t contain gameplay-affecting changes. For example, loading a different map is out of the question, as are changes to mobj states. Doomsday 2 packages with 3D model assets are safe to use locally in multiplayer games.

I now consider this UI, along with the rest of the Home, feature-complete for 2.0. The long-term thinking behind the server info dialog is to evolve it toward a mini-Shell interface so that you could issue quick console commands to servers that you control. That will not be part of the 2.0 release, though.

Version 2 multiplayer servers

skyjake — Mon, 14 Nov 2016 10:22:27 +0000

This is a blog excerpt. http://dengine.net/blog/2016/11/version-2-multiplayer-servers/"; target="_blank">Read Full Article

Yesterday I merged a work branch where I've revised the way information about multiplayer servers is stored and distributed. The changes from “mp-serverinfo” are available in http://files.dengine.net/builds/build2144/">build 2144.

There are some important changes to discuss. Doomsday 2 servers are now incompatible and separate from Doomsday 1.x servers. Doomsday 2 uses a new status information format, new master server web API and new, compressed LAN broadcast messages. Doomsday 1.x clients will therefore not detect Doomsday 2 servers, and cannot query information about them (and vice versa).

Segmentation fault on run

adomas — Fri, 25 Nov 2016 02:24:02 +0000

Hello,
I am running Arch Linux x86_64 and I have compiled last source code for Doomsday 2.0.0 using cmake. Everything went as usual. When I try to run doomsday in terminal I get this log:

[adomas@genesis doomsday-2.0.0-build2153]$ doomsday
000.029    (i) Application path: /usr/bin/doomsday-2.0.0
000.029    (i) Build: 2.0-Unstable [#2155]
000.056        Created a new 32.0 MB memory volume.
000.166 R      Identified 281 data bundles in 0.0 seconds
000.344    (i) Executable: Doomsday Engine 2.0.0 (Unstable 64-bit +D +R) Nov 25 2016 01:13:22
000.344        Command line options:
000.344          0: doomsday
000.347        [RenderSystem > PackageLoader] Loading shader definitions from archive entry "renderer.pack/shaders.dei" from
                                              archive in "(basedir)/net.dengine.client.pack"
000.358                                       Loading shader definitions from archive entry "renderer.pack/lensflares.pack/
                                              shaders.dei" from archive in "(basedir)/net.dengine.client.pack"
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
000.553 I  (i) [Joystick_Init] No joysticks found
Segmentation fault (core dumped)
[adomas@genesis doomsday-2.0.0-build2153]$

All I get is flash of splash screen for a second and bam, seg fault. Tried binary version from AUR but same issue. I have NVIDIA GPU with proprietary drivers installed. Any idea how to solve this?

Improved UI for packages

skyjake — Wed, 18 Jan 2017 22:04:15 +0000

This is a blog excerpt. http://dengine.net/blog/2017/01/improved-ui-for-packages/"; target="_blank">Read Full Article

For the past week I've been finishing up with the Home UI for the 2.0 release. The Packages tab has gained a lot of useful functionality.

Package popup

The Packages tab helps you browse and manage your PWADs, add-ons, resource packs and other data files (all of which are called “packages” in Doomsday 2). http://files.dengine.net/builds/build2208/">Build 2208 introduces a new UI for viewing information about packages and performing quick actions on them. Like the game tabs, I consider the Packages tab now feature-complete for 2.0.

The new package info popup has the following features:

The popup can be quickly opened by right-clicking a package in any Packages list.

There is a convenient “Play in…” button for quickly loading the package in an existing game profile, without making any permanent changes to profiles. This works great for quickly trying out PWADs, for example.

The “Add to…” button lets you add the package to any existing game profile.

The “Show File” button opens the folder containing the package in Windows Explorer / macOS Finder / etc. (This may not be very helpful if all your data files are lumped in a single folder.)

The “Options” button allows selecting from the optional .box contents. It was relocated here from the old context menu that no longer exists.

A little bit of content analysis is done on the package:

Doomsday tries to guess which game the package is for, looking through any auxiliary readme files, the used WAD map format, Snowberry metadata, names of parent folder(s), etc.

In the case of WAD files, the game title picture is shown in the popup as the package icon.

If the package contains an “icon.jpg” (or “icon.png”) file, it is used as the package icon image. Currently these images are only displayed in the popup.

Holiday update

skyjake — Fri, 23 Dec 2016 11:48:44 +0000

This is a blog excerpt. http://dengine.net/blog/2016/12/holiday-update/"; target="_blank">Read Full Article

As usual December has been a busy time, but a little bit of progress has been happening with Doomsday, too.
Saving 3D model state. I've put the most effort into ensuring that the state of 3D model animations gets saved and restored when writing and reading savegames. This has no bearing on gameplay as such, but visually it is pretty important that the objects get rendered the same way before and after loading a save. In practice, this was quite challenging because the new model renderer supports advanced features like multiple animation sequences, scripted rendering passes, and shader variables. All this ...

UDMF experiment, Shell game options, installer facelift

skyjake — Mon, 21 Nov 2016 19:30:27 +0000

This is a blog excerpt. http://dengine.net/blog/2016/11/udmf-experiment-shell-game-options-installer-facelift/"; target="_blank">Read Full Article

Last week I went on a brief modding tangent and added a plugin that loads UDMF maps.

UDMF is an attractive choice for map editing due to its flexibility and potential to be widely compatible with map editors and source ports. However, it is basically only a syntax for describing map data; the real trick is interpreting the contents and supporting all the required gameplay logic, line and sector specials, etc. Doomsday at the moment supports only vanilla maps with a couple of Boom features. The new UDMF plugin also doesn't yet transfer all the data to Doomsday, for example most line flags are ignored.

When it comes to extending Doomsday's support for modding, I view full Boom compatibility as the first milestone to reach. Modding is on the roadmap for the future http://tracker.dengine.net/versions/53">2.4 release, so in the near future the UDMF importer plugin remains an experimental feature.

I also did many small improvements in preparation for the http://tracker.dengine.net/versions/3">stable 2.0 release.

Tightening all the screws

skyjake — Sat, 05 Nov 2016 21:10:57 +0000

This is a blog excerpt. http://dengine.net/blog/2016/11/tightening-all-the-screws/"; target="_blank">Read Full Article

For the past week I have been exclusively focusing on optimizations.

Work in the 2.0 unstable builds has been progressing without much attention having been paid to performance profiling. However, it has become clear that even in very basic maps (like Doom E1M1) there were unacceptable FPS dips. I decided to get to the bottom of what was going on.