Project status?
#2
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.
Reply


Messages In This Thread
Project status? - by roncli - 01-22-2019, 01:39 AM
RE: Project status? - by Kp - 01-22-2019, 03:37 AM
RE: Project status? - by roncli - 01-24-2019, 12:07 AM
RE: Project status? - by Kp - 01-24-2019, 03:13 AM
RE: Project status? - by roncli - 01-25-2019, 06:27 PM
RE: Project status? - by zico - 05-17-2019, 11:57 AM
RE: Project status? - by Blarget2 - 05-17-2019, 09:03 PM
RE: Project status? - by LightWolf - 05-24-2019, 03:03 AM
RE: Project status? - by zico - 05-29-2019, 07:59 AM
RE: Project status? - by Hunter - 05-29-2019, 10:55 AM
RE: Project status? - by Kp - 05-30-2019, 01:38 AM

Forum Jump:


Users browsing this thread: 1 Guest(s)