Live data from Hacker News

Notch trying jsFiddle

jsfiddle.net

41–50 of 143 posts

Re: Notch trying jsFiddle

#42

Why is the framerate poor even when I shrink the viewing area down 10x10? It seems to have the same stutter as the original large view. Is it because it's doing the same calculations but just showing fewer pixels?

Yes. It's the calculations and direct pixel setting that's slow, not the actual "rendering" of the canvas (which is accelerated like crazy in most browsers now).

Re: Notch trying jsFiddle

#43
post #16

Earlier quoted context omitted.

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.

Yes, but when you write in a high-level language like javascript without taking advantage of all of the high-level features like webgl (which are provided by the implementation and assumed to be fast), performance suffers.

In this case, Notch is writing code that doesn't necessitate the overhead of using JS. It could easily be rewritten as C and probably run faster that way. Not that it isn't interesting, of course.

Re: Notch trying jsFiddle

#44

Earlier quoted context omitted.

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.

It is relatively straightforward (at least conceptually) - you're just projecting 3D vectors down onto a 2D plane (your screen)[1]. Conceptually, this is just the bread and butter of vector algebra (first year physics undergrad).

[1] Of course, it gets more complicated if you want to be more realistic, like including a field of view (cone) rather than a screen-sized chunk (prism) of 3D objects, and so on, but these are just details.

Re: Notch trying jsFiddle

#47
post #33

setInterval(clock, 1000 / 100); Is there any reason for writing 1000/100 instead of 10? edit: Thanks guys!

I personal do this for legibility and ease of comprehension. Kinda loses its value when dealing with such nicely rounded numbers but, as an example, 1000ms / 24 is easier or me to comprehend as 24 ticks per second than 41.6666ms.

Re: Notch trying jsFiddle

#48

Why is the framerate poor even when I shrink the viewing area down 10x10? It seems to have the same stutter as the original large view. Is it because it's doing the same calculations but just showing fewer pixels?

[deleted]

Re: Notch trying jsFiddle

#49

Why is the framerate poor even when I shrink the viewing area down 10x10? It seems to have the same stutter as the original large view. Is it because it's doing the same calculations but just showing fewer pixels?

Yep, the hard part is the calculations required for every pixel being displayed.

It does get better framerate changing the variables: http://jsfiddle.net/wATAp/

Re: Notch trying jsFiddle

#50
I enjoy that everything is procedural generated. The software rasterizing is pretty cool too. I don't mind that he uses short variable names, sometimes it's nice to have multiple lines line up perfectly. But this is just silly...

    for ( var x = 0; x 
Post reply on HN