Auralux Release For Browsers Shows Emscripten Is Reaching Indie Devs

New submitter MorgyTheMole writes Porting C++/OpenGL based games using Emscripten and WebGL has been an approach pushed by Mozilla for some time now. Games using the technology are compatible with most modern browsers and require no separate install. We've seen Epic Games demonstrate UnrealEngine 4 in browser as well as Unity show off a variety of games. Now as the technology matures, indie devs are looking to get into the mix, including this near one-to-one port of E McNeill's Auralux, a simplified RTS game, from Android and iOS. (Disclosure: I am a programmer who worked on this title.)

Comments

I appreciate your hard work

[Anonymous Coward]

but please leave real development to real developers that use real technologies on real platforms. No, we don't need 8 core machines with 16gb of ram to be able to play a game that late-90s computers could've handled natively. Games do not belong in the browser.

Re:I appreciate your hard work

[Anonymous Coward]

Exactly.

The html5/javascript platform is inferior, FAR inferior to native code,
HARDWARE-Drivers-HAL->Operating System->DirectX->Web Browser->Javascript->Emscriptem->Game

Or the current flavor of the decade:
HARDWARE-Drivers-HAL->Operating System->Virtualization Layer(eg VMWARE)->Drivers->HAL->Operating System -> DirectX->Web Browser->Javascript->Emscriptem->Game

It's quite honestly stupid when a game console with 1/4 of the CPU and GPU power can beat a desktop machine.

Re:I appreciate your hard work

[Anonymous Coward]

Oh please, the same arguments were made when API's like DirectX first started surfacing. You may as well argue that unless you're programming directly at the assembly level, you're wasting your time.

There are plenty of valid reasons for pushing this technology to the web browser. Nobody's claiming that all your future AAA games will be browser based, but it's currently the best way of making an interactive experience that's not tied to a specific platform. It makes the most sense for indie devs as well, who chances are won't be pushing the hardware to its limits anyway. I don't see you blasting the bigger indie titles like Fez, Towerfall, Braid, etc. because they run like crap for the hardware they require - because your hardware is still plenty fast that it doesn't matter.

That's the bit you have missed - it doesn't matter. Who cares if running native is 10x faster, if you can still get 60FPS?

Re:I appreciate your hard work

[Anonymous Coward]

Why would you WANT to develop a game for the browser? Just like I don't want to give up my background in actual computer science and strongly-typed languages for the sake of learning a mountain of flubbery web technologies, I suspect the answer will be exactly what that other dude said: the web made us all LAZY. JavaScript is a shitty language, pure and simple, and I seriously doubt you want to switch from it for that very reason.

Have you ever developed a complex application in a more native language, even Java? It's beautiful. It's controlled. It's tight. It IS portable. It is pure software, not Marketing determining what you work on 75% of the time because you need more clicks and conversions. In quality languages, you can declare variables unmodifiable (or at least, in Java, un-reassignable) via keywords. Hell, people harp on it because it's not PRETTY by default, but Swing is actually a pretty fucking powerful GUI framework.

It's really gotten to the point of absurdity. Mobile devices as somewhat of a refreshing "reboot" with native apps, I miss my goddamn downloaded Winamp and ICQ.

Re:I appreciate your hard work

[TheRaven64]

Oh please, the same arguments were made when API's like DirectX first started surfacing. You may as well argue that unless you're programming directly at the assembly level, you're wasting your time.

DirectX came with some advantages as well though. Like OpenGL, you ended up with a slower game than writing specialised code for a specific graphics accelerator, but the trade was that you got to support all shipping accelerators (and ones that hadn't shipped yet) by allowing them to write the code once and get a speedup everywhere. With Direct2D, you got things like accelerated sprite drawing from hundreds of graphics cards that all had different interfaces for bit blits. This meant that your Direct2D game would often be faster than a DOS version that was talking to the VGA hardware (or SGVA via VESA) and doing the same thing entirely in software.

An abstraction layer that has a small cost but buys you acceleration support in exchange is worthwhile, because the net result is faster (and simpler) code. An abstraction layer that has a big cost and doesn't give you faster code much harder to justify.

Re:I appreciate your hard work

[MorgyTheMole]

I don't believe you are familiar with this tech then. Asm.js with Emscripten runs at around 50% of native speed on the browser. With C++, this means it is near java or C# equivalency. You don't need an 8 core machine with 16 gb of ram to play this game at all. We achieve getting players to try our game with a single click in a compile-once cross-platform setting. The base code is the same that runs on Android and iOS. Low fragmentation, high yield, instant access. If you can't see the benefits, then you can't see the forest for the trees.

Re:I appreciate your hard work

[Anonymous Coward]

Learn what Emscripten is and does before you start saying such odd things. The entire point is to use whatever language you want, and it complies down to a subset of JS that the browser can run fairly closely to native speeds (1.5-2x as slow so far, and a lot of optimizations haven't been enabled yet like SIMD instructions). Basically it's just like the JVM, just less optimized right now (both in terms of performance and the libraries/API that are exposed).

Honestly, I think people are way too uneducated about the things they're ralling against. This is just making the web a more productive place for traditional coders, who might not need the absolute best performance but want the widest audience possible.

I jut tried it

[JanneM]

Just tried it a little. And it really seems to work flawlessly. Smooth graphics and gameplay, and music and sound effects come through just fine. And it's a very nice abstract game too; reminds me more than a little of Osmos in both style and pacing.

Re:I jut tried it

[Bugamn]

To me it seems more like a clone of Galcon or Eufloria, nothing like Osmos except for the pretty lights. You have fleets, you send those fleets to conquer suns.

Would this work for CrystalSpace 3d?

[GoodNewsJimDotCom]

Just curious if this would work for CrystalSpace 3d. I have experience with that engine, and I've been considering making an Xwing vs TieFighter MOBA.

gyring and gimbling

[phantomfive]

I read that headline in the same way as I would read the Jabberwocky. Maybe a better headline would be, "C++ compiled to Javascript in a Real Game." Or something like that.

I guess this kind of thing will become more common as Flash recedes into irrelevance.

Re:Works in Safari

[Anonymous Coward]

If you change the user agent to Chrome - Mac. Seems fairly CPU intensive though, managed to get the fans on my MacBookPro spinning up fairly quickly. That could just be the WebGL implementation in Safari not being so crash hot though.

I don't know that Safari's JavaScript engine can optimize for asm.js yet, so I'd guess it's the JavaScript more than the WebGL. Asm.js JavaScript works everywhere, but Firefox and Chrome detect and optimize for asm.js specifically and get really high performance figures as a result.

FFS just put LLVM into the browser

[silfen]

Just create a sandboxed version of LLVM and put it into the browser. Or maybe Firefox can adopt NaCl. But translating C into LLVM into JavaScript because a small number of vendors can't be bothered to put an open source plugin into their browser is just ridiculous.

Re:FFS just put LLVM into the browser

[viperidaenz]

Yeah, because browsers need more plugins.

One sandbox is bad enough. Start adding more and you increase the attack surface.

Re:FFS just put LLVM into the browser

[Anonymous Coward]

Google already tried that with Pepper, the other browser vendors wouldn't bite.

There is way too many cruft layers already:
Game-Unity(Game Engine)-DirectX/OpenGL-Operating System-HAL-Drivers-Hardware
So you throw Emscripten in to it and now it's
Game-Unity(Game Engine)-[emscriptem-web browser]-DirectX/OpenGL-Operating System-HAL-Drivers-Hardware

Re:FFS just put LLVM into the browser

[loufoque]

NaCl is the next version of Pepper.

Re:FFS just put LLVM into the browser

[BitZtream]

NaCl is the core of Pepper. Pepper is just a NaCl plugin. They are the same thing for anything less than the most technical of discussions.

Salt and Pepper, git it?

Re:FFS just put LLVM into the browser

[loufoque]

My understanding is that pepper as a public API is being discontinued, NaCl (which relies on pepper in its implementation), will be the the next public API.

Change the title

[viperidaenz]

Auralux Release For Browsers Shows Emscripten Has Reached MorgyTheMole

Just because you can do something

[AuMatar]

Doesn't mean you should. Congratulations- you managed to write your app in the least effective way possible and got both the performance of javascript and the ease of writing code in C++. You are the biggest idiot on slashdot today. Your reward is getting to write a nice check to Dice for the slashvertisement.

Re:Just because you can do something

[squiggleslash]

He's written a high performance game using technologies that are cross platform, have widespread familiarity, and that allow code to be distributed in a form users are finding preferable to older ways of doing things (ie "just works" rather than "install app, then run")

I don't see the problem. Sure, our Netscape-based Web is showing its age, and we could do with a shake-up of much of it, but OTOH is Javascript (not JS+DOM, just Javascript)+OpenGL really so bad? You know half of Slashdot would be having orgasms if it were written in Python or Ruby, and neither language's performance is any better than Javascript these days.

Re:Just because you can do something

[DeVilla]

I'm amazed your comment is marked insightful. Admittedly, I wouldn't call asm.js ready for prime-time, it is interesting technology and it will take lunatics like this guy to exercise it just like it took lunatics 15 to 20 years ago to port Doom and Abuse to Linux to begin to see what needed improvement.

I don't plan on buy games for my web browser, but that doesn't mean that an optimized javascript environment couldn't go somewhere as a portable environment. The good parts of javascript are far more elegant than java. I applaud this nut job.

Re:Just because you can do something

[DeVilla]

Nevermind. It runs slow in my outdated browser. It sucks and the developer should feel bad.

Negotiating around cryptographic lockdown

[tepples]

A lot of machines are cryptographically locked down to run only executable files approved by the network administrator or by the machine's manufacturer. Indie developers often lack the clout to negotiate with said administrators and manufacturers. The advantage of JavaScript is that you don't need such clout to get an application to run.

Re:Negotiating around cryptographic lockdown

[AuMatar]

So you're saying that the advantage of this is being able to work around the security restrictions on a machine- and you think this is a good thing?

Of course any such machine will have javascript turned off anyway.

Re:Negotiating around cryptographic lockdown

[squiggleslash]

No, he's saying the advantage is that it works with, not around the security restrictions of many modern platforms, from ChromeOS to iOS.

The purpose of those restrictions in general is to prevent applications from running that do bad things, rather than to prevent the user from actively doing things they want to do. A webpage isn't going to monitor my keystrokes, replicate itself to send to other users, read my email, or even innocently change system settings or upgrade a DLL that happens to cause a techie a headache for several hours later.

(With iOS, of course, there's also the $$$ motive for Apple for disallowing the installation of apps it doesn't approve, but from memory part of the problem is that iOS's app security model is horrendously insecure, so if they allowed arbitrary app downloads and installs, it would be a major problem. OTOH maybe they fixed that.)

Re:Negotiating around cryptographic lockdown

[AuMatar]

No, the purpose is to prevent unknown code from running at all. It doesn't matter if its in a sandbox or not. It's an end run around the security, and that's always a bad thing.

Re:Negotiating around cryptographic lockdown

[squiggleslash]

No, in the case we're talking about, the purpose is to ensure code doesn't do bad things. If the code is sandboxed, and it is in this case, and the code has been deliberately run by the user, then it's working WITH the security, not AROUND it.

You can continue to pretend otherwise, but before you do, you'll have to write a 2,000 word essay on how virtually every website built in the last ten years "circumvents" ChromeOS's (and iOS's, etc) security because almost all of them include "unknown code" (written in Javascript, usually to animate something, or validate a form, or whatever) which ChromeOS doesn't "prevent" from running due to some unforeseen MAJOR SECURITY HOLE in that platform.

Don't forget to explain to us too how it's a bad thing for a sandboxed application to run in its sandbox, as designed.

As an alternative to doing so, look up that word "sandbox" you just used and ask yourself what its purpose is, and why it would be implemented in web based operating systems if the very concept of running unknown code is itself considered a security hole regardless of whether the code runs in a sandbox or not...

Native

[Dan East]

If your game is written in C++ and OpenGL you can already compile natively for Windows, OSX, iOS, Android and Linux.

Pay for Speed?

[TheBilgeRat]

Although I enjoyed the game enough to waste 20 minutes on it, I am less than impressed with a "Pay to not watch the grass grow" model of business. So, while it may run blazingly fast, I'm not going to pay to see if that's the case.

As it is, it seems painfully slow, and more than a bit of a rip-off of games like these ones I can play for free in my browser with no speed issues.

I'm just not seeing the value.

Re:Works in Safari

[TheRaven64]

It launched for me after doing that, but didn't actually work. It ran in FireFox, using about 50% of one core of a 2.2GHz i7 (Haswell). The same game runs very happily on a 1GHz ARM core, but I don't know what percentage of the CPU it's using there. Aside from being slow, the UI really sucks (I managed to zoom in, but not to zoom out). On a touchscreen device, I really liked the Auralux UI.

Just because you can do something

[SoftwareArtist]

Congratulations, you're being a troll. They managed to take their existing app written for a completely different platform, and port it to the web in a way that runs flawlessly on my four year old laptop. Without having to rewrite the whole thing by hand in Javascript. I'd call that a big win, and a really cool achievement.