Announcement

Collapse
No announcement yet.

Mozilla Brings Unreal Engine 3 To Firefox

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • phoronix
    started a topic Mozilla Brings Unreal Engine 3 To Firefox

    Mozilla Brings Unreal Engine 3 To Firefox

    Phoronix: Mozilla Brings Unreal Engine 3 To Firefox

    For showing off the power of its JavaScript engine with Firefox, Mozilla collaborated with Epic Games to bring a JavaScript-based version of Unreal Engine 3 for the web...

    http://www.phoronix.com/vr.php?view=MTMzNzc

  • GreatEmerald
    replied
    Originally posted by TheLexMachine View Post
    I keep hoping we'll get a port of the original Unreal. That's the only decent Unreal-series game I've ever played. The rest were not at all interesting despite their superior graphics.
    You're in luck, then. It's already done. See this: http://www.oldunreal.com/oldunrealpatches.html It includes Linux binaries, and is still in active development. Post in these forums if you find any bugs: http://www.oldunreal.com/cgi-bin/yabb2/YaBB.pl

    Leave a comment:


  • directhex
    replied
    Originally posted by TheLexMachine View Post
    I keep hoping we'll get a port of the original Unreal. That's the only decent Unreal-series game I've ever played. The rest were not at all interesting despite their superior graphics.
    We're not talking about Epic's Unreal games specifically though, we're talking about the engine.

    UE3 has been used for dozens of games. Borderlands, Batman, Dishonored, Mass Effect, etc.

    Leave a comment:


  • TheLexMachine
    replied
    I keep hoping we'll get a port of the original Unreal. That's the only decent Unreal-series game I've ever played. The rest were not at all interesting despite their superior graphics.

    Leave a comment:


  • directhex
    replied
    Originally posted by schmidtbag View Post
    Makes me wonder if any/all existing UE3 games will work on linux now
    It's not that simple. UnrealEngine 3 from 2012 isn't UnrealEngine from 2011 isn't UnrealEngine from 2010 and so on - developers take a snapshot of the master UnrealEngine code, and hack on it from there. There's a fair amount of porting work involved in doing a major update to the engine, depending on how customized a specific game's copy of UE3 is.

    Not to mention the common use of (platform-specific) middleware in addition to UE3, such as Havok or Wwise. Even if a game were using exactly the right version of UE3 to be easily recompiled using this WebGL port (unlikely) or the Dungeon Defenders Linux port (equally unlikely), then using third party middleware with no Linux port, like Wwise, kills it.

    This port going into the mainline UE3 source tree will help a lot (the Dungeon Defenders Linux port is not in mainline UE3, it's available only from Trendy Entertainment), but only for new games without fancy features that necessitate use of middleware.

    Leave a comment:


  • Kristian Joensen
    replied
    Originally posted by smitty3268 View Post
    Javascript doesn't have to be that slow, if you've got a modern JIT compiler. The whole point of asm.js is to get a subset that can be optimized well and use emscriptem to port everything easily. Don't mistake DOM performance in a browser with javascript.


    99% of games use a scripting language for most of their code. They just have a small c++ engine that does all the low level stuff. And most games are bound by GPU performance more than CPU anyway.

    I agree you aren't going to see Bioshock Infinite in WebGL anytime soon, but all you have to do is look at this demo to see that some impressive stuff is already possible.
    AFAIK even engines with scripting languages that get extensively used like Unreal Engine 3 are still more than 1 million lines of C++ code. We are talking many different subsystems here, Rendering, Lighting(These first two have shaders thrown in as well), Visibility determination, Animation, Sound, AI, Networking, Tools, etc

    Leave a comment:


  • IanS
    replied
    Originally posted by Kristian Joensen View Post
    Which one would that be?
    Painkiller: Hell & Damnation is in the process of being ported, that is probably the one.
    http://www.phoronix.com/scan.php?pag...tem&px=MTMyMDc

    Leave a comment:


  • alexThunder
    replied
    I heard that Oracle's Nashorn should do well. If I remember correctly, they might reach the speed of Java with JS.

    Originally posted by F i L View Post
    Which part and how so?
    Most AAA game companies wont even consider using anything but C++ cause no other language (currently) offers tight control over SIMD instructions.
    OpenCL?

    Leave a comment:


  • liam
    replied
    Originally posted by F i L View Post
    lol, wut? Javascript has... dynamic typing, dynamic prototype based object structures, variable tagging (v8) with 31bit ints, etc... there may be some obscure way to get JS to work at slightly okay performance, or extend the syntax in some human-unreadable way to allow strict compilation rules (eg asm.js), but as it is Javascript is a horribly slow, bug-prone language only suitable for it's original purpose: website scripting.

    NaCL and Dart are much better options than trying to fit a square shape (javascript) into a round whole (efficiency).
    JS is already really fast as far as interpreted languages go, but what moz is pushing here are a subset of js features which gets rid of GC, dynamic typing and boxed values.
    That is how they get the speeds that are within a factor of 2 of C. The guys behind it claim they can do even better.
    What I'd love to see is a way to turn js into asm.js (when appropriate, obviously), but the ability to write for the web with your language of choice (say, ruby) and expect to get really good performance without plugins is frickin amazing.

    Leave a comment:


  • smitty3268
    replied
    Originally posted by F i L View Post
    JIT doesn't matter, because every variable lookup (or assignment in V8's case) requires expensive searching overhead. There isn't much to get around this, though they keep adding in a lot of complex static analysis to optimize code, at some point things break down because of JS's dynamic design.
    Modern JIT engines cache variable lookups, so it's only slow the 1st time you access it for each object type.

    Anyway, like i said i see this as more useful for Flash type games, which javascript should handle perfectly well. No one is talking about running AAA games in html for more reasons than just javascript performance.

    Leave a comment:

Working...
X