Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Auralux Release For Browsers Shows Emscripten Is Reaching Indie Devs

Soulskill posted about a month and a half ago | from the hope-your-servers-are-ready dept.

Real Time Strategy (Games) 44

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

cancel ×

44 comments

Sorry! There are no comments related to the filter you selected.

I appreciate your hard work (2, Insightful)

Anonymous Coward | about a month and a half ago | (#47660679)

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.

And on that note.... (0)

Anonymous Coward | about a month and a half ago | (#47660691)

Any benchmarks on the performance loss of the browser based version against either the apk version on the same hardware, or a PC version on both bare hardware and browser?

Re:I appreciate your hard work (1)

Anonymous Coward | about a month and a half ago | (#47661307)

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 (2, Insightful)

Anonymous Coward | about a month and a half ago | (#47661393)

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 (0)

Anonymous Coward | about a month and a half ago | (#47661637)

This game ran like crap for me. 6 core AMD machine, 6gb ram, Chrome.

Re:I appreciate your hard work (0)

Anonymous Coward | about a month and a half ago | (#47662557)

And the sound is crap/choppy on an iMac running Mavericks. A shame considering having the appeal of this game is supposed to be its music content.

Re:I appreciate your hard work (1)

Anonymous Coward | about a month and a half ago | (#47661689)

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 (1)

Anonymous Coward | about a month and a half ago | (#47663795)

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.

Re:I appreciate your hard work (1)

TheRaven64 (641858) | about a month and a half ago | (#47662327)

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 (0)

Anonymous Coward | about a month and a half ago | (#47661413)

If people reasoned with efficiency in mind you would not have anything on www but static pages. It would be a better world, but in this one people will browse on their multicore workstation for flash games because they heard it from a friend, when damn serious games able to be played on three generations older machines are one install away.

This is the games equivalent of twitter taking over irc, of facebook taking over rss. Could work, could fail like all twitter and facebook precursors and wannabees.

web2.0 made us LAZY. Captcha: annoyed

Re:I appreciate your hard work (1)

MorgyTheMole (932893) | about a month and a half ago | (#47662991)

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 (0)

Anonymous Coward | about a month and a half ago | (#47664487)

Says someone who isn't a real developer nor could tell a real developer from someone who isn't.

I jut tried it (1)

JanneM (7445) | about a month and a half ago | (#47660745)

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 (1)

Bugamn (1769722) | about a month and a half ago | (#47667345)

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? (1)

GoodNewsJimDotCom (2244874) | about a month and a half ago | (#47660769)

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 (1)

phantomfive (622387) | about a month and a half ago | (#47660773)

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:gyring and gimbling (0)

Anonymous Coward | about a month and a half ago | (#47660821)

Yes, I'm real happy to see how advertisers write their ads in C++ then compile it to js to annoy the shit out of us.

Works in Safari (0)

Anonymous Coward | about a month and a half ago | (#47660775)

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.

Re:Works in Safari (4, Interesting)

Anonymous Coward | about a month and a half ago | (#47660921)

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 [asmjs.org] JavaScript works everywhere, but Firefox and Chrome detect and optimize for asm.js specifically [mozilla.org] and get really high performance figures as a result.

Re:Works in Safari (1)

TheRaven64 (641858) | about a month and a half ago | (#47662769)

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.

FFS just put LLVM into the browser (1)

silfen (3720385) | about a month and a half ago | (#47661045)

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 (1)

viperidaenz (2515578) | about a month and a half ago | (#47661165)

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 (1)

Anonymous Coward | about a month and a half ago | (#47661339)

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 (1)

loufoque (1400831) | about a month and a half ago | (#47661927)

NaCl is the next version of Pepper.

Re:FFS just put LLVM into the browser (1)

BitZtream (692029) | about a month and a half ago | (#47662585)

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 (1)

loufoque (1400831) | about a month and a half ago | (#47662711)

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.

Re:FFS just put LLVM into the browser (0)

Anonymous Coward | about a month and a half ago | (#47663839)

I honestly think you have your perspective ass-backwards.

NaCl is Google's "not invented here" version of this, but no one else wants to use it because they already have their own runtimes, and it's not like JS is going away anytime soon, so you're really askinh every browser vendor to adopt TWO runtimes. That's ludicrous! ASM.JS is superior in that regard - vendors will have a much easier time implementing it, and they won't need to bloat their browsers even more for the privilege.

Emscripten is an LLVM target, so I don't understand what the point of sandboxing LLVM would be other than bloating the browser just like NaCl. Again, JS is already all over the web, and we're not getting rid of it. Why bother adding even more bloat? Just focus on migrating to a native bytecode instead of using asm.js... that's much more manageable than forcing people to adopt LLVM or NaCl.

Change the title (1)

viperidaenz (2515578) | about a month and a half ago | (#47661159)

Auralux Release For Browsers Shows Emscripten Has Reached MorgyTheMole

Just because you can do something (2, Insightful)

AuMatar (183847) | about a month and a half ago | (#47661169)

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.

Negotiating around cryptographic lockdown (1)

tepples (727027) | about a month and a half ago | (#47662001)

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 (1)

AuMatar (183847) | about a month and a half ago | (#47663443)

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 (0)

Anonymous Coward | about a month and a half ago | (#47663735)

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.

Machines that are cryptographically locked down and only run executable files approved by the machine's manufacuturer include smartphones (the user can override this in Android and some minor OSes, but not in iOS or Windows Phone) and game consoles. Being able to run code with minimal permissions is good security practice. Google's NaCl was an attempt to do similar sandboxing for native code... but Mozilla's asm.js is actually very similar and the early prototypes only had a 2x slowdown over native code with not much in the way of optimization. I don't know the current stats.

Re:Negotiating around cryptographic lockdown (1)

squiggleslash (241428) | about a month and a half ago | (#47664563)

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 (1)

AuMatar (183847) | about a month and a half ago | (#47664627)

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 (1)

squiggleslash (241428) | about a month and a half ago | (#47664827)

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

Re:Just because you can do something (1)

squiggleslash (241428) | about a month and a half ago | (#47663095)

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.

Just because you can do something (1)

SoftwareArtist (1472499) | about a month and a half ago | (#47666099)

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.

Re:Just because you can do something (1)

DeVilla (4563) | about a month and a half ago | (#47678755)

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 (1)

DeVilla (4563) | about a month and a half ago | (#47678793)

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

Crysis? (0)

Anonymous Coward | about a month and a half ago | (#47661587)

Yes, but will it run Crysis?

Re: Crysis? (0)

Anonymous Coward | about a month and a half ago | (#47663053)

yes it does ;)

Native (1)

Dan East (318230) | about a month and a half ago | (#47662165)

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

Pay for Speed? (1)

TheBilgeRat (1629569) | about a month and a half ago | (#47662583)

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 [armorgames.com] .

I'm just not seeing the value.

This is not an article (0)

Anonymous Coward | about a month and a half ago | (#47663803)

It's a blatant ad.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?