mirror of
https://git.eden-emu.dev/eden-emu/eden.git
synced 2026-11-01 20:01:53 +00:00
e903d70d9e
The spam got a little out of hand. Site policy also disallows things such as asking for donations without giving back to us, piracy, large file uploads, illegal stuff, and more. Signed-off-by: crueter <crueter@eden-emu.dev> - [x] I have read and followed the [Contribution Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/CONTRIBUTING.md#code-contributions). - [x] I have read and followed the [Coding Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/Coding.md) to the best of my ability. - [x] I have read and followed the [website policy](https://git.eden-emu.dev/eden-emu/site-policy). - [x] I affirm that the content of this pull request body was written and submitted entirely by me, in my own words, and not by an AI agent or LLM. - [ ] I affirm that I did not read any of this, and understand that my pull request will be closed if I check this box. - [x] I affirm that, by submitting this pull request, I am responsible for all of the changes contained within these commits. ------------------- Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4612 Reviewed-by: lizzie <lizzie@eden-emu.dev> Reviewed-by: John <john@eden-emu.dev>
98 lines
4.1 KiB
Markdown
98 lines
4.1 KiB
Markdown
# Development guidelines
|
|
|
|
## License Headers
|
|
|
|
All commits must have proper license header accreditation.
|
|
|
|
You can easily add all necessary license headers by running:
|
|
|
|
```sh
|
|
git fetch origin master:master
|
|
.ci/license-header.sh -u -c
|
|
git push
|
|
```
|
|
|
|
Alternatively, you may omit `-c` and do an amend commit:
|
|
|
|
```sh
|
|
git fetch origin master:master
|
|
.ci/license-header.sh
|
|
git commit --amend -a --no-edit
|
|
```
|
|
|
|
If the work is licensed/vendored from other people or projects, you may omit the license headers. Additionally, if you wish to retain authorship over a piece of code, you may attribute it to yourself; however, the code may be changed at any given point and brought under the attribution of Eden.
|
|
|
|
For more information on the license header script, run `.ci/license-header.sh -h`.
|
|
|
|
## Adding new settings
|
|
|
|
When adding new settings, use `tr("Setting:")` if the setting is meant to be a field, otherwise use `tr("Setting")` if the setting is meant to be a Yes/No or checkmark type of setting, see [this short style guide](https://learn.microsoft.com/en-us/style-guide/punctuation/colons#in-ui).
|
|
|
|
- The majority of software must work with the default option selected for such setting. Unless the setting significantly degrades performance.
|
|
- Debug settings must never be turned on by default.
|
|
- Provide reasonable bounds (for example, a setting controlling the amount of VRAM should never be 0).
|
|
- The description of the setting must be short and concise, if the setting "does a lot of things" consider splitting the setting into multiple if possible.
|
|
- Try to avoid excessive/redundant explainations "recommended for most users and games" can just be "(recommended)".
|
|
- Try to not write "slow/fast" options unless it clearly degrades/increases performance for a given case, as most options may modify behaviour that result in different metrics accross different systems. If for example the option is an "accuracy" option, writing "High" is sufficient to imply "Slow". No need to write "High (Slow)".
|
|
|
|
Some examples:
|
|
|
|
- "[...] negatively affecting image quality", "[...] degrading image quality": Same wording but with less filler.
|
|
- "[...] this may cause some glitches or crashes in some games", "[...] this may cause soft-crashes": Crashes implies there may be glitches (as crashes are technically a form of a fatal glitch). The entire sentence is structured as "may cause [...] on some games", which is redundant, because "may cause [...] in games" has the same semantic meaning ("may" is a chance that it will occur on "some" given set).
|
|
- "FIFO Relaxed is similar to FIFO [...]", "FIFO Relaxed [...]": The name already implies similarity.
|
|
- "[...] but may also reduce performance in some cases", "[...] but may degrade performance": Again, "some cases" and "may" implies there is a probability.
|
|
- "[...] it can [...] in some cases", "[...] it can [...]": Implied probability.
|
|
|
|
Before adding a new setting, consider:
|
|
|
|
- Does the piece of code that the setting pertains to, make a significant difference if it's on/off?
|
|
- Can it be auto-detected?
|
|
|
|
# IDE setup
|
|
|
|
## VSCode
|
|
|
|
Copy this to `.vscode/settings.json`, get CMake tools and it should be ready to build:
|
|
|
|
```json
|
|
{
|
|
"editor.tabSize": 4,
|
|
"files.watcherExclude": {
|
|
"**/target": true
|
|
},
|
|
"files.associations": {
|
|
"*.inc": "cpp"
|
|
},
|
|
"git.enableCommitSigning": true,
|
|
"git.alwaysSignOff": true
|
|
}
|
|
```
|
|
|
|
You may additionally need the `Qt Extension Pack` extension if building Qt.
|
|
|
|
# Build speedup
|
|
|
|
If you have an HDD, use ramdisk (build in RAM), approximately you need 4GB for a full build with debug symbols:
|
|
|
|
```sh
|
|
mkdir /tmp/ramdisk
|
|
chmod 777 /tmp/ramdisk
|
|
# about 8GB needed
|
|
mount -t tmpfs -o size=4G myramdisk /tmp/ramdisk
|
|
cmake -B /tmp/ramdisk
|
|
cmake --build /tmp/ramdisk -- -j32
|
|
umount /tmp/ramdisk
|
|
```
|
|
|
|
# Assets and large files
|
|
|
|
A general rule of thumb, before uploading files:
|
|
|
|
- PNG files: Use [optipng](https://web.archive.org/web/20240325055059/https://optipng.sourceforge.net/).
|
|
- SVG files: Use [svgo](https://github.com/svg/svgo).
|
|
|
|
May not be used but worth mentioning nonetheless:
|
|
|
|
- OGG files: Use [OptiVorbis](https://github.com/OptiVorbis/OptiVorbis).
|
|
- Video files: Use ffmpeg, preferably re-encode as AV1.
|