Forgot your password?
typodupeerror
Google Emulation (Games) Games Technology

MAME Running In Chrome 165

Posted by timothy
from the ok-now-iterate-and-1-and-2-and-switch dept.
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."
This discussion has been archived. No new comments can be posted.

MAME Running In Chrome

Comments Filter:
  • by SharkLaser (2495316) on Sunday January 01, 2012 @06:58AM (#38555122) Journal
    We had that shit before with ActiveX. We need standards, not some stuff that only works in Chrome. However, I guess it's better for Google - now they have something that only works with Chrome. So when new users go to some web site it will say that they need to download and install Chrome to use it. Old users will also be locked to Chrome.

    Don't do that. Only use standards like HTML5 that work in every browser.
    • by errandum (2014454) on Sunday January 01, 2012 @07:07AM (#38555142)

      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)

      • by Anonymous Coward

        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.

      • by raburton (1281780) on Sunday January 01, 2012 @09:04AM (#38555466)

        > 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.

        • 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)

            by aloniv (1972020)

            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]

          • by Firehed (942385)

            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.

        • by Hatta (162192)

          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.

        • by YA_Python_dev (885173) on Sunday January 01, 2012 @10:47AM (#38555852) Journal

          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.

          • by makomk (752139)

            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 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

        • Well, as far as I'm concerned, you are right... Until Firefox has a competing implementation. At that point, it's a standard.
          Also, so long as it's /architecture/ independant - I.e. can be compiled for ARM or any other arch you want... Great!

        • by Macrat (638047)

          Why don't we all just run Windows and use ActiveX?

          How about Java applets?

          Anyone remember Java WebStart?

      • by hairyfeet (841228)

        Uhhh...because no matter how smart Google engineers THINK they are the malware writers are smarter? As the first poster said look at the history of ActiveX. When it first came out it was like a Godsend, an easy to use way to just host an app on your server and have ALL the branches instantly have access to it or to do the same for your customers. No rollout headaches or compatibility problems it all "just worked" but before you could say "Oh shit!" every malware writer and his cat and his cat's squeaky toy

        • by Justin_Schuh (322319) on Sunday January 01, 2012 @11:38AM (#38556164)

          I can appreciate your confusion, but comparing NaCl to ActiveX doesn't really make sense. Once you instantiate an ActiveX control it runs arbitrary code at your full user privilege. Whereas NaCl is much more accurately compared to the restricted execution environment of a virtual machine, such as Java, .NET CLR, or even JITed JavaScript. It's just that NaCl virtualizes a well-defined subset of an existing hardware instruction set, rather than one developed specifically for it. That virtualization (and the associated instruction validation) is the primary security mechanism, and is typical of a VM environment. The process sandbox is just a defense-in-depth measure (and a very strong one) layered underneath an existing VM sandbox.

          However, there's no reason to take my word for it. If you research it a bit you should find that NaCl has a comparable or (in most cases) a more robust security model compared to the web-delivered execution environments most people are already running.

      • by TeknoHog (164938)

        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.

        • by gl4ss (559668)

          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?

      • > 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

      • by BZ (40346)

        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.

    • by Anonymous Coward

      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.

      • So why make it again, and especially why bundle it with browser? There is Adobe AIR already and it works with every browser, not just Chrome. And on every platform, too.
    • by drolli (522659)

      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.

    • by 51M02 (165179)

      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

      • Chromium is open source, Chrome is not.
      • 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.

      • 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".

        • by FrangoAssado (561740) on Sunday January 01, 2012 @12:38PM (#38556590)

          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.

          • 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

            • 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

    • NativeClient programs = ChromeOS programs NativeClient support in the Chrome browser creates incentive to write NativeClient apps: write once, run everywhere.
      • by JanneM (7445) on Sunday January 01, 2012 @07:39AM (#38555248) Homepage

        "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?

        • by Anonymous Coward

          ..

          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)

          by StripedCow (776465)

          Native Client is a Chromium project, which means it is open-source, and other vendors can implement it as well.
          Right? (IANAL)

          • That still doesn't change anything. Microsoft lets other browsers implement ActiveX too if they want to. But they don't. Why would other browsers suddenly start supporting everything Google does, especially non-standard stuff?
            • 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.

              • "If NaCl gets sufficient momentum." There fixed that for you.

              • by gbjbaanb (229885)

                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.

            • by chrb (1083577)
              Microsoft never released the source code for free, though. The probability of uptake is higher if other browsers are given a free implementation.
            • 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.

              • by BZ (40346)

                > 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).

      • by deniable (76198) on Sunday January 01, 2012 @08:07AM (#38555338)
        Java programs = JVM programs Java support in the browser creates incentive to write Java applets: write once, run everywhere. Been there, done that. Didn't get a t-shirt.
        • by StripedCow (776465) on Sunday January 01, 2012 @09:02AM (#38555462)

          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.

          • by deniable (76198)
            But this time it's different. I've heard that before. Thanks for the sales pitch.
    • by shione (666388)

      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

      • by shione (666388)

        My bad. It looks like Native Client is windows, Mac and Linux only. Still thats more operating systems supported than activex ever has.

    • by Anonymous Coward

      While we're at it, let's get rid of that pesky Firefox with add-ons that only work under FireFox...

      • Firefox addons are full javascript. Plus Chrome supports similar addons.
        They've nothing in common with NaCl.

    • by Clarious (1177725)

      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.

      • by MichaelJ (140077)

        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.

    • With your logic, any attempt at advancing the web can be seen as an attempt to fragment the web.

    • by supersat (639745)

      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

      • 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

        • by tepples (727027)

          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?

      • by BZ (40346)

        > 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

    • 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.

    • by Ihmhi (1206036)

      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?

    • by Locutus (9039)
      lighten up Frances! This stuff is open source, unlike ActiveX(also known as CaptiveX ). And besides, even if it were technically defined as a "standard" it would still only be available in Chrome initially and other vendors would have to do the work. Since it is open source, other vendors are welcome to use it, implement it in their product(s) and even join in the development just like an official "standard".

      Unlike HTML5, which you seem to think is magically a cross platform standard, Native Client is all o
  • Amazing! (Score:4, Informative)

    by Gaygirlie (1657131) <gaygirlie.hotmail@com> on Sunday January 01, 2012 @07:19AM (#38555178) Homepage

    It's now possible to make a native client of MAME...which...already was native... uhhh, hmm.

    • by tepples (727027)
      All this means is that if you already have an application written in a language that compiles to native code, such as C or C++, you can deploy it easily to Chrome users. So if you've made a new video game that runs on a PC, you can port it to the Pepper API and make a playable demo available to Chrome users (and any IE users willing to install the Google Chrome Frame BHO).
    • 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

      • by mounthood (993037)
        You didn't mention the biggest benefit: no deployment hassles! Imagine taking a C/C++ app your company depends on and won't let go of, recompiling it to work with NaCl, and it's instantly distributed to all clients. Nighty changes would be easy for everyone. Caching is built-in. Troubleshooting an install is dead simple; clear the cache and click the link again.
    • by gr8_phk (621180)

      It's now possible to make a native client of MAME...which...already was native... uhhh, hmm.

      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.

  • 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.

    • But note, if Apple would allow Native Client in Safari, we would be able to run Flash on iOS after all :)

    • by BZ (40346)

      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)

    by Anonymous Coward on Sunday January 01, 2012 @07:51AM (#38555290)

    - 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.

    • by loufoque (1400831)

      Argh, forgot to log in before posting...

    • Re:Summary (Score:4, Insightful)

      by BasilBrush (643681) on Sunday January 01, 2012 @08:37AM (#38555416)

      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.

      • by gbjbaanb (229885)

        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.

    • 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)

    by Anonymous Coward on Sunday January 01, 2012 @08:41AM (#38555422)

    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

    • 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 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.

  • by rossjudson (97786) on Sunday January 01, 2012 @11:50AM (#38556252) Homepage

    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.

  • by CanEHdian (1098955) on Sunday January 01, 2012 @01:35PM (#38556890)

    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.

    • by evilviper (135110)

      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,

      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

  • 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?

  • 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

    • 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

A bug in the code is worth two in the documentation.

Working...