b2aad0a0fc
Significant changes include LDN functionality from @Vudjun (no more separate build!) and an XCI trimmer from @amurgshere. Merged PRs in this release (in the order they were merged): #183, #150, #105, #160, #188, #98, #158, #13, #216, #73, #217, #122, #228, #65, #226, #236, #247, #243, #249, #242, #260, #273, #272, #262, #259, #241 ## Versioning: There now exists "stable" (release branch) and ["canary" (master branch)](https://github.com/GreemDev/Ryujinx-Canary/releases) versions. Instead of everyone using the same emulator, getting updates for every code change, you now *opt-in* to the more frequent updates by using the Canary version. Use stable and you'll get about an update a week, but that update will be MUCH more significant as it's the entire previous week's changes & PR merges. ## LDN LDN functionality is now merged! Use [this](https://github.com/GreemDev/Ryujinx/wiki/Multiplayer%E2%80%90(LDN%E2%80%90Local%E2%80%90Wireless)%E2%80%90Guide) to get started. Please note that LDN is only for local wireless; **this is not a Nintendo Switch Online emulation feature**. ## UI - Added an XCI trimmer (#105). - You can use this feature to trim dead bytes & the embedded firmware out of your dumped XCIs, to make them smaller. - If you right-click an XCI and the trim button it is greyed out, that means your XCI is already as small as possible. - Fix for fullscreen not being really fullscreen (#150) - Fix window sizing calculations when Show Title Bar is enabled (#247) - The "Install/Uninstall file types" buttons will be enabled/disabled depending on which one you contextually need; install will be clickable when they aren't installed, and vice versa. - Fix for showing default config screen when swapping players in controller settings (#122) - Command-line argument to prevent update checking `--hide-updates` (#272) - # RPC: - Added a LOT of game images to Discord RPC. - Play time will now show the time unit hours at a maximum. ## Localization - Update outdated/incorrect & added missing translations for zh-TW (#158) - Add many missing locale strings to all languages (#160) - Update & improve Korean translation (#226) - Minor fixes & add missing translations to Spanish translation (#242) ## Headless - Added `ignore-controller-applet` as an option you can configure via headless command-line options. ## Graphics Backend - ### Vulkan - fix divide-by-zero when recovering from missed draw (#235) - fixes crash in 'Baldo: The Guardian Owls' opening cutscene ## Horizon - fix crash that occurs when launching an NSP forwarder generated by Nro2Nsp (#237) # Nerd Zone Slightly more technical information. If you don't understand what's under here, no worry. - Updater now uses the release's Tag Name instead of its Name for version checking. - Baked in value change logging into ReactiveObject. - Split ConfigurationState into 3, smaller partial classes of the same name. - Specify if the current version is Canary in the version log line --------- Co-authored-by: James Duarte <GarnetSunset@users.noreply.github.com> Co-authored-by: Luke Warner <65521430+LukeWarnut@users.noreply.github.com> Co-authored-by: TheToid <amurgshere@gmail.com> Co-authored-by: GabCoolGuy <gabrielfreville@proton.me> Co-authored-by: Kekschen <52585984+Kek5chen@users.noreply.github.com> Co-authored-by: WilliamWsyHK <WilliamWsyHK@users.noreply.github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Jacobwasbeast <38381609+Jacobwasbeast@users.noreply.github.com> Co-authored-by: Piplup <100526773+piplup55@users.noreply.github.com> Co-authored-by: Vladimir Sokolov <tehnicalmailone@gmail.com> Co-authored-by: Jonas Henriksson <gr3ger@gmail.com> Co-authored-by: Vudjun <Vudjun@users.noreply.github.com> Co-authored-by: extherian <extherian@gmail.com> Co-authored-by: Hack茶ん <120134269+Hackjjang@users.noreply.github.com> Co-authored-by: EmulationEnjoyer <144477224+EmulationEnjoyer@users.noreply.github.com> Co-authored-by: Nicola <61830443+nicola02nb@users.noreply.github.com> Co-authored-by: jzumaran <juan.zumaran@gitz.cl> Co-authored-by: Pitchoune <yrigaud@icloud.com> Co-authored-by: Narugakuruga <31060534+Narugakuruga@users.noreply.github.com>
4.9 KiB
Pull Request Guide
Contributing Rules
All contributions to GreemDev/Ryujinx repository are made via pull requests (PRs) rather than through direct commits. The pull requests are reviewed and merged by the maintainers after a review and at least two approvals from the core development team.
To merge pull requests, you must have write permissions in the repository.
Quick Code Review Rules
- Do not mix unrelated changes in one pull request. For example, a code style change should never be mixed with a bug fix.
- All changes should follow the existing code style. You can read more about our code style at docs/coding-style.
- Adding external dependencies is to be avoided unless not doing so would introduce significant complexity. Any dependency addition should be justified and discussed before merge.
- Use Draft pull requests for changes you are still working on but want early CI loop feedback. When you think your changes are ready for review, change the status of your pull request.
- Rebase your changes when required or directly requested. Changes should always be commited on top of the upstream branch, not the other way around.
- If you are asked to make changes during the review process do them as a new commit.
- Only resolve GitHub conversations with reviewers once they have been addressed with a commit, or via a mutual agreement.
Pull Request Ownership
Every pull request will have automatically have labels and reviewers assigned. The label not only indicates the code segment which the change touches but also the area reviewers to be assigned.
If during the code review process a merge conflict occurs, the PR author is responsible for its resolution. Help will be provided if necessary although GitHub makes this easier by allowing simple conflict resolution using the conflict-editor.
Pull Request Builds
When submitting a PR to the GreemDev/Ryujinx repository, various builds will run validating many areas to ensure we keep developer productivity and product quality high. These various workflows can be tracked in the Actions tab of the repository. If the job continues to completion, the build artifacts will be uploaded and posted as a comment in the PR discussion.
Review Turnaround Times
Ryujinx is a project that is maintained by volunteers on a completely free-time basis. As such we cannot guarantee any particular timeframe for pull request review and approval. Weeks to months are common for larger (>500 line) PRs but there are some additional best practises to avoid review purgatory.
- Make the reviewers life easier wherever possible. Make use of descriptive commit names, code comments and XML docs where applicable.
- If there is disagreement on feedback then always lean on the side of the development team and community over any personal opinion.
- We're human. We miss things. We forget things. If there has been radio silence on your changes for a substantial period of time then do not hesitate to reach out directly either with something simple like "bump" on GitHub or a directly on Discord.
To re-iterate, make the review as easy for us as possible, respond promptly and be comfortable to interact directly with us for anything else.
Merging Pull Requests
Anyone with write access can merge a pull request manually when the following conditions have been met:
- The PR has been approved by two reviewers and any other objections are addressed.
- You can request follow up reviews from the original reviewers if they requested changes.
- The PR successfully builds and passes all tests in the Continuous Integration (CI) system. In case of failures, refer to the Actions tab of your PR.
Typically, PRs are merged as one commit (squash merges). It creates a simpler history than a Merge Commit. "Special circumstances" are rare, and typically mean that there are a series of cleanly separated changes that will be too hard to understand if squashed together, or for some reason we want to preserve the ability to dissect them.
Blocking Pull Request Merging
If for whatever reason you would like to move your pull request back to an in-progress status to avoid merging it in the current form, you can turn the PR into a draft PR by selecting the option under the reviewers section. Alternatively, you can do that by adding [WIP] prefix to the pull request title.
Old Pull Request Policy
From time to time we will review older PRs and check them for relevance. If we find the PR is inactive or no longer applies, we will close it. As the PR owner, you can simply reopen it if you feel your closed PR needs our attention.