Notch trying jsFiddle

[antirez]

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.

[jrogers65]

I would argue that this is terrible code. It's not using the appropriate tools (webGL), it's badly structured, uncommented and unmaintainable (seriously, why on earth would anyone name their variables zd, _zd and __zd?). The Minecraft source code is also of notoriously poor quality. I honestly don't understand how you came to your conclusion.

[Jare]

Indeed, writing straightforward code with no dynamic memory allocations, and simple and predictable types, lets the VM do wonders with optimization and JITting. Good stuff.

[WA]

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

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

[ukjadoon]

If the creator of Redis approves this, it's definitely awesome! =)

[JoeCortopassi]

Such a great example of what can be done in javascript/canvas. As it is, I was completely blown away by how little code it actually took to do that. My only gripe would be, why couldn't he have used descriptive variable names, so I can better go through and understand it? :-)

[antirez]

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.

[petercooper]

I've recorded a screencast that digs into how the programmatic texture generation works in this code: https://www.youtube.com/watch?v=WaZvDCmlERc

[ozataman]

Thanks a lot for taking the time! Any chance you can do one for the game loop and the rest of the code?

[unoti]

Enjoyed that immensely, thank you!

[terhechte]

Great analysis of whats going on. Thanks.

[chii]

great work.

it'd be also great to do an analysis of the geometry data as well, if you can!

[petercooper]

Here's a rendering of the texture map so you can see what it generates directly: http://jsfiddle.net/cXvKa/

[recurser]

Notch has made a couple of comments on reddit :

http://www.reddit.com/r/programming/comments/146v69/how_notc...

    Please do NOT write code like this. It was originally written for the Java4k 
    competition, which focuses on executable code size, and is as a result almost 
    intentionally poorly written. It got even worse when I ported it to JS.
    It was mainly meant as a test for me to see what HTML5/JS can do, and an 
    exercise in porting code over.

http://www.reddit.com/r/programming/comments/146v69/how_notc...

    It would run a bit smoother if it was written in C++ (mainly due to not having 
    to rely on the GC, and having it precompiled gets rid of the warmup time), and 
    modern OpenGL would help quite a lot as well. A lot of the stuff done in CPU 
    now could be moved to a shader, which both makes code simpler, and gets rid of 
    the slow JNI calls required now.
    The main reason why Minecraft is slow is mainly 1) There's a LOT of polygons, 
    combined with 2) The difficulty of making an efficient culling algorithm in a 
    dynamic world.
    If someone solves #2, very interesting things could be made with a game similar 
    to Minecraft.

http://www.reddit.com/r/programming/comments/146v69/how_notc...

    No, they don't get merged because the textures are all pulled from the same atlas 
    to avoid texture swapping. With GLSL, they could be merged, saving quite a lot of 
    polygons. For a while, I did attempt switching the atlas from a 16 x 16 grid to a 
    1 x 256 grid and merging horizontal runs of the same texture, but the resulting 
    texture size was to tall some graphics cards (on low end computers) would 
    automatically downsample it.
    The problem with the occlusion culling is not about knowing what parts are static, 
    but rather figuring out what occluders there are. It would be very beneficial not 
    to have to render caves under ground below the player, for example, or not to 
    render the entire outside when a player is inside a small closed house. Figuring 
    this out in runtime on the fly as the player moves around is.. expensive.

[scottyallen]

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...

[enjalot]

Here is a version adapted for Tributary: http://tributary.io/inlet/4199801/

Press play in the bottom left to have it go, and scrub numbers/colors to your hearts content!

Part of the reason it slows down in livecoding is because of the way the original code uses setInterval, and every change reevaluates the code which polutes the scope and starts way too many threads going. I've added optional functionality to Tributary which gives you a run loop (using requestAnimationFrame) that doesn't polute anything.

Hope this helps!

[dsl]

This "responsive programming environment" you speak of has been around for a really long time. Don't expect sliders and colorpickers to do cool stuff, but this should be a good jumping off point for you to start learning from: http://stackoverflow.com/questions/3305164/how-to-modify-mem...

[undergroundhero]

Thanks for the livecoding link. I assume there's some overhead in constantly checking for and applying code changes - that's probably the reason for the lower frame rate.

[experiment0]

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!

[antirez]

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.

[arriu]

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 < w; x++) {
        var ___xd = (x - w / 2) / h;
        for ( var y = 0; y < h; y++) {
            var __yd = (y - h / 2) / h;
            var __zd = 1;

            var ___zd = __zd * yCos + __yd * ySin;
            var _yd = __yd * yCos - __zd * ySin;

            var _xd = ___xd * xCos + ___zd * xSin;
            var _zd = ___zd * xCos - ___xd * xSin;

[albertzeyer]

Can you explain why?

[moconnor]

I'm shocked and pleasantly surprised that js/canvas can putpixel fast enough for this. It must be around as fast as assembly on a 486!

Part of me can't decide if that's awesome or tragic.

[gavanwoolery]

Very cool, but a few notes to anyone getting their hopes up on the powers of Canvas:

As you may have anticipated, this demo runs at less than 1 frame per second on my Nexus 7. :/

In terms of per-pixel manipulation of a Canvas, it is very slow, even with javascript's (not very well supported) typed arrays. Simply put, multidimensional loops (unrolled or not) will always kill performance in JS with any significant dimensions. I learned this the hard way by trying to write a pixel-based GUI, and even that (with some crazy optimizations) could not render fast enough for all devices. If you are just doing blits, Canvas works very well (especially since this operation often uses the GPU).

For now, I think the best option is still WebGL, even though it is not widely supported yet, mobile devices are beginning to pick it up (Blackberry, for example).

[zzzzzzzzz]

Obligatory flash port: http://wonderfl.net/c/sqL5

[spyder]

That's faster than the JS demo (even the improved one) in any browser. It's sad that browsers still don't have at least the same performance as flash :(

[tgandrews]

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

[AshleysBrain]

While this is cool, isn't this exactly what WebGL is for? I know drivers/support is an issue, but Chrome also ships with a multicore software renderer (SwiftShader) which can probably get a lot further than a JS putImageData engine.

[Raticide]

It's just a demo. It's for fun.

[Pezmc]

Can someone dissect this code and explain what it does?

[snprbob86]

The first set of three nested loops is procedurally generating texmap, which is a multidimensional Array(16 * 16 * 3 * 16). 16x16 pixel textures, one for each the top, sides, and bottom, and then 16 of those. The inner loop tests against i, which is the current block "type" and performs customizations to the procedurally generated textures.

The next set of three nested loops is generating a random "world" with a tunnel cut out of it.

The renderMinecraft function is performing a minimal perspective projection http://en.wikipedia.org/wiki/3D_projection for a single ray cast into the world. Each pixel is cast and then, for each object hit by the ray cast, the closest is found, and a texture mapped pixel is calculated and written into the frame buffer.

[petercooper]

I've recorded a screencast that digs into how the programmatic texture generation works: https://www.youtube.com/watch?v=WaZvDCmlERc (but I'm not touching the 3D.. yet ;-))

[phete]

http://jsfiddle.net/uzMPU/3165/

using window.requestAnimationFrame just because we can!

[Aissen]

Wow! This is incredibly smoother here on Firefox 18! (slow machine)

[shocks]

    setInterval(clock, 1000 / 100);

Is there any reason for writing 1000/100 instead of 10?

edit: Thanks guys!

[anatoli]

It just makes it clearer that he wants it to run at 100FPS: (1000ms / desired FPS)

The usefulness is more obvious when you want 60FPS, which is not easily represented without rounding.

[dag11]

It was probably for readability, i.e. "100 times per second".

Similarly, people will write (10 * 60 * 60) if the value is seconds and the programmer intends to indicate 10 hours.

[estel]

It's a good way to remind you the figure is in ms, and easily manipulate the interval as a fraction of a second.

[sisk]

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.

[Riesling]

Probably just to emphasize that clock will be called 100 times per second (which will result in 100 fps).

[p01]

Tooting my own horn here, but here's my own little "Minecraft" renderer in Neja, circa 2005 ( http://www.youtube.com/watch?feature=player_detailpage&v... ). Over 4 years before Minecraft, and even then that was nothing new. It was kinda cool for JavaScript, in 2005, but all things considered, it was pretty lame compared to Ken Silverman's voxlap for instance.

The "cool" thing about this demo, was that Canvas was not widespread back then so I generated all the chunky effects on the fly as 24bits BMP image, then made a data: URI and update an IMG tag.

[ricardobeat]

"Notch coding in JS" is a bit more descriptive than "trying jsfiddle", specially since it looks like code posted after the fact. A minecraft-like env rendered on canvas with it's own mini-3d-engine is amazing nonetheless :D

[felixthehat]

To be fair, that's the description notch used in his tweet: https://twitter.com/notch/status/275331530040160256 :)

[Flow]

This is actually quite fluid on iPhone 5. I asked a co-worker to try this on his Galaxy S3(quad-core, no lte) and it was really slow there. And in Chrome it was even slower than that on the S3.

Doesn't any web browser on Android use a JIT?

[JungleGymSam]

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?

[kevingadd]

Part of the reason it's slow is that it doesn't use typed arrays. This may be much faster for you: http://jsfiddle.net/uzMPU/1573/

[petercooper]

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).