Can we retire the GitHub wiki?

[dgelessus]

It would be nice to have one fewer place to search for documentation. The GitHub wiki currently contains only four pages, all of which fit well elsewhere, where they would be more discoverable:

• "CMake Flags" could go in the repo itself (in the README or under Docs) or in the build instructions on the website. Done in Move some wiki pages to Markdown files under Docs #1922.
• "Preferred Code Style" could also go in the repo. Done in Move some wiki pages to Markdown files under Docs #1922.
• "Roadmap" is a list of long-term development plans. The page already says that we want to consolidate that in GitHub discussions, so we could go through the list and create a discussion (or issue) for each point that doesn't already have one (and is still relevant).
• "Home" contains a list of "Archived Code Additions/Utilities", last updated in 2012, which links to a couple of old pull requests that weren't merged at the time. I don't think these are relevant anymore. Should we simply remove this list? The PRs themselves will still exist, so no information is lost.

After moving the content, the wiki pages could be replaced with a link to the new location, along with a clear statement that the GitHub wiki should no longer be used. (Or the GitHub wiki feature could be disabled entirely, if breaking old links isn't a concern.)

Does this sound like a good idea?

[colincornaby]

I've been thinking about this in relation to the AI policy discussion that I think is upcoming. (Or in progress?) I think it would be nice to avoid sudden and unexpected large PRs by communicating the state of the project, architecture decisions, and where we'd like to see things go.

Maybe Discussions are a good medium for that. I don't know where long term architecture docs would go. I haven't used the Wiki so I don't have a strong opinion about it. But whatever we do - it would be nice if we were more organized about docs.

[Hoikas]

That sounds good to me. I think the roadmap in the wiki is somewhat stale anyway, and the archived PR list can probably just go away.

[dgelessus]

Looking over the Roadmap, most items already have an associated issue or discussion. Among the rest, there are a few items where I'm unsure if they're still relevant:

• Fix warnings from Coverity code analysis.

Does H'uru still use Coverity? I see somewhat recent PRs (from 2021) referencing it, but can't find any configuration for it.

• Improve rendering efficiency
  • Avatar skinning and shadows (Improve shadow efficiency #113) are factors here

The last comments in the linked issue sound like shadow performance is less of an issue now. I also know that @Hoikas did some optimizations related to avatar skinning. Does that mean this point is resolved, or is there still more to be optimized?

• Replace Ogg Vorbis with Opus for audio files.

Is this still a goal? What would be the benefit of Opus over Ogg Vorbis, and would it be worth the necessary tooling changes and extra work for age builders?

• Other Quality of Life improvements

This is very generic. It seems that this was a list with sub-items in the past, but after the last item ("Windows DPI scaling") was resolved, it's been empty. I guess this can simply be deleted?

[Mystler]

While i love opus, i don't think it's worth worrying about converting all existing content. Do we already support opus files for age audio? (I haven't followed if more work was done on that while i was inactive.) I think supporting it as an option for the future might be neat goal if people want to use it for new files. I wouldn't worry about existing files though.

[dpogue]

Opus is used for voice chat and movie audio. I don't remember if there was a particular reason we were thinking it would be worthwhile moving the game audio over or not. I guess it might be very slightly smaller for compressed data downloading?

[Hoikas]

Does H'uru still use Coverity? I see somewhat recent PRs (from 2021) referencing it, but can't find any configuration for it.

IIRC @zrax would manually upload builds to Coverity, and only maintainers could see the report. At this point, it would probably be better for us to improve our static analysis and test posture in general instead of specifically calling out Coverity.

• Improve rendering efficiency
  • Avatar skinning and shadows (Improve shadow efficiency #113) are factors here

The last comments in the linked issue sound like shadow performance is less of an issue now. I also know that @Hoikas did some optimizations related to avatar skinning. Does that mean this point is resolved, or is there still more to be optimized?

There are still some things to be done there. For example, our FPU implementation is significantly worse than the original source drop - the regression fixed in #1907 caused jitter in the framerate due to the SSE3 path not being taken. I disassembled the code and found the memcpy calls are actually function calls, which is probably the culprit. Further, the SSE3 code should probably be rewritten to SSE2 to avoid the penalty on the haddps instruction. There's also open questions around a compute shader being used in modern graphics APIs to do this.

• Replace Ogg Vorbis with Opus for audio files.

Is this still a goal? What would be the benefit of Opus over Ogg Vorbis, and would it be worth the necessary tooling changes and extra work for age builders?

I would drop this. Opus is a much more efficient codec than Ogg, but all age creation tools basically depend on the artist to provide an ogg file for the game.

• Other Quality of Life improvements

This is very generic. It seems that this was a list with sub-items in the past, but after the last item ("Windows DPI scaling") was resolved, it's been empty. I guess this can simply be deleted?

Nuke it.

[dgelessus]

Thanks for the info. I've now removed the old roadmap items and created tracking issues for the items that didn't have an issue yet - except for the avatar skinning one. @Hoikas Could I ask you to copy your above explanation of the avatar skinning stuff into an issue, so I can link to it?