Live data from Hacker News

Notch trying jsFiddle

jsfiddle.net

11–20 of 143 posts

Re: Notch trying jsFiddle

#11
post #6

Awesome implementation, actually no advanced feature is used, this code could easily ported even to assembler in any device where you can set pixels in RGB format. And indeed it is pretty impressive how fast the rendering happens given that the code operates at such lower level... Even selecting the color of every pixel requires non trivial work in the inner loop. AWESOME code.

I totally agree. You probably meant "code operates at such a _high_ level" :)

low level = close to hardware, high level = high abstraction, like JS

Re: Notch trying jsFiddle

#12
This would be a great demo to see running in a responsive programming environment, ala Bret Victor's amazing Inventing on Principle talk (http://vimeo.com/36579366). I want to be able to click on hex values and get a color picker that updates the demo in realtime, and be able to click on various magic numbers and drag a slider to change them.

Incidentally, Bret Victor's talk was the starting point for Khan Academy's CS curriculum that John Resign led (http://ejohn.org/blog/introducing-khan-cs/).

Edit: I managed to get this running in livecoding.io, which does some of what Bret Victor was talking about (basic sliders and color pickers): http://livecoding.io/4191583. Not sure why it's running so much slower though...

Re: Notch trying jsFiddle

#13

Correct me if I'm wrong but does this procedurally generate the textures for each block. I can't see any code for loading assets and the init function, has some quite complicated color code. If so that is awesome!

[deleted]

Re: Notch trying jsFiddle

#14

Correct me if I'm wrong but does this procedurally generate the textures for each block. I can't see any code for loading assets and the init function, has some quite complicated color code. If so that is awesome!

Yes, the procedure generates the texture of every "type" of block, the first loops after the init() function. 16 different types of blocks are generated.

Then a random map is created, with the "center" that is set to empty blocks with high probability. Finally a function traces the map on the screen at every tick of the clock.

Re: Notch trying jsFiddle

#15
post #14

Correct me if I'm wrong but does this procedurally generate the textures for each block. I can't see any code for loading assets and the init function, has some quite complicated color code. If so that is awesome!

Yes, the procedure generates the texture of every "type" of block, the first loops after the init() function. 16 different types of blocks are generated. Then a random map is created, with the "center" that is set to empty blocks with high probability. Finally a function traces the map on the screen at every tick of the clock.

Ok, that's pretty cool :P

Re: Notch trying jsFiddle

#16
post #11
post #6

Awesome implementation, actually no advanced feature is used, this code could easily ported even to assembler in any device where you can set pixels in RGB format. And indeed it is pretty impressive how fast the rendering happens given that the code operates at such lower level... Even selecting the color of every pixel requires non trivial work in the inner loop. AWESOME code.

I totally agree. You probably meant "code operates at such a _high_ level" :) low level = close to hardware, high level = high abstraction, like JS

No I really mean low level :-)

Javascript is high level, but here notch is using it as a low level framebuffer.

Re: Notch trying jsFiddle

#17
post #16
post #11

Earlier quoted context omitted.

I totally agree. You probably meant "code operates at such a _high_ level" :) low level = close to hardware, high level = high abstraction, like JS

No I really mean low level :-) Javascript is high level, but here notch is using it as a low level framebuffer.

Ah ok, thanks for clarification

Re: Notch trying jsFiddle

#18

Can anyone explain how this works? I never have got to grips with 3D.

Update: Thanks for the repliers. You are absolutely right: this is a 3D rendering. What I meant to say is that it is using Canvas 2D, instead of Canvas 3D, also known as WebGl. Antirez gave a wonderful explanation above[1]: And indeed it is pretty impressive how fast the rendering happens given that the code operates at such lower level... Even selecting the color of every pixel requires non trivial work in the inner…

I appreciate it is written onto a 2d plain. But it does look like 3D. This appearance of looking like 3D when a screen is 2D is complicated and very mathsy (not a word - I know). I've tried reading about it before but it is not straight forward.

Re: Notch trying jsFiddle

#19
post #16
post #11

Earlier quoted context omitted.

I totally agree. You probably meant "code operates at such a _high_ level" :) low level = close to hardware, high level = high abstraction, like JS

No I really mean low level :-) Javascript is high level, but here notch is using it as a low level framebuffer.

> And indeed it is pretty impressive how fast the rendering happens given that the code operates at such lower level.

Sorry if this is a stupid question, but wouldn't you normally expect low level code, whilst more time consuming to write, be faster or just as fast as higher level code.

For example, how C is used as a standard for fast code since it's so low level.

Post reply on HN