Main > Raspberry Pi & Dev Board
Raspberry Pi Full Size Cab w\Arcade Monitor
CoryBee:
--- Quote from: Nephasth on December 18, 2012, 09:24:50 pm ---
--- Quote from: paigeoliver on December 18, 2012, 09:09:33 pm ---Just because you can do something doesn't mean it makes any sense to do it.
--- End quote ---
I thought this same thing when I saw your Joust.
--- End quote ---
404:
--- Quote from: yaksplat on December 18, 2012, 09:03:31 pm ---Perhaps a future Raspberry Pi II?
--- End quote ---
developers are better off forking mame and optimizing the codebase for arm; something i personally don't see anyone doing simply because of the sheer amount of work it would involved in the original mame codebase and the sheer amount of work it would take to port to an already underpowered platform. You also have to take into account that most of the builds out there are basically advancemame which runs on the old, faster rendering base to begin with. One can only imagine how slow a bare bones port of modern mame would run like on the pi.
Haze:
--- Quote from: 404 on December 22, 2012, 10:05:01 am ---
--- Quote from: yaksplat on December 18, 2012, 09:03:31 pm ---Perhaps a future Raspberry Pi II?
--- End quote ---
developers are better off forking mame and optimizing the codebase for arm; something i personally don't see anyone doing simply because of the sheer amount of work it would involved in the original mame codebase and the sheer amount of work it would take to port to an already underpowered platform. You also have to take into account that most of the builds out there are basically advancemame which runs on the old, faster rendering base to begin with. One can only imagine how slow a bare bones port of modern mame would run like on the pi.
--- End quote ---
Emulation is inherently cpu expensive, the pi doesn't have a good cpu.
Sure you can cut back on the emulation quality (or use old versions and effectively do the same) but there are very few *free* optimizations, speed is about compromise.
If you simplify codepaths you make the cores less functional, if you duplicate cores with only the functionality each game / hardware type needs you end up with an unmaintainable mess of copy+pasted+hacked code.
If you start to simulate cpus instead of emulate them you're starting to rewrite / port the game moreso than emulate it, which can work for a handful of games, but isn't really practical.
Hardware as weak as the pi simply isn't designed for something as open-ended and flexible as Mame where the project has been designed with future development in mind rather than something you can abandon once it ships. The reason existing forks ended up dead in the water and unable to integrate any improvements is simply that, they'd forked and optimized themselves into a corner where making any actual improvements was impossible.
As already said, just because you CAN use a Pi for this, with some old version of Mame, which probably pre-dates Bubble Bobble having an accurate protection emulation and countless other things doesn't mean it's actually a good idea to do so and you're unlikely to find a single actual Mame developer who thinks it's even remotely a good idea.
Grasshopper:
I've read Aaron Giles' justification for MAME's (sometimes quite dramatic) slowdowns over the years (link), and I've got two thoughts:
The first is that the slowdown problem could largely be eliminated by redesigning MAME to allow for the use of different plug in drivers. Users would then be free to choose between newer drivers that were more accurate but slower, or older drivers that were less accurate but generally faster. They could also choose a driver that offered an "optimisation point" for the games they actually wanted to play. For example, if you're building a Pac Man cab then you're not going to be interested in a version of MAME that has been optimised to play games from the late 80s, or later.
My second point is that I'm beginning to question the wisdom of MAME consisting of one monolithic bloated executable that can play (almost) all games from the late 70s to the present day. I wonder whether the original MAME Devs ever imagined that MAME would be expanded to the point where it could emulate 3d vector games. I haven't examined the source, but judging from Aaron's comments, I get the distinct impression that this monolithic approach now involves too many compromises being made. Perhaps the time has come for MAME to be split up in some way. For example by processor type , 8 bit era vs 16 bit, 2d sprite based vs 3d vector, etc. Each version of MAME could then be optimised for its own particular era of games.
Haze:
--- Quote from: Grasshopper on December 22, 2012, 01:15:53 pm ---I've read Aaron Giles' justification for MAME's (sometimes quite dramatic) slowdowns over the years (link), and I've got two thoughts:
The first is that the slowdown problem could largely be eliminated by redesigning MAME to allow for the use of different plug in drivers. Users would then be free to choose between newer drivers that were more accurate but slower, or older drivers that were less accurate but generally faster. They could also choose a driver that offered an "optimisation point" for the games they actually wanted to play. For example, if you're building a Pac Man cab then you're not going to be interested in a version of MAME that has been optimised to play games from the late 80s, or later.
My second point is that I'm beginning to question the wisdom of MAME consisting of one monolithic bloated executable that can play (almost) all games from the late 70s to the present day. I wonder whether the original MAME Devs ever imagined that MAME would be expanded to the point where it could emulate 3d vector games. I haven't examined the source, but judging from Aaron's comments, I get the distinct impression that this monolithic approach now involves too many compromises being made. Perhaps the time has come for MAME to be split up in some way. For example by processor type , 8 bit era vs 16 bit, 2d sprite based vs 3d vector, etc. Each version of MAME could then be optimised for its own particular era of games.
--- End quote ---
You're looking at it from the wrong angle.
A plug-in system would solve *nothing* all you'd get were broken incompatibilities and users moaning because a driver from a 5 year old verson didn't run with the current version.
There is no benefit to splitting things up. It doesn't inherently make anything faster, things get slower because they improve, be it cpu cores, or the drivers themselves, which is the exact same reason you can't just expect a plug-in system to work, many of the fixes are NOT in the drivers, but in the cores.
The monolithic approach has been hugely beneficial to MAME in terms of making sure everybody working on MAME knows they have to write usable, CORRECT code, not code so limited in scope that it only works with one system. Of course, that still happened, and one of the biggest jobs in MAME can be cleaning up such instances so they use a common correct implementation.
There is also no logical way to split things up, components, cpus etc. are shared across generations of platforms, one of the reasons Ville has had a lot of success with Konami 3D stuff is because the 2D side of it is almost entirely inherited from the previous generation of systems etc.
Unless you want to maintain a whole bunch of single game emulators, where improvements made in one place CAN'T benefit or affect drivers elsewhere unless you manually port said improvements to every driver then there really is no other way, and MAME would have died a LONG time ago if it was just a collection of single game emulators. The more software, platforms and systems a core can run *without hacks* the more confident you can be that your emulation is actually good, and not just something which conveniently works for one use case. When you're trying to provide a reference model, and something people can reuse with confidence to emulate any platform they want then that trust and confidence in the quality of the components is important.
Users tend to see things as much more simple than they actually are, this only gives further evidence to why a plug-in system would be *bad* because said users would attempt to mix and match all sorts of incompatible versions and just expect them to work, then report bugs without even beginning to consider that the 'super turbo 10 year old 68k core' they used might actually be to blame for random crashing in a game even if they're using the latest game driver.
We've seen other emus do plugin systems, and they've been without exception an unholy confusing mess. Mame either works, or it doesn't.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version