lucius

I think you meant the way Dark Forces handles states... but yeah, that is an issue. The plan is a two-pronged approach: * Expose the hardcoded data as external text files and allow those to be overridden. This will already allow a lot of options given the modular way that Dark Forces handles "logics" (behaviors). This will also allow for weapons to be changed, items to be changed, etc. * Support scripting and expose the ability to add new behaviors through scripts as well as using the built-in behaviors. Scripting support is already in the engine to some degree, but it isn't exposed yet to modders.

I have not posted in this thread for some time, but TFE has continued development. I posted a 2023 Retrospective and 2024 Plans post on the blog - https://theforceengine.github.io/2024/01/01/2023-Retrospective-2024-Plans.html - that summarizes the year and plans for 2024. The TFE built-in level editor has also made a lot of progress, as seen in these videos I recently posted:

That looks like a 2D interior distance field (aka distance to the closest wall at any interior point). What is the intended use?

The reason that Dark Forces feels a bit like a Build engine game is they used portals in a similar way (called adjoins in Dark Forces) - so they could have overlapping sectors, as well as moving and rotating them. The core tech is pretty different though and is, in some ways, less limiting (fewer arbitrary limits) but also with fewer graphical features (no slopes, for example). Though the engine could support 3D models with arbitrary orientation, basic 3D model animations, secondary fire modes for some weapons, etc. - so it did have some features that DN3D did not.

I have tried the "all in one" engine thing myself - and it is a bit surprising how little can be shared between similar FPS games. Obviously, if they use the same engine, that helps a lot (see Doom source ports that support Hexen, Heretic, etc. or even TFE in the future with Dark Forces and Outlaws). But beyond that, if you want to accurately represent the game and its quirks, the best you can do is share the framework - like Nightdive does with Kex. And really, if all you are sharing is the framework it seems you are better off with separate projects that share libraries or code so you can just take what you need and avoid bloat. Often, based on the capabilities of the game, you will want to customize your application anyway. That is how I feel about it now anyway, though my opinions a decade ago were obviously different. :)-

I have considered an "XnGine" project - similar to TFE. The goal would be to support all XnGine games (over time), rather than just Daggerfall. That would allow me to start with something simpler, like FutureShock (which I also really like) rather than jumping straight into maximum complexity. That said, it is currently just an idea. My focus will remain on TFE for quite some time yet, since I still need to finish Outlaws support and version 2.0. I don't plan on taking on any large projects until TFE version 2.0 is out and development is stable (aka in a maintainable state). It will depend on how well TFE is doing, when I want to jump onto another large project, and whether people in general would even be interested (especially with Daggerfall Unity). Though I think there would still be a fair amount of interest in other games, like Future Shock, so that last point is probably less of a concern. Ultimately I have learned to keep scope manageable for these types of projects and avoid taking on too many projects at once, or they don't get done (which is a really common issue).

That is correct and is the approach I took. I put this in the FAQ in case anyone had concerns about using contributor work or assets, which would obviously require permission from said contributors.

Nightdive seems to be genuinely interested in working with fan communities when possible. Unfortunately, that isn't always possible due to the mandates of the client or publisher.

In case anyone is interested in how the Dark Forces Remaster affects TFE, I am double-posting this here: As many of you have seen, Nightdive has announced their Dark Forces Remaster. They have partnered with me to help them in a technical advisory role to help with the project, which includes exchanging information and providing some TFE code. So I have written a FAQ to answer likely questions. https://theforceengine.github.io/2023/08/22/Nightdive-Remaster-FAQ.html

As many of you have seen, Nightdive has announced their Dark Forces Remaster. They have partnered with me to help them in a technical advisory role to help with the project, which includes exchanging information and providing some TFE code. So I have written a FAQ to answer likely questions. https://theforceengine.github.io/2023/08/22/Nightdive-Remaster-FAQ.html

Thanks everyone. :) There has been a small point release (1.09.41) that fixes a few issues with version 1.09.4. You can find it at the same download link: https://theforceengine.github.io/downloads.html Now that this release is out of the way, I'm focusing on the next release - version 1.09.5 (see the blog post for more details about upcoming plans).

Version 1.09.4 has been released, read the blog post at https://theforceengine.github.io/2023/07/31/Version-1-09-04.html. Example from the post - bloom with different strength and spread settings. (Top left: off, Top right: default, Bottom left: high strength; Bottom right: high strength and high spread) Various different shots with bloom with different settings. 8-bit versus 8-bit interpolated comparisons. The 8-bit interpolated mode removes most of the banding while still using the color map - so colormap tricks used to emulate colored lighting and fog still work. And last but not least are the Smooth Vue animation feature and Closed Captions as well, see the blog post for animations and also for more and better quality images: https://theforceengine.github.io/2023/07/31/Version-1-09-04.html

The TFE hardware renderer also handles sprites vs floors/ceilings, using the z-buffer and without using an extra buffer or stencil buffer with very good performance (with support for looking up and down with proper perspective). But it was part of the core design of the renderer and would be difficult to shoe-horn into something like GZDoom without serious compatibility and performance issues since it relies on the way sectors are rendered in Jedi (such as the way walls a clipped and sorted).

For a modern sector engine - if you remove the need to support fully 3D overlapping sectors, then you can use portals for culling and depth buffer for floor/ceiling/wall rendering. TFE actually supports both depth buffering[1] (sector geometry writes to the depth buffer only, sprites and 3D objects read and write) and proper sprite/flat sorting. This is done by generating flats by extruding walls vertically + adding a cap to fill holes and projecting the positions onto the planes in order to generate texture coordinates, determine z value for shading, etc.. Because TFE uses GPU clip planes[2], then by projecting the view to infinity, clamping to the cap planes, quads converge to "infinity" allowing for accurate caps with no triangulation. Once the player leaves the sector, quads that would extend outside are clipped by the GPU clipping planes. Anyway, the largest complexity comes from the need to support overlapping sectors in 3D - which means that full portal clipping is required[3]. For TFE this is done in two phases, 2D on the CPU (top-down[4]) and 3D on the GPU (replaces the column heights). But without that, a simple depth buffer would suffice on its own, though you lose some occlusion culling power and will get some overdraw. So for pure software rendering, you will have to weigh the benefits of increased overdraw over the simplicity of the algorithm. For GPU rendering, it would be a clear and obvious win - especially since you can easily draw front to back and make use of hardware hierarchical z-culling. [1] Jedi actually uses a 1D, column-based, z-buffer for object clipping. So TFE just extends that concept to 2D to support proper perspective when looking vertically. [2] A large buffer of planes get filled in during render setup, where each draw-item has an offset and count to reference the plane table to avoid splitting up batches. [3] Jedi doesn't clip against the portal plane correctly - and the game makes use of its quirks. But other planes are clipped correctly. [4] CPU "wall segment" clipping is required for proper sprite and portal clipping later on to match vanilla behavior. This does allow for fully occluded sprites, 3D objects, and portals to be discarded (occlusion culling).

Generally, it isn't useful for a runtime to support a million different formats. Pick a few formats that provide everything you need and have tools do the conversion from the many formats that are out there. Otherwise, you are increasing the maintenance cost and code size for almost no benefit.