Announcement

Collapse
No announcement yet.

Quake Live Now Available To Linux Gamers

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

  • #46
    Originally posted by Kano View Post
    You do not need Java installed at all, because a native browser plugin uses those libs.
    Ah. That makes more sense.

    Comment


    • #47
      Originally posted by Remco View Post
      Everyone who plays Quake Live apparently wants something that is 10 years old.

      What I want is a real Quake Live. One that is really webbased. That's how Quake Live was presented. That's what piqued my interest, since that's a major technological advancement. Reality is disappointing. It's just Quake 3 Arena with a few gameplay improvements.

      Now, the game is obviously much fun to play. Q3A was a great game, so Quake Live, which is a patched up Q3A, can't be worse.

      It's not that I don't like the game, it's that I hate the marketing, and the technical gimmick that insults real 3D web efforts, and adds a whole new host of compatibility problems, because not only do you depend on a specific operating system, you also depend on a specific browser.
      Mostly agreed with you, the way it comes off makes you think it's an actual web standards-based game. It seems silly to me too, not much different than downloading and running a client, but the way I see it they are basically using the browser plugin system, which is not standardized unfortunately (and should be), for package management. So instead of downloading a file and clicking on it blahblahblah, you may click a few less times to install a "plugin" instead?

      In any case, I too am real excited about the new 3D web standards coming and it would be really neat to see a game using them instead of just being a typical game that is not only platform specific but also browser specific and is simply lightly hooked into those browsers. I don't know how difficult it would be right now to try to make a 3D game with the possibly-still-not-solidified specifications of the two 3D standards, since I don't know how you'd deal with things like additional 3D engine features, but it would certainly be neat.

      Comment


      • #48
        Real 3D game with web standards = impossible. The system is not made for that. Besides this browser-game-plugin crap is... well... crap. Why wasting processing power on a browser and plugin to run a game instead of running an optimized single client? I really see no benefit out of this at all.

        Comment


        • #49
          I wouldn't ever say impossible, just unlikely.
          If we ever get a decent successor to VRML, things should be doable. Probably not fast paced FPSs and certainly not anything that can be seen as cutting edge. Just like there are real, browser based 2D games right now.

          Comment


          • #50
            With real 3D games I meant stuff that pushes the hardware like I do. That stuff is too advanced. NDS type graphics though would be possible and feasible if a sane 3D specification would exist.

            Comment


            • #51
              Originally posted by Dragonlord View Post
              With real 3D games I meant stuff that pushes the hardware like I do. That stuff is too advanced. NDS type graphics though would be possible and feasible if a sane 3D specification would exist.
              If they create an OpenGL ES-like spec, then it will push your hardware. It will have support for shaders and everything.

              Comment


              • #52
                Khronos is preparing the WebGL standard for release during early 2010. It seems they are planning to make it usable from straight Javascript, which opens up some interesting possibilities.

                Comment


                • #53
                  Originally posted by BlackStar View Post
                  Khronos is preparing the WebGL standard for release during early 2010. It seems they are planning to make it usable from straight Javascript, which opens up some interesting possibilities.
                  Yep, the Khronos press release says the same:
                  The WebGL working group is defining a JavaScript binding to OpenGLŪ ES 2.0 to enable rich 3D graphics within a browser on any platform supporting the OpenGL or OpenGL ES graphics standards.
                  I agree with grantek from a few days ago that Quake Live might be a good thing, since it creates a use case for 3D on the web. I don't think it would be too hard to port the Quake 3 engine to WebGL, since OpenGL and OpenGL ES are a lot alike. The translation from C to Js would be the major work. So maybe, by next year, we'll be playing Quake Live in a native <canvas> element in Arora 1.0 on an ARM netbook running FreeBSD.

                  Comment


                  • #54
                    Originally posted by Remco View Post
                    If they create an OpenGL ES-like spec, then it will push your hardware. It will have support for shaders and everything.
                    The specs maybe yes but not the browser. To use hardware to the max you need some heavy CPU processing. JS is not going to provide that. Furthermore you need quite some media data around too. Sending 1GB of game data over the wire each time you want to play? That's ouch. You could cache it but then again you need an extra plugin which brings us back to the question why bother in the first place.

                    Comment


                    • #55
                      Originally posted by Dragonlord View Post
                      The specs maybe yes but not the browser. To use hardware to the max you need some heavy CPU processing. JS is not going to provide that. Furthermore you need quite some media data around too. Sending 1GB of game data over the wire each time you want to play? That's ouch. You could cache it but then again you need an extra plugin which brings us back to the question why bother in the first place.
                      Js scripting may improve dramatically with the trend towards JIT-compiling. A Quake 2 port to Java also exists, and it sometimes outperforms regular Quake 2. (Side note: Jake 2 can be delivered through a Java applet )

                      Caching of data can be done with HTML 5's new offline data storage spec. You can't have any decent webapp without data storage.

                      Comment


                      • #56
                        Quake 2 is rather old and works different in the inside than a current generation engine. And a good webapp does not require data storage.

                        Comment


                        • #57
                          Originally posted by Dragonlord View Post
                          Quake 2 is rather old and works different in the inside than a current generation engine. And a good webapp does not require data storage.
                          Quake 3 is rather old too, and works differently than current generation engines too. But none of it means that 3D graphics games won't work with a JITed language. It's been proven to work for Id Tech 2 with Jake 2, which has comparable performance. I once thought that Quake Live would prove it for Id Tech 3, but that has to wait a while longer.

                          A good webapp may very well require data storage for some functionality. Quake Live is one example of a web app that needs a lot of data all the time. A webmail app with an offline function is another. Any app that wants to offload network capacity is a third. The Canvas element makes it possible to create web-based photo editing software. I'm pretty sure such an application will want to have data storage for brushes, history, and layers.

                          Comment


                          • #58
                            Maybe this is because I dislike web2 stuff but the power of a web app is that it is a "thin" client. All you mention here are requirements of a "thick" client. So why torture a browser with thick client tasks if a real client can do it much better? It's the same crap I fight against with programming languages. People tend to torture languages into doing things they are not designed for to begin with which is bad. There's for a reason the saying "use the right tool for the right task" or "use the right language for the right task". Browsers are for thin clients not for thick clients. It's not the right thing to do.

                            Comment


                            • #59
                              Originally posted by Dragonlord View Post
                              Maybe this is because I dislike web2 stuff but the power of a web app is that it is a "thin" client. All you mention here are requirements of a "thick" client. So why torture a browser with thick client tasks if a real client can do it much better? It's the same crap I fight against with programming languages. People tend to torture languages into doing things they are not designed for to begin with which is bad. There's for a reason the saying "use the right tool for the right task" or "use the right language for the right task". Browsers are for thin clients not for thick clients. It's not the right thing to do.
                              I agree with that. But since some companies want to do everything in the browser, it's going to be used. And from a perverse technological curiosity perspective, I like seeing a high-performance graphics engine running in a JITed language.

                              Interpreted/JITed languages also have the advantage of instant multi-platformness, which is something I like even more.

                              Comment


                              • #60
                                This is true but the problem with JITed language is that they lack the power given by a machine near language like C++. I'm 100% sure that nobody could write my engine ( or any other high performance next generation engine ) using a JITed language with a similar or better performance. I noticed it more than once that doing memory hacks increased performance by a great deal especially in graphics rendering where raw firepower counts. JITed languages can not do such things since they are limited to a certain memory model which gets in the way. That's the main reason why no JITed language can outperform a properly written engine in a C++ language.

                                Comment

                                Working...
                                X