Difference between revisions of "Support emulation projects"

From Emulation General Wiki
Jump to navigation Jump to search
(Game testing & bug reporting)
(Bug reporting =)
Line 18: Line 18:
  
  
=== Bug reporting ====
+
=== Bug reporting ===
  
 
A bug report is about one specific problem. It is aimed at emulator developers.
 
A bug report is about one specific problem. It is aimed at emulator developers.

Revision as of 12:51, 9 January 2019

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 or simulators). Explained here are different ways you can get involved, even if you have low technical skill and no money.

Testing & bug reporting

more text here...

Compatibility reporting

A compatibility report communicates the emulation quality. It is aimed at other users.


Some emulators use GitHub for their compatibility list. Create a GitHub account, most projects have instructions on how bug reports should be written, make sure you search to see if the issues is already brought up by another user, in that case just add your observation to that report.

more text here...


Bug reporting

A bug report is about 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. Bug reports are 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.

If you are not a software developer, you probably shouldn't do bug reports.

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 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. Sometimes it looks like there's a bug in the emulator, but it might be a bug in the game, so it also happens on the console. So you can possibly prevent developers from wasting time on bugs which aren't really bugs in the emulator. Ideally, you have a capture card to record footage as proof.

Also, during the research and documentation phase, some developers will write small programs to test hardware behaviour. In some cases the developers don't have access to the physical hardware or they need test results from many users. You can follow developer chat-rooms, so you can offer your help with running tests and collecting data from real hardware.

Provide support for end users

Discord, IRC, forums


Write & promotion

Write blog posts, promote news, provide information, make videos on YouTube, explain change logs, etc.


Help with technical documentation

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

These research communities often uses Wikis which 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 testing emulation or ROM dumping. These tools are often written in beginner-friendl programming languages (such as C# or Python) and can be stepping-stone for moving towards actual emulator development.

Communities

Learn how to code and help out

WIP

Emulation development is a time intensive task. It's only fair to reward the contributors.

However, emulator development is often a group effort and there is no fair way to distribute money. 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 or how it will be used.

Especially for Open-Source projects, there can also be problems with only supporting the core developer group: it might actively discourage other contributors because of the unfair reward system ("Why should I work for free, but XYZ is getting paid on a monthly bases?"). This can quickly lead to one "hero" developer - if they ever disappear the project is essentially dead because nobody else is familiar with the source-code.

For some projects, there is also 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

Several emulators have a Patreon. Here is a list

BountySource

BountySource let's you directly donate money to certain features or improvements you wish for

PayPal and other ways to donate

Some emulators have PayPal addresses and such on their homepages.

Big projects

MAME

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


Libretro / RetroArch

  • Has a contribute page with wish lists for hardware and other info.
  • Has a Patreon.
  • Has a Bountysource where you can donate money directly to functions and improvements you wish to see.


ScummVM / ResidualVM


WINE

  • Has a donate page where you find information on how to donate with Paypal and other ways to send money, you can also support them by buying merch. Another option is to buy CrossOver which is a commercialized, supported version of Wine from CodeWeavers. They contribute all of their work on Wine back to the Wine Project and make up for 2/3 of the Wine commits.