| Articles posted October 2006 |
Cleaning Up
From a software engineering perspective, there's nothing I like more than getting rid of "dead" code and cleaning up how things work under the hood. There's just something extremely satisfying about taking things apart and putting them back together again, ending up with a final result that is more elegant than what you started with.
The problem is, it's not always easy to do this in a project as big as MAME. A lot of code is dependent upon certain behaviors, and changing how things work can lead to other things breaking in unexpected ways. In most cases, it's simpler just to leave things alone and ignore the underlying ickiness of the code. If you need an enhancement or some new functionality, just hack it in on top of what's already there, so that you don't break the existing functionality.
I'd hate to think what MAME would look like after almost 10 years of that! :)
Even when new ways of doing things are introduced, it is often safer and simpler to do it gradually. For example, when I wrote the new debugger system a few years back, I left the old debugger system in place so that it wasn't a requirement of all the OS-specific ports to immediately update their systems to the new debugger. Unfortunately, this is a prime example where the inertia of having the old system around led to there being little incentive to update to the new system, and so both systems had to be maintained to some extent. (To be fair, in retrospect, I should have provided a bit more guidance in how to write an updated debugger.)
Fortunately, things have recently taken a step in a more positive direction. The new rendering system was introduced and the old one phased out within a couple of releases. Thanks to SDLMAME, Olivier's GTK debugger, and Ernesto's MacOS X debugger, the old debugger has been officially retired. And I just finished removing support for the old disassembler CPU interfaces, which built in a lot of dependence upon the MAME core. This change will allow most of the disassemblers to be easily compiled separately from MAME and used in other tools.
And of course, there's more on the horizon (there always is). There is so much common code between the core MAME and SDLMAME (and the other ports as well) that it makes sense to push more of the functionality down into the core. This requires a few new tweaks to the way things are done, but pays off in the end with a more maintainable source code base.
To the end user, this all may seem like unnecessary churn, but in reality, a lot of the changes that go into improving the core systems in MAME have longer-range benefits that are not immediately tangible, but help keep the project healthy.