Quake Live Now Available To Linux Gamers

[Dragonlord]

Nope, I'm 100% sure this is not going to happen since heuristics "guess" and in such cases only very few tricks work. Such memory hacks are applied across large sections of code and reflect in the design of the code itself. As good as compilers are they can not replace a human brain. As somebody once said so well: "The best optimizer is sitting between your ears".

[smitty3268]

That's not the problem. It's about juggling memory around in a specific way as well as totally going beyond calling functions doing nifty memory hacks. I for example need those to get the performance I need to do the high end stuff I have working right now. These kind of memory tricks are simply impossible in a JITed or interprated language. Hence a JITed language can not ( by design ) ever do such things.

I don't think it's completely impossible. Eventually someone might come up with some good heuristics about the types of situations that those memory tricks are useful in, and then add that to the JIT compiler to automatically implement.

Ok, so that kind of stuff is probably a long ways away, but I wouldn't be surprised to see it happen eventually. Think how far things have progressed in the last 20 years for comparison.

[Dragonlord]

That's not the problem. It's about juggling memory around in a specific way as well as totally going beyond calling functions doing nifty memory hacks. I for example need those to get the performance I need to do the high end stuff I have working right now. These kind of memory tricks are simply impossible in a JITed or interprated language. Hence a JITed language can not ( by design ) ever do such things.

[Remco]

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.

Maybe Js will at some point get a "weak" modifier and a "delete" keyword, you never know.

[Dragonlord]

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.

[Remco]

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.

[Dragonlord]

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.

[Remco]

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.

[Dragonlord]

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.

[Remco]

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.