24fps is often terrible for fast motion. But I would think the thing you like about 24fps (the motion blur), can be done with 48fps (where the blur is carried out over 2 frames instead of 1 as before, to allow for the same amount of blurring time overall), so you have the nice smooth 48fps frame rate and the 'strange/unreal/cool' motion blur effect. Everyone's happy.
I'm glad that film-makers are finally beginning to realize the video world doesn't start and end at 24fps. That particular limit is pretty arbitrary and terrible for fast/smooth motion where higher frame rates are needed. Real life (TM) is actually infinite FPS of course, so things will only be more realistic, not less.
Maybe we can all switch to a standard like 60fps, 120fps or or even better 240fps, and our monitors can adjust too. We'd cure flicker or blurry motion (CRT/LCD respectively), general motion smoothness, and even sometimes input lag, all in one sweep. Finally we'd all have a universal framerate which everything can adhere to.
Oh yeah, obviously you'd need some heavy duty gloves, or you could wrap round your shirt/jacket round the pole for the equivalent effect and squeeze real hard. Not unreasonable if you have minutes to decide what to do. Someone said in that thread that the pole could scrunch up, and that could act as the decelerating force instead.
If the pole was inventive enough, it could have some outer holding device you'd hold onto which could move down the pole, but only with considerable force. Parachutes are good, but you need to reset them after each landing obviously, and they also slow you down if you need to get to the ground quicker. They can also get tangled in mid-flight etc. Yes, the way I'm speaking, you'd think the gravity we have was closer to the moon's. Still...;)
Thanks for the links, I'll check those out. OOI, was the 1/1000 ratio for the "survival" rate or for the "survive AND walk away" rate (and what's the other value very roughly)? I know it's all very much guesswork, but even an "off-by-an-order-of-magnitude" margin-of-error would still prove interesting:)
A while back, I wrote about surviving such a fall by carrying a 3-5 metre pole, maybe made of carbon-fibre or stronger. Not something you're likely to have on you, but in theory, and with a lot of skill and practise, one could use it all the time to save oneself. You would clench the pole as the pole hits the ground to allow for a massive (but less so than concrete!) deceleration at the last moment, as you slid down the pole. See this thread for details, and let me know what you think if you like: http://www.physicsforums.com/showthread.php?t=314044
Wonderful post. I've never seen a place which collates so much info all together like that. My knowledge on even terminal velocity impact with water was sketchy (I think I searched a while back for ages and came to no definite conclusion), but what you've said makes a lot of sense. I wonder if there's ever been a recording of someone falling at terminal velocity and surviving.
Can you give me the rough survival rate as a percentage of those who hit the ground at terminal velocity?
Also can you give me the rough percentage of those who can just "walk away" (must be really low like 0.001%, but I'd be interested).
Unfortunately, that's an over-simplification, because there's a third category, where something can be true or false, and yet potentially not testable at all.
Yes, I use the CLI all the time to do things in complex editors such as Photoshop and Renoise. It's clearly the best way of doing things, so I set up a giant communication scheme between the CLI and the programs. Took me a while, but everything I draw or compose is now from typing text into the CLI.
Summary is exaggerating. Google are not calling software patents 'junk'. They want "patent reform", as the current system is broken, but that's not quite the same thing is it.
This below paragraph quoted from their previous entry summarizes their position much better and is also interesting in and of itself, because it seems like a big factor of exactly HOW the software patent system is so brain-deadingly broken:
The most pressing of those is ensuring fair damage awards. The current system too easily allows damages to be assessed based on the value of the whole product often containing many features — not just the value of the innovation of the allegedly infringed patent — which means the threat of potentially massive awards forces defendants to settle. Balance should be restored by requiring damages to be based on the value of the innovation's contribution to the product.
Okay, going against the flow a bit, I think that those people who take the time, effort, money and energy to create complicated software algorithms should be rewarded. Surely, the potential compensation is partially what motivated them to create it in the first place (as would be the case with in-house company research anyway).
Granted, really stupid, short patents should be given a miss entirely, though thankfully, often there's prior art to the rescue to invalidate those.
And it should also be a lot easier to use another company's patent easily and cheaply when appropriate. But they still deserve something, no matter how small.
Or alternatively: "Before pointing fingers, properly research first", which is terser, less pretentious, and made in 20 seconds by yours truly. Also it has the advantage that it doesn't come from a book with lots of false information.
A rolled up laptop essentially decreases a dimension of space you need to worry about. Therefore it'll take up less space and/or allow for larger screens.
Since the material is flexible, it's also less likely to break when dropped etc.
When it's uncurled it should be as flat to read as a normal laptop if the implementation is decent.
There is no such thing as an universally simpler and better language
You see, that attitude is when we give up and stop trying to improve languages. There are loads of cases where you can improve stuff, and unify two approaches into one which is fast, consistent and terse. If C# is more cumbersome, then perhaps there's a way to make it less so while keeping flexibility and power.
Have you looked at D? For all its drawbacks, that surely seems to combine the advantages of C and C++ without many of the drawbacks of both of those.
Which is why language features should always be unified as much as possible to reduce the bloat. I always find it dumb the way many say: "you can do it this way, or that way, or the other way - such-and-such language gives you the choice - how wonderful!" without considering that there might be a way which takes the best of each of the approaches, and unifies them into one consistent approach.
Similar story to the way many open source projects get forked (which can be okay for experimentation purposes in the short term), and never reunify again later. It's a shame.
Because even for the best developers, super-large projects would be a nightmare to code in assembler. Therefore, you'd get a juicy speed increase indeed, but the human mind isn't yet *that* good.
Slashdot Mirror
They won't go crazy because they can cut out every other frame for their jerkier experience.
I've heard how many can tell the difference between 100 and say, 160fps on CRT monitors. Do you have a reference?
I bet if you saw a very fast motion scene, you'd be able to tell the difference between 100 and 200fps, and even between 200 and 500fps.
I've heard just once in my life that about 500fps is the true perceptible limit. I think that figure is more realistic.
24fps is often terrible for fast motion. But I would think the thing you like about 24fps (the motion blur), can be done with 48fps (where the blur is carried out over 2 frames instead of 1 as before, to allow for the same amount of blurring time overall), so you have the nice smooth 48fps frame rate and the 'strange/unreal/cool' motion blur effect. Everyone's happy.
I'm glad that film-makers are finally beginning to realize the video world doesn't start and end at 24fps. That particular limit is pretty arbitrary and terrible for fast/smooth motion where higher frame rates are needed. Real life (TM) is actually infinite FPS of course, so things will only be more realistic, not less.
Maybe we can all switch to a standard like 60fps, 120fps or or even better 240fps, and our monitors can adjust too. We'd cure flicker or blurry motion (CRT/LCD respectively), general motion smoothness, and even sometimes input lag, all in one sweep. Finally we'd all have a universal framerate which everything can adhere to.
Oh yeah, obviously you'd need some heavy duty gloves, or you could wrap round your shirt/jacket round the pole for the equivalent effect and squeeze real hard. Not unreasonable if you have minutes to decide what to do. Someone said in that thread that the pole could scrunch up, and that could act as the decelerating force instead.
If the pole was inventive enough, it could have some outer holding device you'd hold onto which could move down the pole, but only with considerable force. Parachutes are good, but you need to reset them after each landing obviously, and they also slow you down if you need to get to the ground quicker. They can also get tangled in mid-flight etc. Yes, the way I'm speaking, you'd think the gravity we have was closer to the moon's. Still... ;)
Thanks for the links, I'll check those out. OOI, was the 1/1000 ratio for the "survival" rate or for the "survive AND walk away" rate (and what's the other value very roughly)? I know it's all very much guesswork, but even an "off-by-an-order-of-magnitude" margin-of-error would still prove interesting :)
A while back, I wrote about surviving such a fall by carrying a 3-5 metre pole, maybe made of carbon-fibre or stronger. Not something you're likely to have on you, but in theory, and with a lot of skill and practise, one could use it all the time to save oneself. You would clench the pole as the pole hits the ground to allow for a massive (but less so than concrete!) deceleration at the last moment, as you slid down the pole. See this thread for details, and let me know what you think if you like: http://www.physicsforums.com/showthread.php?t=314044
Oh heck, yeah that makes sense - sorry. Ignore my dumb throwaway comment.
Well said - it's just semantics in the end.
Wonderful post. I've never seen a place which collates so much info all together like that. My knowledge on even terminal velocity impact with water was sketchy (I think I searched a while back for ages and came to no definite conclusion), but what you've said makes a lot of sense. I wonder if there's ever been a recording of someone falling at terminal velocity and surviving.
Can you give me the rough survival rate as a percentage of those who hit the ground at terminal velocity?
Also can you give me the rough percentage of those who can just "walk away" (must be really low like 0.001%, but I'd be interested).
My germs!
My precious germs!
They never harmed a soul!
They never had the chance!
Unfortunately, that's an over-simplification, because there's a third category, where something can be true or false, and yet potentially not testable at all.
Exactly. Mine starts with "C:\Users\Dan>" upon opening, and I suspect yours starts with something similar.
Well that's programming/scripting then, not the CLI per se.
Yes, I use the CLI all the time to do things in complex editors such as Photoshop and Renoise. It's clearly the best way of doing things, so I set up a giant communication scheme between the CLI and the programs. Took me a while, but everything I draw or compose is now from typing text into the CLI.
I agree with other replier.
Modders, please mod parent up.
In that case, replace the word 'people' in my first sentence with 'companies'.
Summary is exaggerating. Google are not calling software patents 'junk'. They want "patent reform", as the current system is broken, but that's not quite the same thing is it.
This below paragraph quoted from their previous entry summarizes their position much better and is also interesting in and of itself, because it seems like a big factor of exactly HOW the software patent system is so brain-deadingly broken:
The most pressing of those is ensuring fair damage awards. The current system too easily allows damages to be assessed based on the value of the whole product often containing many features — not just the value of the innovation of the allegedly infringed patent — which means the threat of potentially massive awards forces defendants to settle. Balance should be restored by requiring damages to be based on the value of the innovation's contribution to the product.
Okay, going against the flow a bit, I think that those people who take the time, effort, money and energy to create complicated software algorithms should be rewarded. Surely, the potential compensation is partially what motivated them to create it in the first place (as would be the case with in-house company research anyway).
Granted, really stupid, short patents should be given a miss entirely, though thankfully, often there's prior art to the rescue to invalidate those.
And it should also be a lot easier to use another company's patent easily and cheaply when appropriate. But they still deserve something, no matter how small.
Or alternatively: "Before pointing fingers, properly research first", which is terser, less pretentious, and made in 20 seconds by yours truly. Also it has the advantage that it doesn't come from a book with lots of false information.
A rolled up laptop essentially decreases a dimension of space you need to worry about. Therefore it'll take up less space and/or allow for larger screens.
Since the material is flexible, it's also less likely to break when dropped etc.
When it's uncurled it should be as flat to read as a normal laptop if the implementation is decent.
Just look on Amazon (or something like it), and find the one with the highest stars - that's what I did.
There is no such thing as an universally simpler and better language
You see, that attitude is when we give up and stop trying to improve languages. There are loads of cases where you can improve stuff, and unify two approaches into one which is fast, consistent and terse. If C# is more cumbersome, then perhaps there's a way to make it less so while keeping flexibility and power.
Have you looked at D? For all its drawbacks, that surely seems to combine the advantages of C and C++ without many of the drawbacks of both of those.
Which is why language features should always be unified as much as possible to reduce the bloat. I always find it dumb the way many say: "you can do it this way, or that way, or the other way - such-and-such language gives you the choice - how wonderful!" without considering that there might be a way which takes the best of each of the approaches, and unifies them into one consistent approach.
Similar story to the way many open source projects get forked (which can be okay for experimentation purposes in the short term), and never reunify again later. It's a shame.
Because even for the best developers, super-large projects would be a nightmare to code in assembler. Therefore, you'd get a juicy speed increase indeed, but the human mind isn't yet *that* good.
You can always use "unsafe", and there's even a way you can imitate malloc, so you can manage your own memory.
http://www.codeproject.com/KB/cs/UnmanagedArraysInCSharp.aspx
So you can get most of the speed advantage of C/C++ if you really want, and otherwise use safer, more convenient C sharpy stuff.
What do you think?