111–120 of 143 posts
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?
Why is init called twice? Once at the end of the js and then again in the html.
I've recorded a screencast that digs into how the programmatic texture generation works in this code: https://www.youtube.com/watch?v=WaZvDCmlERc
it'd be also great to do an analysis of the geometry data as well, if you can!
Earlier quoted context omitted.
Thanks, I'm plenty aware of gdb and debuggers:) (ex-google software engineer, etc etc) Go watch the video. Bret presents a very cogent vision for a dramatic improvement on most of today's standard engineering/design tools.
And here I'm going to point to Bret's later writing, http://worrydream.com/#!/LearnableProgramming . It's not about the sliders it's about the understanding. A good example is the first large loop setting up the texture. for ( var i = 1; i If this was a first introduction to programming it would scare off many people. My interpretation of Bret's idea is that it would be better to have the ability to highlight the sec…
Interesting for an untrained programmer to tweak and see what happens each time - changing colours, speeds, sizes, reversing the flow, changing textures, etc. Accomplishes so much with such concise code.
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 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.
All this using nothing more than a frame buffer, so you could port this easily from a C64 to any other computer. This code contains a lot of knowledge VS use of pre-build APIs.
If a programmer reads this code and understands how every part works, he or she ends knowing a lot more about computer graphics than before.
Earlier quoted context omitted.
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.
It's an handful amount of lines of code doing a world generation, texture map generation, and ray casting rendering with a few tricks like a simple lightning model that still looks good. All this using nothing more than a frame buffer, so you could port this easily from a C64 to any other computer. This code contains a lot of knowledge VS use of pre-build APIs. If a programmer reads this code and understands how ever…
It contains a lot of general knowledge about 3D graphics, and absolutely 0 specific knowledge about the environment in which it's running. All he's accomplished by doing it this way is show off that he knows trig and prevent any of it from being hardware accelerated.
>If a programmer reads this code and understands how every part works
But he never will, because the code is illegible.
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.
I respectfully disagree with your use of low level, though I do understand your analogy about the pixelbuffer being like a frame buffer. But he's actually using Javascript arrays which can get passed around inside a javascript VM, and do not have a set size. Not very "low level". I spent a moment and changed the arrays to Float32Arrays which have set sizes and sit in memory without being fucked with by the VM and spe…
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.
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.
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.http://blog.nsbasic.com/?p=1060
Runs fine on an iPhone 5!