Note how they test from 1280x1024 and up. While widescreen displays might be 1280x800, I think that's a pretty decent resolution for showing the "consumer capabilities" of a card.
I forgot to mention that the above prices are in Canadian dollars, and that they're typical (or slightly below average) for Canadian stores at the time I looked them up.
And a while back I was unable to afford an upgrade from 8iMB because I couldn't afford another 4 or 8 MiB. What's your point exactly? DDR3 costs are multiple times that of DDR2, historical RAM prices are irrelevant.
Memory costs for high-end DDR3 can be several TIMES that of high-end DDR2.
Consider this: high-end DDR2 could be considered DDR2-1066. Just built a rig with 4GB of DDR2-1066, cost me $44.
At the same store, from the same memory manufacturer, 4GB of DDR3-1600 (the high-end equivalent) costs $136, three times the price.
If you cry foul and want to see DDR3-1066 (the slowest DDR3), things improve slightly; the same brand, 4GB goes for $99, only double the price.
In short, DDR3 costs 2x to 3x the price of DDR2, which significantly raises the total cost of building a system. Especially if you wanted to put 8GB or more in a system.
Actually, I understand they perform rather poorly when it comes to AI simulations. Perhaps because they lack any sort of branch prediction. So there are going to be some serious bubbles in the SPE pipelines whenever they hit a branch instruction, which sort of defeats their purpose for such work.
The same argument was used against physics early on, until people who knew better spoke up and informed everyone that branch prediction doesn't do much for physics interactions anyhow.
Is there any evidence that they rewrote the defrag engine rather than just the UI? I vaguely recall hearing that Vista's defrag tool was just a new UI on the same core.
Let's not forget high def rips, which typically clock in at just over 4GB for 720p.
Just because they're not legal (which is itself debatable based on where you live and how you got it) doesn't mean that they aren't extremely prevalent.
Almost, but not quite. The.NET runtime is at 2.0 SP1.
3.0 uses the 2.0 runtime, and 3.5 uses the 2.0 SP1 runtime.
The service pack can make a difference for compatibility, so it's worth differentiating them. They probably should have just called it 2.1 like normal people would...
You're confusing available system ram and the per-process virtual address space. The problem is as I originally stated; by default, a process in Windows can't allocate more than about 2GB of RAM, even if additional system RAM is available. This 2GB limit is a well known limitation, and is completely unrelated to what you're talking about.
Please google "virtual address space" to learn more. A Microsoft KB discussing the 2GB limit and how virtual video RAM was being done inside VAS can be found here: http://support.microsoft.com/kb/940105
uTorrent is another example, in that they implemented some WINE-specific workarounds, which can be enabled/disabled from the advanced preferences menu.
I believe that this is also how Executor worked. It's a (now opensourced) Macintosh emulator that worked by translating Mac toolbox and quickdraw calls into native calls, and emulated the Mac's MC680x0 processor for the rest.
In that regard, it's very similar to QuickTransit (Rosetta) or Darwine. While compatibility wasn't perfect, it was enormously faster than Basilisk II.
Executor was eventually largely made irrelevant both by the continuing switch of the Mac to the PowerPC platform, and by the fact that advances in processing power rapidly made it possible to provide faster-than-real-time full-system emulation of a 68k Mac without the compatibility issues that Executor suffered from. Nonetheless, it was terribly impressive back in the day.
Games don't need >4GB memory addressing most of the time.
Most don't, but some do. By default, Windows uses a 2GB/2GB split. That means that an application can't use more than 2GB of RAM before it gets into trouble.
Supreme Commander is an RTS game that is rather CPU intensive. It does a lot of simulation that a lot of other games don't bother with (such as doing actual 3D hit detection on every single bullet fired by every single unit). It'll fully saturate even a decently powerful dual core processor. And it also is a heck of a RAM hog.
When Supreme Commander hits that 2GB limit, it crashes. This actually became a rather large problem, especially under Vista. Now, for Vista, it turned out that Windows was allocating the virtual VRAM out of the application's 2GB allotment, often bringing the actual available memory down to 1.5GB or less (which caused frequent failures in most larger games).
Anandtech actually did an article on that, and Microsoft eventually released an update for Windows that moved the virtual VRAM out of the application's memory space to deal with the problem. However, that doesn't completely fix the issue; you've still got that 2GB limit.
And so, there are ultimately two solutions to the problem. One, is you tell Windows to switch the user/kernel split from 2/2 to 2.5/1.5 or something similar. That gives SupCom another gig to play with, which should resolve the issue in the majority of cases. Problem is, Windows doesn't always like that, so there can be side effects (BSoDs). Windows also won't boot at the 3/1 split used by Linux. This solution does require patching the SupCom EXE, though, to enable large addressing.
The other solution is to run SupCom on a 64-bit installation of Windows. There, a 32-bit application is allowed to use the full 4GB, which is enough to not run into the issue. The same modified executable as above can then be used.
Activision Blizzard (or as we like to call it here, Blizzactivision, or Tough Actin' Blizzactin) is the company who owns Blizzard, not Blizzard themselves.
Blizzard was bought out in 1994, and bounced around as their parent companies themselves were bought out or merged. Eventually they ended up owned by Vivendi Games, so they've had seven different owners in total, not including the original self-ownership.
Anyhow, Activision merged with Vivendi Games. Vivendi's biggest studio was Blizzard, so Activision decided to rename themselves Activision Blizzard. They could do that since they now owned the Blizzard name.
Activision Blizzard is an independent company from Blizzard, although it does own Blizzard. So the relation is really in name only. Blizzard themselves have absolutely nothing to do with any of those games.
This can be solved by a binary search of the possible TTLs to determine the actual distance to the hop closest to the remote host that does respond to ICMP packets; probably the second to last hop.
Alternatively, you can just send out all the pings at more or less the same time with all the maximum TTLs and quickly map the path.
Of course, geolocation gets you most of the way there to begin with. Knowing the distance in hops just helps refine that.
The "barrage" of pings may not have been necessary. A good first step is simply running the IPs through a geolocation database. There are various free ones available, and it's a pretty good first step for narrowing things down. They're very effective at getting the country right, and do a decent job at getting you to at least a nearby city.
From there, if you need farther precision, a single ICMP packet is required to determine the number of hops to a host by checking the TTL. Combine these two things and it shouldn't take much work to get a list of close-by IPs.
If you're considering connecting to 1000 hosts, it would take just a few seconds (or a fraction of a second) to run them all through a geolocation database, and then a few seconds to send off the thousand pings (while 1000 pings would only require 56KB of data to be sent, you might want to send them out a bit slower than that).
All in all, I don't see why you couldn't evaluate all the IPs provided by the tracker in a matter of seconds, getting both geographic and network distances to each one. That should then be more than enough information to make decent guesses about what the best IPs to connect to are.
Valve has mentioned Black Mesa more than once in Steam news updates, usually shortly after Black Mesa releases a media update. They've said they're really looking forward to it. As such, Black Mesa has been officially sanctioned by Valve, and there should be no legal concerns. It'd be very strange for Valve to sue them after promoting them.
If the software rasterizer is faster in newer games, how about older games? I've always been a fan of software rendering engines. Not because they're necessarily better, just because I think they're neat.
Anyhow, what about Half-Life 1 games (Counter-Strike for example), or Quake 3 engine games, and so on? If they run faster in software mode, then there's some utility here; they'll run fast enough to be playable, and will run better in software than hardware.
Best game of 2008? So, you're trying to tell me that taking an almost 20 year game and slapping some higher res artwork and new music into it makes it a better game than Smash Bros. Brawl, GTA4, MGS4, Burnout Paradise, Sins of a Solar Empire, Disgaea 3, Universe at War, Army of Two, Condemned 2, ET: Quake Wars, R6 Vegas 2, Penny Arcade episodes 1 or 2, Rock Band 2, UT3, Battlefield: Bad Company, Dragon Quest V, Soul Calibur IV, Fatal Frame 4, Tales of Vesperia, Spore, Crysis Warhead, Saints Row 2, Dead Space, Fable II, Guitar Hero World Tour, Red Alert 3, Fallout 3, Little Big Planet, EndWar, Mirror's Edge, Left 4 Dead, etc.?
Don't get me wrong, SF2HD is an excellent product, giving the fans what they want and updating an old favourite. But let's not get out of hand. There were a ton of really great original games out this year, and the vast majority of them are better than SF2HD simply because they're original. I mean, if you want to say that an update of an old game is the best game of the year, I could probably just say "Chronotrigger DS" and end it there.
I'd love to see a great many more games like SF2HD, but there are a lot of games that are far more deserving to be called "best game of 2008 for any platform".
Chrome has built-in support for Greasemonkey scripts, although I believe that there are limitations. They've also said that extensions are eventually planned.
Problem is, you don't need to buy a JPEG codec, so there isn't necessarily anything to trace back to you.
I mean, what if the JPEG codec is determined to be the one included with MS Paint? How does it help to know that the person you're looking for used a copy of Windows XP or Vista?
One could also potentially design an algorithm that subtly obfuscates the subpixel values in such a way that it defeats the technique while minimizing the apparent visual changes to the image.
In fact, since JPEG already downsamples the chroma channel, I'd imagine that merely applying JPEG compression would already defeat any attempts to do this...
Then again, this may all be moot; cameras produce images at increasingly insanely high megapixel counts. what people actually need is often far lower. So as others have pointed out, simply resizing the image (such as to prepare it for web display) may be sufficient.
Slashdot Mirror
I know it's hard to keep things straight, but Canadians are neither Brits, nor Yanks. That, and we've already adopted SI.
Well, you're not looking very hard then.
Here's Anandtech's review of the ATI 4870x2, the closest competitor to the GTX295 (which they haven't reviewed yet):
http://www.anandtech.com/video/showdoc.aspx?i=3372&p=6
Note how they test from 1280x1024 and up. While widescreen displays might be 1280x800, I think that's a pretty decent resolution for showing the "consumer capabilities" of a card.
Or maybe you leave in a place like Montreal where electricity is either cheap (and Hydro) or free (included in rent)?
I forgot to mention that the above prices are in Canadian dollars, and that they're typical (or slightly below average) for Canadian stores at the time I looked them up.
And a while back I was unable to afford an upgrade from 8iMB because I couldn't afford another 4 or 8 MiB. What's your point exactly? DDR3 costs are multiple times that of DDR2, historical RAM prices are irrelevant.
Memory costs for high-end DDR3 can be several TIMES that of high-end DDR2.
Consider this: high-end DDR2 could be considered DDR2-1066. Just built a rig with 4GB of DDR2-1066, cost me $44.
At the same store, from the same memory manufacturer, 4GB of DDR3-1600 (the high-end equivalent) costs $136, three times the price.
If you cry foul and want to see DDR3-1066 (the slowest DDR3), things improve slightly; the same brand, 4GB goes for $99, only double the price.
In short, DDR3 costs 2x to 3x the price of DDR2, which significantly raises the total cost of building a system. Especially if you wanted to put 8GB or more in a system.
Actually, I understand they perform rather poorly when it comes to AI simulations. Perhaps because they lack any sort of branch prediction. So there are going to be some serious bubbles in the SPE pipelines whenever they hit a branch instruction, which sort of defeats their purpose for such work.
The same argument was used against physics early on, until people who knew better spoke up and informed everyone that branch prediction doesn't do much for physics interactions anyhow.
Or they might say "go to mustang.ford for more info"
People would see the dot, and figure it out.
Is there any evidence that they rewrote the defrag engine rather than just the UI? I vaguely recall hearing that Vista's defrag tool was just a new UI on the same core.
Let's not forget high def rips, which typically clock in at just over 4GB for 720p.
Just because they're not legal (which is itself debatable based on where you live and how you got it) doesn't mean that they aren't extremely prevalent.
Almost, but not quite. The .NET runtime is at 2.0 SP1.
3.0 uses the 2.0 runtime, and 3.5 uses the 2.0 SP1 runtime.
The service pack can make a difference for compatibility, so it's worth differentiating them. They probably should have just called it 2.1 like normal people would...
You're confusing available system ram and the per-process virtual address space. The problem is as I originally stated; by default, a process in Windows can't allocate more than about 2GB of RAM, even if additional system RAM is available. This 2GB limit is a well known limitation, and is completely unrelated to what you're talking about.
Please google "virtual address space" to learn more. A Microsoft KB discussing the 2GB limit and how virtual video RAM was being done inside VAS can be found here: http://support.microsoft.com/kb/940105
uTorrent is another example, in that they implemented some WINE-specific workarounds, which can be enabled/disabled from the advanced preferences menu.
I believe that this is also how Executor worked. It's a (now opensourced) Macintosh emulator that worked by translating Mac toolbox and quickdraw calls into native calls, and emulated the Mac's MC680x0 processor for the rest.
In that regard, it's very similar to QuickTransit (Rosetta) or Darwine. While compatibility wasn't perfect, it was enormously faster than Basilisk II.
Executor was eventually largely made irrelevant both by the continuing switch of the Mac to the PowerPC platform, and by the fact that advances in processing power rapidly made it possible to provide faster-than-real-time full-system emulation of a 68k Mac without the compatibility issues that Executor suffered from. Nonetheless, it was terribly impressive back in the day.
Games don't need >4GB memory addressing most of the time.
Most don't, but some do. By default, Windows uses a 2GB/2GB split. That means that an application can't use more than 2GB of RAM before it gets into trouble.
Supreme Commander is an RTS game that is rather CPU intensive. It does a lot of simulation that a lot of other games don't bother with (such as doing actual 3D hit detection on every single bullet fired by every single unit). It'll fully saturate even a decently powerful dual core processor. And it also is a heck of a RAM hog.
When Supreme Commander hits that 2GB limit, it crashes. This actually became a rather large problem, especially under Vista. Now, for Vista, it turned out that Windows was allocating the virtual VRAM out of the application's 2GB allotment, often bringing the actual available memory down to 1.5GB or less (which caused frequent failures in most larger games).
Anandtech actually did an article on that, and Microsoft eventually released an update for Windows that moved the virtual VRAM out of the application's memory space to deal with the problem. However, that doesn't completely fix the issue; you've still got that 2GB limit.
And so, there are ultimately two solutions to the problem. One, is you tell Windows to switch the user/kernel split from 2/2 to 2.5/1.5 or something similar. That gives SupCom another gig to play with, which should resolve the issue in the majority of cases. Problem is, Windows doesn't always like that, so there can be side effects (BSoDs). Windows also won't boot at the 3/1 split used by Linux. This solution does require patching the SupCom EXE, though, to enable large addressing.
The other solution is to run SupCom on a 64-bit installation of Windows. There, a 32-bit application is allowed to use the full 4GB, which is enough to not run into the issue. The same modified executable as above can then be used.
Activision Blizzard (or as we like to call it here, Blizzactivision, or Tough Actin' Blizzactin) is the company who owns Blizzard, not Blizzard themselves.
Blizzard was bought out in 1994, and bounced around as their parent companies themselves were bought out or merged. Eventually they ended up owned by Vivendi Games, so they've had seven different owners in total, not including the original self-ownership.
Anyhow, Activision merged with Vivendi Games. Vivendi's biggest studio was Blizzard, so Activision decided to rename themselves Activision Blizzard. They could do that since they now owned the Blizzard name.
Activision Blizzard is an independent company from Blizzard, although it does own Blizzard. So the relation is really in name only. Blizzard themselves have absolutely nothing to do with any of those games.
This can be solved by a binary search of the possible TTLs to determine the actual distance to the hop closest to the remote host that does respond to ICMP packets; probably the second to last hop.
Alternatively, you can just send out all the pings at more or less the same time with all the maximum TTLs and quickly map the path.
Of course, geolocation gets you most of the way there to begin with. Knowing the distance in hops just helps refine that.
The "barrage" of pings may not have been necessary. A good first step is simply running the IPs through a geolocation database. There are various free ones available, and it's a pretty good first step for narrowing things down. They're very effective at getting the country right, and do a decent job at getting you to at least a nearby city.
From there, if you need farther precision, a single ICMP packet is required to determine the number of hops to a host by checking the TTL. Combine these two things and it shouldn't take much work to get a list of close-by IPs.
If you're considering connecting to 1000 hosts, it would take just a few seconds (or a fraction of a second) to run them all through a geolocation database, and then a few seconds to send off the thousand pings (while 1000 pings would only require 56KB of data to be sent, you might want to send them out a bit slower than that).
All in all, I don't see why you couldn't evaluate all the IPs provided by the tracker in a matter of seconds, getting both geographic and network distances to each one. That should then be more than enough information to make decent guesses about what the best IPs to connect to are.
Valve has mentioned Black Mesa more than once in Steam news updates, usually shortly after Black Mesa releases a media update. They've said they're really looking forward to it. As such, Black Mesa has been officially sanctioned by Valve, and there should be no legal concerns. It'd be very strange for Valve to sue them after promoting them.
If the software rasterizer is faster in newer games, how about older games? I've always been a fan of software rendering engines. Not because they're necessarily better, just because I think they're neat.
Anyhow, what about Half-Life 1 games (Counter-Strike for example), or Quake 3 engine games, and so on? If they run faster in software mode, then there's some utility here; they'll run fast enough to be playable, and will run better in software than hardware.
Best game of 2008? So, you're trying to tell me that taking an almost 20 year game and slapping some higher res artwork and new music into it makes it a better game than Smash Bros. Brawl, GTA4, MGS4, Burnout Paradise, Sins of a Solar Empire, Disgaea 3, Universe at War, Army of Two, Condemned 2, ET: Quake Wars, R6 Vegas 2, Penny Arcade episodes 1 or 2, Rock Band 2, UT3, Battlefield: Bad Company, Dragon Quest V, Soul Calibur IV, Fatal Frame 4, Tales of Vesperia, Spore, Crysis Warhead, Saints Row 2, Dead Space, Fable II, Guitar Hero World Tour, Red Alert 3, Fallout 3, Little Big Planet, EndWar, Mirror's Edge, Left 4 Dead, etc.?
Don't get me wrong, SF2HD is an excellent product, giving the fans what they want and updating an old favourite. But let's not get out of hand. There were a ton of really great original games out this year, and the vast majority of them are better than SF2HD simply because they're original. I mean, if you want to say that an update of an old game is the best game of the year, I could probably just say "Chronotrigger DS" and end it there.
I'd love to see a great many more games like SF2HD, but there are a lot of games that are far more deserving to be called "best game of 2008 for any platform".
Chrome has built-in support for Greasemonkey scripts, although I believe that there are limitations. They've also said that extensions are eventually planned.
Problem is, you don't need to buy a JPEG codec, so there isn't necessarily anything to trace back to you.
I mean, what if the JPEG codec is determined to be the one included with MS Paint? How does it help to know that the person you're looking for used a copy of Windows XP or Vista?
One could also potentially design an algorithm that subtly obfuscates the subpixel values in such a way that it defeats the technique while minimizing the apparent visual changes to the image.
In fact, since JPEG already downsamples the chroma channel, I'd imagine that merely applying JPEG compression would already defeat any attempts to do this...
Then again, this may all be moot; cameras produce images at increasingly insanely high megapixel counts. what people actually need is often far lower. So as others have pointed out, simply resizing the image (such as to prepare it for web display) may be sufficient.
I've tried both gnash and swfdec. They're both useless in that they don't really work for any real-world flash content in practice.