v1.6 roadmap

[Lgt2x]

As v1.5 is about to be released, we're looking for new ideas and suggestions for the next version of the Descent 3 engine!

Now that the game is more stable, we can start incorporating new quality of life features not originally in the main game.

Some developments are already ongoing or planned:

• Renderer rewrite, to get rid of legacy OpenGL code in favor of more modern OpenGLES3-compatible shaders. See draft implementation in Modernize Renderer #527
• Support for higher screen resolutions ([Feature Request] Support for 1080p and Higher Resolutions #205)
• Localization support enhancements (Reactivate and enhance localization support #505)
• Use XDG/Standard directories for user game data ([Feature Request] Linux: use XDG directories #373)

What would you like to see implemented in the next release of the engine?

[JeodC]

I would like to see more Piccu QoLs imported, such as the new resolution picker in options. I would also love to see complete controller compatibility: true xinput and the ability to play the game and set config options using only a controller.

[Lgt2x]

Let's use #205 to track resolution-related features. I've open #536 for controller support.

[dutenhnj]

A better resolution picker would be good, other graphical features that would be nice to see in a roadmap (if not 1.6) would be in-game control of basic anti-aliasing and anistrophic filter support instead of how we have been using driver overrides for the last 25 years, maybe eventually including support for FSR/DLSS/XESS (or their native resolution TAA implementations at least). And related to the resolution picker; high resolution menu/automap instead of them always kicking back to 640x480.

[tophyr]

It's not a very "sexy" project, but telemetry (for crash reporting, at a minimum) would be extremely helpful. I know there is a lot of concern around user privacy and avoiding even the impression of violating that, but I feel fairly confident that we could come up with some opt-in mechanisms that would provide a lot of value.

[Lgt2x]

I'm afraid this will not happen. I understand why telemetry is used in corporate logic, to retain more customers, measure app/site usage, improve metrics, but it does not apply to open source apps and games. In addition to privacy questions, I don't think usage data is relevant to the project. If players are interested in a particular game mode or feature, it is way better for them to ask for it in this roadmap thread than being spied on by telemetry software.

For crash reports, we could display a message "Oops, your game crashed!" with a link to Github issues for easy reporting.

Also keep in mind that for effective telemetry, we need to either have an infra to deploy a server, or rely on a 3rd party website to collect it for us. Both options are not great.

[SiriusTR]

Automatically saving crash dumps and pointing out the location would be almost as good - it is something I wish I had in the D1/2 Redux project :)

[tophyr]

Automatically saving crash dumps and pointing out the location would be almost as good

This is primarily what I'm imagining - crash reports are what I'm interested in, not usage data. Minidumps that get written out at crash time, and then an uploader tool that runs either post-crash or at next game startup. Reporting infrastructure is definitely something that would need figuring out; I don't know what data ingestion/storage mechanisms are available with GitHub and a 3P solution would definitely be non-ideal.

[tophyr]

I am planning to create Apple Developer accounts so that we can sign the MacOS builds, which would be another great thing to get in for 1.6.

[Lgt2x]

As discussed on Discord, Apple Dev accounts need to be attached to an entity or a person, so someone should bear the responsibility of the Apple dev account. Should we open a tracking issue to discuss that?

[tophyr]

Opened #540 for this.

[3doplayer67484]

Some DirectX renderer features added to the new renderer to make the game look the best it can be

[tophyr]

What new graphics features specifically?

[tophyr]

Another one: Before we get too far along in any other PRs, we should aggressively clang-format and clang-tidy the repo. The formatting diff should clearly specify the tool versions and commands used, so contributors can run the same command on their PRs to prevent merge conflicts.

[Lgt2x]

clang-format and clang-tidy are 2 separate things.

clang-format was run once at the beginning of the project, but has not been run again globally since. We dropped CI check to avoid bothering everybody with it. I planned to run it before the 1.5 tag, but I was afraid of causing large conflicts with #495 and #511 open. Once these 2 are merge I'll run clang-format (18)

Given the sheer of the code base, clang-tidy is going to take a lot of time to go through. Many people have helped solving warnings, and there are still a lot to process to get a warning-free code. clang-tidy would add yet another layer of warnings and code smells, but in the long run they would be worth solving.

[tophyr]

Is clang-tidy more a static-analysis/warning-generation tool than a "fixing" tool? I mentioned clang-tidy imagining that it could do things like transforming

if (foo) doSomething();

into

if (foo) {
  doSomething();
}

but if clang-format can do that, then happy days.

[Lgt2x]

clang-tidy can also fix some errors it detects, but you still need to be careful about what it does. I'm used to simply fixing clang-tidy warnings manually when there are not too many of them. It's worth running to see what it finds anyway!

[Lgt2x]

#619

[SiriusTR]

I'm not sure whether it'd be a 1.6 feature or more of a 1.7 or later, but some kind of 32-on-64 virtual machine for running scripts for backward compatibility with existing community-built levels would be important.

[tophyr]

As I understand it, @Lgt2x has some ideas on a WASM port of the game itself, and building levels scripts for WASM + embedding a WASM virtual machine into non-WASM platforms might be the best way to go for cross-platform level scripts. This would be a major lift, however.

[Lgt2x]

WASM is a compilation target, not a magical emulation tool. The challenge of running existing 32-bit level scripts is interpreting 32-bit "blobs" where we don't have the source A tool for that could be Box86, providing x86 emulation in x64 contexts. We need to figure out if it is portable enough to be used. Big challenge for anyone attempting this!

[tophyr]

Good point, I was picturing WASM as being kind of the "lowest common denominator" platform but it wouldn't help at all for running existing historical levels. Box86 looks pretty ideal for Linux and Android, and Mac ARM obviously has Rosetta. I would worry a little bit about iOS and WASM support, but both of those are theoretical platforms right now anyway.

Frankly, a bigger challenge for the existing Linux/Mac platforms may simply be that existing level scripts are DLLs - we'll have to figure out how to link them into an ELF/Mach-O process. I bet there are some WINE-esque tools we can use for that though.

[tophyr]

Bingo: https://github.com/taviso/loadlibrary

[Lgt2x]

#620

[sheepdestroyer]

VR / OpenXR support would be sooo great :D

[tophyr]

Hah, this is my primary goal. This will definitely not make it into 1.6 however.

[Renalicious]

First off, great work so far!! I love Descent 3, and it's SO nice to be able to finally play it on a modern computer (and OS) without "weird issues" :D

Some things that come to mind for updating the original engine is being able to push the options and settings past their current values. Things like forcing the terrain to render at maximum detail, pushing terrain draw distance further, forcing highest LOD for objects, more sounds being played at once (if that's even an issue?), etc.

Eventually it'd be great to improve the responsiveness of the UI like the main menu and auto map.
OpenAL EAX emulation?

Of course not losing compatibility with older hardware either, which I'm sure is not the plan haha. I have an old P3 533Mhz I'm hoping to bring back to life "soon", and Descent 3 is always high on my list of games I'm gonna play.

[Renalicious]

Another quality of life feature is an "autosave" at the start of each level for players who forget to 'save often', which also allows the level to be restarted with the full intro cutscene and music, and previous level's equipment.

[Lgt2x]

#621 opened to track the auto-save feature, thanks for the suggestion. The settings to improve graphics options will come as we improve the new renderer performance.

Eventually it'd be great to improve the responsiveness of the UI like the main menu
Does it feel slow to you? Maybe I'm used to it but it does not really feels like that to me :D

Sorry for your P3 533Mhz, we are only supporting 64-bit architectures now...

[Renalicious]

Just to get some clarity: is it still possible to create a 32-bit build locally with the existing source code? Or are there architectural / library changes that make it impossible to compile? Or at least unlikely to compile without significant rework, etc. Thanks!

[Lgt2x]

it may still be possible to build, but we have not made any effort towards keeping the 32-bit build in a functional state

[0xFADDAD]

With the move to SDL2, the issue of calibrating joysticks/joypads moves from the OS to the program, so being able to do this in-game would be helpful.
Not sure if the move has allowed it on Windows, but Linux allows the mapping of multiple joysticks axes and buttons, it used to only be the primary joystick as set in DirectInput.
In-game setting for AA/AF, as well as gamma correction from the Windows build to all targets would be a plus.
Also, the move to 64-bit broke a lot of community-made single player maps and multiplayer game types. I can understand if this never is addressed, but would be nice if there would be a path to recompile them on the off-chance the original author's still had the code to do so.

[Lgt2x]

#622 tracks joystick calibration, and #620 the 32-bit community-made maps. Thanks for the ideas!

[Lgt2x]

Thank you very much for all your ideas! I opened a few more issues tracking new ideas, please open more if I missed some. You can view the issues we plan to address primarily in the upcoming 1.6 version here: https://github.com/DescentDevelopers/Descent3/milestone/2

To make it short, 1.6 will bring better multiplayer and controller support, as well as graphical enhancements and improved user experience to finding game data files.

Feel free to help solving these issues if you are able to!

[DefectiveByDesign]

Fixing mouselook, and the FPS cap, is an obvious minimum requirement. The mouselook has a ticrate of around 25, and the game is capped to 50 FPS. This was always a bad design, since the standard monitor minimum refresh rate has always been 60hz, and the mouse ticrate breaks movement speed especially at higher FPS. Over 100 FPS, the mouse teleports around, and at 50 FPS the mouse DPI is unusable for precise aiming.

This is already fixed in the Piccu Engine, and is the only version with acceptable mouse look performance.

If you want to add QOL gameplay mechanics, I'd suggest looking at the whole inventory key mess, perhaps eliminating manual use of keys, and highlighting keys and objectives on the map after you roam the area. Descent 3 tried to turn the game into one of those point and click obscure puzzle mechanic games, and it wasn't fun. They even had a soft lock with the keys in 1.4, so you could have bugged out the game, and wouldn't know it.

Speaking of the map, I believe the map defaults to 640x480 or something, and it's pretty bad. It should match the screen resolution.

Fixing the graphics is just obvious. The Direct X version has the most graphics, but it also doesn't work. The lighting was better, the effects were better, there was optional bump mapping, and there was a special Pentium 3 particle effect locked behind detecting a real Pentium 3, which essentially disabled the effect for every CPU before and after Pentium 3. Piccu Engine fixes all of this except bump mapping. Version 1.5 already did a lot of work fixing the LOD system and 32 bit color, but I noticed the Z buffer was broken by default, clipping a lot of geometry. So Z buffer fixing is a requirement.

The more difficult fix would perhaps be the sound engine, because while descent 3 supported EAX, it was best played in A3D, which had raytraced audio effects. You can surpass EAX with OpenAL, but afaik the only audio API for raytracing is perhaps steam audio? IDK, OpenAL is good enough for most people. I've never seen anyone actually fix A3D, so I don't think it's easily done, or anyone has the motivation to do it. It's likely easier to add raytracing to EAX, and the default OpenAL port is good enough.