pnp
Joined 16 years ago
Karma
239
Submissions
37
Member since
Sep 15
Recent submissions
Comment · 1 year ago
Correct, I recall the stock ticker symbol was renamed to JAVA, but not the company.
Comment · 10 years ago
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.
Comment · 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.
Comment · 12 years ago
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.
Comment · 13 years ago
There was a browser written in Java in the past:
Comment · 13 years ago
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.