Quake Live Now Available To Linux Gamers [Archive]

Louise

08-19-2009, 11:35 AM

I still get the "Sorry, you're not supported" message. I'm using the non-branded Firefox 3.5 build (called Shiretoko).

Anyway, this is a disgrace for the web. You have to actually change your browser to install a proprietary binary blob to view this site. It's against everything the web stands for. If you're running a browser that is capable of anything, but it's not one of those supported by Quake Live, you're out of luck. If you're at a place where the computer is locked down, you're out of luck.

Yes, this is a really bad product.

It requires 3D acceleration and it doesn't work in text mode.

Also it requires a monitor and a mouse.

RealNC

08-19-2009, 11:46 AM

Remco

08-19-2009, 11:46 AM

Yes, this is a really bad product.

It requires 3D acceleration and it doesn't work in text mode.

Also it requires a monitor and a mouse.
I'm glad you agree. They should have spent their energy on working with the WHATWG to get a 3D canvas spec off the ground. That's a worthwhile project. If they did that, and then were the first to implement such a thing through a browser plugin, they would get my support.

But as it stands, this is just a cheap trick that doesn't really produce anything worthwhile for the future of the web.

Not only does this require 3D acceleration and mouse input support (which is sensible), it also requires an artificially limited set of browsers. As I said, I use Firefox 3.5, without the branding (since Ubuntu just happens to provide me with that). This browser is just as capable as Firefox 2 and 3.0, which are supported, but still it doesn't work. You can expect every future beta version of supported browsers to fail.

Louise

08-19-2009, 11:54 AM

If I have to download a plugin, then why the hell didn't they simply offer a client? The plugin simply renders inside the browser window. Why the fsck not simply render in it's own window by being a client? Why does it have to be in the browser?

This makes zero sense.
Carmack is pretty intelligent, so you can be sure, there are good reasons :)

But very likely because then you wouldn't have the web integration like you have now with leader boards, high scores and so on.

If you give it fair chance, you will see that the game is very well integrated into the website.

That would be my guess at least.

Louise

08-19-2009, 11:56 AM

Not only does this require 3D acceleration and mouse input support (which is sensible),

Most 3D drivers are closed source, so why is closed source 3D ok, and Flash not? :D

homerhomer

08-19-2009, 11:58 AM

I still get the "Sorry, you're not supported" message. I'm using the non-branded Firefox 3.5 build (called Shiretoko).

Anyway, this is a disgrace for the web. You have to actually change your browser to install a proprietary binary blob to view this site. It's against everything the web stands for. If you're running a browser that is capable of anything, but it's not one of those supported by Quake Live, you're out of luck. If you're at a place where the computer is locked down, you're out of luck.

an easier way is to just change your agent string. Go to about:config and change the "general.useragent.extra.firefox" so that it says Firefox instead of Shiretoko.

yes, lame but it works

Remco

08-19-2009, 12:06 PM

Carmack is pretty intelligent, so you can be sure, there are good reasons :)

But very likely because then you wouldn't have the web integration like you have now with leader boards, high scores and so on.

If you give it fair chance, you will see that the game is very well integrated into the website.

That would be my guess at least.
You can use a web content rendering engine like WebKit or Gecko to provide your application with web content.
Most 3D drivers are closed source, so why is closed source 3D ok, and Flash not? :D
Closed source display drivers are not OK. Some very smart people are working to resolve this issue. Two wrongs doesn't make a right.

Louise

08-19-2009, 12:19 PM

You can use a web content rendering engine like WebKit or Gecko to provide your application with web content.

So they should just not support IE where most of the players are?

Closed source display drivers are not OK. Some very smart people are working to resolve this issue. Two wrongs doesn't make a right.
But there is also an open source Flash project :)

So following your logic, Flash is also ok :)

eugene2k

08-19-2009, 12:30 PM

puts the classic but popular Quake III: Arena game and puts it
Something's not right... :)

Remco

08-19-2009, 01:34 PM

So they should just not support IE where most of the players are?

You misunderstand. There is no support for anything, nor is it needed. You just have a client, which makes use of a web content rendering engine to display highscores and stuff. This rendering engine can be any cross-platform engine, and is simply shipped with the game.
But there is also an open source Flash project :)

So following your logic, Flash is also ok :)
Flash is not an open standard, while OpenGL is, and a Canvas 3D context specification will be. And may I add, Flash has nothing to do with Quake Live.

KeithZG

08-19-2009, 02:32 PM

I'm not going to argue too strenuously since, yes, it's kindof weird that it has to be a web-browser based thing instead of a standalone client (and that it'd be far more impressive if you didn't need to install anything at all), but on the other hand it does seem like it's easier for them to create and disseminate the game this way. They're basically targeting only a few very related platforms (ie. IE and Firefox) with minor tweaks per-OS (which took them forever grumble grumble, but still). To me it seems like just how one might choose Qt or GTK+ or whatever as a platform, they chose web browsing.

And hey, they went through announcing, developing and releasing a Linux version in far less time than it's taken Epic for UT3 so far ;) And hell if I can get UT1 to run on my modern Linux installs. So compared to their main competition, id is looking good.

numasan

08-19-2009, 03:32 PM

I have my opinions, of course, but won't dwell on the open/closed nature of this matter.

All I will say is: This is freaking sweet! Q3A is still in my top 5 favourite games, and I promptly joined QuakeLive when I read the Linux-news yesterday, and had a blast for 2 hours. Will play some games tonight also, for sure. So no complaints from me! :D

Tares

08-19-2009, 04:00 PM

Only for i686 ;/ doesn't work here on amd64 ;x

EDIT :
okay, I was to soon to jump into conclusions ;-) problem was with shiretoko not amd64, as for now the plugin is installed and it's updating. Hope it will work ;-)

about:config -> extra -> change Shiretoko to Firefox and leave rest as it is.

Kano

08-19-2009, 06:36 PM

It does run with amd64 too here. I had to update mesa to 7.3 (from 7.0.3) to play it with Intel Q45, but now it runs even on onboard systems or lowend gfx cards. Well the engine is nealy 10 years old, so that should be normal.

grantek

08-19-2009, 08:17 PM

FunkyRider

08-19-2009, 08:28 PM

What the fsck on earth is "shiretoko" ? Why don't you quit whiming and use a standard Firefox so the user agent string does not get messed up to something like "shakakawaraotoko" or some shit like that?

It's not id software's problem, it can't just go ahead and support whatever obsecure crap there are out in the wild. id has always had good attitude towards Linux world and when they take the lead and release a new title like they always do on Linux, you jumped out shouting because they don't support your "shiretoko"? So you think their effort of making Quake Live working on Linux so soon is not enough? Then what is enough for you?

some-guy

08-19-2009, 08:30 PM

nanonyme

08-19-2009, 08:44 PM

Shiretoko is Arch linux's firefox, just renamed because of mozilla's policies.Oh, someone else wanted to strip unfree Firefox logos out too and then got surprised that Mozilla doesn't want the browser to be called Firefox without them?

Remco

08-19-2009, 09:08 PM

Oh geez, quit whining:
- The source is open, this binary-only version is just a nice wrapped-up package to protect their art and content somewhat, which has value to them, and is paid for by ads. If you don't like it go play Nexuiz or something, which is just as good if not better (but the art may not be quite as nice)

Wait until every new hip site wants you to install their browser plugin. If this becomes a trend, the web as we know it is over. I expect some social networking site to be the first to do this kind of thing.

- People are complaining that they're shipping a client that requires a browser as opposed to shipping a client AND a browser!?
Yes. Well no, they would ship a web content rendering engine, which is not a browser. The engine would be used to show information in-game, instead of in a browser. This solves the browser problem.

- Shipping as a plugin means easy installation on all platforms - you just go to the website, authorise it to install, and play. There's no figuring out how to extract an archive, figuring out where to install or where to leave the unpacked client, going through your filesystem to find the executable when you want to play, adding package repositories on OSes that use them etc. It means anyone can play it, not just those that administrate the computers they use.That's a lie:

Not all platforms with the necessary requirements (internet connection, 3D acceleration) are supported by Quake Live. Think about ARM netbooks, PowerPC Macs, FreeBSD desktops, Solaris workstations...
You need UAC approval to install the browser plugin on Vista and up.
Locked down environments (corporate or public) also don't work.
noexec'd Unix systems don't work.
The actions for the first run of a plugin versus a program are the same:

Plugin: click on Play, click on Install plugin, [Vista: UAC allow, ] click on OK, restart browser.
Program: click on Play, click on Open, [Vista: UAC allow, ] click Install, click Play.

A program installation doesn't require a browser restart.
With a program installation, an icon will be provided in the Games section of the menu. Anyone can find this, since this is where all other games reside.

deanjo

08-19-2009, 11:09 PM

Wait until every new hip site wants you to install their browser plugin. If this becomes a trend, the web as we know it is over. I expect some social networking site to be the first to do this kind of thing.
Yes. Well no, they would ship a web content rendering engine, which is not a browser. The engine would be used to show information in-game, instead of in a browser. This solves the browser problem.
That's a lie:

Not all platforms with the necessary requirements (internet connection, 3D acceleration) are supported by Quake Live. Think about ARM netbooks, PowerPC Macs, FreeBSD desktops, Solaris workstations...
You need UAC approval to install the browser plugin on Vista and up.
Locked down environments (corporate or public) also don't work.
noexec'd Unix systems don't work.
The actions for the first run of a plugin versus a program are the same:

Plugin: click on Play, click on Install plugin, [Vista: UAC allow, ] click on OK, restart browser.
Program: click on Play, click on Open, [Vista: UAC allow, ] click Install, click Play.

A program installation doesn't require a browser restart.
With a program installation, an icon will be provided in the Games section of the menu. Anyone can find this, since this is where all other games reside.

So if you don't want to play in a browser, use the original Q3A release. It really is that simple. Really your wanting something that has already been out for a decade.

deanjo

08-19-2009, 11:18 PM

Shiretoko is Arch linux's firefox, just renamed because of mozilla's policies.

It's also the Codename of Firefox 3.5.2

Shiretoko has actually been the code name for any 3.5 series. 3.6 series is named Namoroka and 3.0 series was Gran Paradiso.

http://en.wikipedia.org/wiki/History_of_Mozilla_Firefox#Release_history

Remco

08-19-2009, 11:30 PM

So if you don't want to play in a browser, use the original Q3A release. It really is that simple. Really your wanting something that has already been out for a decade.
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.

grantek

08-20-2009, 05:01 AM

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.
I agree that user-agent checking is stupid and unnecessary, but as far as the "3d web" is concerned, I don't think it's as ideologically bad as you think - if anything, it's a step in the right direction with instant usable results, and if it catches on, it creates a popular use-case and justification for developing proper 3d browser standards.

Kano

08-20-2009, 05:04 AM

I have nothing against the idea of using a plugin to play. It then downloads 307 mb data into ~/quakelive (you save much time when you copy that directly when you want to play it on another pc). You can use any pc with good internet connection to play - and as the engine is 10 y old it does not need to be very fast. Also don't forget that there is a fullscreen mode (press ESC after the match began) you can use too. It does not look different then to a normally installed game. 10 y ago i would have been better in quake live i guess ;)

Tares

08-20-2009, 05:09 AM

zoomblab

08-20-2009, 05:45 AM

@Remco

Id is more likely in the business of making money instead of making a better web.

L33F3R

08-20-2009, 08:34 AM

I still get the "Sorry, you're not supported" message. I'm using the non-branded Firefox 3.5 build (called Shiretoko).

Excuse me as i turn on my L33F3R ipod on or mount my L33F3R hard disk.

Tares

08-20-2009, 08:52 AM

If someone has problems with cracking sound, try here (http://www.quakelive.com/forum/showthread.php?t=31897). First workaround works here on ubuntu amd64.

Remco

08-20-2009, 10:12 AM

Excuse me as i turn on my L33F3R ipod on or mount my L33F3R hard disk.
Well, I didn't do anything to get an unbranded Firefox. That's just what Ubuntu provides me with if I choose to use Firefox 3.5 as opposed to 3.0. If I'd use Konqueror, Epiphany, or Opera, or the new breed of WebKit browsers -- Arora, Midori, then I would have the same problem.

Funny though that you mention the iPod. Newer iPods and the iPhone have an encrypted USB connection, which means you can only use it with programs that Apple specifically allows (iTunes only, so no Linux). Sound familiar?

L33F3R

08-20-2009, 10:46 AM

Funny though that you mention the iPod. Newer iPods and the iPhone have an encrypted USB connection, which means you can only use it with programs that Apple specifically allows (iTunes only, so no Linux). Sound familiar?

what are you giving me this trip for? I cracked a joke and don't plan to go into a philosophical debate. I pity you for taking what I said with any degree of seriousness.

#kyz

08-20-2009, 02:04 PM

Anyone having crashes when in-game and going to the options then the intermediate options? Its not a big deal but its kinda annoying if you mistakenly click it.

Tares

08-20-2009, 02:54 PM

Anyone having crashes when in-game and going to the options then the intermediate options? Its not a big deal but its kinda annoying if you mistakenly click it.

Everyone. Well, almost. It's a known bug on official forum.

blindfrog

08-20-2009, 04:43 PM

Works great! Although I don't get why it's made to work only with firefox, since it's a java app it basically should work with every browser out there which supports java.

Why make this limitation? There's probably a very good reason why, but still it would be at least good to know why?

Kano

08-20-2009, 04:54 PM

Look into

~/.quakelive/quakelive/home/baseq3/

there are binary libs (for 32 and 64 bit). Does not look like java.

L33F3R

08-20-2009, 05:57 PM

browsers change so rapidly it can be hard to cater to all of them. It's easier just to pick the ones that the vast majority of people will use.

grantek

08-20-2009, 11:31 PM

browsers change so rapidly it can be hard to cater to all of them. It's easier just to pick the ones that the vast majority of people will use.
urgh - do you remember the web 10 years ago!? The Netscape Plugin architecture is a well-known standard and is used by pretty much everything except IE, there's no reason to discriminate between browsers beyond whether they implement it. For support reasons, it'd be much nicer to throw up a message saying "Oh noes, we can't tell what browser you're using. If you have any problems, we recommend trying with Firefox".

The browser whitelist may be a punkbuster thing though, I wouldn't put it past them to checksum various known binaries.

sloggerKhan

08-21-2009, 01:12 AM

urgh - do you remember the web 10 years ago!? The Netscape Plugin architecture is a well-known standard and is used by pretty much everything except IE, there's no reason to discriminate between browsers beyond whether they implement it. For support reasons, it'd be much nicer to throw up a message saying "Oh noes, we can't tell what browser you're using. If you have any problems, we recommend trying with Firefox".

The browser whitelist may be a punkbuster thing though, I wouldn't put it past them to checksum various known binaries.

I tried it. Crashed during the calibration match. And honestly, it seemed pretty boring after having played nexuiz for a while.

And the default of autoswitching weapons EVERY time you pass a weapon spawn is really irritating.

tuke81

08-21-2009, 08:57 AM

I tried it. Crashed during the calibration match. And honestly, it seemed pretty boring after having played nexuiz for a while.

And the default of autoswitching weapons EVERY time you pass a weapon spawn is really irritating.

Thats easily changed with cvar: cg_autoswitch 0
Create file autoexec.cfg in your home base folder and this line in it:
nano ~/.quakelive/quakelive/home/baseq3/autoexec.cfg
seta cg_autoswitch 0

Same default was in original quake3arena... Oh and here you can see all quakelive cvars:
http://www.holysh1t.net/quake-live-commands-list/

Joe Sixpack

08-21-2009, 06:32 PM

I tried it. Crashed during the calibration match. And honestly, it seemed pretty boring after having played nexuiz for a while.

And the default of autoswitching weapons EVERY time you pass a weapon spawn is really irritating.

Which is precisely why I uninstalled OpenArena after I gave Nexuiz a try. This is even more so true since they added a few Quake 3 Arena maps to Nexuiz 2.5. I still respect OpenArena though, it's just not for me.

(now back on topic...)

Quake Live sounds very promising. I watched the video on the website, but I didn't try to play it (I'm not big on trying major projects when they're still in beta).

RagingDragon

08-21-2009, 06:50 PM

Look into

~/.quakelive/quakelive/home/baseq3/

there are binary libs (for 32 and 64 bit). Does not look like java.

Probably a JNI wrapper using the original Quake 3 C/C++ libraries.

Kano

08-22-2009, 04:43 AM

You do not need Java installed at all, because a native browser plugin uses those libs.

RagingDragon

08-22-2009, 11:47 PM

You do not need Java installed at all, because a native browser plugin uses those libs.

Ah. That makes more sense.

Yfrwlf

08-25-2009, 12:52 AM

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.

Dragonlord

08-25-2009, 05:27 AM

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.

djack

08-25-2009, 08:56 AM

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.

Dragonlord

08-25-2009, 11:50 AM

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.

Remco

08-25-2009, 11:58 AM

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.

BlackStar

08-25-2009, 12:01 PM

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.

Remco

08-25-2009, 12:35 PM

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 (http://www.khronos.org/news/press/releases/khronos-webgl-initiative-hardware-accelerated-3d-graphics-internet/) 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. :)

Dragonlord

08-25-2009, 01:05 PM

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.

Remco

08-25-2009, 02:01 PM

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 (http://bytonic.de/html/jake2.html) also exists, and it sometimes outperforms regular Quake 2. (Side note: Jake 2 can be delivered through a Java applet :rolleyes:)

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.

Dragonlord

08-25-2009, 02:09 PM

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

08-25-2009, 02:31 PM

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

08-25-2009, 03:10 PM

Remco

08-25-2009, 03:39 PM

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

08-25-2009, 04:41 PM

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

08-25-2009, 05:16 PM

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

08-26-2009, 01:33 PM

smitty3268

08-26-2009, 08:33 PM

Dragonlord

08-27-2009, 01:43 PM

Remco

08-27-2009, 01:59 PM

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".
I guess you won't find the next Crysis on Javascript any time soon. But you can get a decent performance if you don't reach for such great heights. A 3D game is certainly possible, and I am going to make a rough prediction that the web will be bombarded with casual games in 5 years. In time, if successful, Js language development will be prompted to cater to high-performance application developers, which may result in SIMD support, manual memory management, and the nebulous 'memory tricks' that you're talking about.

In other news: I found a Firefox plugin called Canvas 3D (https://addons.mozilla.org/en-US/firefox/addon/7171), which brings an OpenGL ES 2.0 context to the <canvas> element. I haven't played with it yet, but it looks promising.

smitty3268

08-27-2009, 08:18 PM

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".

Well, I'm still not convinced. Can you tell me why, exactly, each of your "memory hacks" works? And if so, why wouldn't a program monitoring allocations and the flow of your program be able to detect that type of condition automatically? The only thing I can think of would be if the necessary conditions are somewhat difficult to detect and it would impose a performance hit on most programs to check for - and so that type of optimization wouldn't ever get created. Ok, I guess I have half-way convinced myself with that argument.

As far as compilers not replacing the human brain, that's absolutely correct - for now. I still think a computer could get there eventually. People used to think that C was too high level an abstraction and that compilers wouldn't be able to compile it as efficiently as a human in assembly. I think that today the vast majority of programmers wouldn't be able to match a machine at that activity, at least not in a reasonable timeframe. Eventually, we may say the same about higher level languages too.

Dragonlord

08-28-2009, 10:22 AM

The problem with compilers is that they can only analyze an AST. Such an AST does though not contain higher level informations about the the structure of code and how data is accessed. Furthermore the compiler does not now how often code is executed on runtime. Compilers can only optimize what is statically known ( static syntax ) but they have no chance on earth to optimize a runtime behavior. It's simply impossible because determining such a behavior is similar to solving the halting problem which is proven to be impossible to solve. The best thing is guessing ( or heuristics ) but guessing fails in the hard cases and game engines ( the real deals, not the simple ones ) are very hard cases since they push the machine wherever they can. The optimizations I talk about involve often refactoring entire code groups to achieve the desired performance gain. And this information unfortunately is not contained in an AST deductible from source code.

What goes for assembler this is still true but on a different level. Pure C code is more or less assembler but with better wording and easier to comprehend syntax as well as hiding some tasks from the programmer since messing with them is not required. Assembler though is still used today. For example console emulation relies still on assembler to get performance out of the difficult parts simply because they need to spare the few extra cycles introduced by a generic solution a compiler produces. Nevertheless proper code structure is the best optimization out there although you can not force a language outside the boundaries. JS for example will always be inferior to C when it comes to pure number crunching since managed memory is getting in the way. And as soon as you disable managed memory you get in devils kitchen with C# being the prime example of the kind of mess you can get yourself in ( they allow to violate the managed code allowing you to kill yourself ). Hence you will always need a machine language like C/C++ for the raw firepower and a scripted language for highly structure game logic. Trying to swap their places simple calls for troubles and is not worth it ( important hacker saying: "never fix what ain't broken" ). Hopefully this explained it a bit better.

BlackStar

08-28-2009, 11:48 AM

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.

Outside of SSE-optimized math code(*), what kind of "memory hacks" are you using that you cannot implement in, say, C# (specific examples, please)? How much performance do these buy you? How long did it take you to implement those hacks?

I'm not arguing for writing the raw 'engine' in C#, Ocaml or (shudders) Javascript - although this is certainly possible (and could even result in better performance, in the case of Ocaml). C and C++ won't go away any time soon. Modern games, however, rely heavily on scripting: Python, Lua, AngelScript, C# are used extensively, even on consoles. The iPhone is programmed with Obj-C or C#. The Android with Java.

The writing is on the wall. C/C++ will diminish in use as CPU power and JIT technology improves. It's natural evolution: raw assembly became marginalized as computing power and application complexity increased. Low-level languages will slowly but surely follow the same path.

A rhetorical question: Which is better, using a higher-level language and shipping 6 months earlier or using a lower-level language and delivering 5 or 10% better performance?

(*) C# actually supports vector instructions through Mono.Simd.

Dragonlord

08-28-2009, 01:17 PM

Honest answer: 6 months later and it's fucking optimized and working well. Sorry to be blunt but I take a well optimized C/C++ engine over any engine written in a managed language any time. As I said: use the right tool for the right task. Number crunching, deep down, hardware close engine stuff is C/C++ while game logic is a managed language. Just because you have horse power to spare doesn't mean you have to squander it. Use it make it run on systems with less horse power or to implement better game play. Many think this is just a game logic task but boy they are wrong. To do the right game logic you need always low level informations and gathering those requires number crunching to get it done fast.

smitty3268

08-28-2009, 01:37 PM

The problem with compilers is that they can only analyze an AST. Such an AST does though not contain higher level informations about the the structure of code and how data is accessed. Furthermore the compiler does not now how often code is executed on runtime.

That's all true for static compilers, but I was talking about dynamically generated code, like the Java and .NET runtimes. They can compile the code down to a pseudo-assembly and then compile that further down to binary during runtime after checking out what parts of the code are accessed often or any other type of runtime checking. It's conceivable that a program could even try a couple of different strategies, measure which performs better, and save that profile to be used in future sessions, all automatically. Javascript is the same, in that it is interpreted at runtime before being compiled to it's final form (at least for most - Chrome might do it statically).

Assembler though is still used today. For example console emulation relies still on assembler to get performance out of the difficult parts simply because they need to spare the few extra cycles introduced by a generic solution a compiler produces.
Certainly there are many places where it's almost essential. Codecs and video drivers are prime examples, as well as lots of image/video filters. But it is mostly used when you are trying to optimize small hotspots in your code that get called over and over again, rather than a high-level whole-program optimization type of thing. There just gets to be too much for a human brain to remember at that level.

BlackStar

08-28-2009, 01:44 PM

Honest answer: 6 months later and it's fucking optimized and working well.
Here is where your falacy lies. You can use those extra 6 months you gained by using a managed language to optimize your code and potentially improve your performance more than 5-10%.

Also note that you can abstract the intensive number crunching parts of an engine into ultra-optimized native dlls. You can then implement the rest of the engine in a managed language with no or miniscule loss in performance.

Not to mention that languages like Ocaml are faster than C/C++ for a large number of tasks.

The right tool for the right job? 100% agreed. As time passes, managed languages are becoming suitable for a wider range of tasks. Other than low-level math, there's little that managed languages cannot do right now - and math isn't an intractable problem either (see Mono.Simd, which was added exactly because game developers requested it.)

Just because you have horse power to spare doesn't mean you have to squander it.
On the contrary, the more power you have the more you can afford to squander. No game or engine is released 100% optimized anymore - hardware is simply evolving too fast for that. Optimize for current gen cards? Your optimizations are obsolete when your game is released two years later. Optimize for next gen cards? Your game runs suboptimally on current hardware.

Use it make it run on systems with less horse power or to implement better game play. Many think this is just a game logic task but boy they are wrong. To do the right game logic you need always low level informations and gathering those requires number crunching to get it done fast.
Better optimized programs are good, noone will argue against that. However, this paragraph doesn't make any sense. What the hell are "low level informations"? Why do you need "number crunching" to gather them?

Also, you still haven't listed any specific hack you have done in your program that you couldn't do in a managed language like C#.

Dragonlord

08-28-2009, 03:27 PM

That's all true for static compilers, but I was talking about dynamically generated code, like the Java and .NET runtimes. They can compile the code down to a pseudo-assembly and then compile that further down to binary during runtime after checking out what parts of the code are accessed often or any other type of runtime checking.
JIT simply means to compile code "on demand". This has nothing to do with the compiler knowing about who the code is used. This is like having a static compiler and just compiling the code where needed instead of running it through an interpreter. The end result is though still the same. Both compilers can not figure out the logic behind the code and therefore are unable to do the optimizations a human brain can do by structuring the code properly.

Dragonlord

08-28-2009, 03:39 PM

Here is where your falacy lies. You can use those extra 6 months you gained by using a managed language to optimize your code and potentially improve your performance more than 5-10%.
Point denied. You can not optimize beyond the ability of the language. This is a common false idea about managed languages. Each language has barriers and spending more time is not going to get you past the barriers. What you can do is pushing them a bit which is what Java did with JIT. It can do a nice job there but there's just so much a machine can figure out without knowing the higher logic of a program.

Also note that you can abstract the intensive number crunching parts of an engine into ultra-optimized native dlls. You can then implement the rest of the engine in a managed language with no or miniscule loss in performance.
Which brings us back to what I say all the time. The number crunching has to be done in C/C++ code ( therefore the game engine itself ) and only the logic is in the scripted language.

On the contrary, the more power you have the more you can afford to squander. No game or engine is released 100% optimized anymore - hardware is simply evolving too fast for that. Optimize for current gen cards? Your optimizations are obsolete when your game is released two years later. Optimize for next gen cards? Your game runs suboptimally on current hardware.
Which is why I state over and over again that the current way of designing game engines is totally obsolete and unsuitable for todays hardware. Wasting processing power on unoptimized code or manage language house keeping is not the solution just fighting the symptoms.

Better optimized programs are good, noone will argue against that. However, this paragraph doesn't make any sense. What the hell are "low level informations"? Why do you need "number crunching" to gather them?
Game logic needs to sense/understand the world it acts in. This encompasses things like collision detection and various other forms of sensing and decision making. All of these require to gather fast and efficient a subset of informations from the game world to calculate the result. Obtaining these informations is a number crunching work and requires raw firepower.

BlackStar

08-28-2009, 04:16 PM

Point denied. You can not optimize beyond the ability of the language. This is a common false idea about managed languages. Each language has barriers and spending more time is not going to get you past the barriers. What you can do is pushing them a bit which is what Java did with JIT. It can do a nice job there but there's just so much a machine can figure out without knowing the higher logic of a program.
Wrong. You are still thinking on the scale of microoptimizations, where indeed low-level languages shine.

However, you can get much larger benefits by improving your algorithms, writing hardware specific paths (e.g. different shaders for radeons and geforces) or just plain optimizing your level layout and assets.

Which brings us back to what I say all the time. The number crunching has to be done in C/C++ code ( therefore the game engine itself ) and only the logic is in the scripted language.
An engine contains many more things than number crunching and logic: asset loaders, streaming, tracing, threading, scripting, networking, profiling, debugging. Stuff which hardly benefits from a lower level language.

In fact, the lower-level you go, the harder your life becomes: bugs, memory leaks, unportable code, slower compile times, ABI issues (try exporting C++ code from a dll - nice, huh?). A higher level language will help you write more maintainable code with less bugs and less effort. You can then spend the time you saved optimizing the parts where it actually matters and that's why using a managed language can result in better performance.

Point in case: in my last project, I created 3d world driven through a brain-computer interface. High-end graphics (VSM, SSAO, displacement mapping, stereoscopic rendering). Purely GLSL-driven engine, utilizing OpenGL 3.0 (with 2.1 fallbacks) and running on Windows, Linux and Mac OS X.

Technology? C# and OpenTK (http://www.opentk.com). Performance? Scales from laptop graphics to CAVE (http://en.wikipedia.org/wiki/Cave_Automatic_Virtual_Environment) systems. And you know what the best thing is? This was developed on Linux, but deployed on all platforms - without even recompiling the binaries.

This is what you gain for using a managed language for your engine. It allows you to do things that are otherwise painful or flat out impossible to achieve.

Game logic needs to sense/understand the world it acts in. This encompasses things like collision detection and various other forms of sensing and decision making. All of these require to gather fast and efficient a subset of informations from the game world to calculate the result. Obtaining these informations is a number crunching work and requires raw firepower.
Collision detection = math, which you can move into a reusable, hand-optimized, library. You don't need to code the rest of the engine in the same language as your highly optimized math library. Unless you love writing network logic in assembly, that is. :P

You still haven't given any specific example of memory hacks that you have written in C++ (or whatever language you are using for your engine), but couldn't have implemented in C#.

mirv

08-28-2009, 04:29 PM

Anybody who thinks assembly or C will go away....has never done embedded programming.
High end game engines still need that low level kind of programming to get a fast running game. Anyone who thinks otherwise, is simply kidding themselves. You can, however, use scripted languages to help - Unreal is a good example. UnrealScript helped people make some good mods, but it only ran something like 15% of the time (don't quote me on that number - it could well be less or a little bit more). Either way, the bulk of the processing was done in C++.
I will agree that algorithm design is one of the most important features though - no matter what language you use, that is still really important.

Remco

08-28-2009, 04:41 PM

Which brings us back to what I say all the time. The number crunching has to be done in C/C++ code ( therefore the game engine itself )

This is possible in any JITed environment with the right features for number crunching. Keep in mind that there is no reason why C++ couldn't be JITed. Whether a language is JITed or not doesn't really say a whole lot.

Hey, that may be a cool idea: a JITed C++ for the web.

<script type="text/c++" src="bla.cpp"></script>

But Js is obviously no C++, JITed or otherwise. That can change though.

BlackStar

08-28-2009, 04:59 PM

Anybody who thinks assembly or C will go away....has never done embedded programming.
Neither assembly nor C are going away. There are many, *many* jobs where these are the best tools (or where there's no alternative) and I've programmed enough ARMs, MIPSes and even 8085s (shudders) to have gotten rid of any such delusions. :)

However, let me ask you a question: do you consider the iPhone or the Android platforms as embedded? Because none of those can be programmed in assembly or C (there's some work for C on the Android, but it's current API uses Java.)

There's little technical reason why C# couldn't run on such environments with a suitable native compiler (obviously without the whole framework). Indeed, both Microsoft and Novell provide versions of their .Net stacks for embedded platforms and there's a lot of developer interest in those. Just check the MonoTouch mailing list (Mono's iPhone stack) or the main mono-dev list - there's definite interest in embedded programming with managed languages, despite the limitations.

BlackStar

08-28-2009, 05:01 PM

This is possible in any JITed environment with the right features for number crunching. Keep in mind that there is no reason why C++ couldn't be JITed. Whether a language is JITed or not doesn't really say a whole lot.
You mean C++/CLI? ;)

Hey, that may be a cool idea: a JITed C++ for the web.

<script type="text/c++" src="bla.cpp"></script>
Now that's a scary thought! :D

mirv

08-28-2009, 05:16 PM

Neither assembly nor C are going away. There are many, *many* jobs where these are the best tools (or where there's no alternative) and I've programmed enough ARMs, MIPSes and even 8085s (shudders) to have gotten rid of any such delusions. :)

However, let me ask you a question: do you consider the iPhone or the Android platforms as embedded? Because none of those can be programmed in assembly or C (there's some work for C on the Android, but it's current API uses Java.)

There's little technical reason why C# couldn't run on such environments with a suitable native compiler (obviously without the whole framework). Indeed, both Microsoft and Novell provide versions of their .Net stacks for embedded platforms and there's a lot of developer interest in those. Just check the MonoTouch mailing list (Mono's iPhone stack) or the main mono-dev list - there's definite interest in embedded programming with managed languages, despite the limitations.

Actually, I consider Android and iPhone too powerful to be considered embedded. I do have fond memories of the 68HC11 series from Motorola though (accumulator based) - embedded chips have become much more powerful since then.
I was under the impression that you could use C++ for the iphone (or that the development was based on C++) - wonder what Carmack used with doom there.

smitty3268

08-28-2009, 06:51 PM

JIT simply means to compile code "on demand". This has nothing to do with the compiler knowing about who the code is used. This is like having a static compiler and just compiling the code where needed instead of running it through an interpreter. The end result is though still the same. Both compilers can not figure out the logic behind the code and therefore are unable to do the optimizations a human brain can do by structuring the code properly.

You're wrong. Well, you're right that that is the minimum, but wrong that it's the maximum. Wasn't one of the very first Java JIT optimizations to count how often particular methods were called and dynamically inline them when it was often? Even if no current JIT compiler does this, there's absolutely no reason one in the future couldn't, and that was what I was talking about anyway. I have no illusions that the current JS or other compilers are suitable, I'm just saying that someday they could be.

Dragonlord

08-28-2009, 07:35 PM

However, you can get much larger benefits by improving your algorithms, writing hardware specific paths (e.g. different shaders for radeons and geforces) or just plain optimizing your level layout and assets.
I never said something else. Nevertheless at some point you need raw power no matter how neat your design is and this is where things break. What you need is good design and number crunching code. You have to use the right thing at the right place.

In fact, the lower-level you go, the harder your life becomes: bugs, memory leaks, unportable code, slower compile times, ABI issues (try exporting C++ code from a dll - nice, huh?). A higher level language will help you write more maintainable code with less bugs and less effort. You can then spend the time you saved optimizing the parts where it actually matters and that's why using a managed language can result in better performance.
The key is design. If you write messy C code and blaming C for it then you do something wrong. Managed languages are not less error prone. They just remove memory related errors replacing them with higher level problems. But why arguing with somebody who thinks a managed language is the cure-all for everything instead of using the right tool at the right place...

L33F3R

08-28-2009, 08:47 PM

if a might add some noob talk here.

Visual C#
A great combination of power and productivity for the Windows developer.

Visual C# 2008 Express with SP1 is the ideal tool for productively building object-oriented applications for Windows on the .NET Framework.

Visual C++
Horsepower with a finer degree of control than other Express Editions.

Visual C++ 2008 Express with SP1 provides a powerful and flexible development environment for creating native Windows and cool 2D and 3D games.

on the 2005 edition they recommended both c++ and c# for games. Now seems its just c++.

But I could be getting a totally different drift then what you guys are on. This is totally beyond me.

BlackStar

08-28-2009, 09:27 PM

The key is design. If you write messy C code and blaming C for it then you do something wrong. Managed languages are not less error prone.
Sorry, but that's just delusional. Writing correct, safe C code is significantly more difficult than Ocaml or Python. Writing verifiable code is nigh impossible.

They just remove memory related errors replacing them with higher level problems.
I'll take higher level problems over memory related errors any day.

Memory management is the single largest issue plaguing any sufficiently large program and anything that simplifies it will result in large gains in the long run. C doesn't really offer in the way of memory management. C++ is marginally better with smart pointers and other constructs that can be used to implement semi-automatic reference counting.

C#, or any other language with a non-conservative GC, simplifies memory management by an order of magnitude, at the very least. In the common case, you can simply forget about it. For games, you might have to use pools or explicit stack allocations, but that's still simpler than juggling with reference counts.

But why arguing with somebody who thinks a managed language is the cure-all for everything instead of using the right tool at the right place...
Have you even read my posts? I've said more than once that you should use the right tool for the right job. Surprisingly enough (or not, depending on your background), this could mean using something other than C/C++ in parts of your engine.

Unity3d (commercial engine for the Wii, iPhone, Windows, Mac), Second Life (cross-platform title) and several other games embed the Mono runtime directly. Most 3d engines nowadays ship with .Net bindings. The only way you can develop for the XBox is to use C#, unless you are a large, proven game studio. If managed languages were so unsuitable for games as you claim, why are they used to such an extent in actual, shipping games?

Besides, you still haven't managed to list even a single concrete example of a hack you have performed in C/C++ but couldn't in C# - which kinda undermines your point.

L33F3R

08-29-2009, 10:38 AM

Most 3d engines nowadays ship with .Net bindings.

M$ and c# for 360. If you couldn't figure that one out your lost. ;)

BTW building a game using .net off an engine written in c++ is a whole new ball of wax.

deanjo

08-29-2009, 11:27 AM

BTW building a game using .net off an engine written in c++ is a whole new ball of wax.

Ear wax, bee wax, car wax, or candle wax?

L33F3R

08-29-2009, 12:08 PM

the kind shrek used for his candles :eek:

BlackStar

08-29-2009, 02:34 PM

M$ and c# for 360. If you couldn't figure that one out your lost. ;)

Please explain, you are not making any sense. :) What do Delta3d, Ogre3d, Irrlicht3d, CrystalSpace3d, Unity3d, Torque have to do with Microsoft (or the 360 for that matter)?

BTW building a game using .net off an engine written in c++ is a whole new ball of wax.

Speaking from experience, or just speculating? Because it is not any more difficult than building a game in Python or Lua using a C++ engine.

Guess what language(s) Crysis is written in.

L33F3R

08-29-2009, 03:10 PM

Please explain, you are not making any sense. :) What do Delta3d, Ogre3d, Irrlicht3d, CrystalSpace3d, Unity3d, Torque have to do with Microsoft (or the 360 for that matter)?

nothing. If i wanted to specify Delta3d, Ogre3d, Irrlicht3d, CrystalSpace3d, Unity3d or Torque would have. I specified c# and the 360, Not the above. Both c# and xbox are Microsoft technologies. If you couldn't achieve that thread of thought im sorry. I think where you are confused is how i poorly organised my post, the quote was in direction of my second line. What i should have done was quote this 1 first.
The only way you can develop for the XBox is to use C#, unless you are a large, proven game studio.

Guess what language(s) Crysis is written in.

I know they use lua for NPC scripting. Correct me if im wrong tho.

Failix

08-29-2009, 05:06 PM

I've been playing Quake Live on Ubuntu Jaunty for two days now, and all I can say is that until now, I had a lot of fun.

While it may still be the good old quake 3 arena, the new envelope/package it comes in adds a great deal of motivation to play and explore the competitive richness of quake. A friends manager, stats, awards, and way more finally united in one shiny, perfectly designed place. Another sweet feature I like is how Quake Live evaluates your skill and tells you which server and opponents suit you best. Yep, I like it.
Now as much as I love Nexuiz as a game and admire the work behind it, in my very humble opinion Quake Live is superior (if you ignore the fact that Nexuiz is free as in freedom).

All in all, I think Quake Live is a cool and clever attempt to revive a legendary game and its unique competitive scene. Id software was so kind and offered Linux users another chance to show off their potential value in the gaming market. I think there's no better opportunity than with having some quick, clean, fun an hour or two on weekends for free.

By the way, does anybody know what changes were made to id tech3 for QL? It does look quite better than projects using ioquake3. The new/improved art assets probably contribute a lot to it though...

xav1r

08-29-2009, 08:03 PM

So, is it better then to use a managed programming language instead of a plain one, nowadays?? Or does it depend on the situation? For games specifically. BTW, i cant seem to find other managed ones besides .net/c# and .mono. :D

Remco

08-29-2009, 08:38 PM

There are games written in Python, Java, ActionScript, Javascript. All recent commercial 3D games are written in C++ though.

Setlec

08-30-2009, 11:36 AM

What do Delta3d, Ogre3d, Irrlicht3d, CrystalSpace3d, Unity3d, Torque have to do with Microsoft (or the 360 for that matter)?
platform Support?

What do those engines have to do with windows XP/VISTA/7 and/or linux? Please don't answer this question...

for the pc platform which game has been written in C#? i really curious about this.

pvtcupcakes

08-31-2009, 12:27 AM

platform Support?

What do those engines have to do with windows XP/VISTA/7 and/or linux? Please don't answer this question...

for the pc platform which game has been written in C#? i really curious about this.

Dyson uses C#
http://www.dyson-game.com/read.php?page=8

It's a 2D game, and it uses sdl and mono. I don't know why they use SDL, but that's written in C, so the engine itself might be SDL.

BlackStar

08-31-2009, 02:06 AM

platform Support?

What do those engines have to do with windows XP/VISTA/7 and/or linux? Please don't answer this question...
Please rephrase that, I don't copy you. These are cross-platform engines that can be used by .Net languages. Some of them run on consoles, too.

for the pc platform which game has been written in C#? i really curious about this.
You know, there's this wonderful thing called google. A quick search returns gaming juggernauts like Second Life, The Sims 3, plus a metric ton of games written in XNA and Unity3d.

You know what the interesting thing is? Second Life turned to Mono in order to improve performance. Not only that, but they've used Mono to implement some positively awesome things like microthreads (Mono.Continuations) or the ability to record the current state of the engine, wire it to the server or another PC and continue execution there. There was a great discussion on the Mono mailing list recently (around last April) - check it out if you are interested.