HN user

pnp

239 karma
Posts15
Comments22
View on HN
WebGL Fundamentals 11 years ago

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.

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.

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.

EDIT: b9 improved over 8, not itself.

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.

I recall a related fact from simple statistical mechanics: the volume of high-dimensional sphere is concentrated almost exclusively near its surface. This fact allowed some nasty calculation of volume in state space to be approximated by the area of the hypersphere.

IIRC, the basic notion is that volume is like r^n and area like n * r^(n-1). Quite different when n = 2, 3, ... and not so much at n = 10^23. I never thought of them as spikey but I get the picture now.