The "who do you sue" line's as old as the hills and, largely speaking, irrelevant because you're never going to get to first base unless it's a screw-up of epic proportions. Even then, it's more likely to be a colossal waste of your time and merely an exercise of fattening your lawyer's wallet.
No, they apparently didn't. Scuttlebutt has it that Obsidian was told to re-do the rendering engine to support DirectX only for an ephemeral XBox port that they ran out of funds for. Ostensibly, they were thinking they needed a response to Oblivion. To be sure, it's only rumor, but the whole thing feels like this is what happened. It's definitely NOT of the same calibre as NWN was in most things. It does look a lot prettier, but they could have accomplished most of this without the DX9 port work- and then went back and did a proper migration to multiple rendering backends once they got it on the shelves for PC's and saw that it would have made sense (which it doesn't, really) to do on XBox or other consoles.
Heh... Lack of morning coffee more than anything else... I was up and about getting ready for work.
Having pedants complain about "spelling", etc. on/. is what I've come to expect, though- and if that's all you've got to say about my post, it doesn't counter any of the fact that it's STILL accurate, etc. and the gp poster wasn't.
Considering that the power windows happen to have the same general mechanism, just driven via cables and a motor instead of a crank and gears, your manual window will have similar failure modes- it's just made with slightly more robust parts in many cases so it's less likely to fail. And, yes, I've had the window regulator in a manual window fail on me, handles popping off, gears stripping out, and things popping out of guide rails. The big thing about power windows is that with no power, there's no rolling up or down of the window. Manual windows don't have this problem...
Even in the X-Box, you're talking to device drivers, not the hardware directly. That IS what you do with DirectX- it's call that because it bypassed many of the software layers in Windows so you could write games. That's supposed to be the big selling point of the X-Box lines is that you can write for XP and do a minimal amount of work to make a console port to the X-Box or X-Box360. Talking to the hardware directly means poking values into the registers on the GPU, etc. Something few of the developers do- and none on the X-Box/X-Box 360 They typically go through a library or device driver on all the consoles to begin with. You might have done development under a console target, so your mileage may vary- but what I know of things differs from what you just said by a lot.
Wow, post long enough in/. and you will occasionally learn something new. (Honestly so!)
I, honestly, never knew whom put the concept to words- I just see it and hear it from time to time. And, yes, I think it fits- and I'd posted my rendition for the humor value.
If you're using IPCop in flash mode instead of HD mode, you should expect about 2-3 years, maybe 4-5, from the configuration. It avoids writing to the flash constantly, keeping logs, etc. in RAM as long as it can. Flash memory has about a 1-3 million write operation lifespan per any given cell of memory. Newer memory has better lifespans, obviously, and you can pay out the wazoo for a much larger write endurance. In all, HD's have a better write lifespan (Billions or more write operations before failure...) but for power consumption, access time latency, and hostile environment conditions, Flash is still king.
For your configuration, if you've got an IDE CF adapter, enough RAM, and use the Flash configuration install instead of just installing it, it will rock, so long as you've got your configuration backed up, logs periodically backed up, and have a Flash spare identically configureed for it's inevitable failure of the CF...
NWN2 was Atari and Obsidian's doing. Atari made some debatable business decisions over something that should have been a TECHNICAL decision and the rest is history. DA looks to be a good game, even if they choose to not do a Linux or MacOS version. I just won't be buying it if there isn't a Linux client, even if unofficial.
The Killer is a transport offload engine. The TCP protocol has a bunch of things that could be offloaded, etc.
The processing of CRC calculations, framing in the TCP headers, computing the congestion avoidance, etc. takes CPU cycles. For every inbound or outbound packet, there's a price in CPU use. On a heavily loaded machine, it "might" make a difference.
For example, it can take up to 80% or more of the CPU's total available cycles to handle the peak bandwidth of a 10G ethernet adapter if you've even got a bus fast enough to handle that fat a pipe. A TOE would be used to bring that back down out of the stratosphere to something more manageable. However, it doesn't come without a price. Using a TOE, you circumvent the bulk of the network security present in the OS and put it in the hands of the TOE vendor and their stack. In the case of MS products, some might consider that to be a plus...:-) In the case of Linux and *BSD, that's a negative out of the gate. However, it can and does work decently in the 10G ethernet space, so, for things like supercomputer clusters or as something like an iSCSI channel adapter, they work pretty well. Not perfect, but they work well enough that it's worth considering something like an iWARP channel adapter for certain specific applications. Keep in mind, however, that Transport Offload typically only gets used with TCP or iSCSI because there's things that CAN gain by being offloaded- UDP only has checksum and little else that realistically can be offloaded, and most decent NICs already DO this for you if their driver's been set up to do so.
Is it snake oil? Perhaps. Is it a waste of money? Probably.
Vibration and shock are the enemies of most HD tech. Flash is pretty much invulnerable to that compared to hard disks and while it's write operational life is less than a hard drive, it's seek time is nonexistent and it has a superlative read lifespan.
For a device where it's not a simple matter of ordering a HD or popping over to Fry's or CompUSA for a replacement part, Flash, if used right is the right answer even if it's "more expensive" as the cheaper part is actually more expensive in the long-term sense. Until you see something like the rigid foil media technology, where it's vibration and shock characteristics appear to match Flash's and it's read/write endurance exceeds it as well, Flash would be the answer there.
Latin it might have come from, but it's been absorbed into the English language...
We've got bits of French, Latin, Spanish, Italian, and a horde of other languages intermixed in there. To say it's not English when it's in common usage instead of just used in specific circles is being a pedant about it.:-)
They have things like that- and for about every thing imaginable. Engines. Models. Textures. Music.
The biggest problem with all of this stuff is that it tends to make things cookie-cutter unless you're grabbing things like trees, mood music, or sound effects from them. It shortens the cycle at least some- but, depending on the game, it makes it seem cheap if you get carried away with the use of off the shelf content. But, they COULD be using the stuff a little more, I think, without causing problems with everything. But the biggest expense isn't in the production of trees, buildings, etc. It's in being enamored with this or that new fad in coding or insisting upon this or that when it's obvious that what you're flogging isn't going to work.
Each and every one of these studios seems to be interested in "lessening" the amount of work they do- but in the end, most of the places end up shooting themselves in the foot badly on that. They end up putting more effort into the game because of those "labor saving" techniques.
They're not equal. They're not at all equal and won't be for a bit yet because of TDP, etc.
2Gb of L2 versus 1Gb of L2 per Core (1Gb twice over...) isn't the same thing. On non SMP benchmarks the 2Gb will win. Same goes with Four Cores and so forth. They don't do better on a "matched playing field" because it's not. Most of the 'benchmarks' don't really DO SMP operations- they're Uniproc applications, even the games... And on Uniproc, the DUO technically has double the cache because it's got 2Gb shared between the cores. Even with the dual core Athlon64's right at the moment, the biggest L2 they're fielding on the chips being compared is 1Gb per core. "Same memory" but effectively HALF the performance gain in those apps because they're pretty much running against one core and therefore have only 1Gb to work with, not mostly 2.
When you factor in true SMP operations, heavy computation, or the next generation of games even, the story becomes a little muddy. Depending on what the mix of instructions are, you can end up with a stall on the L2 with the Intel part because the CPUs share that L2 and can be in different places at the same time- a cache spill's expensive on machine speed as you well know. The Intel part can conceivably be having a LOT of those under a real multiproc load. With that in mind, one CPU may have 1.5Gb of cache for it to work with reliably before a cache spill and 512Mb of cache on the other core; or even nastier combinations thereof. The Athlon architecture doesn't HAVE that concern- it's as if you've got two (or four) full Athlon64's working at the same time. With the Intel offerings, you're going to have swinging performance losses that you can't quite explain all the time. Sure, it's fast with what's now available, but it's not stable speed; bring in that second CPU into full play and things don't look as rosy.
Intel wins on extra Cache- and the benchmarks that keep getting ran don't reveal performance snags with the SMP operation.
Intel's got a shared L2 that's 2-4 times the size of the AMD equivalents' pool. AMD's got a coherent, but NON-shared L2 split across multiple CPUs- each core has it's own L2. You'll have less L2 thrash with that design.
Under an SMP load, the AMD design will have an edge if all four cores are busy in different parts of system memory. If you pop out of cache, the memory bus design and overall architecture of the AMD parts will have an edge.
Intel has an edge only due to process shrink and the things they can do as a result thereof. As soon as AMD goes to the smaller process size, they'll pick up the lower TDP advantage Intel has right at the moment and then the whole deal will flip-flop on who's got the "best" CPU unless Intel comes up with a few new tricks along the way, which may/may not happen for them.
Heh... But that's what the jokes are on about. You have to have a machine in the Ubercomputer class of machines and GPUs to have usable framerates with it. Try it with the suggested minimums, you'll be pulling your hair out in some of the scenes as the framerate plummets to below 20fps at 800x600 or 1024x768. Kill the CD copy protection, gain 10fps back. I just wish they'd stuck with making the game first and then striving for an X-Box port AFTERWARDS- the engine only needed a few bits and bobs added to it to accomplish what they were reaching for and OpenGL was completely capable of it without major framerate loss like they have with the DX9 version. They literally ripped out the OpenGL rendering engine and re-did it, as rumor has it, ostensibly for an X-Box version they tried to go for and ran out of funds for...
In reality, all but the input (keyboard, etc...) IS there. In reality, DirectX isn't all that integrated- it's just a set of separate APIs, COM based in programming nature, that expose the respective interfaces to the hardware more directly than through the usual GDI, etc. interfaces.
Besides, it's all there and has arrived- and is what is most likely going to be used on mobile devices and other consumer electronics devices going forward:
OpenGL/OpenGL ES OpenSL ES OpenVG OpenML OpenMAX
Check out The Khronos Group for that very thing- they're calling it OpenKODE right at the moment. One stop. One API. Target many platforms easier.
Really... Gods... Besides, even with the "gorgeous" effects, etc., from what I've been hearing from people about NWN2 it's not all that hot and is more of a train wreck because of the framerates and a few other things (Even Illiad was making jokes about the game in recent times on UserFriendly...).
...it's that they don't give a damn either way and seek to "fix" the problem however seems to be the most expedient or merely to look like they're "doing something" about the "problem".
In this case, there is a very, VERY real problem with the security of the nation and few seem to be willing to deal with it appropriately- they'd rather do things that run against the Bill of Rights or just simply waste money and resources and do little to actually SECURE things. But they're going to do "something" so they can't be accused of doing nothing, By God.
When all they think of me is as a Consumer, I am SUPPOSED to do nothing but consume. When all they think of me is a Taxpayer, I am supposed to pretty much do nothing but supply them with money and re-elect them.
I am all the above, but I'm not specifically going to consume or just pay taxes. Consumer is a SUPERSET of the other two and all too often you're viewed as being in one of the subsets mentioned. You apparently don't understand that distinction.
Slashdot Mirror
The "who do you sue" line's as old as the hills and, largely speaking, irrelevant because you're never
going to get to first base unless it's a screw-up of epic proportions. Even then, it's more likely to
be a colossal waste of your time and merely an exercise of fattening your lawyer's wallet.
Interesting... It's something of a shame that they don't do that with all of the cars that have power windows.
Whoa... When did THAT billboard go up? I'd like to think I'd have spotted it in the last week or so.
No, they apparently didn't. Scuttlebutt has it that Obsidian was told to re-do the rendering engine to support DirectX only for an ephemeral XBox port that they ran out of funds for. Ostensibly, they were thinking they needed a response to Oblivion. To be sure, it's only rumor, but the whole thing feels like this is what happened. It's definitely NOT of the same calibre as NWN was in most things. It does look a lot prettier, but they could have accomplished most of this without the DX9 port work- and then went back and did a proper migration to multiple rendering backends once they got it on the shelves for PC's and saw that it would have made sense (which it doesn't, really) to do on XBox or other consoles.
Heh... Lack of morning coffee more than anything else... I was up and about getting ready for work.
/. is what I've come to expect, though- and if that's all you've got to say
Having pedants complain about "spelling", etc. on
about my post, it doesn't counter any of the fact that it's STILL accurate, etc. and the gp poster wasn't.
Considering that the power windows happen to have the same general mechanism, just driven via cables and a motor instead of a crank and gears, your manual window will have similar failure modes- it's just made with slightly more robust parts in many cases so it's less likely to fail. And, yes, I've had the window regulator in a manual window fail on me, handles popping off, gears stripping out, and things popping out of guide rails. The big thing about power windows is that with no power, there's no rolling up or down of the window. Manual windows don't have this problem...
Even in the X-Box, you're talking to device drivers, not the hardware directly. That IS what you do with DirectX- it's call that because it bypassed many of the software layers in Windows so you could write games. That's supposed to be the big selling point of the X-Box lines is that you can write for XP and do a minimal amount of work to make a console port to the X-Box or X-Box360. Talking to the hardware directly means poking values into the registers on the GPU, etc. Something few of the developers do- and none on the X-Box/X-Box 360 They typically go through a library or device driver on all the consoles to begin with. You might have done development under a console target, so your mileage may vary- but what I know of things differs from what you just said by a lot.
There's little further to say on the subject...
Wow, post long enough in /. and you will occasionally learn something new. (Honestly so!)
I, honestly, never knew whom put the concept to words- I just see it and hear it from time to time. And, yes, I think it fits- and I'd posted my rendition for the humor value.
If you're using IPCop in flash mode instead of HD mode, you should expect about 2-3 years, maybe 4-5, from the configuration. It avoids writing to the flash constantly, keeping logs, etc. in RAM as long as it can. Flash memory has about a 1-3 million write operation lifespan per any given cell of memory. Newer memory has better lifespans, obviously, and you can pay out the wazoo for a much larger write endurance. In all, HD's have a better write lifespan (Billions or more write operations before failure...) but for power consumption, access time latency, and hostile environment conditions, Flash is still king.
For your configuration, if you've got an IDE CF adapter, enough RAM, and use the Flash configuration install instead of just installing it, it will rock, so long as you've got your configuration backed up, logs periodically backed up, and have a Flash spare identically configureed for it's inevitable failure of the CF...
NWN2 was Atari and Obsidian's doing. Atari made some debatable business decisions over something that should have been a TECHNICAL decision and the rest is history. DA looks to be a good game, even if they choose to not do a Linux or MacOS version. I just won't be buying it if there isn't a Linux client, even if unofficial.
The Killer is a transport offload engine. The TCP protocol has a bunch of things that could be offloaded, etc.
:-) In the case of Linux and *BSD, that's a negative out of the
The processing of CRC calculations, framing in the TCP headers, computing the congestion avoidance, etc. takes CPU cycles.
For every inbound or outbound packet, there's a price in CPU use. On a heavily loaded machine, it "might" make a difference.
For example, it can take up to 80% or more of the CPU's total available cycles to handle the peak bandwidth of a 10G ethernet
adapter if you've even got a bus fast enough to handle that fat a pipe. A TOE would be used to bring that back down out of
the stratosphere to something more manageable. However, it doesn't come without a price. Using a TOE, you circumvent the
bulk of the network security present in the OS and put it in the hands of the TOE vendor and their stack. In the case
of MS products, some might consider that to be a plus...
gate. However, it can and does work decently in the 10G ethernet space, so, for things like supercomputer clusters or as
something like an iSCSI channel adapter, they work pretty well. Not perfect, but they work well enough that it's worth
considering something like an iWARP channel adapter for certain specific applications. Keep in mind, however, that Transport
Offload typically only gets used with TCP or iSCSI because there's things that CAN gain by being offloaded- UDP only has
checksum and little else that realistically can be offloaded, and most decent NICs already DO this for you if their driver's
been set up to do so.
Is it snake oil? Perhaps. Is it a waste of money? Probably.
Vibration and shock are the enemies of most HD tech. Flash is pretty much invulnerable to that compared to hard disks and while it's write operational life is less than a hard drive, it's seek time is nonexistent and it has a superlative read lifespan.
For a device where it's not a simple matter of ordering a HD or popping over to Fry's or CompUSA for a replacement part, Flash, if used right is the right answer even if it's "more expensive" as the cheaper part is actually more expensive in the long-term sense. Until you see something like the rigid foil media technology, where it's vibration and shock characteristics appear to match Flash's and it's read/write endurance exceeds it as well, Flash would be the answer there.
Latin it might have come from, but it's been absorbed into the English language...
:-)
We've got bits of French, Latin, Spanish, Italian, and a horde of other languages intermixed in there. To say it's not English when it's in common usage instead of just used in specific circles is being a pedant about it.
They have things like that- and for about every thing imaginable. Engines. Models. Textures. Music.
The biggest problem with all of this stuff is that it tends to make things cookie-cutter unless you're grabbing
things like trees, mood music, or sound effects from them. It shortens the cycle at least some- but, depending
on the game, it makes it seem cheap if you get carried away with the use of off the shelf content. But, they
COULD be using the stuff a little more, I think, without causing problems with everything. But the biggest
expense isn't in the production of trees, buildings, etc. It's in being enamored with this or that new fad
in coding or insisting upon this or that when it's obvious that what you're flogging isn't going to work.
Each and every one of these studios seems to be interested in "lessening" the amount of work they do- but in
the end, most of the places end up shooting themselves in the foot badly on that. They end up putting more
effort into the game because of those "labor saving" techniques.
English follows other languages down dark alleys, knocks them over, and goes rifling through their pockets looking for loose grammar.
They're not equal. They're not at all equal and won't be for a bit yet because of TDP, etc.
2Gb of L2 versus 1Gb of L2 per Core (1Gb twice over...) isn't the same thing. On non SMP benchmarks the 2Gb will win. Same goes with Four Cores and so forth. They don't do better on a "matched playing field" because it's not. Most of the 'benchmarks' don't really DO SMP operations- they're Uniproc applications, even the games... And on Uniproc, the DUO technically has double the cache because it's got 2Gb shared between the cores. Even with the dual core Athlon64's right at the moment, the biggest L2 they're fielding on the chips being compared is 1Gb per core. "Same memory" but effectively HALF the performance gain in those apps because they're pretty much running against one core and therefore have only 1Gb to work with, not mostly 2.
When you factor in true SMP operations, heavy computation, or the next generation of games even, the story becomes a little muddy.
Depending on what the mix of instructions are, you can end up with a stall on the L2 with the Intel part because the CPUs share that L2 and can be in different places at the same time- a cache spill's expensive on machine speed as you well know. The Intel part can conceivably be having a LOT of those under a real multiproc load. With that in mind, one CPU may have 1.5Gb of cache for it to work with reliably before a cache spill and 512Mb of cache on the other core; or even nastier combinations thereof. The Athlon architecture doesn't HAVE that concern- it's as if you've got two (or four) full Athlon64's working at the same time. With the Intel offerings, you're going to have swinging performance losses that you can't quite explain all the time. Sure, it's fast with what's now available, but it's not stable speed; bring in that second CPU into full play and things don't look as rosy.
Ahh... Someone that gets this concept.
Intel wins on extra Cache- and the benchmarks that keep getting ran don't reveal performance snags with the SMP operation.
Intel's got a shared L2 that's 2-4 times the size of the AMD equivalents' pool.
AMD's got a coherent, but NON-shared L2 split across multiple CPUs- each core has it's own L2. You'll have less L2 thrash with that design.
Under an SMP load, the AMD design will have an edge if all four cores are busy in different parts of system memory.
If you pop out of cache, the memory bus design and overall architecture of the AMD parts will have an edge.
Intel has an edge only due to process shrink and the things they can do as a result thereof. As soon as AMD goes to the
smaller process size, they'll pick up the lower TDP advantage Intel has right at the moment and then the whole deal will
flip-flop on who's got the "best" CPU unless Intel comes up with a few new tricks along the way, which may/may not happen
for them.
Heh... But that's what the jokes are on about. You have to have a machine in the Ubercomputer class of machines and GPUs to have usable framerates with it. Try it with the suggested minimums, you'll be pulling your hair out in some of the scenes as the framerate plummets to below 20fps at 800x600 or 1024x768. Kill the CD copy protection, gain 10fps back. I just wish they'd stuck with making the game first and then striving for an X-Box port AFTERWARDS- the engine only needed a few bits and bobs added to it to accomplish what they were reaching for and OpenGL was completely capable of it without major framerate loss like they have with the DX9 version. They literally ripped out the OpenGL rendering engine and re-did it, as rumor has it, ostensibly for an X-Box version they tried to go for and ran out of funds for...
I've been there. Don't wanna go back. You can keep the damn T-shirt.
In reality, all but the input (keyboard, etc...) IS there. In reality, DirectX isn't all that integrated- it's just a set of separate APIs, COM based in programming nature, that expose the respective interfaces to the hardware more directly than through the usual GDI, etc. interfaces.
Besides, it's all there and has arrived- and is what is most likely going to be used on mobile devices and
other consumer electronics devices going forward:
OpenGL/OpenGL ES
OpenSL ES
OpenVG
OpenML
OpenMAX
Check out The Khronos Group for that very thing- they're calling it OpenKODE right at the
moment. One stop. One API. Target many platforms easier.
Really... Gods... Besides, even with the "gorgeous" effects, etc., from what I've been hearing from
people about NWN2 it's not all that hot and is more of a train wreck because of the framerates and a
few other things (Even Illiad was making jokes about the game in recent times on UserFriendly...).
Sorry for the misunderstanding on that all...
...it's that they don't give a damn either way and seek to "fix" the problem however seems to be the most expedient or merely to look like they're "doing something" about the "problem".
In this case, there is a very, VERY real problem with the security of the nation and few seem to be willing to deal with it appropriately- they'd rather do things that run against the Bill of Rights or just simply waste money and resources and do little to actually SECURE things. But they're going to do "something" so they can't be accused of doing nothing, By God.
Can I not post right this week? Sigh... "Consumer" was SUPPOSED to be "Citizen" there!
When all they think of me is as a Consumer, I am SUPPOSED to do nothing but consume.
When all they think of me is a Taxpayer, I am supposed to pretty much do nothing but supply them with money and re-elect them.
I am all the above, but I'm not specifically going to consume or just pay taxes. Consumer is a SUPERSET of the other two and
all too often you're viewed as being in one of the subsets mentioned. You apparently don't understand that distinction.