You're not obliged to purchase L4D2. But if you want five new campaigns, pony up the cash.
To be fair, they're not just new campaigns. They're new campaigns with new monsters and new weapons, which means more fun re-learning how to play like a pro.
Or at least that's the line they'll spin when they try to sell it for $50. But I can't blame them, since people pay over $200/yr for WoW, and when I look at WoW, I really don't see $750+ of quality/value.
If you want quality, you need to spend money. I just wish they'd release some new campaigns for the original. Even if I had to buy them for $10 per 3-4, it'd be worth it.
But I must admit, I don't mind cheap expansions/"DLC". If I could get another four campaigns for L4D for $10, I'd buy it. I mean, people pay $200+/yr for WoW, so why not $40 + $10 + $10 + $10 to keep things fresh? (four new maps every 3 months? Too much to hope for?)
If they focused more on the artwork, they could probably draft some level designs and get some community members to help finish the levels. They should tap their resources! It'll cost them a few free copies of the expansions/game, but an extra campaign or two adds a lot of value!
Survival mode, well that was a decent addition, but it only added one small map, all the other survival maps were just expanded panic events from the existing content.
Technically all survival maps are custom made maps. They use artwork that was already present, and have layouts that closely resemble the layouts used in parts of the campaigns, but someone still had to sit there and tweak everything to make them behave properly. Nav maps had to be re-done, blockades and spawnpoints moved, etc.; I'm sure it was time consuming, and they are new maps, but they'd feel newer if they weren't so recognizable as parts of the campaign.
If he offers a $15-20 discount to anyone currently owning L4D, I'll definitely bite.
I'm sorry that you're not the target market. (Actually, I'm not either; I own 3 desktops:P ) Just be aware that although you don't find it useful or affordable, that doesn't discount the market entirely.
I mean, people pay $200 for a Chumby, and $240 for a PSP with $60 worth of hardware in it. This thing probably has $250 worth of hardware. It really is very affordable, if you require a touchscreen panel PC.
It's worth noting that pre-Opera9, most of those site glitches were Opera related.
element.style.backgroundColor = '#ffff80';
Works fine in just about every browser. Works in FF(all), IE(all), Opera(9), Google Chrome, and probably Safari. You can use it on body elements to create crazy funky background colour shifting, and also use it for fading.
Opera 8 needs this:
element.style.bgColor = '#ffff80';
Some properties also can't be set without calling setAttribute. Ex:
element.setAttribute('bgcolor', '#ffff80');
I haven't come across any such stupidity in Opera 9, so those sites are probably broken because they deviate from the standard. People criticize Firefox for taking a long time to implement features, but it's had great compatibility from the start. Opera only just recently acquired that.
Just pointing out that Opera is neither a bad browser nor the best one. Lots of people above are either worshipping it or slamming it. It's just another one, which prioritizes security and new features over compatibility. As a contrast, Google Chrome prioritizes security and simplicity.
Bandwidth? Do you have any idea how many 56k users it takes to clog a 100mbit line, let alone multiple gbit lines?:P
Compressing that data takes CPU power, and memory to temporarily cache it. But considering the quad or octo-core servers we have available now, all packed with 48-192GB of memory.... this service could probably run fine off four to eight servers. Just scale it northward as you approach capacity.
Alright, figured it out. I emailed the guy, and he told me it was the decoder. (ffdshow) The chosen settings were fine. Even the encodes are fine.
About a month after the tests, a new version was on CVS that didn't have the same issues with 5.1 profiles. He didn't think to email me, so I've been spreading outdated/false info. >_<
I pulled one of the h.264 encoded vids off a backup drive, and it looks just fine now. It just wouldn't decode properly back then, and since ffdshow didn't crash(and quality did improve as options were tweaked), we didn't clue in to it being decoder error.
Go figure. The one time I really heavily research something, a software bug nails me. And now my stupidity gets preserved on slashdot for all eternity! Oh well - that's irony, I guess.:P
Oh, and if you're still interested in the clips, I can upload them somewhere - but since they now agree with you, the only thing of interest would be the lack of horrible artifacts in the xvid version.
It could've been a configuration issue, but since I know more about xvid encoding than h.264, I have to go with what other people tell me, and what I can glean off doom9.
The first was the first few minutes of Firefly's first episode. It's quite dark, and has a lot of area that can be blurred out totally without noticing it. But this should've helped h.264?
The second was a home video of a cat drinking out of a glass by using his paw. The (orange) cat was sitting on an orange shag carpet.
The third was a FRAPS recorded video of a battle in Saga Frontier 2. I recall h.264 handled the interface better, but it completely blocked up the graphical stuff. (effects) Xvid made a complete mess of the text/interface, but prioritized the graphical stuff instead.
I'll get back to you once I've re-encoded at least one of those with up to date software.
Wow, that xvid sure looks awful! h.264 is clearly superior there!
I'm not convinced xvid can't do slightly better with tweaks. Perhaps even better than VC-1. (We were getting artifacts close to your VC-1 encode with our xvid encodes; but we had a bit higher bitrate... and also higher resolution)
I'll have to go and ask the guy that ran the tests to re-do them with a new version of the encoder, and a new ffdshow.
The point is that it is easy to program a computer to win, the hard part is to program is lose convincingly.
Winning convincingly is pretty difficult too.
Taking Left4Dead as an example; we were doing good against the bots. We got them all separated, and I'm about to pounce the last guy. Just before I land on Louis's head, he teleports over to an incap'd Zoey that's far away, and picks her up.
Rest assured, the bots died - but stuff like that really takes away from either winning or losing. Imagine if Louis's teleporting act had saved his three friends, and they made their escape?
(Note: This was an all-bot team. Some friends and I were comparing the default AI with a modded one.)
The AI has to have restrictions, and it also needs helpers for if the engine messes up and it gets stuck. The player should have those same helpers. Did I tell you about the time I backed up into a garbage can, and it passed into my legs and slowly rolled through them, giving the tank time to catch up and kill me? Very annoying. I was really wishing for some teleport action right about then.
AIs tend to sprawl, and are able to manage far too much at once.
They need to organize better. Taking Supreme Commander as an example - player bases are usually orderly, but once the shields go down the whole thing goes down. AI bases are usually twice as big, and are packed with lvl 1 power gens. They're awful to move about in; units getting stuck everywhere... but the AI still manages to issue repair commands to everything, and keep 60 factories producing different units.
An AI should be forced to act like a player. Each factory constantly produces 1 unit, and sends it to a rally point. If it needs more of X unit, then it assigns a new factory to build that for a while - but none of this changing unit every single unit crap!
In short, it segregates the controller AI from the unit AI.
I can remember when playing SupCom against easy opponents, if I didn't build any defenses, the opponent would stop sending units into my base for a while, instead moving them around in circles somewhere outside it. Even an easy/stupid AI has to make decisions that a stupid person would make. Mainly - CHARGE!
But at the same time, the best AIs were omniscient. They'd target your first fusion reactor with bombers as soon as you build it... It became so predictable that I'd build a shield, turn it off, build a fusion, then turn the shield back on.
But in SupCom there were all the modded AIs which chose more interesting tactics, and you could enable cheating for any AI to give them a resource and difficulty boost.
I think to be realistic, AI has to be segregated even more. You need an Advisor, which decides the direction things should be going. Do we need more resources? Do we have an urgent matter to deal with, like artillery pelting the base? The Advisor should just decide what to tackle, and then pass that on to the other AI subsystems. Like a player, the AI subsystems should take time to do stuff. An AI can't instantly decide what's an entrance to his base. He has to study where the units usually come from, and locate possible landing zones for air transports, etc.
To ramp up the intelligence, you let it assign more issues to its subordinates more rapidly, and you let it learn across missions. Pretty soon the AI can tackle any frequently played map.
Send me to some demo videos then, and also links to all the settings used.
We researched it quite heavily a year or so back. All the "superior" h.264 examples were superior because they lied about their bitrates. In one example a clip was supposed to be 512kbit, but when we encoded it ourselves with x264 at ~800kbit, it came out smaller than the video that was supposedly 512kbit. (and still larger than it should've been)
The xvid was smaller than it, and superior in quality to our x264 encode. But if you have some examples to link to that are newer than roughly one year, send me the links and I'll look into them and pass them along.
No sense spreading outdated info, if things really have changed. I just don't buy that things have improved that much without proof. Results are easy to craft in your favour, if you have enough time to play with the encoder and source clips.
If you are getting worse quality at lower bitrates with h.264 over an ASP codec, you are doing something wrong. H.264 was designed precisely to be better than ASP at lower bitrates.
Oh, let me assure you, I'm hopeless at configuring h.264 for low bitrates.
That's why I got someone that constantly reads the doom9 boards to run the tests. Xvid consistently blurred out more of the background stuff and devoted more bytes to what we were likely going to be looking at.
x264, even tweaked, had problems with far too much blockiness. Mind you, it could've been our choice of decoder. It was a while back, and ffdshow didn't have great h.264 support until the last year or so.
Maybe if we re-ran the tests now it'd be different? Or maybe not?
Now, this does mean that Google gets a record of when an IP address visited my server and what page they looked at. Is this an invasion of privacy? I don't think so. What's the worst that is going to happen? Google sells my browsing habits so that companies I already have a business relationship with send me targeted advertising? OH NO
Google doesn't sell that info. They use it internally to improve their advertising services, which in turn raises its value, and allows them to charge more for their services.
Microsoft and Yahoo sell stuff to the highest bidder. And I'm sure most other companies doing this are as well.
Thankfully privacy is one issue Google seems to be respecting. Thus far they haven't done anything nefarious with the info they collect. They even refused to turn tons of it over to the government.
Theora can't beat XviD and XviD is inferior to x264.
Nothing beats Xvid for low bitrates. (The bitrates which create ~350MB videos)
It blurs more details than some other codecs, which lets it save on space and put more detail into important stuff.
h.264 gets quite blocky well before Xvid does; mind you, it does a better job preserving details when a higher bitrate is allowable. h.264 is often the preferred format for raw video footage, since at high bitrates it comes remarkably close to totally uncompressed video. (which is usually too big to do anything with)
For static content, VP7/VP8 are quite impressive, but VP3... not so much.
A presentation with slides occasionally changing works wonderfully in VP7. It'll use a couple hundred kilobytes on the first frame, plus any frame where it suddenly changes, but aside from that it won't use much/any bandwidth. The result is a video that looks like a 32bit gif animation(perfect quality).
On2's algorithms for figuring out which pixels changed are quite advanced; a 10 second video showing a slide was a couple kilobytes smaller than a 4 minute video showing the same slide... with x264 and xvid, I didn't get results like that even after spending a day tweaking everything.
On2's encoder also automatically removes minor jitter/angle abnormalities, so if the camera was being held by a person, the difference in size will be even more pronounced.
Too bad last time I checked, their encoder was single-threaded. I'm also betting "Superior codec for lectures." isn't the kind of endorsement they wanted.:P
Not really OT. It's all similar actions involving different software.
7300 GO... that's quite underpowered. Driver issues are going to be very noticeable on that.
It's possible that the hardware acceleration is misbehaving because your desktop is already accelerated. I wonder how it would act if Aero were disabled? In theory it should behave the same as XP.
It's worth noting that the ARM architecture has a different instruction set, which does a better job of not straining the memory. Often you can do things one byte at a time, or do multiple one byte things in a single clock.
ARM CPUs are usually packed with tons of registers(way more than x86), so short functions can be blazing fast, and not require cache or memory thrashing.
But these ways of reducing memory bandwidth consumption are counteracted by having everything share memory. GPU, Co-Processor, CPU, LCD, etc.
Just keep in mind that as you optimize your code, and reduce memory consumption, you probably also reduced the memory bandwidth used. Native ARM programs can be extremely fast.
Slashdot Mirror
You're not obliged to purchase L4D2. But if you want five new campaigns, pony up the cash.
To be fair, they're not just new campaigns. They're new campaigns with new monsters and new weapons, which means more fun re-learning how to play like a pro.
Or at least that's the line they'll spin when they try to sell it for $50. But I can't blame them, since people pay over $200/yr for WoW, and when I look at WoW, I really don't see $750+ of quality/value.
If you want quality, you need to spend money. I just wish they'd release some new campaigns for the original. Even if I had to buy them for $10 per 3-4, it'd be worth it.
You raise some interesting points.
But I must admit, I don't mind cheap expansions/"DLC". If I could get another four campaigns for L4D for $10, I'd buy it. I mean, people pay $200+/yr for WoW, so why not $40 + $10 + $10 + $10 to keep things fresh? (four new maps every 3 months? Too much to hope for?)
If they focused more on the artwork, they could probably draft some level designs and get some community members to help finish the levels. They should tap their resources! It'll cost them a few free copies of the expansions/game, but an extra campaign or two adds a lot of value!
Survival mode, well that was a decent addition, but it only added one small map, all the other survival maps were just expanded panic events from the existing content.
Technically all survival maps are custom made maps. They use artwork that was already present, and have layouts that closely resemble the layouts used in parts of the campaigns, but someone still had to sit there and tweak everything to make them behave properly. Nav maps had to be re-done, blockades and spawnpoints moved, etc.; I'm sure it was time consuming, and they are new maps, but they'd feel newer if they weren't so recognizable as parts of the campaign.
If he offers a $15-20 discount to anyone currently owning L4D, I'll definitely bite.
I'd happily pay them $15/mo to get access to all their shows. It'd save me money!
$300 is dirt cheap for an x86 PC with a touchscreen that huge.
See: http://www.logicsupply.com/categories/panel_pc
I'm sorry that you're not the target market. (Actually, I'm not either; I own 3 desktops :P ) Just be aware that although you don't find it useful or affordable, that doesn't discount the market entirely.
I mean, people pay $200 for a Chumby, and $240 for a PSP with $60 worth of hardware in it. This thing probably has $250 worth of hardware. It really is very affordable, if you require a touchscreen panel PC.
It's worth noting that pre-Opera9, most of those site glitches were Opera related.
element.style.backgroundColor = '#ffff80';
Works fine in just about every browser. Works in FF(all), IE(all), Opera(9), Google Chrome, and probably Safari. You can use it on body elements to create crazy funky background colour shifting, and also use it for fading.
Opera 8 needs this:
element.style.bgColor = '#ffff80';
Some properties also can't be set without calling setAttribute. Ex:
element.setAttribute('bgcolor', '#ffff80');
I haven't come across any such stupidity in Opera 9, so those sites are probably broken because they deviate from the standard. People criticize Firefox for taking a long time to implement features, but it's had great compatibility from the start. Opera only just recently acquired that.
Just pointing out that Opera is neither a bad browser nor the best one. Lots of people above are either worshipping it or slamming it. It's just another one, which prioritizes security and new features over compatibility. As a contrast, Google Chrome prioritizes security and simplicity.
Bandwidth? Do you have any idea how many 56k users it takes to clog a 100mbit line, let alone multiple gbit lines? :P
Compressing that data takes CPU power, and memory to temporarily cache it. But considering the quad or octo-core servers we have available now, all packed with 48-192GB of memory.... this service could probably run fine off four to eight servers. Just scale it northward as you approach capacity.
Not exactly breaking the bank.
Alright, figured it out. I emailed the guy, and he told me it was the decoder. (ffdshow) The chosen settings were fine. Even the encodes are fine.
About a month after the tests, a new version was on CVS that didn't have the same issues with 5.1 profiles. He didn't think to email me, so I've been spreading outdated/false info. >_<
I pulled one of the h.264 encoded vids off a backup drive, and it looks just fine now. It just wouldn't decode properly back then, and since ffdshow didn't crash(and quality did improve as options were tweaked), we didn't clue in to it being decoder error.
Go figure. The one time I really heavily research something, a software bug nails me. And now my stupidity gets preserved on slashdot for all eternity! Oh well - that's irony, I guess. :P
Oh, and if you're still interested in the clips, I can upload them somewhere - but since they now agree with you, the only thing of interest would be the lack of horrible artifacts in the xvid version.
Yes, I did. x264 clearly did the best job.
And no - 800x480.
It could've been a configuration issue, but since I know more about xvid encoding than h.264, I have to go with what other people tell me, and what I can glean off doom9.
Certainly. Three clips were chosen.
The first was the first few minutes of Firefly's first episode. It's quite dark, and has a lot of area that can be blurred out totally without noticing it. But this should've helped h.264?
The second was a home video of a cat drinking out of a glass by using his paw. The (orange) cat was sitting on an orange shag carpet.
The third was a FRAPS recorded video of a battle in Saga Frontier 2. I recall h.264 handled the interface better, but it completely blocked up the graphical stuff. (effects) Xvid made a complete mess of the text/interface, but prioritized the graphical stuff instead.
I'll get back to you once I've re-encoded at least one of those with up to date software.
small-time directshow codec
The Codec isn't small time; just the company. Last I checked, it was the lightest h.264 codec available as far as CPU usage. Very heavily optimized.
Wow, that xvid sure looks awful! h.264 is clearly superior there!
I'm not convinced xvid can't do slightly better with tweaks. Perhaps even better than VC-1. (We were getting artifacts close to your VC-1 encode with our xvid encodes; but we had a bit higher bitrate... and also higher resolution)
I'll have to go and ask the guy that ran the tests to re-do them with a new version of the encoder, and a new ffdshow.
I don't remember all the settings, but a few did stick in my head.
Video was 800x480 (odd size, I know; matches resolution of some upcoming handheld devices)
5.1 profile
subq 7
trellis?
VBR (2 pass I think?)
B/I/P Frames were enabled. (BIP...heh)
And I think motion estimation was set fairly low - 8 pixels? The source content didn't have a huge amount of movement.
That's all I can remember offhand. I'll have to get a hold of the guy that did it if you want more details.
The point is that it is easy to program a computer to win, the hard part is to program is lose convincingly.
Winning convincingly is pretty difficult too.
Taking Left4Dead as an example; we were doing good against the bots. We got them all separated, and I'm about to pounce the last guy. Just before I land on Louis's head, he teleports over to an incap'd Zoey that's far away, and picks her up.
Rest assured, the bots died - but stuff like that really takes away from either winning or losing. Imagine if Louis's teleporting act had saved his three friends, and they made their escape?
(Note: This was an all-bot team. Some friends and I were comparing the default AI with a modded one.)
The AI has to have restrictions, and it also needs helpers for if the engine messes up and it gets stuck. The player should have those same helpers. Did I tell you about the time I backed up into a garbage can, and it passed into my legs and slowly rolled through them, giving the tank time to catch up and kill me? Very annoying. I was really wishing for some teleport action right about then.
AIs tend to sprawl, and are able to manage far too much at once.
They need to organize better. Taking Supreme Commander as an example - player bases are usually orderly, but once the shields go down the whole thing goes down. AI bases are usually twice as big, and are packed with lvl 1 power gens. They're awful to move about in; units getting stuck everywhere... but the AI still manages to issue repair commands to everything, and keep 60 factories producing different units.
An AI should be forced to act like a player. Each factory constantly produces 1 unit, and sends it to a rally point. If it needs more of X unit, then it assigns a new factory to build that for a while - but none of this changing unit every single unit crap!
In short, it segregates the controller AI from the unit AI.
I can remember when playing SupCom against easy opponents, if I didn't build any defenses, the opponent would stop sending units into my base for a while, instead moving them around in circles somewhere outside it. Even an easy/stupid AI has to make decisions that a stupid person would make. Mainly - CHARGE!
But at the same time, the best AIs were omniscient. They'd target your first fusion reactor with bombers as soon as you build it... It became so predictable that I'd build a shield, turn it off, build a fusion, then turn the shield back on.
But in SupCom there were all the modded AIs which chose more interesting tactics, and you could enable cheating for any AI to give them a resource and difficulty boost.
I think to be realistic, AI has to be segregated even more. You need an Advisor, which decides the direction things should be going. Do we need more resources? Do we have an urgent matter to deal with, like artillery pelting the base? The Advisor should just decide what to tackle, and then pass that on to the other AI subsystems. Like a player, the AI subsystems should take time to do stuff. An AI can't instantly decide what's an entrance to his base. He has to study where the units usually come from, and locate possible landing zones for air transports, etc.
To ramp up the intelligence, you let it assign more issues to its subordinates more rapidly, and you let it learn across missions. Pretty soon the AI can tackle any frequently played map.
x264 pounds xvid into dust at low bitrates.
Send me to some demo videos then, and also links to all the settings used.
We researched it quite heavily a year or so back. All the "superior" h.264 examples were superior because they lied about their bitrates. In one example a clip was supposed to be 512kbit, but when we encoded it ourselves with x264 at ~800kbit, it came out smaller than the video that was supposedly 512kbit. (and still larger than it should've been)
The xvid was smaller than it, and superior in quality to our x264 encode. But if you have some examples to link to that are newer than roughly one year, send me the links and I'll look into them and pass them along.
No sense spreading outdated info, if things really have changed. I just don't buy that things have improved that much without proof. Results are easy to craft in your favour, if you have enough time to play with the encoder and source clips.
If you are getting worse quality at lower bitrates with h.264 over an ASP codec, you are doing something wrong. H.264 was designed precisely to be better than ASP at lower bitrates.
Oh, let me assure you, I'm hopeless at configuring h.264 for low bitrates.
That's why I got someone that constantly reads the doom9 boards to run the tests. Xvid consistently blurred out more of the background stuff and devoted more bytes to what we were likely going to be looking at.
x264, even tweaked, had problems with far too much blockiness. Mind you, it could've been our choice of decoder. It was a while back, and ffdshow didn't have great h.264 support until the last year or so.
Maybe if we re-ran the tests now it'd be different? Or maybe not?
Isn't that OpenID crap annoying? That was the deciding factor in me using Wordpress rather than Blogger.
Now, this does mean that Google gets a record of when an IP address visited my server and what page they looked at. Is this an invasion of privacy? I don't think so. What's the worst that is going to happen? Google sells my browsing habits so that companies I already have a business relationship with send me targeted advertising? OH NO
Google doesn't sell that info. They use it internally to improve their advertising services, which in turn raises its value, and allows them to charge more for their services.
Microsoft and Yahoo sell stuff to the highest bidder. And I'm sure most other companies doing this are as well.
Thankfully privacy is one issue Google seems to be respecting. Thus far they haven't done anything nefarious with the info they collect. They even refused to turn tons of it over to the government.
Theora can't beat XviD and XviD is inferior to x264.
Nothing beats Xvid for low bitrates. (The bitrates which create ~350MB videos)
It blurs more details than some other codecs, which lets it save on space and put more detail into important stuff.
h.264 gets quite blocky well before Xvid does; mind you, it does a better job preserving details when a higher bitrate is allowable. h.264 is often the preferred format for raw video footage, since at high bitrates it comes remarkably close to totally uncompressed video. (which is usually too big to do anything with)
For static content, VP7/VP8 are quite impressive, but VP3... not so much.
A presentation with slides occasionally changing works wonderfully in VP7. It'll use a couple hundred kilobytes on the first frame, plus any frame where it suddenly changes, but aside from that it won't use much/any bandwidth. The result is a video that looks like a 32bit gif animation(perfect quality).
On2's algorithms for figuring out which pixels changed are quite advanced; a 10 second video showing a slide was a couple kilobytes smaller than a 4 minute video showing the same slide... with x264 and xvid, I didn't get results like that even after spending a day tweaking everything.
On2's encoder also automatically removes minor jitter/angle abnormalities, so if the camera was being held by a person, the difference in size will be even more pronounced.
Too bad last time I checked, their encoder was single-threaded. I'm also betting "Superior codec for lectures." isn't the kind of endorsement they wanted. :P
Not really OT. It's all similar actions involving different software.
7300 GO... that's quite underpowered. Driver issues are going to be very noticeable on that.
It's possible that the hardware acceleration is misbehaving because your desktop is already accelerated. I wonder how it would act if Aero were disabled? In theory it should behave the same as XP.
I'll ask him if it's okay to distribute it. Last I heard, he wasn't done with it yet - but now he's working on L4D maps, so maybe he won't mind.
I'm talking about the AI variables.
Bots will not shoot through you if they can avoid it, because it causes damage. This means their friendly fire cvar is turned OFF.
Turn it ON, and they have no problem unloading shotgun shells right through your back if it keeps the zombies off you. :P
It's worth noting that the ARM architecture has a different instruction set, which does a better job of not straining the memory. Often you can do things one byte at a time, or do multiple one byte things in a single clock.
ARM CPUs are usually packed with tons of registers(way more than x86), so short functions can be blazing fast, and not require cache or memory thrashing.
But these ways of reducing memory bandwidth consumption are counteracted by having everything share memory. GPU, Co-Processor, CPU, LCD, etc.
Just keep in mind that as you optimize your code, and reduce memory consumption, you probably also reduced the memory bandwidth used. Native ARM programs can be extremely fast.