Announcement

Collapse
No announcement yet.

Mozilla Brings Unreal Engine 3 To Firefox

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

  • 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

  • #2
    Makes me wonder if any/all existing UE3 games will work on linux now, and there's a LOT out there. I own at least 4 games that use it, with only 2 of them being a FPS.

    Comment


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

      Comment


      • #4
        Originally posted by schmidtbag View Post
        Makes me wonder if any/all existing UE3 games will work on linux now, and there's a LOT out there. I own at least 4 games that use it, with only 2 of them being a FPS.
        well dungeon defenders already works on linux.

        also there was news of a good FPS that is coming too.

        but this browser technology looks good, specially since the linux version of flash didnt support it. So take that Adobe, less and less flash every day !

        Comment


        • #5
          Originally posted by madjr View Post
          well dungeon defenders already works on linux.

          also there was news of a good FPS that is coming too.

          but this browser technology looks good, specially since the linux version of flash didnt support it. So take that Adobe, less and less flash every day !
          Which one would that be?

          Comment


          • #6
            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.
            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).

            Comment


            • #7
              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).
              This is wrong.

              Anyway, the main problem with running real games inside a browser is the texture data. AAA games have > 10GB of texture data that's typically installed to the hard drive, and you aren't going to want to try and stream that on demand. Meaning you need to install it all ahead of time. And once you've done that, is there really much of a point to try to run it in the browser instead of locally?

              Apparently Mozilla is working on some kind of new system that would check the bandwidth available and dynamically download textures of different sizes and quality based on how much you can stream from the server, but I still doubt you'd want to do that for a major AAA game. It seems like it'd be more useful for something that in the past would used Flash.

              Comment


              • #8
                Originally posted by smitty3268 View Post
                This is wrong.

                Anyway, the main problem with running real games inside a browser is the texture data. AAA games have > 10GB of texture data that's typically installed to the hard drive, and you aren't going to want to try and stream that on demand. Meaning you need to install it all ahead of time. And once you've done that, is there really much of a point to try to run it in the browser instead of locally?

                Apparently Mozilla is working on some kind of new system that would check the bandwidth available and dynamically download textures of different sizes and quality based on how much you can stream from the server, but I still doubt you'd want to do that for a major AAA game. It seems like it'd be more useful for something that in the past would used Flash.
                I think in the end it becomes more a matter of compatibility than anything. It seems that more and more programs are becoming web based, because Windows no longer has a greater market share than all other platforms combined. Windows, Windows RT, Mac, Android, and iOS are all pretty much binary incompatible with each other, and linux is just starting to crack out of it's shell of being apart of the rest of the flock (pun intended). When you consider games, Xbox and PS are also in the loop. So that can become potentially 8 modern binary-incompatible platforms to support, and that's a turnoff for any developer. By making something browser based, it no longer becomes the developers' responsibility to make it cross-compatible, as long as the product is known to work on that particular browser.

                I'm sure one of the reasons Mozilla is working on this is so they have something extra appealing to offer for their Firefox OS.

                Comment


                • #9
                  Originally posted by smitty3268 View Post
                  This is wrong.
                  Which part and how so?

                  I write in Javascript every day, it's slow and I know it. Moreover, there's no dynamic language out there that compares to the performance of native static-typed ones (C & C++). Most AAA game companies wont even consider using anything but C++ cause no other language (currently) offers tight control over SIMD instructions. There's no way Javascript is going to be a target for anything more than simple Indie games unless something drastic happens to the language itself, or (like with asm.js) human-unreadable subset idioms are introduced that allow JS compilers to have more structural guarantees. Even then, unless you add very specialized SIMD commands, C++ will win by a milestones.

                  Moreover, even if the performance wasn't a concern, Javascript sux. Prototype inheritance is horrible for big projects compared to proper OOP. You can't even have private variables without killing performance.

                  Comment


                  • #10
                    Incredible.
                    The portage done in just four hours. Ok, probably a little more with some additionnal tunning.
                    Meanwhile, shall I remember that the Linux players have been waiting for UT3 for years for nuts ? I thought there was some "legal" problems avoiding the port to linux? Is there no "legal" problem anymore so that the engine can be directly ported to all existing platforms at the same time because of using Java?

                    Comment


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

                      Comment


                      • #12
                        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/

                        Comment


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

                          Comment


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

                            Comment


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

                              Comment

                              Working...
                              X