Editing Support emulation projects

'''''WIP page, help wanted.'''''

There are several ways to support or contribute to an emulation project (or similar projects such as [[compatibility layers]], [[game engine recreations/Source Ports|game engine recreations/source ports]] or simulators). Explained here are different ways you can get involved, even if you have low technical skill and/or no money.

Note that almost all these methods require getting involved in some way. Offering to help in a specific area may not be necessary in some cases, so you'll have to check with each project you're interested in to determine what they're looking for and what they find useful.

==Testing & bug reporting==
One area you may be able to help in is reporting information, especially if you notice bugs in games that you play. This can be done a number of ways, but they all help the developer see where the emulator still has to improve.

''more text here...''

=== Compatibility reporting ===

A compatibility report communicates the emulation quality. It is aimed at other users, and often consists of a compatibility list.

Some emulators use GitHub for their lists. Most projects have instructions on how they should be written. Make sure you search to see if any issues you're having has already been encountered by another user. Note that sending users to GitHub is dangerous - you should only do it if the project has a simplified compatibility list which doesn't require technical understanding / writing; most projects actually use wikis or custom tools / websites for compatibility reporting. Some use spreadsheets and forms to get their data.

''more text here...''

=== Bug reporting ===

A bug report concerns one specific problem. It is aimed at emulator developers.

Because bug reports are meant for developers, they are expected to be more technical than a compatibility report.
They're also typically expected to include details about specific situations when the problem arises, but also technical details as to why it happens.
Developers also read compatibility reports and create respective bug reports themselves.

Sometimes you need a fair bit of experience in order to report bugs to the major projects. If you lack the experience to match what developers themselves report then most smaller projects are fine with it as long as you try to make it coherent and professional. Many projects have the program set up to automatically forward logs to developers at the user's discretion. This can avoid having to explain the problem, though sometimes they'll want context in case they need to reproduce it.

Generally you should chat to other developers / maintainers (via IRC or Discord) before creating a bug report.
Often they are aware of issues and have grouped them under a known technical term.

''more text here...''

=== Console verification ===

Despite being aimed at developers, users should read / follow bug reports they care about.

Many emulators not only need games tested in the emulator, but also on real hardware, because games aren't perfect. If you've been involved with the speedrunning community, you ''know'' bugs exist, and can be taken advantage of to get a faster time.
Determining what is a bug in the game and what is inaccurate emulation can prevent developers from wasting time on problems they didn't create. All projects encounter this at some point; even the testers behind [[Dolphin]] encounter [https://www.youtube.com/watch?v=kd29mWwp5c8 bugs that happen on hardware].
Ideally, you should have a capture card for recording footage from hardware.

During the research and documentation phase, some developers will also write small programs to test hardware behavior.
In some cases the developers don't have access to the physical hardware or they need to confirm results by having multiple users run the tests. This can also be done in cases where the code doesn't work on all hardware revisions, and the developer needs to test it on all revisions to understand where each model has deficiencies; sometimes they don't have all models, but the more accuracy-focused projects will have this covered in some way. Hackers and those in the homebrew scene may have documented these deficiencies already.
You can follow developer chat-rooms, and offer assistance by running tests and collecting data from real hardware.

==Provide support for end users==
Helping and guiding other users through problems is one of the pillars of open communities. If there's one thing a developer doesn't want to have to do alone, it's troubleshoot problems that end users get themselves into. Providing support for end-users will allow developers to focus on the software they make, creating a filter that allows actual bugs to be reported and saving time in the process. You also need a slight sense of confidence to make decisions for the user. For most people who work in IT (or just Google their problems), this comes naturally.

Support can be provided on a Discord server, IRC server, or a project's forums.

==Write & promotion==
Outreach and promotion is an important factor in the success of an emulator because it gets people talking about it, especially emulators for newer consoles that make strides in their efforts regularly.

This can be done by writing official blog posts, posting news on social media, providing information, making videos for YouTube, explaining and summarizing changelogs, etc.

== Archival & hardware donations ==

Optical discs like CD and DVDs have a limited lifespan. They degrade over time and will eventually be unreadable to a disc reader.
Projects like [http://wiki.redump.org/index.php?title=Redump.org Redump] are focused on identifying all officially released discs.
Each known disc is stored with information which makes it possible for users to verify the correctness of their disc.
Contributing to these databases (by dumping your discs and contributing metadata) helps to build a full-set for testing emulators.
It also encourages users to make legal backups of their discs before they break.

Game databases like [https://www.mobygames.com/ MobyGames] can be used to find additional information for each game. Launchers can use the uploaded descriptions and cover artwork. You can contribute by scanning your game artwork, finding and adding game information (such as release dates).
MobyGames also stores barcodes and serial numbers which can be used to find releases in Redump's database.
You can look at the existing cover artwork and extract such information.

You can donate games or hardware to developers or other volunteers who are accepting such donations.
Donated games can then be analyzed by the recipient and their information can be added to databases such as those listed above.
Emulator developers usually require a large number of consoles, games, and peripherals (controllers, memory cards, ..), so donations are typically welcome.
Depending on the project structure these will be forwarded to people who are in need of such hardware.
Contact project maintainers to find out what they accept.

== Help with technical documentation ==

Emulators depend on technical documentation about the systems they emulate.
Typically, there are dedicated communities (often including people from the homebrew scene, and much less commonly the piracy and warez scene) for these research and documentation tasks.

These research communities often uses wikis that need to be maintained.
Beginners can help by fixing typos or formatting. For some of these tasks, no coding skills are required.
Advanced users and developers can contribute their own research, or participate in technical discussions.

Many of these communities also maintain their own tools which can be helpful for ROM dumping or testing emulation.
These tools are often written in beginner-friendly programming languages (such as C# or Python) and can be stepping-stone for moving towards actual emulator development.

=== Communities ===

* [https://github.com/xboxdev/xboxdev XboxDev] for original Xbox and SEGA Chihiro
* [https://www.3dbrew.org/ 3DBrew] for 3DS

== Learn how to code and help out ==
A pretty obvious one, but it should be stated that most open-source emulation projects don't get nearly enough support in the programming area. Bigger projects often have an abundance of developers to constantly check on the code and make sure it's written well, but those are rare, so most projects are often one man operations or have few (if multiple) developers. Many projects are actively looking for programmers, so if you have knowledge in systems programming and such, you could definitely be of help.

Programming for the emulator itself isn't even necessary, as many projects are in need of websites and continuous integration (CI). If the emulator doesn't use stable builds (or all that exists are instructions for compiling from source), you could implement CI and integrate it with the website so it can host precompiled builds for users. Continuous integration is also useful because it can run the program with test ROMs to ensure that compatibility isn't broken between commits. The major projects will have this covered. Sometimes older project developers don't like to change the website's infrastructure, so you're better off handling projects for which there is no existing website.

If you're experienced with Linux, you can help port a program to your distribution (or mostly every distro if the main developers are already considering something like AppImages).

==Donate money==

Emulator development is a time-intensive task. A lot of projects could use some money, especially ones where they often don't get it when they should. Some projects are simply possible because the developers have money from their existing job to be able to fund their efforts on the emulator. Sometimes it goes a long way in helping archivists on the team hunt for rare items.

Many projects are often a group effort, so from a user's perspective there's no fair way to distribute what comes in.
Often developers of emulators can only do their work because research has been done by other people - unfortunately, that work often goes unrewarded.
It's therefore important to understand who you donate to, and how that money will be shared and used among the group. Make sure developers are upfront about who gets paid and what they're using your donations for. More informal ones will say they use the donations on a beer or coffee, but it's also often put towards project operations like domain registration for the website and such to keep the website running.

Some problems may arise from this; money can potentially be a deterrent for newcomers on open-source projects. By only supporting the core developer group, it might actively discourage other contributors because the reward system would be unfair. ("Why do I have to work for free when ''x'' is getting paid on a monthly basis?") This can quickly lead to one "hero" developer - if they ever disappear, the project essentially dies because nobody else is familiar with the [[source code]]. Some projects have countered this by implementing a bounty system, where newcomers can be rewarded for fixing bugs that are outside the scope of what the core developers focus on. Keep in mind that even in the hundreds of dollars, a bounty isn't going to pay the developer's bills, but it's a better incentive than otherwise.

For some projects, there is no practical use for money: money doesn't write code.
There's also a lot of free services for open-source projects, so many projects don't have any expenses.

=== Patreon ===
[[Emulators on Patreon|Several emulators have a Patreon.]] We've been tracking projects that use Patreon since mid-2017.

=== BountySource ===
BountySource lets you directly donate money to certain features or improvements you wish for. Some known projects that use BountySource include [https://www.bountysource.com/teams/libretro libretro] and [https://www.bountysource.com/teams/reicast Reicast].

=== PayPal and other ways to donate ===
Some emulators have PayPal addresses and such on their homepages.

== Big projects ==
Note that this list is only intended to provide examples of ways to help out/getting involved, so we only list major examples.

=== MAME ===
It's not possible to donate directly to MAME, but several other projects that help MAME's development can be supported.

* [http://www.mameworld.info/ubbthreads/showthreaded.php?Number=311481 The Dumping Union] - Accepts donations from PayPal.

* [https://team-europe.blogspot.com/ Team Europe] - Accepts donations from PayPal. [https://www.reddit.com/r/emulation/comments/9txdsz/mame_team_europe_would_like_help_funding_some/ See info here on how to donate].

* [https://caps0ff.blogspot.com/ CAPS0ff] - [https://www.patreon.com/user?u=4805718 Has a Patreon].



=== Libretro / RetroArch ===
The libretro Team has
* A [https://www.libretro.com/index.php/contributions/ contribute page] with wish lists for hardware and other info. 
* [https://www.patreon.com/libretro A Patreon.]
* [https://www.bountysource.com/teams/libretro A BountySource system] where you can donate money directly to features, bugfixes, and improvements you'd wish to see.



=== ScummVM / ResidualVM ===
The ScummVM Team has
* [http://sourceforge.net/donate/index.php?group_id=37116 A PayPal.]
* [https://bugs.scummvm.org/ A bug tracker.]
* [https://translations.scummvm.org/projects/scummvm/scummvm/ A translation portal.]
* [https://wiki.scummvm.org/index.php?title=Developer_Central A Developer Central page] with instructions on how to contribute code.

ResidualVM has a [http://wiki.residualvm.org/index.php/Getting_Involved getting involved page] and a [http://wiki.residualvm.org/index.php/Reporting_Bugs page for reporting bugs].



=== Wine ===
The Wine Team has a [https://www.winehq.org/donate Donate page] where you can find information on how to donate with PayPal and other ways to send money. You can also support them by buying merchandise.

Another option is to buy [https://www.codeweavers.com/about/support-wine CrossOver] which is a commercialized, supported version of Wine from CodeWeavers. They contribute all of their work on CrossOvers back to Wine and make up about two thirds of the commits made to Wine.