Submitting Source Code: Difference between revisions
mNo edit summary |
|||
Line 33: | Line 33: | ||
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. | 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. | ||
Back to [[How MAME Works]] |
Revision as of 18:31, 12 September 2012
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 more unexpected improvements to MAME come from folks who are not "official" MAME devs.
Acceptable Submissions
When working on modifications to MAME, keep the following guidelines in mind:
- We are not interested in adding features to MAME 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.
- 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 MAME is arbitrary. 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 names 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.
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; modifiedtree is the 'src' directory of your updated sources; and patchname.diff is the name of the diff you want to create.
Submissions are most often accepted or rejected without feedback. If you submitted something and it hasn't shown up in MAME within a few intermediate releases, feel free to ask what the status of your submission is.
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. That said, there are still ways of contributing to MAME 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 MAME.
- 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.
- Go to MAMETesters and look over the bugs. There are many tricky bugs in there, but there are also many straightforward issues that nobody has yet taken the time to look into.
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.
Back to How MAME Works