Originally posted by Dragonlord
View Post
Announcement
Collapse
No announcement yet.
Quake Live Now Available To Linux Gamers
Collapse
X
-
Originally posted by BlackStar View PostKhronos 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.
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.
Comment
-
Originally posted by Remco View PostIf they create an OpenGL ES-like spec, then it will push your hardware. It will have support for shaders and everything.
Comment
-
Originally posted by Dragonlord View PostThe 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.
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
-
Originally posted by Dragonlord View PostQuake 2 is rather old and works different in the inside than a current generation engine. And a good webapp does not require data storage.
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
-
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
-
Originally posted by Dragonlord View PostMaybe 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.
Interpreted/JITed languages also have the advantage of instant multi-platformness, which is something I like even more.
Comment
-
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
Comment