Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This code uses zero canvas / javascript specific functions. It is using basic trigonometric functions and is using canvas only to write RGB pixels. Canvas are much more powerful and high level than that, but this is not a good example as Notch just needed to set pixels.


Having watched Notch write Prelude of the Chambered (which I then ported to JRuby) it seems he really loves this direct pixel manipulation style - as do I!

The sad part, though, is it doesn't particularly scale well with canvas (yet) and using sprites, shape primitives, or even WebGL is way to get full speed at a regular resolution. (Imagine a 640x480 pixel field of randomized colors, you can get hundreds of FPS for that in Java without a sweat. Not so in the browser and most certainly not in JRuby.. my PotC port struggled to hit 12fps with equivalent code.)

The title of "ChamberedTest" here makes me wonder if notch is planning to use JS and canvas in the forthcoming Ludum Dare 25 (the gamedev contest where he created Prelude of the Chambered). I hope so!


For those interested, here are the first three hours of the "Prelude of the Chambered" stream.

http://www.youtube.com/watch?v=rhN35bGvM8c&t=10m05s&...


Thanks so much for this! I watched this back when ludum dare was happening, but after he moved his streaming channel to twitch.tv this part of the stream was lost.


An hopefully ad free version will soon be available here (I trimmed the first ten minutes where nothing was happenning but infringing audio):

http://www.youtube.com/watch?v=xYRBBXq3s6c&hd=1


Please disregard. Other copyrighted stuff was instantly detected.


> Having watched Notch write Prelude of the Chambered (which I then ported to JRuby) it seems he really loves this direct pixel manipulation style - as do I!

> The sad part, though, is it doesn't particularly scale well with canvas (yet) and using sprites, shape primitives, or even WebGL is way to get full speed at a regular resolution.

It doesn't just not scale well with canvas, it doesn't scale well with modern hardware. A single call to draw a textured polygon of any size is ~as expensive as the call drawing a single pixel. A call to draw a stored model with with thousands of polygons is ~as expensive as the call to draw a single polygon.

When doing pixel at a time drawing like that you are completely ignoring the specialized hardware found in the GPU, which is vastly more efficient at pushing pixels than the CPU, even in the lowest-end Intel integrated GPUs of the newest generation.

If you want to do serious graphics, you really should just get used to OpenGL/DirectX.


I agree this is not taking advantage of the GPU, but it's not making a draw call for every pixel either.

It looks to me like it's probably making a single call for each frame. Perhaps it mostly depends on how well the pixels.data[] call is implemented.


Notch gave a little more context[1]:

Spent most of today learning new stuff. Ported Minecraft4k. Code is awful due to the nature of the project, but here: http://jsdo.it/notch/dB1E

[1] https://twitter.com/notch/status/275329867984302081


Aren't the following canvas/javascript specific?

ctx = document.getElementById('game').getContext('2d');

pixels = ctx.createImageData(w, h);

ctx.putImageData(pixels, 0, 0);

EDIT: Thanks for the clarification!


Antirez meant to say that notch is using canvas as a dumb framebuffer.

He builds the raster image pixel by pixel instead of using higher level primitives (polygons).


I think the point was that this code can work in any environment where you can write to specific pixels (without magic WebGL transformation/rasterization operations or complex Canvas drawing routines).


Reminds me of when I wrote a Game of Life implementation in JavaScript in college using a bunch of tiny absolutely positioned <divs>.


That sounds...fun? ;)


I would never have thought canvas performance would be good enough for this.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: