Announcement

Collapse
No announcement yet.

Quake Live Now Available To Linux Gamers

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

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