These days you can "quick format" a drive, which only alters the file table and so on, it doesn't zero the whole disk. Zeroing the disk takes so long and is of only dubious benefit.
However lower clock frequencies also require less voltage to keep a stable signal (and correspondingly, high frequencies need to be driven by a higher voltage). Taking this into account, power use does drop much more than linearly when clock frequency drops.
That's a bad implementation then, the IP RFC says that 0.0.0.0 is only valid as a source address (meaning "this machine") not a destination address.
Even if your implementation treats it like localhost, you're no worse off than 127.0.0.1. Amusingly 255.255.255.255 is a broadcast address, so really stupid to use, despite having seen it recommended.
Don't block using a hosts file, it's not for that. If you do, at least redirect to 0.0.0.0 (guaranteed invalid address) not 127.0.0.1 or 255.255.255.255.
For browsing adblock is better, for general blocks (like what a hosts file would give) use a damn firewall.
Consider Battlefield: Bad Company 2. A beta was available on Steam more than a month before game release, but you could only access it by pre-purchasing the game. There is a small step from that to splitting the cost between beta content, and full game content.
Or, more likely, splitting that cost into one reduced beta payment and one not-reduced-at-all game payment.
I wouldn't mind if you got a discount off of the final game, but you never will.
Spore was good. £5 for the creature thingy beforehand, gets you £5 off of EA's store, which was £10 more than where I actually bought it from. I bet many people were duped into paying extra for the game because of this, and getting a time-limited-download version (instead of my real disk) in return...
The only things that don't work on XP are geometry shaders, and a web browser does not need these.
And interprocess sharing of a graphics surface. And the entire hardware accelerated text subsytem for direct-x (which also happens to support cleartype). Given that Internet Explorer uses multiple processes, the former is probably quite important. Being a web-browser, the latter would be immensely helpful.
I wasn't arguing that 8ms wasn't insignificant, just that it would still exist on top of the frame time. Compared to the 100ms latency of a typical console game, 8ms is minor.
Strangely I haven't seen anyone complain about the latency of a wireless gamepad, only mice.
I personally use a wired mouse, but only because on my wireless mouse the batteries always went flat in the middle of a game. With a rechargeable mouse that wouldn't be an issue.
Only if you assume the input is happening at the exact start of a frame (so isn't sampled until 16ms later in both cases). If you assume the controller can be pressed at any point during a frame, then the difference in input latency does show up.
Assuming the game samples input at the start of a frame and the results of that sample show up on-screen 16ms later at the end of the same frame*, the latency between pressing a button on a 1ms controller and seeing the result on-screen would be 17ms if you pressed it exactly 1ms before the input sample is taken by the game. A fraction of a second later and it would miss that frame. You'd press the button, see the last frame show, the game would input sample, then your input would arrive, wait a frame, see another frame without your input be displayed, then the game samples and actually sees your input, then wait again before a frame with your input makes it to the screen. Two frames, plus just under the full input latency. 32.99ms! Pressing it later and later gets you slowly back towards pressing it 1ms before the input sample for a frame is taken. The end result is an even distribution of 17ms to 33ms latency.
For an 8ms input latency, the same is true. Minimum latency is 24ms (8ms input + 16ms frame). Max is just shy of 40ms (8ms input + two 16ms frames).
So increasing input latency from 1ms to 8ms does add 7ms to the min, max and average latency between activating that input and seeing the result on-screen.
* pipelining is popular in game code these days, a 60 fps game will likely use a 2-stage pipeline (game code, render), with each being 16ms and happening in parallel. So one frame it's rendering the last frame while running game code for this one, then next frame it's rendering what is now the last frame and doing game code for this frame. This means that there is a two-frame latency between the input sample being taken and the game finishing rendering the frame that uses that, meaning 33ms latency. However because input is still sampled every 16ms, the best case total latency between controller and screen is input latency + 33ms game latency, and the worst is input latency + 16ms sample rate + 33ms game latency.
Not to mention that the graphics chip will take time to transmit the rendered image to the display (typically an entire frame, aka 16ms), which will take time to display it (crts normally display as received, so are effectively no latency, tfts doing rescaling can be as bad as 100ms), and most games being only 30 fps on consoles (with the same two-frame pipeline, i.e. 66ms latency), you could end up with over 200ms latency locally. That's pretty horrendous, and could account for a lot of the "133ms" of latency seen in this controller.
In the UK all the banks have an agreement that they won't charge anyone for withdrawing from each others' cash machines, even if it is not their own bank. The big shops have cash machines provided by a bank, so they're free too. Of course, using a debit card to pay for something directly is also free.
The only machines that cost to withdraw from are the "portable" ones found at independent petrol stations, in pubs, etc. However these places normally let you pay by card with no additional charge, so you're not usually forced to use them.
I'd consider that evidence supporting my assertion. A minor bug caused a pretty obvious error in the software's output. In this case the output was rocket motion, in the bloodhound's case the software's output is only the design of the vehicle. A similar bug at the design stage should be just as obvious (e.g. "The wings should be minus 3000 meters long!") and not result in loss of life.
If there was a bug, it's unlikely the final result would make sense. "It would go fastest with the engine in the ground!", or "it would go fastest with the engine backwards!". With that many calculations, one error would be magnified.
I pay my rent by a standing order directly into my landlady's bank account, which I set up through my bank's online banking. All of this (the bank account, online banking, standing orders, direct money transfers) are free.
If this is not true in the US, the US banks are backward.
Re:Just when you thought you were at the bottom...
on
CCTV In School Toilets
·
· Score: 1
Except in the media, obviously.
Re:Just when you thought you were at the bottom...
on
CCTV In School Toilets
·
· Score: 1
Strangely enough, I've never seen the UK do anything this bad.
I have roughly that size display on a 800x600 digital projector. It needs replacing, and the only reason I'm planning on getting a higher resolution one is because my xbox 360 won't output 800x600 resolution natively, leaving me with 640x480 resolution either badly stretched or centred with massive borders...
The resolution (which is only a few pixels higher than British SD (720x576)) is plenty for film watching. Being able to make out the individual stubble hairs on the Hollywood hero's face just doesn't improve films for me. People say that after a few minutes they can forget that they're watching a black and white film, and the same goes for SD/HD, if not more so.
I don't own a PS3, but I would get one if it had enough exclusive games that interested me. So far the few I've been looking forward to have all ended up on PC or xbox 360 as well. I wouldn't buy movies through this service, because it would be much cheaper to get the dvd delivered, and I wouldn't have to worry about my hard-disk getting full and not being able to redownload any films I delete without repurchasing them or other such nonsense.
I hope they've fixed it by now, but when I first got Overlord, it wouldn't run on my pc. I was running XP x64, so I assume their DRM didn't support 64-bit Windows. Strangely enough, it worked fine after I cracked it.
Steam, on the other hand, installed an x64 version of the Source Engine, so Half-Life 2 and so on were running native 64-bit.
It's simple, the CSS key is stored in normally unreadable/unwritable areas of the disk, so a straight copy misses the key and it won't play. However, if you decrypt it and burn the decrypted version to a new disk, it will play fine.
Oh, and that car doesn't seem to be sold in the UK, and all the Toyota SUVs that are have handbrakes. I wonder if it's law in the UK to have a handbrake?
These days you can "quick format" a drive, which only alters the file table and so on, it doesn't zero the whole disk. Zeroing the disk takes so long and is of only dubious benefit.
However lower clock frequencies also require less voltage to keep a stable signal (and correspondingly, high frequencies need to be driven by a higher voltage). Taking this into account, power use does drop much more than linearly when clock frequency drops.
That's a bad implementation then, the IP RFC says that 0.0.0.0 is only valid as a source address (meaning "this machine") not a destination address.
Even if your implementation treats it like localhost, you're no worse off than 127.0.0.1. Amusingly 255.255.255.255 is a broadcast address, so really stupid to use, despite having seen it recommended.
Don't block using a hosts file, it's not for that. If you do, at least redirect to 0.0.0.0 (guaranteed invalid address) not 127.0.0.1 or 255.255.255.255.
For browsing adblock is better, for general blocks (like what a hosts file would give) use a damn firewall.
Actually historically only paying msdn subscribers got the betas. So it's actually a pretty good comparison.
Consider Battlefield: Bad Company 2. A beta was available on Steam more than a month before game release, but you could only access it by pre-purchasing the game. There is a small step from that to splitting the cost between beta content, and full game content.
Or, more likely, splitting that cost into one reduced beta payment and one not-reduced-at-all game payment.
I wouldn't mind if you got a discount off of the final game, but you never will.
Spore was good. £5 for the creature thingy beforehand, gets you £5 off of EA's store, which was £10 more than where I actually bought it from. I bet many people were duped into paying extra for the game because of this, and getting a time-limited-download version (instead of my real disk) in return...
A
H
H
I
(imagine it in Courier ...)
Perhaps code tags would help?
A
H
H
I
Not quite, lines are too far apart.
I noticed that too.
I think the lesson is that no AV is perfect...
The only things that don't work on XP are geometry shaders, and a web browser does not need these.
And interprocess sharing of a graphics surface. And the entire hardware accelerated text subsytem for direct-x (which also happens to support cleartype).
Given that Internet Explorer uses multiple processes, the former is probably quite important. Being a web-browser, the latter would be immensely helpful.
See the first episode of season 3 of Futurama.
I wasn't arguing that 8ms wasn't insignificant, just that it would still exist on top of the frame time. Compared to the 100ms latency of a typical console game, 8ms is minor.
Strangely I haven't seen anyone complain about the latency of a wireless gamepad, only mice.
I personally use a wired mouse, but only because on my wireless mouse the batteries always went flat in the middle of a game. With a rechargeable mouse that wouldn't be an issue.
Only if you assume the input is happening at the exact start of a frame (so isn't sampled until 16ms later in both cases). If you assume the controller can be pressed at any point during a frame, then the difference in input latency does show up.
Assuming the game samples input at the start of a frame and the results of that sample show up on-screen 16ms later at the end of the same frame*, the latency between pressing a button on a 1ms controller and seeing the result on-screen would be 17ms if you pressed it exactly 1ms before the input sample is taken by the game. A fraction of a second later and it would miss that frame. You'd press the button, see the last frame show, the game would input sample, then your input would arrive, wait a frame, see another frame without your input be displayed, then the game samples and actually sees your input, then wait again before a frame with your input makes it to the screen. Two frames, plus just under the full input latency. 32.99ms! Pressing it later and later gets you slowly back towards pressing it 1ms before the input sample for a frame is taken. The end result is an even distribution of 17ms to 33ms latency.
For an 8ms input latency, the same is true. Minimum latency is 24ms (8ms input + 16ms frame). Max is just shy of 40ms (8ms input + two 16ms frames).
So increasing input latency from 1ms to 8ms does add 7ms to the min, max and average latency between activating that input and seeing the result on-screen.
* pipelining is popular in game code these days, a 60 fps game will likely use a 2-stage pipeline (game code, render), with each being 16ms and happening in parallel. So one frame it's rendering the last frame while running game code for this one, then next frame it's rendering what is now the last frame and doing game code for this frame. This means that there is a two-frame latency between the input sample being taken and the game finishing rendering the frame that uses that, meaning 33ms latency. However because input is still sampled every 16ms, the best case total latency between controller and screen is input latency + 33ms game latency, and the worst is input latency + 16ms sample rate + 33ms game latency.
Not to mention that the graphics chip will take time to transmit the rendered image to the display (typically an entire frame, aka 16ms), which will take time to display it (crts normally display as received, so are effectively no latency, tfts doing rescaling can be as bad as 100ms), and most games being only 30 fps on consoles (with the same two-frame pipeline, i.e. 66ms latency), you could end up with over 200ms latency locally. That's pretty horrendous, and could account for a lot of the "133ms" of latency seen in this controller.
In the UK all the banks have an agreement that they won't charge anyone for withdrawing from each others' cash machines, even if it is not their own bank. The big shops have cash machines provided by a bank, so they're free too. Of course, using a debit card to pay for something directly is also free.
The only machines that cost to withdraw from are the "portable" ones found at independent petrol stations, in pubs, etc. However these places normally let you pay by card with no additional charge, so you're not usually forced to use them.
I'd consider that evidence supporting my assertion. A minor bug caused a pretty obvious error in the software's output. In this case the output was rocket motion, in the bloodhound's case the software's output is only the design of the vehicle. A similar bug at the design stage should be just as obvious (e.g. "The wings should be minus 3000 meters long!") and not result in loss of life.
If there was a bug, it's unlikely the final result would make sense. "It would go fastest with the engine in the ground!", or "it would go fastest with the engine backwards!". With that many calculations, one error would be magnified.
I pay my rent by a standing order directly into my landlady's bank account, which I set up through my bank's online banking. All of this (the bank account, online banking, standing orders, direct money transfers) are free.
If this is not true in the US, the US banks are backward.
Except in the media, obviously.
Strangely enough, I've never seen the UK do anything this bad.
I have roughly that size display on a 800x600 digital projector. It needs replacing, and the only reason I'm planning on getting a higher resolution one is because my xbox 360 won't output 800x600 resolution natively, leaving me with 640x480 resolution either badly stretched or centred with massive borders...
The resolution (which is only a few pixels higher than British SD (720x576)) is plenty for film watching. Being able to make out the individual stubble hairs on the Hollywood hero's face just doesn't improve films for me. People say that after a few minutes they can forget that they're watching a black and white film, and the same goes for SD/HD, if not more so.
I don't own a PS3, but I would get one if it had enough exclusive games that interested me. So far the few I've been looking forward to have all ended up on PC or xbox 360 as well. I wouldn't buy movies through this service, because it would be much cheaper to get the dvd delivered, and I wouldn't have to worry about my hard-disk getting full and not being able to redownload any films I delete without repurchasing them or other such nonsense.
and doubles as a telephone!
I hope they've fixed it by now, but when I first got Overlord, it wouldn't run on my pc. I was running XP x64, so I assume their DRM didn't support 64-bit Windows. Strangely enough, it worked fine after I cracked it.
Steam, on the other hand, installed an x64 version of the Source Engine, so Half-Life 2 and so on were running native 64-bit.
If Steam is the future of DRM, I like it.
If you were happy enough to not even consider returning them for over a month, they must have been pretty good fakes.
The only DOA hard-disk I have ever had was caused by a courier-related impact...
So this could be the problem "clarkkent09" is having too.
It's simple, the CSS key is stored in normally unreadable/unwritable areas of the disk, so a straight copy misses the key and it won't play. However, if you decrypt it and burn the decrypted version to a new disk, it will play fine.
Oh, and that car doesn't seem to be sold in the UK, and all the Toyota SUVs that are have handbrakes. I wonder if it's law in the UK to have a handbrake?