Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/eden-emulator/mirror/llms.txt

Use this file to discover all available pages before exploring further.

Contributing to Eden involves a few conventions you should follow before opening your first pull request — from getting a Git account, to adding license headers, to optimizing assets. This page walks through each step so your contribution lands cleanly.

​
Getting a Git account

Eden’s primary repository lives at git.eden-emu.dev. Registration is closed by default to limit spam, so you must email a request. Valid reasons to request access include:
  • You want to implement a specific feature or fix a specific bug.
  • You have experience in a relevant area (Vulkan, macOS, audio, etc.) and want to contribute.
  • You can provide insight or review on a particular subsystem.
Invalid reasons include generic messages (“I want to contribute to Eden”), wanting to report issues (use GitHub Issues instead), or wanting to download and play the emulator.
1

Write your request email

Use exactly this format:
Subject: [Eden Git] Registration Request
Username: <your desired username>
Email: <your desired email>
I wish to sign up because... <your specific reason>
Requests that are blank, generic, or appear automated will be filtered automatically.
2

Send the email

Email crueter@crueter.xyz with the subject and body above.
Gmail and Outlook frequently route responses to spam. Always check your junk folder — a response should arrive within 48 hours.
3

Receive your credentials

Once approved, you will receive a confirmation email with your password and a link to SSH setup instructions. You are required to change your password on first login.

​
Submitting patches by email

If you prefer not to request an account, Eden also accepts email patches:
1

Prepare your branch

Make your changes on a clean copy of master and commit with a descriptive message following the PR naming conventions.
2

Format the patch

git format-patch -1 HEAD
3

Email the patch

Send it to eden@eden-emu.dev with the subject:
[Eden] [PATCH] <brief description>
Attach the .patch file. Include both bracketed prefixes or your email may be missed.

​
License headers

All commits must include proper SPDX license header accreditation in every source file you create or modify.
1

Fetch master

git fetch origin master:master
2

Run the license header script

The -u flag updates headers, and -c automatically commits the result:
.ci/license-header.sh -u -c
Then push:
git push
Alternatively, omit -c and amend your last commit manually:
.ci/license-header.sh
git commit --amend -a --no-edit
If the work is licensed or vendored from another project, you may omit license headers. If you want to retain authorship attribution, you may add it — but the code may later be brought under Eden’s general attribution. Run .ci/license-header.sh -h for full usage details.

​
IDE setup

​
VSCode

Copy the following to .vscode/settings.json in your repository root, then install CMake Tools from the extensions marketplace: 
{
    "editor.tabSize": 4,
    "files.watcherExclude": {
        "**/target": true
    },
    "files.associations": {
      "*.inc": "cpp"
    },
    "git.enableCommitSigning": true,
    "git.alwaysSignOff": true
}
If you are building the Qt frontend, also install the Qt Extension Pack extension.

​
Build speedup

If your build drive is an HDD, building in RAM (a ramdisk) dramatically reduces build times. You need approximately 4–8 GB of RAM headroom for a full build with debug symbols. 
mkdir /tmp/ramdisk
chmod 777 /tmp/ramdisk
# Mount an 8 GB tmpfs
mount -t tmpfs -o size=8G myramdisk /tmp/ramdisk
cmake -B /tmp/ramdisk
cmake --build /tmp/ramdisk -- -j$(nproc)
umount /tmp/ramdisk
Adjust -j$(nproc) to match your CPU thread count, or set it explicitly (e.g. -j32). Using too many threads on low-RAM machines can cause OOM kills during linking.

​
Assets and large files

Before committing any binary asset, optimize it to keep the repository lean:
File typeTool
PNGoptipng
SVGsvgo
OGGOptiVorbis
Videoffmpeg — re-encode as AV1

​
Adding new settings

Before adding a setting, ask yourself:
  • Does toggling this setting make a significant, observable difference?
  • Can the correct value be auto-detected instead?
If you do add a setting, follow these rules:
  • Default must work. The majority of games and hardware must function correctly with the default value selected, unless the setting significantly degrades performance.
  • Debug settings must be off by default. Never ship a debug feature enabled.
  • Provide reasonable bounds. A VRAM limit setting should never allow 0 as a valid value.
  • Keep descriptions short. If a setting “does a lot”, consider splitting it. Avoid padding like “recommended for most users and games” — use “(recommended)” instead.
  • Avoid writing speed qualifiers redundantly. If an option is labeled “High accuracy”, that already implies it may be slower. Writing “High (Slow)” is redundant.
  • Use tr("Setting:") for field-type settings and tr("Setting") for boolean/checkmark settings. See Microsoft’s colon usage guide.

​
Description writing examples

VerboseConcise
”negatively affecting image quality""degrading image quality"
"this may cause some glitches or crashes in some games""this may cause soft-crashes"
"FIFO Relaxed is similar to FIFO […]""FIFO Relaxed […]” — the name implies similarity
”but may also reduce performance in some cases""but may degrade performance"
"it can […] in some cases""it can […]” — “may” already implies probability
If an option is an accuracy setting, writing “High” is sufficient — it implies slower. Do not write “High (Slow)” unless performance impact is the primary distinguishing factor and it clearly degrades performance for a given use case.

Build docs developers (and LLMs) love

Get started for freeTalk to us