Submission Guidelines
The following guidelines are derived from those of MAMEDev, as found at
http://mamedev.org/submit.html
If you have a fix relating to files present in MAME only, please send it to them, similarly if your fix is AGEMAME related, send it here. If you’re not sure, contact me, and I’ll probably be able to direct you.
Although AGEMAME related fixes submitted to MAMEDev may well reach us in cases where MAME and AGEMAME both share a game, AGEMAME is a smaller project and as such may be able to review your submission faster.
If you’re handy with C and want to help out, there are several ways you can do so. Source code submissions from outside developers are welcome. In fact, many of the developers who have done work on behalf of AGEMAME are not “official” MAME devs, the administrator included.
Acceptable Submissions
When working on modifications to AGEMAME, keep the following guidelines in mind:
* We are not interested in adding features to AGEMAME to make games look better or improve playability or cheat the hardware emulation in order to make things run faster. Submissions that serve only to do this will not be considered. Please note that this does not include visualisation systems, such as the one in the Scorpion 1 driver, as these are necessary in order to view the program in progress.
* Technical accuracy is our #1 goal. ROM patches or hacks to games are generally not appropriate as they do not improve our understanding of the hardware. Submissions which are merely wild guesses about something and which don’t make sense based on what is known about the hardware will tend to be rejected.
* ROM set naming in AGEMAME is based on fairly precise criteria. There is no point in submitting changes to ROM set names; they are crammed into 8 characters and have many other limitations. Plus it tends to annoy the developers.
* If you think there is a problem in the naming of a game, you should send an email rather than a source code patch. Game name changes are discussed among the developers and aren’t really code changes.
* Cosmetic changes to the source are best left up to the core developers. If your change doesn’t add anything worthwhile to the actual code, it is not worth your time to submit it. However, if you can offer more information about a game than is already known, that is worth your time, as it will help with improving the emulation.
Submission Guidelines
Before sending in a submission, you should make sure that you follow these guidelines:
* All submissions must be compiled in both debug (make DEBUG=1) and non-debug builds using the official build tools (download them from here), and all warnings or errors fixed.
* All submissions should be in diff format, taken against the most recent intermediate update. (If you are using Windows, you can get a set of diff/patch tools here.)
* To create a correct diff, use the following command line:
diff -Nru originaltree modifiedtree > patchname.diff
where originaltree is the ’src’ directory of the original, unmodified sources, and modifiedtree is the ’src’ directory of your updated sources.
Once you have a .diff containing your changes, ZIP it up and submit it by sending email to agemame-admin at beeb dot net.
Submissions are most often accepted or rejected without feedback. If you submitted something and it hasn’t shown up in AGEMAME within a few releases, feel free to ask what the status of your submission is - it may have been lost.
Getting Started
MAME is a huge project, and to work on many parts of it requires extensive understanding of C, arcade game hardware, CPU architectures, audio systems, graphics systems, and reverse engineering. These are not easy to come by, and the learning curve is very steep. AGEMAME tends to be a less intense project, as we tend to use the existing MAME and MESS code to emulate other hardware forms. That said, this may still be difficult in many cases.
There are still ways of contributing to MAME and AGEMAME that don’t require a full top-to-bottom understanding of everything. Here are a couple of suggestions:
* Add save state support to a driver. The save state system is very modular and pretty straightforward to use. Furthermore, very few drivers are set up to use it right now. Digging into a driver and figuring out what data needs to be preserved in order to resume execution is a great way to learn about the MAME core.
* Figure out what unknown DIP switches do. Some of this can be determined by twiddling the DIP switches and watching what happens, but often this is not enough. Delving into the game code to understand how the DIP switches are read and what their values are used for is a good beginning challenge in reverse engineering.
If you’re new to emulator programming, these are a far better places to start than trying to tackle the emulation of a game that doesn’t yet work. Any games that still don’t work are usually due to complicated protection or hardware emulation issues and are more than likely going to be a daunting (and discouraging) challenge for someone just getting started.