Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 24

Thread: Mozilla Brings Unreal Engine 3 To Firefox

  1. #11
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,399

    Default

    That's interesting, I'd like to see Epic Citadel just working like that on stock Firefox. Also, hah, the trailer used the soundtrack from UT3, complete with UT3 sounds in the background. Pretty funny, but not very fitting for the Citadel views.

  2. #12
    Join Date
    Jan 2013
    Posts
    512

    Default

    Quote Originally Posted by Kristian Joensen View Post
    Which one would that be?
    I think he may be referring to Bananabread, the Saurerbraten port that uses Emscripten too.
    It may be debatable that it's a good FPS, but it's an interesting demo none the less.
    https://developer.mozilla.org/en-US/...nabread/launch

    @F i L
    While Javascript might not be the ideal choice, its performance is still limited to the interpreter, which Mozilla seems to be making an effort with too.
    http://techcrunch.com/2013/03/21/fir...native-speeds/

  3. #13
    Join Date
    Sep 2007
    Location
    Connecticut,USA
    Posts
    941

    Default

    Quote Originally Posted by e8hffff View Post
    Arguably it's in a small canvas in Firefox. It's good to see people moving toward Javascript use as there's no reason for JS not to be super fast language.
    With proper optimizations JS can indeed be a fast and relatively versatile language well suited for running applications within a web browser as if they were locally installed. Fast CPUs/GPUs should be able to handle JS quite well so games written in JS could definitely be quite playable in the browser.

    Browser based games are a great thing as they could make use of game servers much in the same fashion as the games that are installed right on a desktop/laptop

  4. #14
    Join Date
    Oct 2008
    Posts
    2,912

    Default

    Quote Originally Posted by F i L View Post
    Which part and how so?
    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.

    Most AAA game companies wont even consider using anything but C++
    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.

  5. #15
    Join Date
    May 2012
    Location
    Sunshine State
    Posts
    296

    Default

    Quote 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.
    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. Compiling to native code doesn't mean it's as fast as C/C++.


    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.
    CPUs are still a very big bottle-neck in modern games. Most game companies just design their games to target a broad range of hardware. Animation, Physics, and Sorting are the biggest hot-loops in game code (besides the Rendering pipeline). Much more so than the logic scripts, though on certain engines that use Lua, etc, performance of those is a concern. Unity3D uses .NET which is much faster than any Javascript VM. Some of the biggest game-engines though (Crytek, Frostbite [i believe]) use C++ or Logic bricks (which generate out C++) specifically so there wont be any performance loss with complex scripts.

    I help write a C# game engine, but my day-job is writing a HTML5 game in Javascript. I feel the performance difference between the two technologies daily. With HTML5 stuff, Javascript is the biggest performance concern, since all the new Canvas and WebGL stuff gets you pretty close to native performance with rendering (which is why these Unreal/Uniengine demos actually run okay.. cause WebGL is doing all the work, JS just move the camera around). If Javascript wasn't the language of the web, we would truly be at a point where major games could be ported to it. Ah... how i wish Ecmascript 4 hadn't been killed by MS and Yahoo.... but this is why I also support NaCL and Dart. Both have the potential to directly increase the raw horsepower of the web, without any stupid hackish stuff going on with the language (eg asm.js).

    Maybe WebCL will change things...

  6. #16
    Join Date
    Oct 2008
    Posts
    2,912

    Default

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

  7. #17
    Join Date
    Jan 2009
    Posts
    1,199

    Default

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

  8. #18
    Join Date
    Sep 2011
    Posts
    183

    Default

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

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

  9. #19
    Join Date
    Jan 2013
    Posts
    208

    Default

    Quote 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

  10. #20
    Join Date
    Mar 2012
    Location
    Faroe Islands
    Posts
    168

    Default

    Quote 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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •