The ONLY genre not helped by a M&K is racing games,
And Robotron/Geometry-Wars style arena shooters (specifically designed for twin analogue sticks), and Pac Man (really benefits from a 4 way joystick), and Virtual On...
Thing straight. You demand analogue control over the direction you look/shoot. Why don't you also want analogue control over the direction and speed you move?
WASD as a movement controller is a shoddy compromised, based on the fact that you're using a device invented for word processing, as a games controller.
In other words, console gamers are starting to panic as game production shifts to tablets, waaah waaaah waaaah.
Not really. Casual gamers, who previously played on consoles, are happily gravitating towards phone/tablet games.
Where were you when games shifted from PCs to consoles, a vastly inferior game design and experience? Playing a FPS with a clumsy controller instead of keyboard and mouse is like building a ship in a bottle, struggling with inadequate tools to do something cool. And the lack of dozens of powers available at once. Duke Nukem can carry only 2 weapons at once?
I'm old enough to remember when home gaming was a choice between a NES/SMS, a Game-and-Watch/etc or a Spectrum/64. What would happen was that a console would come out that would vastly outperform (for gaming) similarly priced home computers, due to dedicated graphics chips. So you just couldn't do anything like SNES Mario Kart on a home computer of the time (due to SNES's Mode 7 Chip), or PS1 Ridge Racer (due to the Playstation's 3D chip), or Saturn Street Fighter (due to the Saturn's sprite hardware), etc.
PCs would catch up with the abilities of these machines, and overtake them. Then a new console would come out and the cycle would begin anew.
Nowadays PC graphics cards are in step with console graphics, so that particular cycle has ended. What we're left with is:
- people who can be bothered with the hassle of PCs (keeping Windows, drivers, AV etc. up to date) versus people who are willing to sacrifice money and freedom in exchange for ease-of-use.
- people who prefer to play games on an armchair than at a desk (so, no mouse control thanks)
I think as time goes on, those differences between PCs and consoles will wear away too. Steam seems to be working towards that.
Personally I don't particularly like FPSs, although sometimes I'll give one a go. I recognise that mouse control is more accurate, but I'd rather use a "clumsy" controller and slump in an armchair.
Graphics APIs aren't that much of a big deal, from what I understand (IANA Games Developer). It's APIs for storing/retrieving saves, player profiles, Achievements/Trophies etc. that are a big deal. Not only are there different screwy APIs for the same thing, but different platforms have different features which users expect to find supported.
Because the free market decided that selling console hardware as a loss-leader and trying to make up for it in game licenses and market share was a good business model. The problem is, it was a horrible business model and was doomed from the start.
...
The problem is, "people" want a cheap console and don't appear to be fazed by rip-off game prices. This has been proven over the years.
Don't those two statements contradict each other? As long as people want a cheap console, and don't mind paying big money for games, then selling hardware as a loss-leader is a very sound business model. It worked for at least three generations of hardware.
It may cease to work in the current climate, but I think that's because people's desires have changed, and gaming has become cheap and practical on ubiquitous general-purpose hardware. That is, people buy an iPad or an Android tablet for other reasons, and find they can buy adequate games for less than $2 a pop.
I haven't any direct contact with that kind of programmer either, because they are not relevant to my particular field of programming. But they do exist, and they're sought after in certain niches.
Niches including:
- fine-tuning the inner loops of gaming engines
- software for high speed financial transactions (where a microsecond could mean the difference between profit and loss)
From what MSFT is pulling with the Xbox One all I see is the end of console gaming.
Game prices are already out of control, $80.00 for a new release is criminal. $60.00 is borderline criminal. Couple with that the new "no used, no borrowing" stance the game companies desperately want to put in place and all I see is consoles coming to an end.
I will Tolerate no loaning and no used if the games cost $20.00 to me, but I guarantee that the next games for the new consoles will start at $100.00 for new releases.
If they go through with the "no used, no borrowing" stance, and the "fee to enable a used game" thing, then the price of new games must come down.
That $80 price point must surely reflect the fact that in many cases it's not money from one gamer but from a chain of buyers (whoever buys it new, whoever he sells it to, and so on). Prevent that chain from happening, and you must bring the new price down accordingly. Also, the people at the back of that chain are people who can't/won't pay for full price games, yet their money trickles up to games retailers through the used game chain. If they want to get those people's money through a different route, they'll have to get them with earlier budget releases.
So, a sensible route, perhaps - $40-$50 for a brand new release (similar to the "$80, sell it later for $30" someone might bank on today). Price drops to $30-40 6 months later when the first surge of demand dies down.
I'll be really interested to see if that's what they actually do. Keeping prices high while simultaneously killing the used market, seems like commercial suicide, but they might do it anyway.
- these are concerns for a handful of engine developers
- that PS4 and Xbox One both have the same CPU family, doesn't mean there won't be other architectural foibles the more bit-twiddly developers can exploit. Even differences in the various levels of CPU cache are interesting to those guys.
The point has been made before, that even direct ASM programming isn't writing "to the metal" any more; all the branch prediction (etc.) that's actually happening on the metal is abstracted away from the ASM programmer's control. The really hardcore optimising programmer has to target those CPU features without having direct control over them... in the same way as an optimising C programmer has half an eye on what he imagines the resulting ASM will look like. Even a Java programmer can use their understanding of CPU architecture and code in such a way as to minimise CPU cache misses.
Well, I fail to see difference between console and PC in case of steam
The fact that it will Just Work. On a Steambox, if the game is available, you should expect that it works, and works well: no slowdowns, freezes or graphical glitches.
On an arbitrary PC, or one you've built yourself, you'll need to check the recommended requirements for every game, apply some reasoning, to decide whether it'll work on your system.
For example, I got the game "Closure" as part of a Humble Bundle. the requirements for which state "512MB with support for OpenGL 2.0, older or integrated cards may not work". As it turns out, for my integrated graphics, "may not work" == "does not work".
The Steambox user doesn't need to know what a graphics card is. Assuming it's done properly, the only games available to buy will be games that definitely work on the platform.
It's probably not a coincidence that the PS4 and Xbox One are both running x86 chips inside them. Aside from a few choice bits, developing on each machine should be incredibly similar to the point where it's just a different API for either.
The faster CPUs get, and the better optimising compilers get, the less likely anyone is to code directly in assembly. I think APIs are probably much more significant to games developers than the underlying chips.
Terrorism is the act of publicising your cause by making people afraid to go about their normal lives.
The whole point of the IRA bombing shopping centres, hotels and pubs was that it would impact how people lived, and keep the Irish Republican cause in the news. "Shall we go for a booze-up in Birmingham this weekend?" "Oh, hmm, bit worried about getting killed by a bomb."
These guys committed their murder in broad daylight, then waited around for the cameraphones to come out. Then did what appears to be a rehearsed speech, outlining their grievance, and then saying (approximately) "What are you going to do when we come out with our guns? None of you is safe. Next time it will be you, or your children."
They want us to believe (I don't) that there's an army of people like them, who will follow up with more attacks like this. That is specifically designed to terrify, and that's what terrorism is.
It's an implementation detail as to whether you use a different pad in each direction, though I don't really know why you would do.
The principle is well understood -- if you both know a secret list of numbers that's as long as your plaintext, you can exchange messages confidentially.
The challenge, which these guys claim to address, is how to get to the point where you both have the secret list of numbers, and can be confident that nobody else has it.
Once you have that confidence, I don't see why you wouldn't use the same pad in both directions. In fact it's equivalent (since the numbers are random, having one list of length 2x is equivalent to having two lists of length x).
No, but once you've used a chunk of randomness, you don't reuse it, and eventually the glass plate is "finished".
TFA:
... it ought to be possible to generate a terabit of randomness from a single cubic millimetre of diffusing glass with higher-resolution equipment.
And even thought this can only be used once, the slabs can be easily reset by heating the glass to change its microstructure at which point Alice and Bob must meet again to create a new set of combined keys.
On some device when the two glass owners meet: pad = generateRandomBytes(many GB) combinedKey = encodeToCombinedKey(pad, glass1, glass2) publishToInternet(combinedKey)// shared key i
Later, to send a message: chunkOfPad = decryptSharedKey("http://repository/combinedKeyId", glassAlice) cipherText = xor(plaintext,chunkOfPad)
To decode: chunkOfPad = decryptSharedKey("http://repository/combinedKeyId", glassBob) plaintext = xor(ciphertext,chunkOfPad)
There may be some novelty in the way the combinedKey is constructed (probably not). The main novelty is in the properties of the glass (hence this being in an optics journal, not a cryptography journal).
The "one time" in "one time pad" means you never use a piece of key twice. The OTP needs to be as long (or longer than) the plaintext, and when you've used up your OTP, you need to get together and share a new one.
You can make an OTP last longer by compressing before encrypting, or by using OTP encyption to exchange temporary keys, to be used with other encryption methods.
Clearly you *could* re-use your OTP, perhaps starting from the beginning when you run out of bytes. But each time you do that you weaken your security.
In what way guarding a block of glass different from guarding a telephone book?
You can trivially borrow a telephone book, copy what you need, then return it without the owner noticing.
TFA:
And even if Eve steals the glass, they estimate that it would take her at least 24 hours to extract any relevant information about its structure.
This extraction can only be done by passing light through the glass at a rate that is limited by the amount of heat this creates (since any heating changes the microstructure of the material). And the time this takes should give the owners enough time to realise what has happened and take the necessary mitigating actions.
... and their abstract...
Benefits of volumetric physical storage over electronic memory include the inability to probe, duplicate or selectively reset any random bits without fundamentally altering the entire key space
Easiest one time pads are to get two copies of the same yellow pages. The caller specifies a page number. The receiver turns to that page. Ignore all alphabets and collect all the phone numbers write them down in sequence. You got a one time pad.
"Easiest", but not unbreakably secure in the manner of a truly random OTP.
No, the two devices don't match. Each device contains a different several GB of random numbers (or I suppose, random transformations), encapsulated in the structure of the glass.
The two owners meet, and using both their devices, produce a "combined key". The combined key can be stored in a public repository. The shared OTP can be extracted from the combined key using either device.
The two parties exchange confidential data encrypted with bytes from the OTP until the OTP is all consumed. Then they must meet up again to create a new OTP.
There's nothing novel about the cryptography. What might be novel is the physical properties of the device used to allow someone to carry their personal list of random numbers around.
Slashdot Mirror
The ONLY genre not helped by a M&K is racing games,
And Robotron/Geometry-Wars style arena shooters (specifically designed for twin analogue sticks), and Pac Man (really benefits from a 4 way joystick), and Virtual On...
da fuq?
ANaloge stick stil lsucks compared to a keyboard.
Thing straight. You demand analogue control over the direction you look/shoot. Why don't you also want analogue control over the direction and speed you move?
WASD as a movement controller is a shoddy compromised, based on the fact that you're using a device invented for word processing, as a games controller.
In other words, console gamers are starting to panic as game production shifts to tablets, waaah waaaah waaaah.
Not really. Casual gamers, who previously played on consoles, are happily gravitating towards phone/tablet games.
Where were you when games shifted from PCs to consoles, a vastly inferior game design and experience? Playing a FPS with a clumsy controller instead of keyboard and mouse is like building a ship in a bottle, struggling with inadequate tools to do something cool. And the lack of dozens of powers available at once. Duke Nukem can carry only 2 weapons at once?
I'm old enough to remember when home gaming was a choice between a NES/SMS, a Game-and-Watch/etc or a Spectrum/64. What would happen was that a console would come out that would vastly outperform (for gaming) similarly priced home computers, due to dedicated graphics chips. So you just couldn't do anything like SNES Mario Kart on a home computer of the time (due to SNES's Mode 7 Chip), or PS1 Ridge Racer (due to the Playstation's 3D chip), or Saturn Street Fighter (due to the Saturn's sprite hardware), etc.
PCs would catch up with the abilities of these machines, and overtake them. Then a new console would come out and the cycle would begin anew.
Nowadays PC graphics cards are in step with console graphics, so that particular cycle has ended. What we're left with is:
- people who can be bothered with the hassle of PCs (keeping Windows, drivers, AV etc. up to date) versus people who are willing to sacrifice money and freedom in exchange for ease-of-use.
- people who prefer to play games on an armchair than at a desk (so, no mouse control thanks)
I think as time goes on, those differences between PCs and consoles will wear away too. Steam seems to be working towards that.
Personally I don't particularly like FPSs, although sometimes I'll give one a go. I recognise that mouse control is more accurate, but I'd rather use a "clumsy" controller and slump in an armchair.
Graphics APIs aren't that much of a big deal, from what I understand (IANA Games Developer). It's APIs for storing/retrieving saves, player profiles, Achievements/Trophies etc. that are a big deal. Not only are there different screwy APIs for the same thing, but different platforms have different features which users expect to find supported.
It's called an "interest only mortgage".
... which leads us to an ideal FPS setup of a mouse under the right hand, and an analogue stick under the left thumb.
However, personally I prefer to do my gaming slumped on an armchair - so a mouse isn't practical. And I prefer my games not to be FPSs.
XBone marketing has barely started. There's been one press conference about PVR / social media / blah. There's been stuff about CoD. And that's it.
Of course there will be games. Lots of them. Whether they're games worth buying an expensive new system for, we'll have to wait and see.
Because the free market decided that selling console hardware as a loss-leader and trying to make up for it in game licenses and market share was a good business model. The problem is, it was a horrible business model and was doomed from the start.
...
The problem is, "people" want a cheap console and don't appear to be fazed by rip-off game prices. This has been proven over the years.
Don't those two statements contradict each other? As long as people want a cheap console, and don't mind paying big money for games, then selling hardware as a loss-leader is a very sound business model. It worked for at least three generations of hardware.
It may cease to work in the current climate, but I think that's because people's desires have changed, and gaming has become cheap and practical on ubiquitous general-purpose hardware. That is, people buy an iPad or an Android tablet for other reasons, and find they can buy adequate games for less than $2 a pop.
I haven't any direct contact with that kind of programmer either, because they are not relevant to my particular field of programming. But they do exist, and they're sought after in certain niches.
Niches including:
- fine-tuning the inner loops of gaming engines
- software for high speed financial transactions (where a microsecond could mean the difference between profit and loss)
From what MSFT is pulling with the Xbox One all I see is the end of console gaming.
Game prices are already out of control, $80.00 for a new release is criminal. $60.00 is borderline criminal. Couple with that the new "no used, no borrowing" stance the game companies desperately want to put in place and all I see is consoles coming to an end.
I will Tolerate no loaning and no used if the games cost $20.00 to me, but I guarantee that the next games for the new consoles will start at $100.00 for new releases.
If they go through with the "no used, no borrowing" stance, and the "fee to enable a used game" thing, then the price of new games must come down.
That $80 price point must surely reflect the fact that in many cases it's not money from one gamer but from a chain of buyers (whoever buys it new, whoever he sells it to, and so on). Prevent that chain from happening, and you must bring the new price down accordingly. Also, the people at the back of that chain are people who can't/won't pay for full price games, yet their money trickles up to games retailers through the used game chain. If they want to get those people's money through a different route, they'll have to get them with earlier budget releases.
So, a sensible route, perhaps - $40-$50 for a brand new release (similar to the "$80, sell it later for $30" someone might bank on today). Price drops to $30-40 6 months later when the first surge of demand dies down.
I'll be really interested to see if that's what they actually do. Keeping prices high while simultaneously killing the used market, seems like commercial suicide, but they might do it anyway.
Yes absolutely. But
- these are concerns for a handful of engine developers
- that PS4 and Xbox One both have the same CPU family, doesn't mean there won't be other architectural foibles the more bit-twiddly developers can exploit. Even differences in the various levels of CPU cache are interesting to those guys.
The point has been made before, that even direct ASM programming isn't writing "to the metal" any more; all the branch prediction (etc.) that's actually happening on the metal is abstracted away from the ASM programmer's control. The really hardcore optimising programmer has to target those CPU features without having direct control over them... in the same way as an optimising C programmer has half an eye on what he imagines the resulting ASM will look like. Even a Java programmer can use their understanding of CPU architecture and code in such a way as to minimise CPU cache misses.
Well, I fail to see difference between console and PC in case of steam
The fact that it will Just Work. On a Steambox, if the game is available, you should expect that it works, and works well: no slowdowns, freezes or graphical glitches.
On an arbitrary PC, or one you've built yourself, you'll need to check the recommended requirements for every game, apply some reasoning, to decide whether it'll work on your system.
For example, I got the game "Closure" as part of a Humble Bundle. the requirements for which state "512MB with support for OpenGL 2.0, older or integrated cards may not work". As it turns out, for my integrated graphics, "may not work" == "does not work".
The Steambox user doesn't need to know what a graphics card is. Assuming it's done properly, the only games available to buy will be games that definitely work on the platform.
It's probably not a coincidence that the PS4 and Xbox One are both running x86 chips inside them. Aside from a few choice bits, developing on each machine should be incredibly similar to the point where it's just a different API for either.
The faster CPUs get, and the better optimising compilers get, the less likely anyone is to code directly in assembly. I think APIs are probably much more significant to games developers than the underlying chips.
It must be at least read-twice. Once to jointly encrypt the "common key", which contains the pad, and once retrieve the pad from the common key.
Sure, never use the same byte twice.
But, using the same pad in both directions:
> Hello Alice -- encrypts with pad[0..11] ... and so on.
< Hello Bob -- encrypts with pad[12..21]
Using two pads: ... and so on.
> Hello Alice -- encrypts with pad[0][0..11]
< Hello Bob -- encrypts with pad[1][0.9]
Equivalent, in terms of the randomness, the one-time-ness of the numbers, and the necessity that both sides have access to all the pads.
I am not a cryptographer, but I *think* it would not harm the strength of the encryption if you compress then encrypt.
In theory, it should actually make it stronger, by removing redundancy. ...
it can be a bad idea to begin each message with something predictable.
Both completely irrelevant if you're encrypting with a OTP.
No, it's terrorism.
Terrorism is the act of publicising your cause by making people afraid to go about their normal lives.
The whole point of the IRA bombing shopping centres, hotels and pubs was that it would impact how people lived, and keep the Irish Republican cause in the news. "Shall we go for a booze-up in Birmingham this weekend?" "Oh, hmm, bit worried about getting killed by a bomb."
These guys committed their murder in broad daylight, then waited around for the cameraphones to come out. Then did what appears to be a rehearsed speech, outlining their grievance, and then saying (approximately) "What are you going to do when we come out with our guns? None of you is safe. Next time it will be you, or your children."
They want us to believe (I don't) that there's an army of people like them, who will follow up with more attacks like this. That is specifically designed to terrify, and that's what terrorism is.
It's an implementation detail as to whether you use a different pad in each direction, though I don't really know why you would do.
The principle is well understood -- if you both know a secret list of numbers that's as long as your plaintext, you can exchange messages confidentially.
The challenge, which these guys claim to address, is how to get to the point where you both have the secret list of numbers, and can be confident that nobody else has it.
Once you have that confidence, I don't see why you wouldn't use the same pad in both directions. In fact it's equivalent (since the numbers are random, having one list of length 2x is equivalent to having two lists of length x).
I don't think we share a vocabulary on this topic. None of that made sense.
I am not a cryptographer, but I *think* it would not harm the strength of the encryption if you compress then encrypt.
You could also use the OTP as a source of symmetric keys for AES, moving to a new one regularly, as SSL does.
Do they change the glass plate after every use?
No, but once you've used a chunk of randomness, you don't reuse it, and eventually the glass plate is "finished".
TFA:
... it ought to be possible to generate a terabit of randomness from a single cubic millimetre of diffusing glass with higher-resolution equipment.
And even thought this can only be used once, the slabs can be easily reset by heating the glass to change its microstructure at which point Alice and Bob must meet again to create a new set of combined keys.
On some device when the two glass owners meet:
// shared key i
pad = generateRandomBytes(many GB)
combinedKey = encodeToCombinedKey(pad, glass1, glass2)
publishToInternet(combinedKey)
Later, to send a message:
chunkOfPad = decryptSharedKey("http://repository/combinedKeyId", glassAlice)
cipherText = xor(plaintext,chunkOfPad)
To decode:
chunkOfPad = decryptSharedKey("http://repository/combinedKeyId", glassBob)
plaintext = xor(ciphertext,chunkOfPad)
There may be some novelty in the way the combinedKey is constructed (probably not).
The main novelty is in the properties of the glass (hence this being in an optics journal, not a cryptography journal).
You are wrong.
The "one time" in "one time pad" means you never use a piece of key twice. The OTP needs to be as long (or longer than) the plaintext, and when you've used up your OTP, you need to get together and share a new one.
You can make an OTP last longer by compressing before encrypting, or by using OTP encyption to exchange temporary keys, to be used with other encryption methods.
Clearly you *could* re-use your OTP, perhaps starting from the beginning when you run out of bytes. But each time you do that you weaken your security.
In what way guarding a block of glass different from guarding a telephone book?
You can trivially borrow a telephone book, copy what you need, then return it without the owner noticing.
TFA:
And even if Eve steals the glass, they estimate that it would take her at least 24 hours to extract any relevant information about its structure.
This extraction can only be done by passing light through the glass at a rate that is limited by the amount of heat this creates (since any heating changes the microstructure of the material). And the time this takes should give the owners enough time to realise what has happened and take the necessary mitigating actions.
... and their abstract...
Benefits of volumetric physical storage over electronic memory include the inability to probe, duplicate or selectively reset any random bits without fundamentally altering the entire key space
Easiest one time pads are to get two copies of the same yellow pages. The caller specifies a page number. The receiver turns to that page. Ignore all alphabets and collect all the phone numbers write them down in sequence. You got a one time pad.
"Easiest", but not unbreakably secure in the manner of a truly random OTP.
No, the two devices don't match. Each device contains a different several GB of random numbers (or I suppose, random transformations), encapsulated in the structure of the glass.
The two owners meet, and using both their devices, produce a "combined key". The combined key can be stored in a public repository. The shared OTP can be extracted from the combined key using either device.
The two parties exchange confidential data encrypted with bytes from the OTP until the OTP is all consumed. Then they must meet up again to create a new OTP.
There's nothing novel about the cryptography. What might be novel is the physical properties of the device used to allow someone to carry their personal list of random numbers around.