I haven't seen that. I have seen a rotating camera of a castle spire with the Z buffer culling backwards. It looked strange as the castle seemed to be rotating the wrong way. I recall the skybox was rendered properly adding to the illusion.
Edit: I realize what I saw is a textured version of what you are describing.
I can explain why this hits a nerve for me. When I was first learning about 3D rendering (in OpenGL/DirectX) I intuitively thought about the screen space being 2D. I was wrong, and it made me confused about a lot of issues, in particular, I couldn't understand why there must be a near and far clip plane.
The 3D perspective page http://webglfundamentals.org/webgl/lessons/webgl-3d-perspect... clearly describes the rasterization phase as having 3D: the automatic perspective divide and the triangle clipping to a 3D space. Clip space being 3D seems very strange if WebGL is only a 2D API.
My suggested patch would be to rephrase it for the beginner. "WebGL is largely a 3D rasterizing API and not a fire-and-forget scene rendering solution."
If WebGL were only 2D it would be trivial to implement 3D without shaders in <canvas> -- and that is not true, canvas cannot rasterize 3D triangles.
I've experimented with adding sound to my TRS-80 emulator. It seems like the only workable solution is to use the ScriptProcessorNode callback as the sole source to timing and run the emulator from there. This will still jitter if Javascript is too slow. But if the emulator is too slow, then, there is nothing you can do except report it to the user.
The graphics are done on an ordinary timer which redraws based on the cached video state from the audio callback. JSMESS could probably do the same.
You'll always have a serious problem when there is more than one timer. If I could change the APIs, I'd add a requestAudioVideoFrame() timer callback where you would supply both the video (rendering) and the audio buffer for a given segment of time. That would also give the browser more control over the situation.
This is great news. I've been playing around with audio streams generated by script (DAC emulation) on Chrome/Safari and now I can try Firefox.
A key problem (and measure of quality) for me is reducing the latency. I've had trouble getting continuous sound with less than a quarter second of buffer. (Ideally, I'd like to achieve smooth sound with only 17ms of buffer/lag). Another browser to work with will help, and, maybe the IE team will take notice.
Certainly not legions but it is worthwhile to step into an Apple store and give your sites a try. I was surprised to find my canvas-based code breaking on the Retina MacBook Pro.
FWIW, the cause was getImageData(0, 0, w, h) returning 4wh pixels and not w*h as I naively expected.
You are definitely thinking a step ahead. Being able to compile existing programs directly would be great. If someone is successfully using those translators I'd like to see it.
Porting or re-implementing these kinds of oddball programs is a way to explore the possibilities. How fast can Javascript really run? Are the graphics APIs sufficient? Should browsers support USB joysticks? Cameras? In other words, helping to see where the straightjacket is loose. And, ideally, encouraging the browser developers to cut some of the straps.
Looks like two reasons. First to differentiate Lowe's from Home Depot which is using Motorola devices (Android?).
Second, I imagine they will use the devices as actual phones to contact the employees. No need to PA a clerk to pick up a phone. Just forward the call.
The article goes on to point out how Ford successfully disrupted the market but then lost a lot of market share later by sticking too closely to his original plan.
That's a good warning. My wife always did a quick spoon-to-her-lips check on the food temperature as precaution. Similar idea to squirting the milk on your wrist.
As always, pay attention to how the child reacts, too.
Raymond Chen recently posted about 386 B1 problems. In the end Microsoft decided not to support it. I imagine most early 386 chips just ran 16-bit MS-DOS code.
I see a lot of interesting techniques here. I couldn't figure out is how writes are prevented to code areas in the sandbox. I'd guess they mark pages with code-bundles as read-only but I don't see any specific mention of it.
(The article does mention that the guard pages are set to no read/write/execute)
I updated the page with a graph from FF4.0b9 which is a bit improved over b8. The Javascript is now respectively similar.
You're right about the 80/10 split. FF4's rendering speed is an outlier compared to Safari/Chrome/Opera on the same hardware. To better compare the faster browsers I'd need to run multiple emulators per page.
I'll update after I get my iPad upgraded. My guess is there will be little difference.
I didn't mention in the article, but I have run the emulator on the Wii's Opera browser and the PS3--both slow but the Wii is much faster. The XBOX360 hasn't heard about the WWW yet.
Agree on the bug tracker fail. The classification of bugs is way too primitive for a such a large project.
For example, when I reported a bug, I was surprised there seemed to be no (obvious) way to search/mark bugs by release. I had no way to describe a bug as "exists in stable but not in dev release" besides adding a textual commentary.
The people handling the bugs seem overwhelmed as well. A large percentage of those bugs are probably stale.
It would depend on the console. I worked on "Midway Arcade Treasures" (PS2, XBOX and GameCube) and none of the emulators in that package was based on MAME, including Spy Hunter.
You have asked an important question: how do you detect the keyboard layout (in Javascript) when using KeyUp/KeyDown events? A regular press event will provide the charCode but the press/release versions do not.