my only issue with this has to do with the occasional lapse in recognition of the touch ID. if it can't read your fingerprint several times, it asks for your password code. touch ID is of course not theft-proof, but initially it's a slightly greater obstacle than a simple numeric code.
I would guess 0. My understanding is that you are rendering at the full higher resolution then simply computing the proper subpixels on the offset displays to align them right. You still need all the data there using the full amount of memory otherwise you can't really perform the calculations necessary for the subpixel/temporal interpolation.
Wouldn't that be too taxing on battery life? I'd rather have WebGL used for 3D games or visualizations where I at least know the impact beforehand rather than like flash or as a CSS animation alternative.
That's a good point. I've never compared the battery usage. But you don't have to make everything 3D (I think). I think you can use WebGL in a 2D context and the battery impact is probably less significant.
Mostly, I just want to avoid learning each mobile platform just to make one app. That's been turning me off from mobile development for years. I'd rather use something like Cordova with webgl and hit all mobile platforms in one shot.
I've never heard of "WebGL in a 2D context". WebGL is WebGL is WebGL - it's a WebGL context. Whether or not you decide to feed it drawing commands that will end up looking like a 3d object or like a 2d sprite is up to you.
I was thinking of a 2d canvas context. Basically, I would expect battery consumption to be lower when WebGl is rendering 2d than it would be if it were rendering 3d. It just seems intuitive that 3d requires more computation. But I really don't know. I've never seen any battery usage comparisons.
the browser may be able to optimize the 2D canvas operations by using the GPU more efficiently, but drawing with the webgl stack is going to suck the same amount of battery whether doing 2D or 3D. After all, 3D is really just correctly positioned 2D triangles.
It would be interesting to see what the impact would be in a more limited context as you suggest. Also, having it as part of a toolkit would lessen the burden and allow for continuous optimization. Exciting times!
I nod my head in agreement with most of these OpenGL are broken articles. I've work on the OpenGL version of Call of Duty, Civilization, and more for the Mac. I think Timothy misses the real point on driver quality.
I would love to see this with a giant screen. The iPad is great but kids needs space and room to play. Great start and I really feel that things like this will have a great impact in the future.
I'm sure this would be fun on a giant screen, but it's not necessary. Kids play with tablets and phones all the time. Large screens are not a prerequisite for enjoyable playtime.
Where has this been all these years? No idea if this project works (depends on a local Mac so that ruins it for me), but it kills me that we can AirPlay to TV's and run high resolution with bluetooth keyboard/mouse hookup and still we can't develop on our iPhone/iPad?
That's what you get when using a platform that's not developer, but app store customer friendly. Without breaking into your own device you can't do much with it, so it's hardly a surprise.
Syntax is hard to read and easy to make mistakes in considering how it overloads every letter of the alphabet as a command, but the extreme speed pays off I think.
K is only hard if you try to read it without first studying it. Looping is achieved through adverbs. The key to it is understanding what is a noun (data), verb (operator/function) and adverb (takes a verb, creates a new verb to be used infix). A verb with a noun to its right is a dyad if there is also a noun to its left, and is otherwise a monad. If it is needed, the monad can be specified by appending a colon to the right of the symbol. Fortunately, most kdb+ developers program in Q, which has a bunch of helper routines defined in k, and assigns monads to names such as neg x instead of -:x.
It's the same thing I said in the recent J discussion: J (and probably Q) is meant to be read with a help of computer. Reading and writing J consists of incrementally building/decomposing expressions in a REPL. You have wonderful tools to visualize expressions structure in the REPL and you are expected to use them and to experiment with the expressions. You're not supposed to read it as prose, don't even try.
There is also an sql like interface in addition to the Q and K languages.
This is probably easier to get started than diving into Q if that is too daunting.
You're incorrect. No individual letters of the alphabet are commands. Every symbol on the keyboard however is an operator (excluding semicolon, braces, brackets, and parens, which operate as line/expression terminators, function definitions, function invocation/array access, and list definitions, respectively).
