Main > Main Forum
the state of mame
Grasshopper:
Haze, you make a good case but I still think you're wrong.
I should firstly point out that in my day job I'm a software developer (mostly C and PERL). However, as I've only ever experienced MAME from the end user's side of the fence, I've chosen to wear my user's hat for the purposes of this discussion. It is my intention to get my head round MAME's source code at some point but real life has a nasty habit of getting in the way of my plans.
I do understand the necessity for code to be clean and easily maintainable. But what I don't accept is that properly written code will automatically be slower than hacked code. Maybe in some cases but in my experience it's mostly the opposite. It generally takes more care and effort to come up with the optimal algorithm for solving a problem. Sometimes the quick and dirty solutions are actually slower.
The reality is, as ark_ader has already pointed out, that the size of programs tends to expand over time to fit the resources available. You mentioned that Windows is a mess because of the legacy support. But that's only part of the story. Windows has also become bloated because the developers have been spoilt by ever increasing processor speeds and memory sizes.
I don't see software bloat as inevitable. When Vista first appeared and required vastly more memory than XP and ran like a snail in comparison, we were told that it was the price that users had to pay if they wanted extra features like semi-transparent windows (most didn't). This is a line that Microsoft stuck to for some time. No doubt some of their developers felt irritated that their efforts weren't properly appreciated, and that the users should stop moaning, upgrade their hardware, and accept "progress".
However, when it looked like Microsoft might lose the netbook market to Linux they pulled their fingers out and came up with Windows 7 which offers similar performance to XP combined with all the extra features (and more) of Vista.
When it comes to programming, necessity is the mother of invention. I'm pretty sure that if computers weren't getting faster then MAME wouldn't be getting slower.
Grasshopper:
--- Quote from: ark_ader on January 16, 2011, 07:13:36 am ---The subject has been brought up before - why not just develop Mame for Linux and do away with Windoze based machines?
--- End quote ---
I'm a Linux nut, so from a purely selfish point of view, I think that's highly desirable. But I don't think it's practical at the moment because not enough people use or understand Linux. However, I would agree that the mamedevs have nailed their colours too firmly to the Windows mast. A lot of MAME's limitations appear to be caused by Windows' limitations.
Personally, I think they should have continued basing development around the MSDOS version. Yes MSDOS is primitive and old fashioned. But in this context I see that as a positive. It would have imposed discipline on the developers not to base MAME's features on features (or limitations) of the underlying OS.
Derrick Renaud:
Whhaaaa, why can't I run the newest Acrobat Reader; Office; Adobe Audition; Windows; Leisure Suit Larry; MAME; etc on my old P2. I can't believe you people are serious. For all of them you are free to use older versions that worked on that hardware. To demand that the latest version work on something that is barely fast enough to play MP3s is insane. You have been told that this is a hobby. Would you prefer 95% of our hobby time be spent maintaining old versions?
You have been told ad nauseum that Donkey Kong now uses a discrete simulation that generates the waveforms in real time based on the electrical circuit. This replaces the old inaccurate samples. So yes it is slower. Oh well, it still runs 13 times faster then the real thing on my obsolete Core 2.
You have been told you are free to maintain old versions yourself, but won't because you are too lazy; can't bother to learn programming; not insane enough to bother; etc. Instead there are the continual demands that your needs are more important then the needs of those that actually do the code. If you want your needs to be that important, step up and do/maintain the code yourself.
Haze, here is no hope.
For the undemanding people, sorry for all the ranting. For the demanding people, I demand that you make me an arcade machine in your spare time and drive it to my house.
I think I need to leave these forums so I can return to sanity.
Take care
CheffoJeffo:
:cheers:
Haze:
--- Quote from: ark_ader on January 16, 2011, 07:13:36 am ---What I do not understand that you have a project that has been developed to emulate several (in today's standards) basic processors like the z80, 65xx and even the 808x series cores, that have multiple operating requirements. What should have worked on a P2 should still work on at least on a P3 (quite a margin there) and not having a requirement of a 1ghz processor. If that part of the game/core is loaded off disc and retained in memory, should it be moot what kind of platform you are running it from (obviously from the target platforms as described)?
Unless you have engineered the software to operate as a complete entity than just targeting the relevant core. That would make more sense, in light of the availability of hardware. Which would explain why I cannot run the latest build on a stock P3 and have the classic games just lag. I'm not expecting any games that require CHDs, or are more complex to zip along. Dkong should run out of the box on any build with the minimal platform of P3,128mb, 1mb VGA.
--- End quote ---
There's more to it than that.
Old versions ran in 8-bit screenmodes. New version run using D3D, usually in a 32-bit mode. That instantly means you're doing 4x the work.
Supporting 8-bit screenmodes was a pain, it was done, because at the time most PC hardware didn't support 32-bit modes (15/16 bit modes were a mess and you were lucky if they worked properly)
To support these modes every MAME driver had to have code in it in order to track which colours were being displayed when, mid-screen palette tricks weren't possible, and the whole thing was incredibly limiting because MAME had to start approximating (which caused all sorts of problems) if a game tried to display more than 256 colours at any point. This wasn't fun to work with, and the code to support it / maintain it just got in the way of other stuff.
These days 8-bit modes are the ones that don't work, supporting them, even if we could makes no sense. Technology has changed, it's moved on.
In addition to this there were other 'optimizations' such as only updating the parts of the display that had changed, again this just about worked for some older titles, but again required specific coding in each driver to mark areas of the screen as dirty. It was messy, ugly code which as time has passed we've been able to do away with.
These are all positive changes for the project, as they make it easier to work with. The cost of a new system is FAR less than the cost of trying to maintain this kind of legacy support.
Current versions of MAME have their own form of optimization in the form of caching (tiles, tilemaps) etc. which again may change in order to make the code cleaner and more maintainable as things develop.
It's evolution. MAME isn't slower now because the code is worse, in most cases it's slower because the code is better, cleaner, and _more reliable_
Also there is no such thing as a 'simple' processor really. It all depends on what level you emulate it at. The 68k core in MAME runs probably 50% of the supported titles in MAME at the moment, that's a lot of them, but there are areas in which it could be improved (and should be improved) which could cut the speed of the emulation in half. (Interruptable instructions, sub-opcode timing -- if the MAME cores are to be used as the basis of a good Atari ST emulator they will need to support such features)
The discrete games will be slower than anything currently supported if they ever run in MAME, because everything has to be emulated at gate / logic level! You might call those 'simple' doesn't mean they'll be fast, or 'simple' in terms of emulation.
MAME provides documentation and technology, reference emulation and cores which other people can refer to. The target platform(s) are roughly dictated by what the developers own, and are happy developing with, optimizations are targeted at THAT point. MAME is hardly going to switch over to being primarily developer on Linux when most of the active devs have no interest in Linux at all, nor is it going to be optimized for 10 year old systems at the expense of good code. Did anybody say 'side-effect' ?
Again, keeping old, broken versions of the code around doesn't make sense. Nobody is going to maintain them, and they're just going to break further. If you want old versions, they're on the web-site. If you want _support_ for old versions, you're on your own. We make progress, and offer our own form of support, it's called releasing NEW versions.