MAME Running In Chrome 165
An anonymous reader writes to point out this interesting outgrowth of Google's Native Client: a Google engineer has ported MAME 0.143 to the browser-based platform, and written about the process in detail, outlining the overall strategy employed as well as specific problems that MAME presented. An impressive postscript from the conclusion: "The port of MAME was relatively challenging; combined with figuring out how to port SDL-based games and load resources in Native Client, the overall effort took us about 4 days to complete."
Is Google trying to fragment web? (Score:5, Insightful)
Don't do that. Only use standards like HTML5 that work in every browser.
Re:Is Google trying to fragment web? (Score:5, Informative)
I don't see your problem. It's not like they won't be supporting the standard, investing on their platform (that they even consider big enough to be your whole PC UI).
I, for one, like the idea that I can have desktop quality applications running independent of platform on my browser - and wouldn't mind if this became the standard. By uniting all OS'es under this platform, I don't believe that there is fragmentation (what exists now IS fragmentation)
Re: (Score:1)
I for one don't want control of my desktop applications in the hands of 'cloud'. If I have dependence on something, I want to ensure I have access to it. this includes control, not just convenience.
there is nothing wrong with fragmentation. it allows innovation. if everything's monolithic, nothing can change.
Re:Is Google trying to fragment web? (Score:5, Insightful)
> I, for one, like the idea that I can have desktop quality applications running independent of platform on my browser - and wouldn't mind if this became the standard
The browser is your platform, that's the whole concept behind moving everything to web based. That's a good thing if you take the traditional view that the OS is the platform - now you can run any old OS you like (with a standards compliant browser) and you'll be able to run the apps.
This doesn't make you platform independent though, it makes you OS independent - all you've done is just redefined 'platform'. While apps only use standards you maintain independence. As soon as they use non-standard extensions you are no longer independent and now you are limited again. In this case you are limited to Chrome.
In this respect it's really no different to ActiveX. Just because google have published the workings of this doesn't make it a standard and there is really no reason for all other browsers to implement it. And if it isn't a standard and isn't available in all browsers people working with it will be forcing their choice of platform on their users and we're back to where we started. Why don't we all just run Windows and use ActiveX?
Richard.
ActiveX is non-free (Score:3)
Why don't we all just run Windows and use ActiveX?
The difference is that Windows is non-free and chromium-browser is free software. (Google Chrome is chromium-browser plus Flash and a couple other minor non-free bits.)
Re: (Score:3, Interesting)
The difference is that Windows is non-free and chromium-browser is free software. (Google Chrome is chromium-browser plus Flash and a couple other minor non-free bits.)
Actually chromium-browser isn't entirely free software:
http://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines#chromium-browser [libreplanet.org]
Re: (Score:2)
Great, I've gone from $179 vendor lock-in to $0 vendor lock-in. Until others implement NaCl, I'm still forced to use Chrome to get at that software. As it so happens I use and quite like Chrome, but when that inevitably changes and suddenly I want to start using Firefox again, I will not have that option. No, I will not fork chromium and make my own browser. Technically possible does not mean practical, and therefore I don't consider it an option.
Re: (Score:2)
That's a good thing if you take the traditional view that the OS is the platform - now you can run any old OS you like (with a standards compliant browser) and you'll be able to run the apps.
Except that it defeats the purpose of choosing your OS. Why bother having multiple OSs at all, if you're just going to launch a browser and do everything there. You might as well boot directly into the browser to begin with.
Re: (Score:3)
Well that's the strategy of ChromeOS. The browser is, effectively, the OS.
Two BIG differences between NaCl and ActiveX (Score:5, Informative)
1) NaCl is free/open source software, both the SDK and the client implementation in Chromium; ActiveX was proprietary and every program required to be signed by Microsoft to run by default;
2) NaCl is secure (see this IEEE article [chromium.org], it's very interesting) and designed to be portable to different browsers and OSes; you can safely run untrusted code, just like you would do with JavaScript; ActiveX required not only to trust that the controls weren't malicious, but also to trust that they all were free of security bugs: if only a single signed ActiveX control somewhere had a security bug, it could be exploited to p0wn Windows PCs (that's why Microsoft had a growing list of signed controls and another growing list of signed-but-blacklisted controls).
Native Client is certainly not perfect, but please don't compare it to ActiveX. Entirely different beast.
Disclaimer: I speak only for myself and not anyone else. IANARE.
Re: (Score:2)
NaCl is secure
It's so secure that by default Google Chrome only uses it to execute code that's from trusted sources, more specifically from their app store.
NaCl and ActiveX are both *not* CPU-portable (Score:2)
NaCl is designed to be portable to different browsers and OSes
But it is *not* designed to be portable to different CPUs. Try running NaCl MAME on your ARM or MIPS phone or on your PowerPC game console's browser - it won't work. This by itself makes NaCl unsuitable for the web. Not only can't we run it on non-x86 hardware now, it would make life harder for new CPU archs in the future.
(Yes, there is a research project trying to make NaCl portable to different CPUs. It is too early to tell if it will succeed, and what tradeoffs it will have in terms of speed, portabil
Re: (Score:2)
Well, as far as I'm concerned, you are right... Until Firefox has a competing implementation. At that point, it's a standard. /architecture/ independant - I.e. can be compiled for ARM or any other arch you want... Great!
Also, so long as it's
Re: (Score:2)
Why don't we all just run Windows and use ActiveX?
How about Java applets?
Anyone remember Java WebStart?
Re: (Score:3)
Comment removed (Score:5, Informative)
Re: (Score:2, Insightful)
Re: (Score:3)
I, for one, like the idea that I can have desktop quality applications running independent of platform on my browser - and wouldn't mind if this became the standard. By uniting all OS'es under this platform, I don't believe that there is fragmentation (what exists now IS fragmentation)
AFAIK, the "native" in NaCl means that it is compiled for a given CPU architecture. It is probably independent of the OS, but you still couldn't run an x86 version on ARM, for example.
Re: (Score:2)
I, for one, like the idea that I can have desktop quality applications running independent of platform on my browser - and wouldn't mind if this became the standard. By uniting all OS'es under this platform, I don't believe that there is fragmentation (what exists now IS fragmentation)
AFAIK, the "native" in NaCl means that it is compiled for a given CPU architecture. It is probably independent of the OS, but you still couldn't run an x86 version on ARM, for example.
'
it's noteworthy that google has sort of parallel development going on with NDK for android, which is using native code from within android apps. but that has support for fat x86+arm binaries. now, why couldn't they just do android for chrome?
Re: (Score:2)
> I, for one, like the idea that I can have desktop quality applications running independent of platform on my browser
I for one welcome your new OS overlord :D
The advantage in running everything through the browser is ease of installation and compatibility with all platforms using that browser.
The disadvantage is the security problem such freedom of installation poses, google browser becomes the os, and has to solve every problem the traditional os do. And until EVERYTHING you need has a native client ve
Re: (Score:2)
The whole issue with Native Client is that it is NOT independent of platform. You have to specifically compile for particular hardware architectures; whichever ones your server doesn't have binaries for won't work.
Re: (Score:1)
I don't think its intended to be accessed as a web resource, but a purely local one. Chrome has its own apps and an app store of its own as google intends to use it as an OS on their own devices while still enabling all software on their OS to be cross-platform. So, if you code your app on native client it should run on ANYTHING (OSX, Windows, Linux, & Google Chrome OS), locally. Far as I'm concerned, HELL YEAH.
I'm coding for native client.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
And if you want some native program, then why not to compile the C on the client side (or use LLVM from the beginning)? In that way at least a new platform had a chance to compete. Compiling something for a specific architecture will automatically put all other architectures in a disadvantage.
Re: (Score:2)
That's what PNaCL is for, but it's still in earlier stages.
Re: (Score:1)
We had that shit before with ActiveX.
Native Client runs in a sandbox so it's nothing like ActiveX.
HTML5 does nothing in itself, it still needs some coding to be done in Javascript. While Javascript interpreters did get better and faster it's still far from native speed. And it's still only Javascript. If you have a game developped in C I still don't see how to convert it to Javascript. MAME is one example of a complex C program hard to translate to Javascript but could be ported easily (4 days) to the Native Client platform.
Chrome is available
Re: (Score:2)
Appears to be part of Chromium (Score:2)
Re: (Score:3)
MAME is one example of a complex C program hard to translate to Javascript but could be ported easily (4 days) to the Native Client platform.
Just because it was done in 4 days doesn't mean it was easy. They said themselves it was relatively challenging. And reading through their description of how many things that MAME does are not supported in Native Client, it does indeed look challenging.
This was done by a team of damn good engineers.
Re: (Score:3)
The source is not sufficient. A standard should be discussed and developed in partnership with the other parties, not just "here's a code dump, take it if you want".
Re:Is Google trying to fragment web? (Score:4, Informative)
A standard should be discussed and developed in partnership with the other parties [...]
A lot of standards we have today (Ethernet, HTTP, Javascript, to name a few) were born out of small groups of individuals with no input from other parties, at first. In each case, the new technology became a standard only after it was implemented and proven really useful.
Demanding that every new technology comes out of a committee is insane: it's a great way to stifle innovation.
Now, there is a danger about non-standardized technology: it can be very bad if the creator tries to use it to prevent everyone else from competing in the same area, like was the case with ActiveX. However, I don't see how that would be the case with NaCl: anyone can see how it works, take the code, make it work in any browser (or anything else), and change it at will with no strings attached -- it has a BSD license. It could be a problem if Google refuses to participate in an effort to make a standard out of it, when (and if) it becomes widely used and has competing implementations. But it's way too early to be worried about it -- currently, NaCl is a mere curiosity.
Re: (Score:2)
There's a big difference between forcing everything to go through to committee, and having a strong leadership but with a "release early, release often" approach and seeking input.
And Javascript is a great example of a good technology with bad warts that could've been corrected if he had a little more time to gather feedback. As for HTTP, have you looked at the original spec [w3.org]? The implementation was so simple feedback would've been almost useless.
currently, NaCl is a mere curiosity
Possibly, but NaCl is just an example of what it seems to me a
Re: (Score:3)
There's a big difference between forcing everything to go through to committee, and having a strong leadership but with a "release early, release often" approach and seeking input.
I don't understand your position. Are you suggesting no one should develop anything except in the open and accepting suggestions from anyone, or merely that it might be a good idea to be considered?
Javascript surely would have benefited from input from other people. OR it would never have existed, because Netscape and others would be too busy deciding the features of the language to ship it with Netscape 2.0, and then someone else would do something else first. And maybe the CERN people, after receiving inp
Re: (Score:2)
Re:Is Google trying to fragment web? (Score:5, Insightful)
"write once, run everywhere"
Write once, run in Chrome.
You really want to return to the days when sites required a specific browser to let you in?
Re: (Score:1)
..
You really want to return to the days when sites required a specific browser to let you in?
The biggest problem was that it was not just one specific browser but it was one specific browser on one specific platform.
Re: (Score:2, Insightful)
Native Client is a Chromium project, which means it is open-source, and other vendors can implement it as well.
Right? (IANAL)
Re: (Score:3)
Re: (Score:2)
Once NaCl gets sufficient momentum, I guess other vendors will, simply because it will allow them to access the content provided by the NaCl ecosystem.
ActiveX was not adopted because the technology was just inherently broken.
Re: (Score:2)
"If NaCl gets sufficient momentum." There fixed that for you.
Re: (Score:2)
ActiveX was not adopted because it required (basically) Windows. If you tried porting it to another platform, you'd be onto an never-ending port.
Re: (Score:3)
Because it's smaller than Windows (Score:4, Insightful)
Microsoft lets other browsers implement ActiveX too if they want to. But they don't.
Because they'd have to reimplement the entirety of Windows.
Why would other browsers suddenly start supporting everything Google does, especially non-standard stuff?
Because the Pepper API is a much more achievable target than the entirety of Win32.
Re: (Score:2)
> Because the Pepper API is a much more achievable
> target than the entirety of Win32.
That's not saying much.
The Pepper API is tied to various details of how V8 and WebKit interact, from what I've seen, and has no sane definition other than the implementation. Attempting to actually duplicate it would require enormous resources. Probably less than duplicating win32, but the latter is actually a semi-solved problem (see Wine project).
Re:Is Google trying to fragment web? (Score:4, Insightful)
Re:Is Google trying to fragment web? (Score:5, Insightful)
Java is much more high-level, because it integrates a garbage collector in the VM. This is what makes it a sluggish memory hog.
NaCl does not do that. It allows lean-and-mean code. It is basically like a lightweight version of VMWare/VirtualBox sitting in your browser.
Re: (Score:2)
Re: (Score:2)
NaCI doesn't garbage collect? So it just crashes after a while by using up all memory?
That depends on how you define garbage collection. Some people define it to include only tracing garbage collection using a reachability metric, as used in the Java virtual machine, the .NET CLR, or the Boehm GC. Others define it more loosely to include reference counting schemes like that of CPython, retain/release in Objective-C, and the shared_ptr of Boost and C++11.
Re: (Score:2)
I can't see whats wrong with this as this is a binary and not a website. Mame is ported to many OSs already and by porting it to chrome, it now works on any device that can run chrome. Websites are different though. They're public pages on the web and if they're only written to work in chrome then other browsers would be discriminated against. Chrome is also on windows, mac, linux, ios and android which basically covers everything. When ms was doing their activex shit, ie was only available on windows which
Re: (Score:2)
My bad. It looks like Native Client is windows, Mac and Linux only. Still thats more operating systems supported than activex ever has.
Re: (Score:1)
While we're at it, let's get rid of that pesky Firefox with add-ons that only work under FireFox...
Re: (Score:2)
Firefox addons are full javascript. Plus Chrome supports similar addons.
They've nothing in common with NaCl.
Re: (Score:2)
NaCl is open source, but Mozilla has refused to include it in Firefox.
Also NaCl is quite different from ActiveX, if you have time to read the papers you will see that it is highly secure without hurting the performance much, as the code is analyzed before executing to make sure it won't do anything macilious.
Re: (Score:3)
it is highly secure as the code is analyzed before executing to make sure it won't do anything macilious.
That's not highly secure. That's a challenge.
Re: (Score:2)
With your logic, any attempt at advancing the web can be seen as an attempt to fragment the web.
Re: (Score:3)
I've thought about this a fair amount and have come to the conclusion that Native Client is not at all like ActiveX.
First, ActiveX targeted the Win32 APIs, ensuring that it only works under Windows. Native Client now uses the new Pepper APIs (which is a replacement for the old Netscape Plugin APIs) and runs under Windows, OS X, and Linux.
ActiveX relied on users to decide if a plugin is trustworthy. Native Client uses a sandbox to prevent code from doing anything that a regular web page couldn't do.
Work is u
Re: (Score:2)
NaCl is much more similar to java applets.
And no, MS point of activex was, probably to allow easier plugin implementation (they already had sufficient lock-ins to have 95% of the OS market back then)
Google's goal is obviously client browser control by enforcing Chrome. For one thing, NaCl is actually, well, about running native apps and not writing open apps (web technologies such as html/js/webgl/etc force you to write open apps). For the other, it's terribly difficult to implement in other browsers, and t
Re: (Score:2)
For one thing, NaCl is actually, well, about running native apps
When an NES emulator running in JavaScript runs as fast as an NES emulator in native code, I'll believe you that native code isn't useful.
a few Chrome-only things
If not Chromium, then in which project should developers experiment with new features before proposing their addition to HTML5?
Re: (Score:2)
> Native Client now uses the new Pepper APIs
Which are not so much documented; the only documentation is the implementation. How is that different from Win32?
> and runs under Windows, OS X, and Linux.
That's not all that interesting a metric. More interesting to me is that it only runs on certain hardware platforms, by design, so if it takes off that means no new hardware platforms can arise that can use the web.
Or put another way, if this had happened in 1998, ARM-based phones would have been a non-s
Re: (Score:2)
The problem with HTML is that it actually does not work in every browser (reliably). The reason is that the standard is way too complex. The underlying reason is that it was designed for humans, not for compiler back-ends. Supporting a handful of machine instructions in a reliable and secure way is actually much simpler than supporting the enormous HTML (and javascript, css, etc.) standard.
So, in a way, W3C actually fundamentally fragmented the web when it introduced HTML.
Re: (Score:2)
To be fair, you could use the same argument and say that it's not fair that Firefox extensions don't work in Chrome, Opera, IE, etc.
I mean, I get the web should be all about open standards and everything, but if every browser could the same things as every other browser, why would people even make a choice?
Re: (Score:2)
Unlike HTML5, which you seem to think is magically a cross platform standard, Native Client is all o
Re:Is Google trying to fragment web? (Score:4, Informative)
Re: (Score:1)
Then what, exactly are you trying to say?
ROM images are not some new Web markup technology. They are old tech. Older than the Web itself. They have nothing whatsoever to do with the Web.
MAME is for local use.. Having a plugin for Chrome allows one to open ROMs locally and run them within the browser on tablet devices. This is pretty cool and useful.
It is entirely useless over the Web, however, because who, exactly, is going to open himself up to lawsuits by serving up ROM images of Zaxxon or Frogger ou
Re:Is Google trying to fragment web? (Score:5, Informative)
It's not a plugin. It's integrated in chrome. It's called NaCl aka native client.
the mame emulator is just ran from NaCl just like you load a java applet when you visit the web, except that the java part would be integrated into chrome.
it doesn't work anywhere else. do you call java applets loaded from - the web - local programs?
And there are tons of emulators that work on the web *without* NaCl and which are fully open. Heck there's even a Linux emulator.None of which uses NaCl.
Finally please note that you can't currently run NaCl properly on tablet devices. Also that's *Android* tablet devices, and no, they don't actually ship with Chrome yet.
So you're entire post is very uninformed.
Re: (Score:2)
Re: (Score:2)
PPAPI is, as I understand it, the Chrome-specific plugin API that's implemented by NaCl applications; NaCl itself is integrated into the browser. (I believe they're planning on migrating everything across and dropping support of NPAPI at which point Chromium users will be even more screwed than currently because the version of the Flash plugin that ships with Google Chrome isn't available to anyone using Chromium. Their Google Chrome-only PDF reader plugin already uses PPAPI incidentally.)
Re: (Score:2)
It's not a plugin. It's integrated in chrome. It's called NaCl aka native client.
NaCl works through the Pepper plugin interface, which is a plugin API just like NPAPI is. So NaCl is most definitely a plugin, even if it is bundled in Chrome. For comparison, Flash is also bundled in Chrome, but it is of course still a plugin (it works through NPAPI).
Finally please note that you can't currently run NaCl properly on tablet devices.
You can't run them on anything that isn't x86 or x86_64, and it isn't clear whether we ever will.
Re: (Score:2)
Didn't Google work on something like this recently? It wasn't Go, something else I think.
You mean Dart.
Re: (Score:2)
SPDY is also non-standardized and Google keeps changing the details. Basically, the standard is however Google's implementations happen to behave, and only the client side of them is open. The Firefox developers are working on an implementation but kept running into issues because of this.
The actual extension... (Score:2)
Comment removed (Score:4, Informative)
Re: (Score:2)
Why is this important (Score:3)
It's now possible to make a native client of MAME...which...already was native... uhhh, hmm.
It's not immediately obvious, but there are two advantages in having a program running in NaCl rather than directly on top of the OS:
1) portability: exactly the same code runs in any OS that has a browsers that supports NaCl (right now this means Linux, Mac OS X and Windows);
2) security: users can safely try running it even without knowing if MAME can be trusted (users often are not good at making security decisions); obviously this is not terribly important in this particular case since MAME is free softwa
Re: (Score:3)
Re: (Score:2)
Yeah, but instead of running MAME full-screen, you can now run it inside a web browser. Awesome! I want all my apps to sprout web interface features. Not.
general purpose computing (Score:2)
In light of the discussion here:
http://yro.slashdot.org/story/11/12/30/2159200/doctorow-the-coming-war-on-general-purpose-computing [slashdot.org]
Let me say: Finally, general purpose computing coming to the web!
Besides, if this trend continues, we can finally be relieved of the quirks of web-browsers and just send our applications as-is, without any compatibility problems, and continuous maintenance due to continuously changing browser specs. Apps will JUST WORK (tm). About time.
Re: (Score:2)
But note, if Apple would allow Native Client in Safari, we would be able to run Flash on iOS after all :)
Re: (Score:2)
As long as you're willing to tie your app to particular hardware platforms.
Which is terrible for the future of the web, of course.
Summary (Score:5, Interesting)
- They had to adapt the makefiles because they didn't support cross-compilation. However they did that by using ad-hoc hacks specific to Native Client rather than doing it the right way: they still compile stuff that should be compiled for the host for the target, and then run it on the host with an emulator. They also chose to remove use of makedep entirely, meaning their "port" is not something that anyone can keep or that could be integrated upstream. It's something you can throw away once finished, and that you'll need to redo whenever a new version gets released.
- Native Client runs applications in a minimal virtualized operating system for sandboxing, that only has partial POSIX support and doesn't even have support for the libc fopen/fclose functions (at least this is what the authors claim -- googling about Native Client says it supports POSIX file I/O just fine, and C I/O should be the obvious thing to come with it). The provided libc implements many things as macros, which is a cause for several conflicts. The sandbox also disallows certain classes of instructions because they are "unsafe", and in particular most uses of inline assembly are likely to not work (again, this is what the authors claim, googling says native client supports hand-coded assembly code just fine).
Again, the modifications they did to the code was very ad-hoc and is not proper support for an extra operating system in the MAME codebase, and is therefore not suitable for inclusion upstream.
So finally, they claim something was "relatively challenging" and they did it "in 4 days". This is quite contradictory, if it was challenging it would have taken significantly more time. In particular, for most software, it is not uncommon to take several months to port to another platform, and typically takes much more work than what they've done.
What they did is adapt a piece of cross-platform software to work on an extra platform that is very similar to one other platform it already supports. The process in doing so was fairly straightforward and accessible to any software engineer. They did it quickly and badly, preferring ad-hoc hacks over good software architecture. They didn't fully port it and disabled significant parts of the software and reduced its performance.
Not really a great achievement.
Re: (Score:2)
Argh, forgot to log in before posting...
Re:Summary (Score:4, Insightful)
I'd tend to go with what "the authors claim" rather than your Googling, since this port was done by Google engineers working on Native Client. If they don't know what it does and doesn't do, no one does.
Resume of the person who posted the method of porting:
http://muth.org/Robert/resume.html [muth.org]
You're probably right that they went for a quick and dirty approach rather than future maintainable port. But why not, if that is what met their objective? They obviously want to test/prove/demonstrate the capabilities of Native Client. They can do that by just getting MAME running and pointing to it. It isn't their job to take much longer (several months in your estimation) to make it fully maintainable.
Re: (Score:2)
sure, but a quick and dirty hack only proves some possible potential of the platform, it does not mean its ready for real-world use as no-one wants a platform that only supports a ton of hacking to get it to work.
Until they release MAME in a maintainable form that is supported upstream (as that would be a fine recommendation of fitness for purpose), this is just a toy to be played with.
Re: (Score:2)
Cool. You seem to know what MAME is? What is it? I clicked on the link, but the site doesn't say.
party like its 1999 (Score:4, Interesting)
Sorry, this comment requires Google Chrome 11.56258772331 with WebGL and VP6 installed
Click here to go back
Click here to visit webring
The internet, 1 step forward, 2 steps back, feet together
Re: (Score:3)
I get your point, but please note that WebGL is a web standard (implemented in Firefox, Chrome, Safari, Opera and Internet Explorer) and VP8 (I assume you mean VP8, the video codec used in WebM, and not literally VP6 that's obsolete) has multiple free/open source implementations and even its patents are available with very liberal conditions that make them compatible with free software licences.
WebM unfortunately is not (yet?) part of the HTML standard due to strong opposition from Apple and Microsoft, but
Now what codeing mame to use GPU Cpu for some stuf (Score:2)
Now that will speed it up and maybe make running games that used 3d chips run at a good speed or some kind of on it's own X86 VM for the games that used X86 cpus where you need to emu the input / security boards in them + maybe a 3d card.
Linux in Native Mode? (Score:4, Funny)
I wonder who will construct the crazy mobius loop of running Linux in Chrome's native mode? It'll be google-colored turtles all the way down.
Just run linux in javascript (Score:2)
Just run linux in javascript, someone did that and it is online. You now only have to install Chrome on it to perfect the loop.
MAME and ROMs (Score:3)
I love MAME and have been using it (on and off) since the very early MS-DOS days. The problem with MAME is that most of the needed ROM dumps are still copyrighted, and will remain under copyright for a very, very, very long time and it remains to be seen when they will enter the Public Domain [slashdot.org], if at all.
The MAME community should be on the forefront of the Copyright Term Reduction struggle; freeing up ROMs should be a major goal. Some ROMs, with Exidy being the Shiny Example, have been made available to us, but everything that is not listed here [mamedev.org] should be treated as suspious if not downloaded from a trusted source.
Re: (Score:2)
I fail to see how that can be considered a "problem" of MAME. It's a bit like saying the problem with ATMs is that they won't give you free money. I mean sure, that's a negative, of sorts, but a "problem"?
Personally, I think the situation with MAME is pretty positive... Copyrighted ROMs are pretty freely and widely available, and the gaming ind
Re: (Score:2)
But newer MAME versions won't probably be able to run those ROMs though. Yes, updating ROMs and MAME annoying. :(
15 years old? (Score:2)
Uh, MAME isn't 15 years old yet according to http://mamedev.org/history.html [mamedev.org] ... On 2/5/2012, it will be. Or did I miss something? :(
Re: (Score:2)
Ah thanks. How did you remember that? [grin]
Re: (Score:2)
Hahaha. Belated happy birthday. I have a coworker whose birthday is on Christmas eve as well. :)
I want to play game, how to? (Score:2)
There's all this bickering in this thread along the usual lines of programming nuances and security blah blah blah which is fine and good but how about for the people who just want to see how this thing does with a few of their favorite ROMs?
Anybody actually have this installed (preferably on a GNU-Linux installation) and care to point out how they went about it?
Re: (Score:2)
Hey, that's more like it. But I'm not a big Robby Roto fan. How about using local roms?
emscripten and JSLinux suggest this is irrelevant (Score:2)
emscripten [emscripten.org] can compile C code, or anything that can produce LLVM bitcode, directly into JavaScript, allowing heavyweight code like Ruby/Python/Lua, physics engines, raytracing, FreeType, text-to-speech, etc. to run in a browser. JSLinux [bellard.org] emulates the 386 instruction set to the point it can boot a stock Linux kernel, start a terminal, and run ELF executables like the Busybox command-line utilities in a browser (JSLinux's Fabrice Bellard could probably do MAME in JavaScript in his sleep one-handed.) So despite
Re: (Score:2)
99%+ of Android devices use ARM so the current form of NaCL can't work (and it still doesn't actually work on the rest).
The Chromebook hardware can't run their current killer-app Bastion (not enough VRAM). They also really mean it when they say ChromeOS doesn't come with any native Apps. The is a small command line shell and SSH (sandboxed but not plain NaCL) and the Browser, nothing else.
Currently emscripten's graphics output is too slow to usefully run Mame. A more interesting project would be to compile