Those are valid concerns. I think the pinmame situation example specifically is a cautionary tale of what happens when something like this gets ignored though.
Correct me if I'm wrong but the deal with pinmame was that pinball enthusiasts wanted to use roms with their simulations, but at the time at least mame didn't allow pinball roms. So they took mame and made their own variant. The problem that happened was that as time rolled on and more and more core changes to mame rolled in, it became harder and harder to upkeep that highly divergent fork. Eventually even the pinmame authors gave up and it's been in a pseudo stagnant state ever since.
PinMame is a cautionary tale for a number of reasons.
1) It shows what happens if we're too stubborn and continue to ignore things we should be doing; back then the criteria for something being included in MAME was strictly 'arcade video game' and nothing else, so yes, they went their own path.
2) It also shows what happens if a derivative build strays too far from mainline. They added so much of their own code and hacks to our system it because nearly impossible to keep it updated with core changes going on in MAME.
3) It also, as I've mentioned, shows what happens if you let yourself / your project be controlled by a popular closed source external entity, in this case things like Visual PinMAME / Visual Pinball wanted to communicate with PinMAME in very specific ways. The main MAME project decided on a different way to handle certain aspects of this (the way lamps etc. are driven today) but updating PinMAME to use such methods / expand on such methods instead of the ones they had wasn't possible because the external software already heavily depended on their methods, and they couldn't change that.
4) It also shows what happens if when the authors of a derivative build somehow think they have more say over the MAME code than the people who wrote it, I believe the PinMAME guys licensed our code to people for commercial use without consulting the individual authors.
The scenarios are simplified, but yes, a lot can be learned from PinMAME, some already has.
1) We are more open now, it's more anything arcade related, I still think we should make it an emulation project for anything tho.
2) We prevented the gambling stuff from going the same way by integrating it, I know a lot of people weren't happy about that, but the code is utterly useless to us if it's being created in 10 year old builds. Likewise we did bring MESS a lot closer, and unified the project codebase otherwise that could easily have ended up as an incompatible codebase, there were already periods where it lagged behind trying to keep up with MAME changes.
3) We take this into consideration, although as discussed, it's a difficult situation.
4) Idiots will be idiots.. not really much can be done about this!
Some of these hybrids are becoming pretty complete on the mame end of things. I'm afraid whatever the solution that if it's ignored much longer another pinmame-like fork is going to immerge, it will become popular due to speed hacks, ect, and the cycle will repeat itself.
I suggested over the mameworld expanding the current output system to a input/output system btw. Things were threw back like it would promote piracy and that it would have to be cross platform ect. I tried to cite the current output system as a precedent where cross platform portability isn't an issue (outputs were windows only for quite some time) and that's where the hostility started so I gave up.
So my follow up question is do you think what's holding it up is a "politics" issue or a lack or motivation or what? I know this stuff takes time, but it seems like at this point somebody would be working on it at least.
Yeah, the promotes piracy thing (hides Mame, makes it easier for remote control / credit management etc. stuff on cabs) was definitely an issue in the past.
These days I think it's actually less of an issue, our current versions aren't actually that cab friendly, there's a lot more stuff you WOULDN'T want on a cab in there (if you just make all the working games available you get several gambling ones, and while most locations don't care if arcade games are bootlegs or not if they see something that looks like a sniff of a gambling game the cab is history) higher systems requirements also means greater cost for the bootleggers etc. In reality most of them stick with older things, because they already have solutions and it's cheaper. Bootleggers tend to not care about quality, just what is easiest and cheapest. Most of what we do is invisible these days, even to the bootleggers.
Some of the devs still seem to think it's a major issue, but the last bootleg cabinet I heard about was a good couple of years old now and relied on the save state code, that ironically the very same devs did a lot of work on. (the frontend would hack a # of credits into the save state file using a custom list containing the memory location that needed modifying for each game, load the state with -state from the commandline, have -autosave enabled so that a state was also created on exit, and read back the number of credits left from that state file)
The cross platform thing is a bit more of a real issue once you start allowing external control / using closed libs because really you want MAME to be usable in the same way regardless of platform. The features that aren't right now are more low level 'fluff' features like the current output system that not many people are going to make use of, or HLSL which just makes things look pretty (and the SDL builds have had GL shader system for much longer anyway) If it becomes a case of 'Mame can only play Pinball titles on Windows XP' or something stupid where many more people are likely to be affected, you can see the issue ;-)
Home
Help
Search
Login
Register
Send this topic
Print
Topic: MAME / MESS / UME in 2013 (Read 2212 times)
