A lot of people say I can be overly critical of Mamedev and some of the ways they go about things these days, and while personally I feel any criticism is warranted it is true I often have more negative things to say than positive.
However, I’ve always tried to highlight in equal measure times when the development process works well, times when really impressive work has been done and show examples of where the way things are being done really helps people.
Recently ‘hap’ has stepped up to the mark and has been doing a lot of work on smaller less well known / less popular systems which is something I’ve always seen as vital to the progress of MAME because it shows a genuine interest in the emulation process. If you’re following the GIT Mirror, which I’ve pointed out before is an invaluable resources, you’ll also see he’s adopted a development pattern which is one I’ve always strongly encouraged, that being to submit small amounts of progress on a regular basis.
Some argue that regular submissions clog up the changelog, but in reality they have one major advantage, it allows people to follow Mame development, and better understand Mame development by seeing how a driver progresses from a non-working state to something which is actually functional.
While the Initial submission put in by Kale after a couple of days of private work did have a lot already done compared to many skeleton drivers it didn’t work, it just crashed and reset after a few seconds.
Subsequently there were a couple of cleanup submissions as well as Input Fixes (so that it could be coined up and started), ROM Banking Fixes (to stop it crashing), Layer Enable Fixes (so that the playfield vanishes when the title / highscore are displaed), and Preliminary Colour RAM Hookup (as a first attempt to fix the colours so that the text layer wasn’t just monochrome)
This is much better than a single opaque submission because people can learn from it, they get a better understanding of how decisions have been made, the order in which progress has been made, and also the insight that driver development really is broken into several simple steps, not a brick-wall process nobody could hope to achieve.
When I was doing this there was no public mirror, but I like to think the devs I invited to the team at the time were following and learning from it back then too, and likewise that there is still enough public interest for people to actually be following the GIT and thinking ‘I could do that too’
So, as I was saying, I’m glad to see ‘hap’ adopting this approach because I think it only serves to benefit the project in the long run. Furthermore it sets a good example, because the very best devs are the ones who don’t stick to just a single platform which interests them, but instead put in work where it’s needed and the team absolutely needs more like that :-)
The game, if you were wondering is a nice little 8-bit video pinball game called Flipper Jack, rather rare.
Thanks for the compliments. To clarify, it actually went more like this:
– Smitdogg dumps game, Tafoid sends it to hap
– hap starts flipjack.c, gets the game running with sound but no gfx. he gets stuck and gives up and sends WIP to dox
– dox doesn’t have much time to work on it and sends it to Kale
– Kale figures out how gfx works and submits driver to svn
– etc
Keep up the good work guys.
hap,
Very grateful for the work you’ve put into the driving games lately.
Thanks!