I'm tempted to say that if it ran Doom 3, it will run Quake 4. I concur with other posters that the performance is on-par, and often better. On the other hands, there are graphically intense scenes too that are as bad as they get. Grab a copy off BitTorrent, see how it runs, and then decide if it runs fast enough to buy the game or not.
I played through all of Quake 4 on a Mobility Radeon 9700, which in the performance spectrum is slightly below a desktop 9600 XT. Yes, it was choppy in places, but it was playable on the whole.
Besides, I was playing at 800x600 on medium quality. Had I decided to play at low quality at 640x480, I am certain that the game would have had much higher framerates and still looked good. Let us not forget Carmack's statements about how the Doom 3 engine was designed to look good at 640x480. I'm just a sucker for eye candy.
In short, the 9600 is more than capable when it comes to Quake 4.
1) It does not only work at 4xAA, that is just where the gains are more impressive. With or without AA before they were behind, now they're ahead.
2) It is not just the X1800XT. The review was a roundup of high-end cards, and as such only included the X1800 XT and X1800 XL (Not just the XT like you suggest). The optimizations should affect ATI's entire product line fom the X1300 on up.
3) There are no other major games, to my knowledge, that still use OpenGL. As such, this can be considered a general fix for OpenGL performance. General in the sense that it fixes the problem (Poor OpenGL performance) as far as the vast majority of gamers are concerned.
nVidia already HAS optimized their drivers for it. They did that back when Doom 3 was news. ATI did the same.
What ATI is doing this time is tweaking the programmable memory controller in their new cards, not really tweaking the drivers. As I said both ATI and nVidia have already tweaked their drivers for Doom 3. So unless nVidia has some similar tweak up their sleeves (Which they may or may not) then the situation won't change with waiting. I think Doom 3 has been out enough that both companies have grabbed the low-hanging fruit, and even the medium-hanging fruit (And perhaps even the hard-to-reach fruit). The only reason we're seeing this is because of new possibilities opened up by ATI's new hardware.
Programmable memory controller in new cards. Tweaks to it for these games. No quality degredation, though it is still directed at the two specific games.
They have and they haven't. The tweak is targeted at Doom 3 and Quake 4, and it is indicated that there is some game-detection going on, but this isn't a quality-sacrificing optimization. The X1000 series has a programmable memory controller, and it is obvious that some games benefit from certain memory controller settings. Since D3 and Quake 4 are popular games, they obviously deemed that it was worth the effort to try to find more optimal settings for the memory controller for these two games. They did, and it led to a rather large performance increase.
This isn't a question of ATI having poor drivers, it's a question of taking time to do optimizations.
The X1000 series features programmable memory controllers. For Quake 4 (And Doom 3, so this may be a general OpenGL optimization) they have put together some new code for the memory controller that provides the large benefits.
On DM_Rankin, (absolute lowest in-game settings, 640x480) I'm seeing 13FPS with 12 bots, and almost 17FPS with 3 bots. So I guess that's in-line with what is to be expected. Again, default SwiftShader settings. I wouldn't know where to begin tweaking, so I'll just leave them as-is.
I'm hoping you guys will keep the demo updated to the latest version. I have no reason to licence the engine, but I've always been interested in software renderers, so it is the kind of thing that I'd like to poke around with when new versions come out.
I'm thinking I'm going to try into HL2 just to see what happens. And maybe grab an OpenGL wrapper and try it on GLquake for kicks. Or maybe I'll be lazy and just use D3DQuake;)
I was using UT2004's DX9 renderer. It isn't production quality, certainly, but on real hardware it is pretty close in speed and visuals to the DX8 renderer. I tested UT2004 with the DX8 DLL (which ran, slowly) and the DX9 DLL (which crashed right away).
I am running v3355 retail. It was on ons_torlan, with the default number of bots (12 or 16 I think).
I've re-benchmarked it with umark, 10 bots, ons_torlan. Average comes out to 10FPS. This seems to be in line with what I saw before, slightly higher FPS from less bots.
I've taken a screenshot of the visual glitches, which can be seen here:
Notebook's CPU was forced to the max clockspeed at the time (Using Notebook Hardware Control). SwiftShader's INI was totall default except for the two UT2004 related settings. I'm going to save a copy of my UT2004.ini file for future reproduction and see if lowering the quality settings makes a difference (with the visual glitches). Let me know if you want a copy of my UT2004.ini file for reproduction purposes.
Also I can report that when they say it is as fast as low-end 3D cards, by low-end they mean the original Voodoo 1.
I tried it with UT2004, one of the reccommended games according to the readme. UT2004 in DX9 mode crashed right away. DX8 mode ran, but with series issues and low performance.
I left the INI file at the default settings, except for the two settings they reccommended for UT2004. I left UT2004 on the quality settings I have on my machine, which is "normal" and "low" for all graphical settings. I lowered res to 640x480.
I saw something like 5 to 8 fps average, barely playable. And even the cheapest of low-end cards can get several times that. On top of this, most visual effects were missing (Fire the lightning gun and see the impact but not the shaft), and there were major texturing issues (Most textures were just matte brown or white). My test system was a laptop with a 1.7Ghz Pentium M processor, roughly the equivalent of a P4 2.8ghz or 3.0ghz.
Honestly I can't see this as being useful. Assuming they fix the visual glitches, yes, it is perhaps one of the fastest software renderers available. Unfortunately, it is totally useless. Any PC with a CPU fast enough to take advantage of this is going to have onboard or low-end 3D hardware that would run circles around SwiftShader.
Think about it. The readme claims that the Pentium-M runs their software particularly well. However, all laptops ship with some sort of onboard 3D hardware, and all of it is loads faster than this software thing. Even the onboard laptop video these days is DX9. Many desktop motherboards ship with onboard DX9 Intel graphics, and few PCs sold don't feature any 3D hardware at all.
So, again, interesting to play around with perhaps, but totally useless in the marketplace. I'm very surprised they convinced even one company to license this thing.
You can't compare audio editing apps to a dedicated software DSP. One is generalized and probably not optimized for realtime audio work, and the other is the opposite.
You forget also that there are hardware programmable DSPs in modern computers; Creative soundcards, for one thing, and all modern videocards.
I actually recall reading an article a while back on doing audio processing on videocards. This was part of the growing trend of using videocards as math co-processors or DSPs.
Assuming you could do the processing right on the soundcard, and perhaps do this inside a kernel-level driver, you can potentially get extremely low latency. Of course you'd be monopolizing the soundcard.
Not to mention the fact that while UMDs are encoded at DVD resolution, the PSP only displays them at a lower resolution. UMDs were meant to be used outside the PSP, which is why they're encoded at a highe resolution.
By doing this webcam-on-psp garbage, not only are you limiting yourself to PSP resolution on your TV, you're putting up with the higher response time of the LCD on the PSP. You're recording the LCD screen's flaws.
Not to mention the fact that I highly doubt the camera in this rediculous contraption is going to be high enough detail to even capture the true resolution of the LCD.
This is going to come out looking worse than overused VHS tapes, mark my words.
The audio stuttering problem, which might I add is currently only experienced by a vey small number of people (the extremely vocal minority) is not directly related to the sound system, but is instead caused by other subsystems inducing hitching. I believe one primary cause of the audio stuttering that was solved early on was due to loading assets at runtime. This was solved, IIRC, by pre-loading more content during level loads.
It is unlikely that a hardware-accelerated sound engine would have solved such problems.
You're thinking of the Aureal Vortex (http://en.wikipedia.org/wiki/A3D). A3D simulated a low-detail version of the 3D environment and calculated reverb based on the reflections inside that environment.
A3D died off years ago, and Aureal was bought out by Creative. EAX still can't come close to A3D's capabilities.
For an idea of the A3D generation, Quake 3 supported A3D for 3D audio, though it was later removed when A3D died off.
I would not buy USB (Too much added bulk), however I am also hoping for a PCMCIA version.
The Audigy 2 Notebook (PCMCIA) was very impressive, as it provided the entire feature set of the Audigy 2 ZS (with the exception of hardware midi synth I think?) in the PCMCIA form factor.
A PCMCIA version of the X-Fi would be greatly welcomed by me, for the vastly improved SNR over my notebook's onboard audio, as well as the 3D headphone virtualization.
HL2 does ALL of it's sound processing (3D, effects, etc) entirely in software. The only benefit a higher priced Creative card can provide is a better SNR, which isn't the end-all-be-all.
Using a generic onboard card with surround support will not be much of a different experience than using an X-Fi. You'll notice cleaner sound due to the better SNR, but that's it.
Valve did this because CPUs have advanced to the point where sound processing can be done in software without too much of a processing time investment, and it ensures that everybody gets to hear the same soundscape/quality no matter what soundcard they are using. No longer does environmental audio depend on what version of EAX your soundcard supports.
Exactly. The statement might be revised to "Precious few sound cards feature full hardware acceleration for 3D audio", since some cards like the SB Live! do 3D acceleration, just not on enough 3D channels to cover it all in hardware.
This used to be a big issue in games where 3D (surround) sound was used. These days with faster processors, it isn't such a big issue any more. In fact, many modern games (Half-Life 2's Source engine, and DooM 3) both do all sound processing exclusively in software (though Creative later blackmailed Id into adding hardware support for DooM 3). It was decided for this current generation of games that CPUs were fast enough to do the sound processing in hardware, and that it was the best way to provide a consistent presentation no matter what sound card is used. Both games do all their 3D mixing, and their post-processing (reverb for example) entirely in software.
Does doing it in hardware still provide a CPU benefit? Yes. Is it that important anymore? No, unless you're going nuts for framerates.
I seem to recall a benchmark done years ago on an Athlon 1.4 that showed 40% CPU usage exclusively for 3D sound on the SB-Live, and something like 5% on the Audigy. Now, with current high-end CPUs at something like 3x faster than that, spending 15% of a game's CPU budget on sound is fine. Multithreading in games (to support multicore processors) will further reduce this, since you'll be able to offload sound processing to the second core.
So in other words if I type "dellgaminglaptops.com" into my browser, instead of getting a "Domain not found" page, I'll be redirected to an ebay search for "dell gaming laptops"? What a wonderful improvement over Verislime's previous activities.
I stand by the statements I've made the past two times that the iPod Video seemed on the cusp of release. Allow me to quote a post I made a few days ago:
I think a previous post I've made still applies to this situation, and I'll reiterate the key points: Every time Apple hints they are about to make an announcement, the media always tells the public that it is undoubtedly going to be a video iPod. And every single time they have been wrong. Does this mean that this announcement is not a video iPod? No. I merely point out that screaming "OMG TEH VIDEO IPOD IS HERE!" every time apple prepares for an announcement is stupid.
This nonsense has just proven my point; yet another Apple announcement, the media claims it can be nothing but the Video iPod, but now, well, not so much. Yes, the official announcement has yet to be made. But consider this; for years the media has been saying that announcements for the next iPod related product was a Video iPod. For years I've been saying they're full of shit. Every single time, I've been right and they've been wrong. Says something about the "experts" making the claims, doesn't it?
You seem to have skipped over most of my post. I said that in order to convince peers to upload to the client, the malicious client should upload small amounts of valid data to convince peers to send. BitTorrent doesn't really have tit-for-tat, just a higher weight to uploading to clients that upload back. I'm pretty sure speed is divided evenly, to the extend that that is possible.
This is potentially much more damaging than half a swarm taking up half the bandwidth. First of all if half the swarm is taking up half the bandwidth, you are effectively left with one quarter the bandwidth. Twice as many peers, half the bandwidth.
Seeds don't use round-robin. They send the rarest pieces to those who request them, as much as their set limits allow. Random isn't round-robin. They are, as you pointed out, usually a small part of the swarm. If the fake clients jump into a swarm that is just starting out, not only can they suck up a ton of peer-to-peer transfers, they can prevent (Or delay) peers from becoming seeds, keeping the swarm in the desirable (for them) low-seed situation.
The idea is to turn the BitTorrent client into a bandwidth black hole into which the swarm's bandwidth is sucked. If you get enough of them, and if the modified clients are smart enough, they could potentially do lots of damage.
There is something that nobody has considered, though. This action (And the ones already being taken) are DDoS (Or regular DoS) attacks, and are illegal. Remember, DoS stands for "Denial of Service", and sending fake chunks or trying to suck up bandwidth in bad faith IS an attempt to deny service to users. It doesn't matter if they are the copyright holder or not; vigilante justice is outlawed. For example, you are not allowed to kill a person, even if he killed your brother. And you can't DDoS a service that is being used to share your copyrighted material.
The problem is that BitTorrent, despite it's semi-centralized topology, is still too decentralized to do anything about it. The obvious people who are in the position to take action are the owners of the trackers, and there are thousands (or tens of thousands) of trackers out there. Few trackers are large enough to take action. Some of the larger ones might be, the ones that are operated by web sites (Such as Pirate bay's tracker), however few are in the US and fewer still would want to call attention to themselves by protesting.
So what we end up with is one party performing an illegal act to attempt to stop another party from performing an illegal act, and neither side is going to be stopped. HBO won't be stopped because nobody can stand up and fight them in court, and the BitTorrent trackers won't be stopped because they exist all over the world and probably aren't illegal in most places anyhow. What a wonderful situation.
I know this is turning into a rant, but I'm disappointed that HBO decided to waste money doing this instead of introducing a legitimate BitTorrent based distribution system. BitTorrent (the company) has already entered into deals with the entertainment industry to be used as a distribution mechanism for copyrighted content, and I applaud them. I've long said I would pay to subscribe to television shows over the internet. I already watch most TV via the internet for the simplicity and convienience, and I would indeed be willing to pay to get DVD or HD quality content legally. BitTorrent lowers the cost of distributing HD content to next to nothing, making the size of the content irrelevant. $50 could distribute millions of copies of a 2400MB HD episode, whereas to distribute just a hundred thousand copies within 6 hours would cost something like $900,000 with HTTP (We're talking ~90 gigabits). To be able to distribute that hundreds of thousands of times cheaper, you'd think the companies would be jumping on it.
As a note, I'm trying a quick test to see how much of my bandwidth is wasted.
I grabbed the latest torrent of Rome (1x06) off TorrentSpy and started downloading. We'll see how many hash fails it has by the time it is done. So far I've downloaded 5 and all are valid.
1) With a chunk size of 256KB, typical for a 350MB show, only 75MB of bandwidth would be wasted in your scenario. Hardly a major slowdown 2) Blacklists such as PeerGuardian will quickly block the HBO IP addresses, and users of such blacklists won't be affected at all 3) Decentralized tracking helps against this since peers wouldn't report bad peers when queried.
They're going about this all wrong. What they should be doing is acting as peers with none of the file. If you flood a swarm with 100 malicious BitTorrent clients, you could do a lot of damage to swarm capacity. Here's what I'd do:
1) Have each client connect to AS MANY peers as possible. All that will allow them to connect. Lie to the tracker about whatever is needed to get connected to as many peers as possible 2) Actively seek to download chunks from other peers, but never upload 3) Report, to each peer, that the client now has available the chunk it just downloaded. This makes it impossible for a peer to detect bad nodes based on the fact that they never increase in progress even though they are downloading
The goal of this is to waste as much upstream bandwidth as possible so that others suffer. While their current methods can affect some people, anybody who has a PeerGuardian type plugin is totally unaffected, and those that don't aren't affected much. If those clients are actively seeking to suck up the swarm's upload capacity, they affect everyone, PeerGuardian or not.
The only trick is to try to get around the tit-for-tat rule. Yes, I know there is no such rule, however in practice it works out; clients are much more likely to upload to you if YOU are uploading to THEM. One possible way around this might be to upload real legitimate data to everyone possible. A peer sending data at 1KB/s for brief periods every few minutes isn't going to help much, but it could potentially suck up a lot more bandwidth.
Don't get me wrong, I think HBO is fucking stupid to be doing this. I was just looking at it as an interesting mental puzzle.
These are Tier 1 ISPs. You don't use them for your home internet connection. Nobody who would take up Cogent's offer is going to be running a web browser through a Level 3 connection. Tier 1 ISPs serve other ISPs and large businesses.
Re:it's all just rumor...
on
Video iPod Oct 12?
·
· Score: 4, Insightful
Don't they host most such events in theaters? I mean, they need someplace big with lots of seats and a stage for such announcements. Isn't a theater (and not the movie kind) the obvious place to host such a thing?
I think a previous post I've made still applies to this situation, and I'll reiterate the key points: Every time Apple hints they are about to make an announcement, the media always tells the public that it is undoubtedly going to be a video iPod.. And every single time they have been wrong. Does this mean that this announcement is not a video iPod? No. I merely point out that screaming "OMG TEH VIDEO IPOD IS HERE!" every time apple prepares for an announcement is stupid.
Slashdot Mirror
I'm tempted to say that if it ran Doom 3, it will run Quake 4. I concur with other posters that the performance is on-par, and often better. On the other hands, there are graphically intense scenes too that are as bad as they get. Grab a copy off BitTorrent, see how it runs, and then decide if it runs fast enough to buy the game or not.
I played through all of Quake 4 on a Mobility Radeon 9700, which in the performance spectrum is slightly below a desktop 9600 XT. Yes, it was choppy in places, but it was playable on the whole.
Besides, I was playing at 800x600 on medium quality. Had I decided to play at low quality at 640x480, I am certain that the game would have had much higher framerates and still looked good. Let us not forget Carmack's statements about how the Doom 3 engine was designed to look good at 640x480. I'm just a sucker for eye candy.
In short, the 9600 is more than capable when it comes to Quake 4.
Apparently you should RTFA.
1) It does not only work at 4xAA, that is just where the gains are more impressive. With or without AA before they were behind, now they're ahead.
2) It is not just the X1800XT. The review was a roundup of high-end cards, and as such only included the X1800 XT and X1800 XL (Not just the XT like you suggest). The optimizations should affect ATI's entire product line fom the X1300 on up.
3) There are no other major games, to my knowledge, that still use OpenGL. As such, this can be considered a general fix for OpenGL performance. General in the sense that it fixes the problem (Poor OpenGL performance) as far as the vast majority of gamers are concerned.
nVidia already HAS optimized their drivers for it. They did that back when Doom 3 was news. ATI did the same.
What ATI is doing this time is tweaking the programmable memory controller in their new cards, not really tweaking the drivers. As I said both ATI and nVidia have already tweaked their drivers for Doom 3. So unless nVidia has some similar tweak up their sleeves (Which they may or may not) then the situation won't change with waiting. I think Doom 3 has been out enough that both companies have grabbed the low-hanging fruit, and even the medium-hanging fruit (And perhaps even the hard-to-reach fruit). The only reason we're seeing this is because of new possibilities opened up by ATI's new hardware.
Programmable memory controller in new cards. Tweaks to it for these games. No quality degredation, though it is still directed at the two specific games.
They have and they haven't. The tweak is targeted at Doom 3 and Quake 4, and it is indicated that there is some game-detection going on, but this isn't a quality-sacrificing optimization. The X1000 series has a programmable memory controller, and it is obvious that some games benefit from certain memory controller settings. Since D3 and Quake 4 are popular games, they obviously deemed that it was worth the effort to try to find more optimal settings for the memory controller for these two games. They did, and it led to a rather large performance increase.
This isn't a question of ATI having poor drivers, it's a question of taking time to do optimizations.
The X1000 series features programmable memory controllers. For Quake 4 (And Doom 3, so this may be a general OpenGL optimization) they have put together some new code for the memory controller that provides the large benefits.
What the Slashdot article neglects to mention is that Microsoft has already fixed the problem .
They had a fix within 24 hours and started rolling it out. It didn't affect wireless networks in general, only some specific point-of-sale systems.
Anyhow, to sum up, problem was fixed before launch and wouldn't have affected consumers anyhow.
On DM_Rankin, (absolute lowest in-game settings, 640x480) I'm seeing 13FPS with 12 bots, and almost 17FPS with 3 bots. So I guess that's in-line with what is to be expected. Again, default SwiftShader settings. I wouldn't know where to begin tweaking, so I'll just leave them as-is.
;)
I'm hoping you guys will keep the demo updated to the latest version. I have no reason to licence the engine, but I've always been interested in software renderers, so it is the kind of thing that I'd like to poke around with when new versions come out.
I'm thinking I'm going to try into HL2 just to see what happens. And maybe grab an OpenGL wrapper and try it on GLquake for kicks. Or maybe I'll be lazy and just use D3DQuake
I was using UT2004's DX9 renderer. It isn't production quality, certainly, but on real hardware it is pretty close in speed and visuals to the DX8 renderer. I tested UT2004 with the DX8 DLL (which ran, slowly) and the DX9 DLL (which crashed right away).
I am running v3355 retail. It was on ons_torlan, with the default number of bots (12 or 16 I think).
I've re-benchmarked it with umark, 10 bots, ons_torlan. Average comes out to 10FPS. This seems to be in line with what I saw before, slightly higher FPS from less bots.
I've taken a screenshot of the visual glitches, which can be seen here:
http://teknews.net/~guspaz/swiftshader_error.JPG
Notebook's CPU was forced to the max clockspeed at the time (Using Notebook Hardware Control). SwiftShader's INI was totall default except for the two UT2004 related settings. I'm going to save a copy of my UT2004.ini file for future reproduction and see if lowering the quality settings makes a difference (with the visual glitches). Let me know if you want a copy of my UT2004.ini file for reproduction purposes.
Also I can report that when they say it is as fast as low-end 3D cards, by low-end they mean the original Voodoo 1.
I tried it with UT2004, one of the reccommended games according to the readme. UT2004 in DX9 mode crashed right away. DX8 mode ran, but with series issues and low performance.
I left the INI file at the default settings, except for the two settings they reccommended for UT2004. I left UT2004 on the quality settings I have on my machine, which is "normal" and "low" for all graphical settings. I lowered res to 640x480.
I saw something like 5 to 8 fps average, barely playable. And even the cheapest of low-end cards can get several times that. On top of this, most visual effects were missing (Fire the lightning gun and see the impact but not the shaft), and there were major texturing issues (Most textures were just matte brown or white). My test system was a laptop with a 1.7Ghz Pentium M processor, roughly the equivalent of a P4 2.8ghz or 3.0ghz.
Honestly I can't see this as being useful. Assuming they fix the visual glitches, yes, it is perhaps one of the fastest software renderers available. Unfortunately, it is totally useless. Any PC with a CPU fast enough to take advantage of this is going to have onboard or low-end 3D hardware that would run circles around SwiftShader.
Think about it. The readme claims that the Pentium-M runs their software particularly well. However, all laptops ship with some sort of onboard 3D hardware, and all of it is loads faster than this software thing. Even the onboard laptop video these days is DX9. Many desktop motherboards ship with onboard DX9 Intel graphics, and few PCs sold don't feature any 3D hardware at all.
So, again, interesting to play around with perhaps, but totally useless in the marketplace. I'm very surprised they convinced even one company to license this thing.
You can't compare audio editing apps to a dedicated software DSP. One is generalized and probably not optimized for realtime audio work, and the other is the opposite.
You forget also that there are hardware programmable DSPs in modern computers; Creative soundcards, for one thing, and all modern videocards.
I actually recall reading an article a while back on doing audio processing on videocards. This was part of the growing trend of using videocards as math co-processors or DSPs.
Assuming you could do the processing right on the soundcard, and perhaps do this inside a kernel-level driver, you can potentially get extremely low latency. Of course you'd be monopolizing the soundcard.
Not to mention the fact that while UMDs are encoded at DVD resolution, the PSP only displays them at a lower resolution. UMDs were meant to be used outside the PSP, which is why they're encoded at a highe resolution.
By doing this webcam-on-psp garbage, not only are you limiting yourself to PSP resolution on your TV, you're putting up with the higher response time of the LCD on the PSP. You're recording the LCD screen's flaws.
Not to mention the fact that I highly doubt the camera in this rediculous contraption is going to be high enough detail to even capture the true resolution of the LCD.
This is going to come out looking worse than overused VHS tapes, mark my words.
The audio stuttering problem, which might I add is currently only experienced by a vey small number of people (the extremely vocal minority) is not directly related to the sound system, but is instead caused by other subsystems inducing hitching. I believe one primary cause of the audio stuttering that was solved early on was due to loading assets at runtime. This was solved, IIRC, by pre-loading more content during level loads.
It is unlikely that a hardware-accelerated sound engine would have solved such problems.
You're thinking of the Aureal Vortex (http://en.wikipedia.org/wiki/A3D). A3D simulated a low-detail version of the 3D environment and calculated reverb based on the reflections inside that environment.
A3D died off years ago, and Aureal was bought out by Creative. EAX still can't come close to A3D's capabilities.
For an idea of the A3D generation, Quake 3 supported A3D for 3D audio, though it was later removed when A3D died off.
I would not buy USB (Too much added bulk), however I am also hoping for a PCMCIA version.
The Audigy 2 Notebook (PCMCIA) was very impressive, as it provided the entire feature set of the Audigy 2 ZS (with the exception of hardware midi synth I think?) in the PCMCIA form factor.
A PCMCIA version of the X-Fi would be greatly welcomed by me, for the vastly improved SNR over my notebook's onboard audio, as well as the 3D headphone virtualization.
HL2 does ALL of it's sound processing (3D, effects, etc) entirely in software. The only benefit a higher priced Creative card can provide is a better SNR, which isn't the end-all-be-all.
Using a generic onboard card with surround support will not be much of a different experience than using an X-Fi. You'll notice cleaner sound due to the better SNR, but that's it.
Valve did this because CPUs have advanced to the point where sound processing can be done in software without too much of a processing time investment, and it ensures that everybody gets to hear the same soundscape/quality no matter what soundcard they are using. No longer does environmental audio depend on what version of EAX your soundcard supports.
Exactly. The statement might be revised to "Precious few sound cards feature full hardware acceleration for 3D audio", since some cards like the SB Live! do 3D acceleration, just not on enough 3D channels to cover it all in hardware.
This used to be a big issue in games where 3D (surround) sound was used. These days with faster processors, it isn't such a big issue any more. In fact, many modern games (Half-Life 2's Source engine, and DooM 3) both do all sound processing exclusively in software (though Creative later blackmailed Id into adding hardware support for DooM 3). It was decided for this current generation of games that CPUs were fast enough to do the sound processing in hardware, and that it was the best way to provide a consistent presentation no matter what sound card is used. Both games do all their 3D mixing, and their post-processing (reverb for example) entirely in software.
Does doing it in hardware still provide a CPU benefit? Yes. Is it that important anymore? No, unless you're going nuts for framerates.
I seem to recall a benchmark done years ago on an Athlon 1.4 that showed 40% CPU usage exclusively for 3D sound on the SB-Live, and something like 5% on the Audigy. Now, with current high-end CPUs at something like 3x faster than that, spending 15% of a game's CPU budget on sound is fine. Multithreading in games (to support multicore processors) will further reduce this, since you'll be able to offload sound processing to the second core.
So in other words if I type "dellgaminglaptops.com" into my browser, instead of getting a "Domain not found" page, I'll be redirected to an ebay search for "dell gaming laptops"? What a wonderful improvement over Verislime's previous activities.
I stand by the statements I've made the past two times that the iPod Video seemed on the cusp of release. Allow me to quote a post I made a few days ago:
I think a previous post I've made still applies to this situation, and I'll reiterate the key points: Every time Apple hints they are about to make an announcement, the media always tells the public that it is undoubtedly going to be a video iPod. And every single time they have been wrong. Does this mean that this announcement is not a video iPod? No. I merely point out that screaming "OMG TEH VIDEO IPOD IS HERE!" every time apple prepares for an announcement is stupid.
This nonsense has just proven my point; yet another Apple announcement, the media claims it can be nothing but the Video iPod, but now, well, not so much. Yes, the official announcement has yet to be made. But consider this; for years the media has been saying that announcements for the next iPod related product was a Video iPod. For years I've been saying they're full of shit. Every single time, I've been right and they've been wrong. Says something about the "experts" making the claims, doesn't it?
You seem to have skipped over most of my post. I said that in order to convince peers to upload to the client, the malicious client should upload small amounts of valid data to convince peers to send. BitTorrent doesn't really have tit-for-tat, just a higher weight to uploading to clients that upload back. I'm pretty sure speed is divided evenly, to the extend that that is possible.
This is potentially much more damaging than half a swarm taking up half the bandwidth. First of all if half the swarm is taking up half the bandwidth, you are effectively left with one quarter the bandwidth. Twice as many peers, half the bandwidth.
Seeds don't use round-robin. They send the rarest pieces to those who request them, as much as their set limits allow. Random isn't round-robin. They are, as you pointed out, usually a small part of the swarm. If the fake clients jump into a swarm that is just starting out, not only can they suck up a ton of peer-to-peer transfers, they can prevent (Or delay) peers from becoming seeds, keeping the swarm in the desirable (for them) low-seed situation.
The idea is to turn the BitTorrent client into a bandwidth black hole into which the swarm's bandwidth is sucked. If you get enough of them, and if the modified clients are smart enough, they could potentially do lots of damage.
There is something that nobody has considered, though. This action (And the ones already being taken) are DDoS (Or regular DoS) attacks, and are illegal. Remember, DoS stands for "Denial of Service", and sending fake chunks or trying to suck up bandwidth in bad faith IS an attempt to deny service to users. It doesn't matter if they are the copyright holder or not; vigilante justice is outlawed. For example, you are not allowed to kill a person, even if he killed your brother. And you can't DDoS a service that is being used to share your copyrighted material.
The problem is that BitTorrent, despite it's semi-centralized topology, is still too decentralized to do anything about it. The obvious people who are in the position to take action are the owners of the trackers, and there are thousands (or tens of thousands) of trackers out there. Few trackers are large enough to take action. Some of the larger ones might be, the ones that are operated by web sites (Such as Pirate bay's tracker), however few are in the US and fewer still would want to call attention to themselves by protesting.
So what we end up with is one party performing an illegal act to attempt to stop another party from performing an illegal act, and neither side is going to be stopped. HBO won't be stopped because nobody can stand up and fight them in court, and the BitTorrent trackers won't be stopped because they exist all over the world and probably aren't illegal in most places anyhow. What a wonderful situation.
I know this is turning into a rant, but I'm disappointed that HBO decided to waste money doing this instead of introducing a legitimate BitTorrent based distribution system. BitTorrent (the company) has already entered into deals with the entertainment industry to be used as a distribution mechanism for copyrighted content, and I applaud them. I've long said I would pay to subscribe to television shows over the internet. I already watch most TV via the internet for the simplicity and convienience, and I would indeed be willing to pay to get DVD or HD quality content legally. BitTorrent lowers the cost of distributing HD content to next to nothing, making the size of the content irrelevant. $50 could distribute millions of copies of a 2400MB HD episode, whereas to distribute just a hundred thousand copies within 6 hours would cost something like $900,000 with HTTP (We're talking ~90 gigabits). To be able to distribute that hundreds of thousands of times cheaper, you'd think the companies would be jumping on it.
As a note, I'm trying a quick test to see how much of my bandwidth is wasted.
I grabbed the latest torrent of Rome (1x06) off TorrentSpy and started downloading. We'll see how many hash fails it has by the time it is done. So far I've downloaded 5 and all are valid.
Here's why:
1) With a chunk size of 256KB, typical for a 350MB show, only 75MB of bandwidth would be wasted in your scenario. Hardly a major slowdown
2) Blacklists such as PeerGuardian will quickly block the HBO IP addresses, and users of such blacklists won't be affected at all
3) Decentralized tracking helps against this since peers wouldn't report bad peers when queried.
They're going about this all wrong. What they should be doing is acting as peers with none of the file. If you flood a swarm with 100 malicious BitTorrent clients, you could do a lot of damage to swarm capacity. Here's what I'd do:
1) Have each client connect to AS MANY peers as possible. All that will allow them to connect. Lie to the tracker about whatever is needed to get connected to as many peers as possible
2) Actively seek to download chunks from other peers, but never upload
3) Report, to each peer, that the client now has available the chunk it just downloaded. This makes it impossible for a peer to detect bad nodes based on the fact that they never increase in progress even though they are downloading
The goal of this is to waste as much upstream bandwidth as possible so that others suffer. While their current methods can affect some people, anybody who has a PeerGuardian type plugin is totally unaffected, and those that don't aren't affected much. If those clients are actively seeking to suck up the swarm's upload capacity, they affect everyone, PeerGuardian or not.
The only trick is to try to get around the tit-for-tat rule. Yes, I know there is no such rule, however in practice it works out; clients are much more likely to upload to you if YOU are uploading to THEM. One possible way around this might be to upload real legitimate data to everyone possible. A peer sending data at 1KB/s for brief periods every few minutes isn't going to help much, but it could potentially suck up a lot more bandwidth.
Don't get me wrong, I think HBO is fucking stupid to be doing this. I was just looking at it as an interesting mental puzzle.
These are Tier 1 ISPs. You don't use them for your home internet connection. Nobody who would take up Cogent's offer is going to be running a web browser through a Level 3 connection. Tier 1 ISPs serve other ISPs and large businesses.
Don't they host most such events in theaters? I mean, they need someplace big with lots of seats and a stage for such announcements. Isn't a theater (and not the movie kind) the obvious place to host such a thing?
I think a previous post I've made still applies to this situation, and I'll reiterate the key points: Every time Apple hints they are about to make an announcement, the media always tells the public that it is undoubtedly going to be a video iPod.. And every single time they have been wrong. Does this mean that this announcement is not a video iPod? No. I merely point out that screaming "OMG TEH VIDEO IPOD IS HERE!" every time apple prepares for an announcement is stupid.