And funnily enough, you pay more for a cable with the better wire gauge... (Not necessarily $900 more, but it's probably the difference between the $15 cable and the $30 cable on ebay.)
The really annoying part is that HDMI 1.3b introduced the distinction in cable testing between "works to original spec" and "works to newer spec with more bandwidth", but both types are "1.3b-certified", you have to look at the bandwidth to distinguish them.
The article is a verbatim repost of a verbatim repost of the ICANN PDF press release. Including down to having left out the ccTLDs from their list of "new IDN country code top-level domains (ccTLDs) and the associated organizations"
The original PDF linked to the meeting minutes collection on the ICANN site, a link that was lost by the reposting process.
The ICANN Meeting Minutes themselves are quite clear on what has been done: http://www.icann.org/en/minutes/resolutions-25jun10-en.htm#2
Other interesting links are the provided plans on how they will be implemented such that they don't cause confusion or other troubles in the way described by many previous posters.
Although they're keeping the simplified and traditional name variants in sync, they don't appear to be intending to also sync the.cn and.tw hierarchies.
Definitely fishy about that menu... IT'S TOO EXPENSIVE FOR A CHINESE RESTAURANT! For $10, (in ANY English-speaking country's currency) that fried rice better be some top-of-the-line rice with corn-fed organic egg cooked to golden perfection!
I'd disagree that it's a different standard. Dollars per hour is only part of it though, the other half is the dollar value you put on the entertainment.
Hours per dollar spent and dollars enjoyed per hour. You estimate these two amounts, and you get an estimate of dollars enjoyed versus dollars spent.
So you're (or at least I'm, maybe I'm alone in this...) generally looking at games or DVDs or occasionally audio CDs and trying to guess how long/often I'll play 'em, and whether the entertainment per hour is sufficient to justify the cost-per-hour.
Portal's a great example someone used below, because it's only 6 hours, but it's 6 high-quality hours, which you might pay more per-hour for than six hours of something dreadful.
Games big difference over the cinema (and actually a commonality with books and audio CDs and DVDs) is that in the case of cinema, the entertainment length is arbitrarily limited by someone else, so you know the dollars-per-hour up front.
For everything else, you have to guesstimate how much you're going to play/read/listen to something (I wouldn't pay for an album I'll listen to once through, but I'll buy an album which has a song or two I've had on my shortlist of songs for a month...)
All the control you have over cinema entertainment (or a concert) is leaving early if you wish. That comes down to a sunk-cost consideration, which I can't say I've ever done, but I can see that people reach the point where they're enjoying a movie not at all (eg. $0/hour benefit).
I personally generally use my income per hour when I consider entertainment dollars per hour. Something'd better be damn good for me to spend more than the income I make in an hour on it, but my Steam purchase history suggests that for $5, I'll buy something that I never expect to play...
This also means that I generally give new full-price games a few hours at least, so they're dragged down to below my wage level, before they go onto the shelf and I forget to ever finish 'em.
And funnily enough, I like longer movies because I do feel I'm getting better value for my ticket. Short-but-awesome will beat long-and-underwhelming still.
On the other hand, I don't really apply this to books, but only because they're almost always less than an hour's work in cost, and more than an hour to read. So they're already below my pain threshold, in that respect.
Graphic novels, on the gripping hand, are hideously expensive on a per-hour basis, so I generally buy only that which I know I'll enjoy. And I still always feel that it was too short for the cost.
But "androids" would be a single product category. And a "Nexus-One Android" and a "Nexus-6 Android" would certainly have potential to confuse the marketplace.
Maybe someone thinks Google are in the android business?
(Dunno what happened with my other comment. The preview was fine...)
Little miss entitlement got a "Bachelor of Business Administration" in "IT".
Wait, she got a B.BAIT? And is now upset that she paid lots of money and didn't get what she expected?
If only there was some kind of consumer protection authority or industry ombudsman to step in and examine the details of this purported Bait And Switch before it went so far as to end up in court...
Going off the C89 spec linked earlier in this discussion
You're looking for section 3.3.2.3 for -> and 3.3.3.2 for *.
The latter refers to footnote 34 which indicates that dereferencing the null pointer type is invalid. However, the former makes no statement about requiring that the left operand of -> be a valid pointer, but I suppose you could read into the existing statement "The value is that of the named member of the object to which the first expression points, and is an lvalue." the inference that once -> is used on a pointer, that pointer must have pointed to a valid object.
It's far from explicit though, and I think that'd be the backwards inference to make at that point, myself.
XTest? That generates synthetic events, I don't think it lets you read relative mouse input data, or stop the cursor moving around when doing so, which is what that bug needs.
You might be thinking of XTrap, which Xorg dropped in 1.6. See comment 237 through comment 241 of that bug for details.
Rendering Japanese in romaji (roman characters) makes it all but unreadable. You lose a massive amount of semantic information.
The same information is lost when speaking or reading out aloud.
Not true. Japanese has tonal aspects to the spoken language which are not present in its phonetic writing system, but which differentiate phonetically similar words and ambiguous phrases, and indicate divisions within sentences.
If the agile development roundtable at GDC 2008 was any indication, scrum is already rather popular in games development, and gaining momentum.
Never tried it myself though. I'm quite happy being able to go to my boss and say "What do you think I should be working on next?". I'm not convinced that self-management is the path to self-empowerment.
In fact the best project I've worked on was completely devoid of any significant overtime whatsoever (the only overtime was due to some misinterpreted TCRs during finaling).
So no crunch time, except that one bit of crunch time?
I do admit that one is pretty damn close to zero compared to some of the horror stories that float around the games industry the same way that coffee-cup holder incidents float around support desks.
As another poster or two have already noted, I think people's idea of crunch (and the companion term, "death march") varies quite wildly.
My own feeling currently is that if you don't crunch on a project, you get left with a sort of feeling that you could have done more or better. Milestones are soft of like exams in that way.
But I haven't really experienced a crunch-free project to compare it with, nor have I experienced a death march or even been scarred by a particularly heavy crunch.
That last 10% is all the unexpected stuff. The stuff you can't schedule, but can merely attempt to estimate what time it'll take.
I'll pick some random examples.
Requirements disagreements. Not changes, but when requirements are perfectly clear to all parties, but nonetheless not the _same_ clear vision.
Greater-than-budgeted for absenteeism. As I already mentioned, losing the whole team for a week due to illness will be devastating to a milestone.
For that matter, a few low-output days at the wrong time can also make quite a big dent, if you're on the critical path.
Incredibly difficult to replicate and track down bugs. Everybody gets heisenbugs. I'm open to suggestions on estimating time to fix for an issue you haven't got a solid repro on, let alone an idea of the actual bug.
Technology changes. New VCS, new graphics engine, new audio engine, new language, new art tools, new Internet connection. You only change these things before a project starts, obviously, but that doesn't prevent them throwing up new and interesting delays well after you thought they'd settled into the routine quite nicely. And that's when they aren't so bad that you need to switch and retool mid-project.
Oversights in the scheduling. The number of times I've said "Oh, I forgot to allow time for change X, which is needed for features Y and Z which I have to do this milestone"... well actually only a couple of times, so far.
Natural disasters. When a burst water main puts your office and the server room under 30cm of water on a Sunday afternoon, the mere existence of backups doesn't remove the smell from the carpets. That can vary from shutting down the office for a few days, to merely causing everyone to take any opportunity possible to get out of the building.
And the nastiest one, to my mind.
Once the game comes together into something the designer can play with, the designer discovers that it's not actually that fun. One could argue that this is a change in requirements, but at the end of the day, "it has to actually be a game" is a fundamental requirement of producing games. Some places have the luxury of killing projects that hit this point and moving on to something new. Some places have the bloody-mindedness to ship it anyway. Some places will try and fix it during polish time. And some places will tell the publisher what's happened and try and retool the milestones to squeeze some more design time in.
Anyway, moving milestones to account for the above avoids the crunch and is usually the correct decision but doesn't actually change the fact that the project took longer than scheduled.
The issue that started this "split" is about people who _are_ being paid for crunch time, in so far as they have (according to what I've read about Epic, anyway) agreed to work above-and-beyond a 40-hour week on a regular basis for the money being offered. I don't think these people are being unfairly exploited.
It's of course blown out to encompass all those for whom crunch is above and beyond the call of their contract, and who aren't getting compensated for it.
And I certainly agree, no compensation, no crunch. If your studio doesn't look after you, don't labour on thinking you're setting yourself up for better later. You're just marking yourself as willing to be taken advantage of.
But not a heck of a lot more complicated/complex than a collaborative picture, which also involves manufacturing or paying someone else to manufacture the canvas, easel, paints, and having to stop and remeasure for different museums every step of the way. And where half your artists are using acrylics, and half are using watercolours, except for the one person who insists on painting by putting the entire canvas on the floor and flinging chocolate syrup at it.
Which is why so many games use an existing engine. It's like starting your picture with the easel already set, a nice set of premixed colours, and possibly even a set of measurements for common museums.
It's also why so many games studios refuse to hire people who fling chocolate syrup at things.
As opposed to all the other things you don't like in your terms of employment? Frankly, I'm happier with the idea of Epic saying up front "we expect you to work 60 hour weeks" than of ending up somewhere which has a 37.5-hour week on the contract, but then gives you negative performance reviews and references if you fail to be at the office before your boss every Saturday.
Not to say I'd necessarily take a job at Epic. I don't think they're bad for doing it, I just think they're wrong.
And, for the most part, we do it becomes we love games, and want to be part of that process.
Yep, and that lasts a couple of years until you realize that making games isn't anything like playing them, and that working behind the scenes on a product you used to enjoy has killed your enjoyment of them.
Which usually indicates that you've confused "love games and want to be part of the process" with "love playing games and want to be able to play games for a living". They're not mutually inconsistent, but my criteria for enjoying a game has gone up drastically since I started working in the industry.
This is not a bad thing.
And sure, I could be making more money programming in a business environment, or administering systems (and have done exactly that) but then I wouldn't be a video games programmer. I wouldn't be (sometimes a bit indirectly) manufacturing fun, producing someone's creative vision, and generally contributing to that vast pool of noise that entertained me throughout my childhood.
Slashdot Mirror
You mean like the official Group Voting Tickets?
Oh, except within 6 metres of the polling place, as per another AEC backgrounder.
The AEC's backgrounder says not. It's illegal to _force_ or _bribe_ people to vote informally (or in any other way) though.
And funnily enough, you pay more for a cable with the better wire gauge... (Not necessarily $900 more, but it's probably the difference between the $15 cable and the $30 cable on ebay.)
The really annoying part is that HDMI 1.3b introduced the distinction in cable testing between "works to original spec" and "works to newer spec with more bandwidth", but both types are "1.3b-certified", you have to look at the bandwidth to distinguish them.
http://en.wikipedia.org/wiki/HDMI#Version_comparison
Unfortunately the Labour Party (Current Federal Government)
Wait, when did the Labor Party lose government? They were still in charge on Friday...
The article is a verbatim repost of a verbatim repost of the ICANN PDF press release. Including down to having left out the ccTLDs from their list of "new IDN country code top-level domains (ccTLDs) and the associated organizations"
The original PDF linked to the meeting minutes collection on the ICANN site, a link that was lost by the reposting process.
The ICANN Meeting Minutes themselves are quite clear on what has been done:
http://www.icann.org/en/minutes/resolutions-25jun10-en.htm#2
Other interesting links are the provided plans on how they will be implemented such that they don't cause confusion or other troubles in the way described by many previous posters.
http://www.cnnic.cn/html/Dir/2010/06/12/5852.htm
http://www.twnic.net/english/dn/dn_07a.htm
(HKIRC's isn't in the minutes)
Although they're keeping the simplified and traditional name variants in sync, they don't appear to be intending to also sync the .cn and .tw hierarchies.
Actually, I had no idea what "SIFI" meant until I read the replies.
I did enjoy the rest of your comment, and considered it informative. What a day to not have mod points. >_
Definitely fishy about that menu... IT'S TOO EXPENSIVE FOR A CHINESE RESTAURANT! For $10, (in ANY English-speaking country's currency) that fried rice better be some top-of-the-line rice with corn-fed organic egg cooked to golden perfection!
Maybe they're in Hong Kong?
SCUMM was developed for Maniac Mansion. That's the final MM in SCUMM.
See http://www.scummvm.org/faq/#1_2 since you already read the Wikipedia page... ^_^
I'd disagree that it's a different standard. Dollars per hour is only part of it though, the other half is the dollar value you put on the entertainment.
Hours per dollar spent and dollars enjoyed per hour. You estimate these two amounts, and you get an estimate of dollars enjoyed versus dollars spent.
So you're (or at least I'm, maybe I'm alone in this...) generally looking at games or DVDs or occasionally audio CDs and trying to guess how long/often I'll play 'em, and whether the entertainment per hour is sufficient to justify the cost-per-hour.
Portal's a great example someone used below, because it's only 6 hours, but it's 6 high-quality hours, which you might pay more per-hour for than six hours of something dreadful.
Games big difference over the cinema (and actually a commonality with books and audio CDs and DVDs) is that in the case of cinema, the entertainment length is arbitrarily limited by someone else, so you know the dollars-per-hour up front.
For everything else, you have to guesstimate how much you're going to play/read/listen to something (I wouldn't pay for an album I'll listen to once through, but I'll buy an album which has a song or two I've had on my shortlist of songs for a month...)
All the control you have over cinema entertainment (or a concert) is leaving early if you wish. That comes down to a sunk-cost consideration, which I can't say I've ever done, but I can see that people reach the point where they're enjoying a movie not at all (eg. $0/hour benefit).
I personally generally use my income per hour when I consider entertainment dollars per hour. Something'd better be damn good for me to spend more than the income I make in an hour on it, but my Steam purchase history suggests that for $5, I'll buy something that I never expect to play...
This also means that I generally give new full-price games a few hours at least, so they're dragged down to below my wage level, before they go onto the shelf and I forget to ever finish 'em.
And funnily enough, I like longer movies because I do feel I'm getting better value for my ticket. Short-but-awesome will beat long-and-underwhelming still.
On the other hand, I don't really apply this to books, but only because they're almost always less than an hour's work in cost, and more than an hour to read. So they're already below my pain threshold, in that respect.
Graphic novels, on the gripping hand, are hideously expensive on a per-hour basis, so I generally buy only that which I know I'll enjoy. And I still always feel that it was too short for the cost.
William Shatner's TekWar is what you're thinking of.
But "androids" would be a single product category. And a "Nexus-One Android" and a "Nexus-6 Android" would certainly have potential to confuse the marketplace.
Maybe someone thinks Google are in the android business?
(Dunno what happened with my other comment. The preview was fine...)
But
Little miss entitlement got a "Bachelor of Business Administration" in "IT".
Wait, she got a B.BAIT? And is now upset that she paid lots of money and didn't get what she expected?
If only there was some kind of consumer protection authority or industry ombudsman to step in and examine the details of this purported Bait And Switch before it went so far as to end up in court...
Going off the C89 spec linked earlier in this discussion
You're looking for section 3.3.2.3 for -> and 3.3.3.2 for *.
The latter refers to footnote 34 which indicates that dereferencing the null pointer type is invalid. However, the former makes no statement about requiring that the left operand of -> be a valid pointer, but I suppose you could read into the existing statement "The value is that
of the named member of the object to which the first expression points, and is an lvalue." the inference that once -> is used on a pointer, that pointer must have pointed to a valid object.
It's far from explicit though, and I think that'd be the backwards inference to make at that point, myself.
Try "High-accurary Heliocentric Galactic Time-normalised Tetrahedron GPS" as a better acronym?
XTest? That generates synthetic events, I don't think it lets you read relative mouse input data, or stop the cursor moving around when doing so, which is what that bug needs.
You might be thinking of XTrap, which Xorg dropped in 1.6. See comment 237 through comment 241 of that bug for details.
Rendering Japanese in romaji (roman characters) makes it all but unreadable. You lose a massive amount of semantic information.
The same information is lost when speaking or reading out aloud.
Not true. Japanese has tonal aspects to the spoken language which are not present in its phonetic writing system, but which differentiate phonetically similar words and ambiguous phrases, and indicate divisions within sentences.
If the agile development roundtable at GDC 2008 was any indication, scrum is already rather popular in games development, and gaining momentum.
Never tried it myself though. I'm quite happy being able to go to my boss and say "What do you think I should be working on next?". I'm not convinced that self-management is the path to self-empowerment.
In fact the best project I've worked on was completely devoid of any significant overtime whatsoever (the only overtime was due to some misinterpreted TCRs during finaling).
So no crunch time, except that one bit of crunch time?
I do admit that one is pretty damn close to zero compared to some of the horror stories that float around the games industry the same way that coffee-cup holder incidents float around support desks.
As another poster or two have already noted, I think people's idea of crunch (and the companion term, "death march") varies quite wildly.
My own feeling currently is that if you don't crunch on a project, you get left with a sort of feeling that you could have done more or better. Milestones are soft of like exams in that way.
But I haven't really experienced a crunch-free project to compare it with, nor have I experienced a death march or even been scarred by a particularly heavy crunch.
That last 10% is all the unexpected stuff. The stuff you can't schedule, but can merely attempt to estimate what time it'll take.
I'll pick some random examples.
Requirements disagreements. Not changes, but when requirements are perfectly clear to all parties, but nonetheless not the _same_ clear vision.
Greater-than-budgeted for absenteeism. As I already mentioned, losing the whole team for a week due to illness will be devastating to a milestone.
For that matter, a few low-output days at the wrong time can also make quite a big dent, if you're on the critical path.
Incredibly difficult to replicate and track down bugs. Everybody gets heisenbugs. I'm open to suggestions on estimating time to fix for an issue you haven't got a solid repro on, let alone an idea of the actual bug.
Technology changes. New VCS, new graphics engine, new audio engine, new language, new art tools, new Internet connection. You only change these things before a project starts, obviously, but that doesn't prevent them throwing up new and interesting delays well after you thought they'd settled into the routine quite nicely. And that's when they aren't so bad that you need to switch and retool mid-project.
Oversights in the scheduling. The number of times I've said "Oh, I forgot to allow time for change X, which is needed for features Y and Z which I have to do this milestone"... well actually only a couple of times, so far.
Natural disasters. When a burst water main puts your office and the server room under 30cm of water on a Sunday afternoon, the mere existence of backups doesn't remove the smell from the carpets. That can vary from shutting down the office for a few days, to merely causing everyone to take any opportunity possible to get out of the building.
And the nastiest one, to my mind.
Once the game comes together into something the designer can play with, the designer discovers that it's not actually that fun. One could argue that this is a change in requirements, but at the end of the day, "it has to actually be a game" is a fundamental requirement of producing games. Some places have the luxury of killing projects that hit this point and moving on to something new. Some places have the bloody-mindedness to ship it anyway. Some places will try and fix it during polish time. And some places will tell the publisher what's happened and try and retool the milestones to squeeze some more design time in.
Anyway, moving milestones to account for the above avoids the crunch and is usually the correct decision but doesn't actually change the fact that the project took longer than scheduled.
The issue that started this "split" is about people who _are_ being paid for crunch time, in so far as they have (according to what I've read about Epic, anyway) agreed to work above-and-beyond a 40-hour week on a regular basis for the money being offered. I don't think these people are being unfairly exploited.
It's of course blown out to encompass all those for whom crunch is above and beyond the call of their contract, and who aren't getting compensated for it.
And I certainly agree, no compensation, no crunch. If your studio doesn't look after you, don't labour on thinking you're setting yourself up for better later. You're just marking yourself as willing to be taken advantage of.
But not a heck of a lot more complicated/complex than a collaborative picture, which also involves manufacturing or paying someone else to manufacture the canvas, easel, paints, and having to stop and remeasure for different museums every step of the way. And where half your artists are using acrylics, and half are using watercolours, except for the one person who insists on painting by putting the entire canvas on the floor and flinging chocolate syrup at it.
Which is why so many games use an existing engine. It's like starting your picture with the easel already set, a nice set of premixed colours, and possibly even a set of measurements for common museums.
It's also why so many games studios refuse to hire people who fling chocolate syrup at things.
As opposed to all the other things you don't like in your terms of employment? Frankly, I'm happier with the idea of Epic saying up front "we expect you to work 60 hour weeks" than of ending up somewhere which has a 37.5-hour week on the contract, but then gives you negative performance reviews and references if you fail to be at the office before your boss every Saturday.
Not to say I'd necessarily take a job at Epic. I don't think they're bad for doing it, I just think they're wrong.
Yep, and that lasts a couple of years until you realize that making games isn't anything like playing them, and that working behind the scenes on a product you used to enjoy has killed your enjoyment of them.
Which usually indicates that you've confused "love games and want to be part of the process" with "love playing games and want to be able to play games for a living". They're not mutually inconsistent, but my criteria for enjoying a game has gone up drastically since I started working in the industry.
This is not a bad thing.
And sure, I could be making more money programming in a business environment, or administering systems (and have done exactly that) but then I wouldn't be a video games programmer. I wouldn't be (sometimes a bit indirectly) manufacturing fun, producing someone's creative vision, and generally contributing to that vast pool of noise that entertained me throughout my childhood.