Project status?
Hey guys. o/  Seriously?  I didn't have an account on here yet???? Tongue

I was wondering if there was some kind of project status site for Rebirth?  I am curious what the roadmap looks like for 0.60 and beyond (I see SDL2 is happening, sweet!).  Is that kind of information public anywhere?
Most of it's in my private notes or in my head. You're the first person to ask about it in a long time, so I haven't been keeping public records. As a quick summary:
  • 0.60 is not getting any new feature work. All new features and big changes go into master, which will be 0.61 and beyond.
    • 0.60 could probably be released any time a release manager shows up to make binaries for it (Windows and Mac at a minimum; Ubuntu packages would be a nice plus). I don't publish Windows builds and cannot create Mac builds. I've historically rationalized this on the basis that I do practically all the development work, so farming off some administrative work to other people seems fair to me.
    • There are a few pending bug reports (most notably, the newly reactivated thread about some Windows 10 users getting a hang on startup), but it seems to be in good order overall.
    • 0.60 gets bug fixes when I fix a problem that I think users will notice, which includes anything that users reported as a bug in either branch, and also some fixes that I happen across in the course of other work. It doesn't necessarily get subtle fixes (such as the Buddy_gave_hint_count bug) if the fix doesn't cherry-pick cleanly and isn't likely to be noticed by users.

For longer term goals:
  • Reorganize data structures to reduce use of globals. Users won't notice this until new features based on it get published, but you can see a lot of churn in the source. This reorganization serves several purposes:
    • It makes an eventual file format redesign more straightforward, by making it easier to see what needs to be saved/loaded/reset when processing a new file (savegame, level).
    • It clarifies data flow. Would you have expected that drawing part of the level can change the texture on a wall? I didn't, but that's something the old renderer could do.
    • If I get really ambitious, it could facilitate holding more than one level in memory at once. If I ever get to that point, a variety of interesting possibilities open up.
  • Clean up or abandon the existing file format parsers. There are too many ways for an ill-formed file to bring down the program completely, even when it should be possible to back out and tell the user that the file is broken. I probably can't abandon the existing level parsers, but I might get away with deprecating them and encouraging people to write new levels in a more extensible format.
  • Overhaul the demo/replay system. The existing demo format is horrible. I probably can't remove the existing parser since people are likely attached to their old demos, but I very much want to make an extensible replay system that is more flexible than the existing demo system. This has never been a high priority for me though, and there is quite a bit of other work that is more important.
  • Fix the minor remaining issues with SDL2, then declare it preferred. I think all the known SDL2 bugs are publicly documented in the Issue Tracker on Github. I'm not holding anything back in my private records here.
    • Decide what to do about SDL-only (the no-GL build). I accidentally broke it when I enabled SDL2, and nobody's remarked on it yet. It's been broken for months now and nobody seems to care. Scrapping this would enable some major OpenGL-related changes elsewhere. If I restore SDL-only support, then certain things that don't make sense for modern OpenGL need to be retained to keep SDL-only working. Otherwise, I can discard things that modern OpenGL doesn't need.
  • Resurrect my old branch of kconfig rewrites, with an eye toward better input handling. SDL2's joystick changes may require some redesign in this area to improve the user experience.
  • Resurrect my old branch of observer support. The UI was never finished, so people can't actually use it yet.
  • Consider multiplayer handling. I've been tempted for a long time to switch it to be TCP-based so that all the flow control can be delegated down to the OS. However, users may have become accustomed to the benefits and quirks of UDP. (In particular, the tracker's hole punch feature can't work reliably with TCP.) Many people, including me, would also need to update their port forwarding rules if I switched to TCP.
  • Resurrect (or at this point, probably rewrite) my old branch of enhanced developer tools in the engine.
  • Consider switching to a proper parsing library for data persistence. Most of it right now is based on printing out strings and parsing them back in by hand. Among other things, this leads to the annoying bug that Retro deletes post-0.58.1 settings from configuration files and Rebirth deletes Retro settings from configuration files, because both games ignore fields they don't understand, and write back only what they did understand. (Also, 0.58.1 deletes post-0.58.1 settings, but that doesn't bother me as much, since the only reason anyone should be running 0.58.1 era code is if they are using Retro. Anyone who wants to use Rebirth should be on much newer code unless they're hunting down regressions.)
    • This would also simplify saving new user settings, and provide a smoother path for adding settings that need to default to enabled in order to avoid surprising user regressions. (For example, if I add a toggle to let the host purge vulcan ammo from the level, it needs to default to not-purge, since old builds never purged and users would be surprised if upgrading caused purging-by-default.)
  • Fix some of the layering violations in the engine. Would you believe that loading a level can redraw the screen, but only if you're in multiplayer? It does. Would you believe that redrawing the screen advances the game simulation if the main game window is visible, but not if the main window is hidden? It does. Those two quirks combined to cause a nasty bug, but only if you died in multiplayer while the reactor countdown was running. Dying in single player was OK. Dying in multiplayer while the countdown was not running was OK.
  • Review Retro changes for anything that should be brought back into Rebirth. This has been low priority for a long time, and is a bit quirky now that Rebirth was relicensed and Retro was not. In light of that, I feel more pressure not to use the Retro implementation unless the respective authors specifically submit it for inclusion in Rebirth. Even before that, teasing out Retro features from reviewing its commit log was a bit frustrating. I got the sense that the people writing those changes weren't too concerned with making them easy to review in isolation (looking only at the commits, without access to whatever community discussions prompted the change). I'm still not opposed to bringing in equivalent functionality. For places where Rebirth and Retro will never agree on how a feature works (e.g. I doubt Drakona and Zico will ever agree on homing weapons - I'm not sure anyone will ever agree on those, actually), I'd like to have both implementations in one source tree, with a build time switch, so that the disagreement doesn't require other code to drift. While I don't have much hope it will ever happen, I've always wished Retro would rebase forward so that Retro users could benefit from post-0.58.1 changes in Rebirth.
Wow, this is a lot of info, thanks a ton. Smile  A few questions, comments, and other musings:

Is the 0.60 stable branch the correct branch to look at for the 0.60 release code?

"Would you have expected that drawing part of the level can change the texture on a wall?"  Oh yes, Retro ran across something similar using a global rather than a parameter to a function, which resulted in fun effects such as energy powerups having an odd flash in their animation.  There's little I don't believe anymore when it comes to the Descent source code. Smile

Regarding your old branch of observer support, is that separate from Jinx's observer mode (which is now in Retro's source)?  If it's different, I'm somewhat curious as to how the implementations might differ.  Jinx's, for instance, slots all observers into player ID 7, rendering that unusable for actual play... and makes hosting while observing impossible.

"Even before that, teasing out Retro features from reviewing its commit log was a bit frustrating.  I got the sense that the people writing those changes weren't too concerned with making them easy to review in isolation"  You're telling me! Smile  The first three commits on Retro are essentially, "Here's Rebirth 0.58.1", "Let's update some READMEs a bit", and "Here's Retro 1.2.6!"  Trying to figure out everything that got added and updated serially will be a daunting task.  I know the big stuff... ie: sniper packets, homing missiles... but not the details.  For reference, I started working on Retro after 1.4x3, or around the time of the 20th anniversary LAN.

"I doubt Drakona and Zico will ever agree on homing weapons - I'm not sure anyone will ever agree on those, actually"  People still don't.  There's other frame-dependent issues as well, such as fusion shake, AI movement, AI pathing garbage collection, reactor-player detection, non-moving projectile deletion, and something called "obsolete stuck objects" that I haven't bothered to figure out what they are yet. Smile

"I'd like to have both implementations in one source tree, with a build time switch, so that the disagreement doesn't require other code to drift."  While that would certainly be good from a development perspective, I think it would be a long while before Retro would be willing to even consider that.  However...

"While I don't have much hope it will ever happen, I've always wished Retro would rebase forward so that Retro users could benefit from post-0.58.1 changes in Rebirth."  ...this would be the BEST place to start.  One of my pipe dreams is doing a Retro 2.0 that properly bases itself from Rebirth 0.60 for the very reasons you suggest, pushing the updates to Retro players.  I don't know if that's something I'd be willing to do (not because I don't want it to happen, but rather because of the massive time committment that would entail).
Yes, stable-0.60.x is the source for the 0.60 betas, and is where I expect the 0.60 release to come from. (Aside: I never asked for write access to anything on the domain, so I can't post Windows binaries here even if I wanted to deal with that.)

Yes, it was completely independent of Jinx's work. I never looked at his. My implementation makes observers invisible/immaterial (like they used the ghostphysics cheat, but with a secondary hack to prevent them accidentally exiting the level prematurely). It isn't identifier locked, but does consume slots on a 1-for-1 basis, so you get at most 8 humans in a game, with any combination of combatants and observers you want drawn from that set of 8.

Cleaning up all the frame-locked logic is another thing I'd like to see done, but I'm reluctant to even put it on the roadmap with all the other big projects sitting there.

Stuck objects is something I looked at within the last few months. It refers to flares (and anything else with PF_STICK, but I think just flares) that were set to zero speed and not deleted when they hit a door. Obsolete stuck objects deals with flares that are stuck in doors that have opened, so the flare just hangs in the air where there once was a door to support it. I eliminated that logic and prune the flare when the door opens instead of trying to garbage collect the flares later. I think that old versions of one of the engines had a theoretical bug with obsolete stuck objects that could let it delete things that weren't actually stuck flares.

Yes, rebasing Retro would likely mean rewriting most of its changes on top of a current Rebirth branch. That is a significant task on its own, and is likely made harder by the lack of good information explaining what you should change and why. Even ignoring the file reorganization, I'd be surprised if any non-trivial Retro changes still applied to the Rebirth source without manual fixups. Too many lines have been touched since then. If you want to try it, start small and keep your commits easy to read. That will make it easier to maintain them long term.
It sounds like your observer interface more matches Descent 3's paradigm than Jinx's. That's not a bad idea, and was probably easier to implement netcode-wise. In Descent 3 that worked because of the 32 player limit, but in D1 the downside will be that if you have many observers, you can't have a big anarchy game.

The frame-locked stuff is a nightmare, and what's worse is that people don't agree on it. A few people in the DCL community would love to see fusion shake returned to how it was in the old days, ie: more shake. But there's no agreement on whether this should be done at all, or even how.

Another stuck object issue that happens occasionally is fusion getting stuck on walls. You can even run into it and take damage, it's annoying. I've never seen stuck flares on open doors though.

One of the challenges for me working on Retro is that I have vastly more git experience than Drakona does. There's been times she's managed to completely overwrite some of my changes on accident, no attempt at a merge. I actually keep my work in a separate repository (roncli/DXX-Retro, not considered production-quality code!) and then merge it back to the main repository when I've completed a feature or a full version.


As for Retro... since Drakona's been on hiatus with new family, it's pretty much been just me, with Sirius helping port the observer code to Descent 2. And I also have a number of other projects going on, including the Overload Teams League (, The Observatory (, out of date by about 2 months, I should probably fix that soon!), and my own streaming endeavors (, so I'm not always working on Retro.

The current goal is a full 1.4 release, and that release is to include a complete observer mode for both D1 and D2, along with a new game mode for D2 we're calling "Capture the Flag Classic", another of Jinx's ventures. This is basically D3's version of Capture the Flag.

We're currently putting a ton of polish on observer mode. The current interface you see on The Observatory has been overhauled to provide more information, with each bit of information available fine-grained in observer options. We already have some stats including streaks and runs, time since kills/deaths, a kill feed (similar to Overload's), and a graph of kills that appear at specified intervals (shows when someone reaches a multiple of 5 kills for the first time, also in 1v1 shows after 20 kills because 1v1 games are typically game to 20 win by 2). We also have planned stats that show damage stats broken down by source... for 1v1 I'm going to add a "kill summary", and for all observer game modes we'll have an end of game summary as well.

CTFC should be rather simple, I plan on adding to the original CTF mode so that you can do either of them if you want. CTFC basically will take CTF and make some important changes: 1) Flags always spawn in your team's base, AKA the goal cube (Not sure if you can have multiple goals, but CTFC won't be compatible with that if so). 2) Outside of your team's base, your team can capture your own flag to reset it to your team's base. 3) You can only score your opponent's flag when your team's flag is in base. 4) Team scoring will be 1 point per flag, 0 points per kill. Individual scoring will remain unchanged (5 per flag, 1 per kill).

After 1.4 is fully released, I am probably going to stop working on that code base except for major bug fixes. At that point I'm not sure what I'm going to do next. Retro 2.0 *is* an option, so if I go that route I'll be sure to let you folks here know. Smile
Hello everyone,

I've been meaning to post a small update and this seems to be as good as place as any to do that.

I still don't have a lot of time these days, but I sure hope it's going to be enough to do some minor bug hunting/fixing and provide a new stream of weekly builds.
I am mostly finished setting up the environment for that and have started to do a minor reorganization of the site and fixing some things up. I'm still undecided to switch to another CMS (probably flat) to reduce maintenance, but that's a minor issue.

As of now I am planning to push a new weekly build next Thursday and hopefully continue in a weekly interval.
It takes some time for me to get back into this, especially mentally, but I am in good hopes.

Frankly, I am not sure what to do with the forums, however. It's been always a big time sink and I am not confident I will be able to spend a lot of time here. Additionally, I feel that bug reports may be best served on Github.
The greatest pleasure in life is to do what people say you cannot do.
Uhm... Honey, there's a head in the toilet!
I agree on bug reports. That being said, you should still come here more often or one of the Descent discords. It would be a blast to have you more socially active in the Descent community.
Do weekly builds include XP builds?
(05-24-2019, 03:03 AM)LightWolf Wrote: Do weekly builds include XP builds?

Officially, no. If the builds work on XP, great, but if not there is little I can do at this point, honestly with pretty much all the toolsets and libraries I use for Rebirth not being supported on XP anymore either.
The greatest pleasure in life is to do what people say you cannot do.
Uhm... Honey, there's a head in the toilet!
Small request: Is there no chance to get the Macplay cockpit installed without having a copy of Macplay? The GOG Mac version doesn't seem to include the original Macplay data, instead it seems to be a variant of the DOS version. And though the Shareware files contain the cockpit, that's just the first 3 levels.. hmm.

Forum Jump:

Users browsing this thread: 1 Guest(s)