This is a non-story. And it's rather insulting that it made it ANYWHERE let alone a major news/blog/whatever site. Who is the source? Oh, that's right, some random "offended" person at http://gaygamer.net/index.php?id=1632 who is complaining that the team behind a currently-in-production game made an art decision.
Have you actually read the disclaimer? It specifically says "in-game". The quote on shacknews omits that, and adds other (scarier) words that aren't actually in the disclaimer. Pure FUD.
That disclaimer you link to explicitly says "in-game". It does nothing that Steam doesn't do, with regards to tracking what the player looks at and how much time is spent with something visible on screen (in this case, targetted in-game ads).
Thanks for the gamespot link. See my other comment in reply to the sibling post - this appears to be a vaguely and dangerously worded piece of paper to describe a relatively harmless "how-long-did-they-look-at-that-in-game-advertisem ent" reporting tool.
"Other popular game titles have included spyware in the past to aid anti-cheating measures. Is spyware acceptable to the public when it comes with a game, or has EA made a PR misstep?"
What a disgusting attempt to inflame people on an issue that doesn't exist. First of all, anti-cheating measures are not spyware. Spyware reports back on what you are doing. Programs like PunkBuster or Warden (part of Blizzard's WoW client) do not report on anything except the game process, UNLESS THEY CATCH YOU CHEATING.
Secondly, there are more options than "spyware is acceptable" and "EA did something evil". For starters, maybe (probably?) Battlefield 2142 does not contain spyware. Maybe it does, but it is opt-in, which would not be evil. Maybe it does, but is opt-out on install, which would still be evil but not as bad as this/. post makes it out to be.
And maybe this whole thing is made up because AFAIK, nobody other than that one ShackNews forum poster has confirmed this.
This rumor has been going around the net based off of ONE post on the ShackNews forums, with no confirmation whatsoever as far as I can tell. It seems to be fueled by the neverending hate for anything that EA does.
If you have a power tripping guild leader and you don't like the 39 other people you're there with, maybe that's a sign to find a new guild, hmm? There are good ones out there where people have a great time, eveb occasionally meet up in real life to have drinks and hang out. They're just harder to find because they don't have the huge burnout rate that crappy guilds do, thus they don't need to advertise so blatently.
The Wii controller is never used as a 1:1 motion replication like you see in the advertising trailers. The amount of motion you need to put in is very small; you can leave your hands by your sides or in your lap or wherever. Of course, you're still welcome to flail around if that's what you really want to do.
I wish I got paid $5 a minute, but I don't. If you fix your math to reflect that, it comes out to 12,000 * $5/hour * (5/60) hours = $5000... still greater than zero, but not as big a deal.
Oh, don't get me wrong. I've got an HDTV and I love me some hi-def.
I'm not saying that 720p doesn't look freaking amazing. But I am saying that EDTV looks good already. Maybe you demand that extra visual quality, and then Revolution is not for you. But I can watch my DVDs without complaining about bad quality, so I think that most people will play Revolution games without minding either.
Widescreen 480p @ 60fps with a high enough triangle count looks pretty damn awesome. And you can always get a fancy interpolating upconvertor if you're bothered *that much*.
In case you've forgotten, those DVDs you watch are 480p @ 30fps (well, 480i @ 60...)
No, no no no no no! Warcraft Adventures was a point-and-click 2D adventure game, much like the old Monkey Island games, or The Dig and other LucasArts titles. It was essentially completed, but needed a lot of tuning for puzzle difficulty and "fun factor".
While it was still in development, a Monkey Island 4 came out and basically made every 2D adventure game look obsolete. Blizzard realized that Warcraft Adventuers didn't meet the new bar for adventure games, and they were having a lot of trouble fine-tuning the game, and they probably didn't want to make it in the first place (the idea was being pushed by Vivendi, the parent company). So they cancelled it and ate a huge loss on the development costs, which they then owed to Vivendi and only started paying back when World of Warcraft money came rolling in.
You could make the same argument against SimCity, The Sims, etc: "That looks like a lot of cool technology, and there is a huge degree of player freedom, but is it a compelling game?"
Maybe Spore is just doomed to repeat the failures of SimCity and The Sims;) Or maybe we have a very narrow-minded stereotype of what actually makes a game compelling.
My pleasure! Believe me, many "senior" C++ programmers have never bothered to understand these issues either... and while they may be rare in practice, they do come up every now and then, and ignorance is not a defense against unbounded memory usage:)
A handle can be defined as a double pointer, and the locking operation could just be dereferencing it (assuming a single-threaded model of operation). I was speaking metaphorically about notification, not describing an actual event model;)
The technique is still very useful if you have a program that follows one of a few very specific allocation patterns. For example, consider a program that allocates many small blocks at once and then frees a large (but non-consecutive) percentage. The ability to compact the heap lets you regain all the space you lose when your free holes are smaller than your VM page size.
Will most applications have this problem? Probably not. But the ones that do have it, tend to have it in spades. A handle-based allocation sytem can be a real win in those cases.
There is a large difference between "C++ as an official specification" and "C++ as most people use it".
You could probably write a standards-conforming C++ compiler that abstracted pointers in a way that allowed objects to be relocated to new memory. But you could never compile a large application with it, because so few people actually write 100% standards-conforming C++ code. C++ programmers expect to be able to cast their void*'s to size_t's and screw around with them, specifications-be-damned.
I've seen some positively hideous tricks in shipping applications, like casting pointers to char* to be able to use the low bits and top bit as flags. You'll never be able to erase that from the language, no matter how loudly you scream "undefined behavior" at the programmers.
I was not necessarily talking about Firefox, just addressing (hah) a misconception in the parent post: fragmentation is not related to garbage collection. I didn't want to get into a lengthy discussion of virtual addressing, page faults, etc. as well;)
But you're correct. Thanks to the rise of "smart" binned allocators like dlmalloc, fragmentation is no longer the huge concern that it used to be with (for example) the basic Win32 heap API. Modern allocators are now reasonably smart about reusing best-fit blocks and not leaving tiny holes scattered in your VM pages.
Anyway, fragmentation is certainly not the primary cause of Firefox's high memory use. I am merely pointing out that my original post's parent had a poor conception of how fragmentation could be dealt with in.
You're confusing garbage collection with heap compaction.
People have written garbage collectors for C++, and they work just fine. But they do not help with fragmentation, which is the problem you're describing. That requires a heap-compacting allocator (aka a "handle" allocator). Many languages with garbage collection also use a heap-compacting allocator. C++ does not, because of a low-level language "feature": pointers, and specifically, pointer arithmetic.
If an object moves in memory, then people have to be notified that it has moved, or they won't know where to access it. Languages like Java handle this behind-the-scenes; the system library tracks objects for you, and your program never knows (or cares) whre an individual object is.
C++ allows direct access to system memory, and it tells you precisely where your objects are located. Programmers are then free to do all kinds of things like compute distance to other objects, or convert the location to a number and do arbitrary math operations on it.
When an object moves, anything that refers to it needs to be updated. Well, good luck figuring that out in a language with pointer arithmetic! The system would need to magically determine whether or not a numeric value was actually a memory locations. And what if a program computed the distance between two objects, and later on used that distance to get from one object to the other? The system has no idea of what can be safely moved, and what has to stay put. So nothing can ever be moved.
There are workarounds of course -- if you write a program with heap-compaction in mind, then you can use a "handle" system, where every object has an ID. You remember the ID, and to access the object, you ask the system for a temporary memory location. And as soon as you're done, you "forget" the memory location and let the system shuffle things around in memory. The next time you give that ID to the system, you might get back a different memory location, but you were already expecting that so your program doesn't mind.
But handle allocation is slower, less efficient, and more annoying to use than a traditional fixed-location allocator. You have to start your project with it in mind; retrofitting existing code to use a handle allocator is a giant timesink and prone to conversion errors. And if you don't mind the loss of performance due to using a handle allocator, why are you using C++ in the first place?
Apparently it was so buggy and incomplete that even EA could not hash together a shippable build in time for holidays, and now it's been pushed back to late spring.
You make it sound like a bad thing! The fact that they let it miss the holiday season indicates, to me at least, that they are focusing on a high-quality product instead of trying to "hash together a shippable build".
Everybody gives game companies shit for releasing incomplete or buggy games, and now some people are giving companies shit for not releasing incomplete or buggy games.
I read your post twice and I still can't figure out what you're saying.
EA is not the only game company, so if staff is being worked "into an early grave" on games that "they wouldn't have touched with a barge pole" if they had a choice, why do they still work there? Midway, Activision, THQ, and MS Games are all hiring. And EA has just conveniently pointed out that their employees are not bound by non-compete agreements.
The only reason EA had such poor earnings is that so few people actually GOT a 360 during the holiday sales season; customers are saving up their cash instead of spending on current-gen games.
Every console-heavy publisher is going through the same squeeze right now. EA is just being squeezed the most because it is the heaviest.
Slashdot Mirror
This is a non-story. And it's rather insulting that it made it ANYWHERE let alone a major news/blog/whatever site. Who is the source? Oh, that's right, some random "offended" person at http://gaygamer.net/index.php?id=1632 who is complaining that the team behind a currently-in-production game made an art decision.
Have you actually read the disclaimer? It specifically says "in-game". The quote on shacknews omits that, and adds other (scarier) words that aren't actually in the disclaimer. Pure FUD.
That disclaimer you link to explicitly says "in-game". It does nothing that Steam doesn't do, with regards to tracking what the player looks at and how much time is spent with something visible on screen (in this case, targetted in-game ads).
Thanks for the gamespot link. See my other comment in reply to the sibling post - this appears to be a vaguely and dangerously worded piece of paper to describe a relatively harmless "how-long-did-they-look-at-that-in-game-advertisem ent" reporting tool.
Oh, you mean in this post, where he refutes this entire story, directly and succinctly ?
6 6802&postcount=27
/. editors to add an Update to this story with a link to this post.
http://www.totalbf2142.com/forums/showpost.php?p=
I hereby call on the
"Other popular game titles have included spyware in the past to aid anti-cheating measures. Is spyware acceptable to the public when it comes with a game, or has EA made a PR misstep?"
/. post makes it out to be.
What a disgusting attempt to inflame people on an issue that doesn't exist. First of all, anti-cheating measures are not spyware. Spyware reports back on what you are doing. Programs like PunkBuster or Warden (part of Blizzard's WoW client) do not report on anything except the game process, UNLESS THEY CATCH YOU CHEATING.
Secondly, there are more options than "spyware is acceptable" and "EA did something evil". For starters, maybe (probably?) Battlefield 2142 does not contain spyware. Maybe it does, but it is opt-in, which would not be evil. Maybe it does, but is opt-out on install, which would still be evil but not as bad as this
And maybe this whole thing is made up because AFAIK, nobody other than that one ShackNews forum poster has confirmed this.
This rumor has been going around the net based off of ONE post on the ShackNews forums, with no confirmation whatsoever as far as I can tell. It seems to be fueled by the neverending hate for anything that EA does.
I highly doubt that this is true.
If you have a power tripping guild leader and you don't like the 39 other people you're there with, maybe that's a sign to find a new guild, hmm? There are good ones out there where people have a great time, eveb occasionally meet up in real life to have drinks and hang out. They're just harder to find because they don't have the huge burnout rate that crappy guilds do, thus they don't need to advertise so blatently.
The Wii controller is never used as a 1:1 motion replication like you see in the advertising trailers. The amount of motion you need to put in is very small; you can leave your hands by your sides or in your lap or wherever. Of course, you're still welcome to flail around if that's what you really want to do.
Yeah. I'm tired of sequels too. Lets destroy all copies of The Empire Strikes Back, and burn all the comic books after #1 of any series.
George Bernard Shaw said that there are only two stories. Should we stop writing books because they borrow from old themes?
Just because something presents a familiar CONCEPT doesn't mean that it can't still be original in its execution.
I wish I got paid $5 a minute, but I don't. If you fix your math to reflect that, it comes out to 12,000 * $5/hour * (5/60) hours = $5000 ... still greater than zero, but not as big a deal.
Never mind, the slashdot server was just refusing to serve the images to me for some reason. It's fine. Please ignore the parent post!
Compare the preview link to this PNG thumbnail from the author's website:n tent/uploads/2006/05/slashdot.png
http://summit.makalumedia.com.nyud.net:8080/wp-co
The images for all the rounded corners appear to be missing.
Oh, don't get me wrong. I've got an HDTV and I love me some hi-def.
I'm not saying that 720p doesn't look freaking amazing. But I am saying that EDTV looks good already. Maybe you demand that extra visual quality, and then Revolution is not for you. But I can watch my DVDs without complaining about bad quality, so I think that most people will play Revolution games without minding either.
Widescreen 480p @ 60fps with a high enough triangle count looks pretty damn awesome. And you can always get a fancy interpolating upconvertor if you're bothered *that much*.
In case you've forgotten, those DVDs you watch are 480p @ 30fps (well, 480i @ 60...)
No, no no no no no! Warcraft Adventures was a point-and-click 2D adventure game, much like the old Monkey Island games, or The Dig and other LucasArts titles. It was essentially completed, but needed a lot of tuning for puzzle difficulty and "fun factor".
While it was still in development, a Monkey Island 4 came out and basically made every 2D adventure game look obsolete. Blizzard realized that Warcraft Adventuers didn't meet the new bar for adventure games, and they were having a lot of trouble fine-tuning the game, and they probably didn't want to make it in the first place (the idea was being pushed by Vivendi, the parent company). So they cancelled it and ate a huge loss on the development costs, which they then owed to Vivendi and only started paying back when World of Warcraft money came rolling in.
You could make the same argument against SimCity, The Sims, etc: "That looks like a lot of cool technology, and there is a huge degree of player freedom, but is it a compelling game?"
;) Or maybe we have a very narrow-minded stereotype of what actually makes a game compelling.
Maybe Spore is just doomed to repeat the failures of SimCity and The Sims
My pleasure! Believe me, many "senior" C++ programmers have never bothered to understand these issues either ... and while they may be rare in practice, they do come up every now and then, and ignorance is not a defense against unbounded memory usage :)
A handle can be defined as a double pointer, and the locking operation could just be dereferencing it (assuming a single-threaded model of operation). I was speaking metaphorically about notification, not describing an actual event model ;)
The technique is still very useful if you have a program that follows one of a few very specific allocation patterns. For example, consider a program that allocates many small blocks at once and then frees a large (but non-consecutive) percentage. The ability to compact the heap lets you regain all the space you lose when your free holes are smaller than your VM page size.
Will most applications have this problem? Probably not. But the ones that do have it, tend to have it in spades. A handle-based allocation sytem can be a real win in those cases.
There is a large difference between "C++ as an official specification" and "C++ as most people use it".
You could probably write a standards-conforming C++ compiler that abstracted pointers in a way that allowed objects to be relocated to new memory. But you could never compile a large application with it, because so few people actually write 100% standards-conforming C++ code. C++ programmers expect to be able to cast their void*'s to size_t's and screw around with them, specifications-be-damned.
I've seen some positively hideous tricks in shipping applications, like casting pointers to char* to be able to use the low bits and top bit as flags. You'll never be able to erase that from the language, no matter how loudly you scream "undefined behavior" at the programmers.
I was not necessarily talking about Firefox, just addressing (hah) a misconception in the parent post: fragmentation is not related to garbage collection. I didn't want to get into a lengthy discussion of virtual addressing, page faults, etc. as well ;)
But you're correct. Thanks to the rise of "smart" binned allocators like dlmalloc, fragmentation is no longer the huge concern that it used to be with (for example) the basic Win32 heap API. Modern allocators are now reasonably smart about reusing best-fit blocks and not leaving tiny holes scattered in your VM pages.
Anyway, fragmentation is certainly not the primary cause of Firefox's high memory use. I am merely pointing out that my original post's parent had a poor conception of how fragmentation could be dealt with in.
You're confusing garbage collection with heap compaction.
People have written garbage collectors for C++, and they work just fine. But they do not help with fragmentation, which is the problem you're describing. That requires a heap-compacting allocator (aka a "handle" allocator). Many languages with garbage collection also use a heap-compacting allocator. C++ does not, because of a low-level language "feature": pointers, and specifically, pointer arithmetic.
If an object moves in memory, then people have to be notified that it has moved, or they won't know where to access it. Languages like Java handle this behind-the-scenes; the system library tracks objects for you, and your program never knows (or cares) whre an individual object is.
C++ allows direct access to system memory, and it tells you precisely where your objects are located. Programmers are then free to do all kinds of things like compute distance to other objects, or convert the location to a number and do arbitrary math operations on it.
When an object moves, anything that refers to it needs to be updated. Well, good luck figuring that out in a language with pointer arithmetic! The system would need to magically determine whether or not a numeric value was actually a memory locations. And what if a program computed the distance between two objects, and later on used that distance to get from one object to the other? The system has no idea of what can be safely moved, and what has to stay put. So nothing can ever be moved.
There are workarounds of course -- if you write a program with heap-compaction in mind, then you can use a "handle" system, where every object has an ID. You remember the ID, and to access the object, you ask the system for a temporary memory location. And as soon as you're done, you "forget" the memory location and let the system shuffle things around in memory. The next time you give that ID to the system, you might get back a different memory location, but you were already expecting that so your program doesn't mind.
But handle allocation is slower, less efficient, and more annoying to use than a traditional fixed-location allocator. You have to start your project with it in mind; retrofitting existing code to use a handle allocator is a giant timesink and prone to conversion errors. And if you don't mind the loss of performance due to using a handle allocator, why are you using C++ in the first place?
You've committed the fallacy of assigning hypocrisy to a group.
Perhaps, but I would say that it's more along the lines of "You can never please everyone."
Apparently it was so buggy and incomplete that even EA could not hash together a shippable build in time for holidays, and now it's been pushed back to late spring.
You make it sound like a bad thing! The fact that they let it miss the holiday season indicates, to me at least, that they are focusing on a high-quality product instead of trying to "hash together a shippable build".
Everybody gives game companies shit for releasing incomplete or buggy games, and now some people are giving companies shit for not releasing incomplete or buggy games.
I read your post twice and I still can't figure out what you're saying.
EA is not the only game company, so if staff is being worked "into an early grave" on games that "they wouldn't have touched with a barge pole" if they had a choice, why do they still work there? Midway, Activision, THQ, and MS Games are all hiring. And EA has just conveniently pointed out that their employees are not bound by non-compete agreements.
The only reason EA had such poor earnings is that so few people actually GOT a 360 during the holiday sales season; customers are saving up their cash instead of spending on current-gen games.
Every console-heavy publisher is going through the same squeeze right now. EA is just being squeezed the most because it is the heaviest.