Microsoft's VM is not going to run your code, unless you specifically write it to work on it.
That's a fairly broad assertion...is the MS JVM that different, that code just won't run on it?
My rusty memory tells me it's a few library calls that are different, and a lot of moaning about MS adding their own native C interface (which if you then used, then sure, it wouldn't run on other JVMs), but I'm willing to be corrected...this was a long time ago:-)
One thing I'd really like - to be able to open more than one email in a window at once. On Windows, with TB 0.6 and 0.7, I seem to be allowed exactly one and only one email window to be open to display an email in.
Is it just me? Have I missed an option somewhere?
Seems like an odd and irritating limitation to me...
I didn't say the problem was unsolvable, I said it was hard. Adding hard problems = costs more money, and games publishers (the ones who pay for it all) don't like that a whole lot. It also doesn't solve the problem that you have to break up the level in terms of visibility. It is easy to envisage a level design that would run ok on a decent PC, yet cause a console to be utterly unable to render it, streaming or no streaming.
Btw, the main reason you don't see streaming content on PCs is the crap support for async streaming from optical drives. At least it was when I last tried to do it:(
And I'm sure Prince of Persia had more than 3 load points...maybe I just died a lot...:-)
I know you're trying to be funny, but I see comments like this a lot, and here are 2 points:
[1] Of all the things you can say about game developers, that they are 'lazy' is probably the least accurate. I doubt there are many game projects where the developers sat around saying "You know, we really ought to have spent more weekends at the office than we did!"
[2] Who do you think decides whether or not to approve extra budget for spending time producing a 'souped up'/different PC version of the game? (Hint: it's not the developers)
I may be getting into a habit of replying to you (i.e. a well-known troll), but I saw your posting got "5, Informative", and I can't hold back.:-)
It's not just the technology (i.e. engine/framework APIs) that's the problem. The problem is game production. And the problem is that game production is not just about technology. It's about game design, asset production, and so on.
Producing assets that will work fine on a GC, PS2, but hey, also on an Xbox 2 (and take advantage of the Xbox 2) is not as easy as 're-exporting'.
As for different tech capabilities limiting game design, look at the complaints about Thief: Deadly Shadows, where PC users feel the game (level design/size) was compromised to make it work ok on the XBox. I keep seeing comments on the web from people who feel that games out on PC and console suffer on the PC, because the levels expansiveness, draw distance, etc, have to be compromised to make it work on the consoles (which have much less RAM, and cpu/gfx hardware is for many tasks not as capable). These problems, despite what armchair developers like to think, are hard problems to solve in a real shipping game. That's why a lot of developers don't want to take them on. Making a game is hard enough already. Hence some of the views expressed in the article in question.
However, your point about ease of programming of PS n versus Xbox n is right on the mark. (Presumably due to the same reason that a broken clock is right twice a day...)
No problem - I checked via Google for the correct attribution as I couldn't remember who said it, and most web pages do say it's Jefferson - I only persevered until I found Wendell Phillips because I knew it definitely wasn't Jefferson, from the last time I looked into it:-).
I know you're a well known troll, but anyway, just to offer real world experience...this devkit here doesn't say "Property of [Manufacturer name]" on it, or anything like that. It wouldn't surprise me if the agreement we have with [Devkit Manufacturer] states something along those lines, but it aint written on the hardware.
7. What moron thinks there's such a thing as 100% security?
8. What moron thinks you can ship software faster just by hiring more people?
9. Maybe the 'retarded' programmer was actually trying to do his job and get the work done as soon as possible, and not reading bugtraq all the live long day or modelling attack trees so he wouldn't get owned.
10. Cut Valve some slack. They are the victims here, despite what some might think.
I think the point the poster was making was: why are you letting your friends use an account that is able to do these things? (i.e. install spyware/crap)
So the response that in order to be able to install something, you need to be using an admin account isn't really getting the point. The point is - don't let your clueless friends run riot with an admin account!
Also, Windows XP does have 'su' of a sort - right click on an exe, and choose "Run as...". Or use the runas command from the command line. I think this is in Win2k too.
Tasks that are trivial under Unix, have thus far eluded me. I still don't know how to set up DNS under Win2K.
Doesn't that sound like precisely the Why $FREE_UNIX_SYSTEM Can Never Succeed on the Desktop Argument?
Um, no, not really. I must confess I've never heard the Joe Sixpack will never use Linux because it's so hard for him to set up his DNS server argument before.
Yeah, damn those crass yanks and their labelling of a quarter of a billion people as all the same.
FWIW, I'm British, and I never realised that Ford Prefect was a joke about Americans not getting British culture. I must be one of those crass Brits.
Are you sure you didn't just decide that that was what Ford Prefect's name was about? Part of me wishes DNA was still alive so I could ask him if that's really true. Because I don't think it is.
Oh no, wait, I don't need to ask him, because he explained it himself:
I decided to call him Ford Prefect. (This was a joke that missed American audiences entirely of course, since they had never heard of the rather oddly named car, and many thought it was a typing error for Perfect.)
It seems to me that Douglas didn't intend this to be a joke at Americans' expense, because he clearly wouldn't have made the above comment if it was. If that was the point of the joke, he wouldn't have bothered to point out that Americans missed the joke.
Also, Douglas was not as prejudiced as you, and tended not to reject the population of a country out of hand in the way you seem to be doing.
Right, here's a question that pops into my head whenever I see references to Cocoa/Carbon on slashdot...
See, I've written some libraries that I use to write my apps, and I deliberately chose to make them portable, in case I ever decided to switch from Windows to Linux or Mac OS X - so I wouldn't end up losing all my software (or having to put a lot of work into porting them).
So I have APIs for general OS interface and GUI programming, which I designed to be portable, having passing familiarity with Linux and Mac OS APIs. The libraries are currently implemented for Windows, but I try to wrap Windows specific functionality in a generic 'GUI' way (something I wish other libs would do a bit more, wxWindows I'm looking at you).
Anyway, the libraries have a C++ interface, and are implemented in C++ on top of Win32.
My question is: if I want to create Mac OS X versions of these libraries, should I use Carbon or Cocoa?
My understanding is that both will work, but Cocoa is the nice shiny API that does all the clever stuff, and Carbon is being phased out, and I shouldn't use it. So new UI widgets, dialogs, various functionality have clean, comprehensive implementations via Cocoa, and Carbon is a sort of DIY solution if you want to use the new stuff. I'm also not sure how well IB works with Carbon (if at all).
But: Cocoa seems heavily oriented towards Objective C. It seems possible to mix C++ and Obj-C in an app, but how feasible is it for me to implement a version of my lib that exposes a C++ interface, yet uses Cocoa/ObjC internally? And even if it works, would it be full of nasty hacks?
If any Mac programmers can offer me any insight here, I'd be grateful.
Please note that such insight does not include "You should just use Objective C for everything", just to warn you in advance. I use C++ because of its ubiquity, my familiarity with it, and the large amount of code I already have that uses it. Objective C might be absolutely wonderful, but as all I ever hear about it is this fantastic new (sic) idea called MVC, it's hard to tell:-)
If I'm going to learn/use a different language, I'd rather try something really portable like Python. Objective C still seems like an 'oddball' language to me, that's only used on Macs. While I want to support Macs with my libraries, I'm not re-architecting and re-writing the whole lot just because Apple decided the preferred interface to their OS/GUI was an OO interface, and they wanted to use Objective C, because NeXT used it.
Slashdot Mirror
That's a fairly broad assertion...is the MS JVM that different, that code just won't run on it?
My rusty memory tells me it's a few library calls that are different, and a lot of moaning about MS adding their own native C interface (which if you then used, then sure, it wouldn't run on other JVMs), but I'm willing to be corrected...this was a long time ago :-)
I knew no-one would get it.
So in about 10 years time, we'll all be speaking different languages.
(I can wait...)
See subject
I recognise most of these rules from here - note the publication date.
Quite a good book. The things being said are good. The way they are said is terrible. Very poor writing.
So if he disregards it completely, then we can assume it's true, I guess.
I think I might set my sig to be:
and we'll see how long Linus goes without denying it! If he waits long enough, then we can take it to be true :-)
One thing I'd really like - to be able to open more than one email in a window at once. On Windows, with TB 0.6 and 0.7, I seem to be allowed exactly one and only one email window to be open to display an email in.
Is it just me? Have I missed an option somewhere?
Seems like an odd and irritating limitation to me...
I didn't say the problem was unsolvable, I said it was hard. Adding hard problems = costs more money, and games publishers (the ones who pay for it all) don't like that a whole lot. It also doesn't solve the problem that you have to break up the level in terms of visibility. It is easy to envisage a level design that would run ok on a decent PC, yet cause a console to be utterly unable to render it, streaming or no streaming.
:(
:-)
Btw, the main reason you don't see streaming content on PCs is the crap support for async streaming from optical drives. At least it was when I last tried to do it
And I'm sure Prince of Persia had more than 3 load points...maybe I just died a lot...
I know you're trying to be funny, but I see comments like this a lot, and here are 2 points:
[1] Of all the things you can say about game developers, that they are 'lazy' is probably the least accurate. I doubt there are many game projects where the developers sat around saying "You know, we really ought to have spent more weekends at the office than we did!"
[2] Who do you think decides whether or not to approve extra budget for spending time producing a 'souped up'/different PC version of the game? (Hint: it's not the developers)
I may be getting into a habit of replying to you (i.e. a well-known troll), but I saw your posting got "5, Informative", and I can't hold back. :-)
It's not just the technology (i.e. engine/framework APIs) that's the problem. The problem is game production. And the problem is that game production is not just about technology. It's about game design, asset production, and so on.
Producing assets that will work fine on a GC, PS2, but hey, also on an Xbox 2 (and take advantage of the Xbox 2) is not as easy as 're-exporting'.
As for different tech capabilities limiting game design, look at the complaints about Thief: Deadly Shadows, where PC users feel the game (level design/size) was compromised to make it work ok on the XBox. I keep seeing comments on the web from people who feel that games out on PC and console suffer on the PC, because the levels expansiveness, draw distance, etc, have to be compromised to make it work on the consoles (which have much less RAM, and cpu/gfx hardware is for many tasks not as capable). These problems, despite what armchair developers like to think, are hard problems to solve in a real shipping game. That's why a lot of developers don't want to take them on. Making a game is hard enough already. Hence some of the views expressed in the article in question.
However, your point about ease of programming of PS n versus Xbox n is right on the mark. (Presumably due to the same reason that a broken clock is right twice a day...)
No problem - I checked via Google for the correct attribution as I couldn't remember who said it, and most web pages do say it's Jefferson - I only persevered until I found Wendell Phillips because I knew it definitely wasn't Jefferson, from the last time I looked into it :-).
Pedantry alert:
Actually, that one is from Wendell Phillips, although according to that link, it's a common mistake to attribute it to Jefferson.
And it's refreshed, not watered, I believe. It sounds better, too, Sounded good when Ed Harris said it, anyway ;-)
I know you're a well known troll, but anyway, just to offer real world experience...this devkit here doesn't say "Property of [Manufacturer name]" on it, or anything like that. It wouldn't surprise me if the agreement we have with [Devkit Manufacturer] states something along those lines, but it aint written on the hardware.
EA's idea of 'work' may differ from Valve's.
7. What moron thinks there's such a thing as 100% security?
8. What moron thinks you can ship software faster just by hiring more people?
9. Maybe the 'retarded' programmer was actually trying to do his job and get the work done as soon as possible, and not reading bugtraq all the live long day or modelling attack trees so he wouldn't get owned.
10. Cut Valve some slack. They are the victims here, despite what some might think.
Step 1: Click on the 'Safely remove hardware' icon in the taskbar notification area, and choose the hardware to unplug from the pop-up menu.
Step 2: Unplug the hardware.
Step 3: There is no step 3.
Works for me on XP with hard drives, USB keys, iPods, PCMCIA cards, etc.
I think the point the poster was making was: why are you letting your friends use an account that is able to do these things? (i.e. install spyware/crap)
So the response that in order to be able to install something, you need to be using an admin account isn't really getting the point. The point is - don't let your clueless friends run riot with an admin account!
Also, Windows XP does have 'su' of a sort - right click on an exe, and choose "Run as...". Or use the runas command from the command line. I think this is in Win2k too.
Um, no, not really. I must confess I've never heard the Joe Sixpack will never use Linux because it's so hard for him to set up his DNS server argument before.
But maybe I wasn't paying attention :-)
Well, the shrooming should help that :-)
To not have to redecorate it every 10,000 hours?
Yeah, damn those crass yanks and their labelling of a quarter of a billion people as all the same.
FWIW, I'm British, and I never realised that Ford Prefect was a joke about Americans not getting British culture. I must be one of those crass Brits.
Are you sure you didn't just decide that that was what Ford Prefect's name was about? Part of me wishes DNA was still alive so I could ask him if that's really true. Because I don't think it is.
Oh no, wait, I don't need to ask him, because he explained it himself:
It seems to me that Douglas didn't intend this to be a joke at Americans' expense, because he clearly wouldn't have made the above comment if it was. If that was the point of the joke, he wouldn't have bothered to point out that Americans missed the joke.
Also, Douglas was not as prejudiced as you, and tended not to reject the population of a country out of hand in the way you seem to be doing.
Right, here's a question that pops into my head whenever I see references to Cocoa/Carbon on slashdot...
See, I've written some libraries that I use to write my apps, and I deliberately chose to make them portable, in case I ever decided to switch from Windows to Linux or Mac OS X - so I wouldn't end up losing all my software (or having to put a lot of work into porting them).
So I have APIs for general OS interface and GUI programming, which I designed to be portable, having passing familiarity with Linux and Mac OS APIs. The libraries are currently implemented for Windows, but I try to wrap Windows specific functionality in a generic 'GUI' way (something I wish other libs would do a bit more, wxWindows I'm looking at you).
Anyway, the libraries have a C++ interface, and are implemented in C++ on top of Win32.
My question is: if I want to create Mac OS X versions of these libraries, should I use Carbon or Cocoa?
My understanding is that both will work, but Cocoa is the nice shiny API that does all the clever stuff, and Carbon is being phased out, and I shouldn't use it. So new UI widgets, dialogs, various functionality have clean, comprehensive implementations via Cocoa, and Carbon is a sort of DIY solution if you want to use the new stuff. I'm also not sure how well IB works with Carbon (if at all).
But: Cocoa seems heavily oriented towards Objective C. It seems possible to mix C++ and Obj-C in an app, but how feasible is it for me to implement a version of my lib that exposes a C++ interface, yet uses Cocoa/ObjC internally? And even if it works, would it be full of nasty hacks?
If any Mac programmers can offer me any insight here, I'd be grateful.
Please note that such insight does not include "You should just use Objective C for everything", just to warn you in advance. I use C++ because of its ubiquity, my familiarity with it, and the large amount of code I already have that uses it. Objective C might be absolutely wonderful, but as all I ever hear about it is this fantastic new (sic) idea called MVC, it's hard to tell :-)
If I'm going to learn/use a different language, I'd rather try something really portable like Python. Objective C still seems like an 'oddball' language to me, that's only used on Macs. While I want to support Macs with my libraries, I'm not re-architecting and re-writing the whole lot just because Apple decided the preferred interface to their OS/GUI was an OO interface, and they wanted to use Objective C, because NeXT used it.
Thanks....
Heh. A government run dept. who won't deal with you because you're too slow when responding.
That's a good one! :)
Because you can find a place to park the Pinto.