Minecraft Forums

I used to be able to play minecraft a few builds ago, but I've since become unable to play due to the intensely low FPS. It kinda sucks - I would appreciate it being recoded now so I could continue enjoying it before its final release :\

I was somewhat "inspired" to write a blog post recently for reasons unrelated to this thread, but parts of what I wrote are relevant.

For example, regarding C++ and memory management:

As for memory management: once you learn how to do it, and how to work with it, it just get’s in the way. No matter how much practice you get with malloc() and free() you’re still going to have bugs where you miss a malloc or you miss a free or you perform a double-free or something; the only recourse is always to create some sort of automatic tool or use a design pattern to make finding these problems easier. What something like garbage collection does is make such design patterns unnecessary since there is essentially a design pattern for memory management built in.

The point being that Minecraft should be playable on far distance on any frikkin netbook (yes, even written in Java).

Why?

This is done by a Garbage Collector, which in its simplest form is a loop which walks through all of the objects allocated by the Java code, decides whether they are actually used or not, and frees them in consequence.

Absolutely no modern Virtual Machine currently uses that method. The two simplest methods implemented in the very earliest Virtual Machines (Sun's and Microsoft's) used Two Algorithms: Mark and Sweep, and Stop and Copy.
The Sun VM used Mark and Sweep, which (is pretty much as you noted, it goes through the list of objects and finds those that are no longer referenced, "marks" them, and then when it's done goes over it again and deallocates all of them (it does it in two steps because deallocating the objects as it does so could cause issues with invoked finalizers) The MS Virtual Machine used "Stop and Copy" which was faster, but cost a bit more memory. Instead of marking objects that weren't used, the MS VM copied all objects that were still present to a new piece of memory, and then basically said "ok, this is the new memory block" and discarded all of the memory it was using. That doesn't sound right, since it sounds like it should be slower, I probably didn't describe it properly. Oh well.

In any case, all Modern Java VM's use a Garbage Collector implemented using a Generational Approach more java relevant stuff here, all I know about generational GC's is from .NET, which probably isn't the same:http://java.sun.com/docs/hotspot/gc1.4.2/faq.html

another nice article: http://www.javacoffeebreak.com/articles ... ction.html

The biggest problem with the Java method is that if the Garbage Collector isn't called fast enough, the game might actually run out of memory, which, due to how Windows works, causes a sizeable amount of its memory to be dumped to the hard drive

Wrong. Only inactive pages are paged out to disk. Other applications might be page-faulted back into physical memory when you switch to them, but Minecraft's private working set will always "take priority" as long as it is "hitting" it's memory frequently enough. As a foreground application however it basically means that it's entire working set will be kept "at the ready" in physical memory- I mean, it is the active application.

(replace C++ by any other compiled language really, it's just for context)

Visual Basic 6 compiles to native code. IT doesn't require you to perform allocations and deallocations manually. Delphi Compiles to native code. It doesn't require it either.
and

they are actively porting the game to compiled language

Java is a compiled language. So I guess their work is done then. You both obviously mean a language that has a compiler that can compile to machine code, well, there are native code compilers for Java, but the thing is, that defeats the entire purpose of the language, which is to be portable. If you want to tie yourself down to a certain architecture or maintain some retarded setup for compiling to different architectures, that is your perogative, but to come to some half-baked solution that compiling to native code is better is simply wrong. For one thing, it limits your options. If you compile a program with certain optimizations, that's it. you'll have to recompile to change it. With java- the compiled bytecode is compiled to the machine code of the native environment, with optimizations based on the configuration, such as availability of processor extensions, x64, etc.

And there's this really magical moment when you fire up your game, look at the task manager and see that memory usage is going up and down smoothly as you play the game, with no memory leaks. Really satisfactory.

Um... I get that with my C# game. Not sure why it's magical, unless, despite what you just stated, manual memory management is hard to do right?

So overall if you have enough memory to have a "safety margin" while running Minecraft, you wouldn't notice a significant performance gain from a direct port to another language without changing the code. If you don't, well, you would notice a big difference. A quick and dirty workaround for those of you with this problem is to reduce the interval at which the garbage collector is called (google it).

I believe your information on the garbage collector was based on current information in 1996.

Quote from Bacterius »

Why?

Because it does not require even close to the amount of power required by even mid-range games such as Half-Life 2.

I'm fairly certain that Minecraft actually has more visible triangles then half-life 2 in your "average" scene. It sounds counterintuitive, but really the blocky nature of minecraft adds more triangles, not fewer; the models and built scenery and whatnot in a game like Half-life 2 are individually tweaked to get the best look for as few poly's as possible; minecraft's dynamic world generation makes any sort of "optimizations" in that way far more difficult and only algorithmically feasible; a good example, would be sort of like how on most machines, if you have a font file but that font doesn't have a bold and/or italic styling, the computer will algorithmically make it bold, italic, etc by applying a predefined set of rules; but a bold/italic font file for that family will almost always look better, because it's designed. There are in fact a few optimizations to my knowledge in minecraft, such as larger squares of wall and land being represented using the minimum number of triangles (a 128x128 square of the same texture on the ground will only use two triangles, for example).

Say what you want but it is inferior in every way in terms of computational power - less vertices, less textures, etc

In addition to what I noted above, Minecraft doesn't have as many options open for how the vertices represent the on-screen poly's. For example, in a game like half-life 2, certain features might use a triangle fan (which has a singel vertice followed by N vertices which creates N-1 triangles, (so having 9 points gives you 8 triangles, which saves on the 24 vertices that would be required for a more conventional Triangle List. Basically the whole "randomly generated terrain" is what causes some of the issues, because most other games it is compared to performance wise (such as, in your example, HL2) were indescribably optimized resource wise; basically, my point here is that there seems to be credit being given to the language and compile method that games like HL2 use (C++) for the better performance when it may very well be a factor of optimal resource construction (models, textures, terrain, etc).

what I'm really saying is that TINY VIEW DISTANCE SHOULD NOT SLOW DOWN MORE THAN FAR DISTANCE.

I didn't even know that was the case, seems that lower view distances aren't actually culling closer to the viewer. That's just... weird.

Go have a look at the MC source code

Minecraft is closed source; sure, it is possible to decompile it and deobfuscate it, but it is foolish to judge the competency of any segment of code that is nothing more then a reconstructed ghost of what it really was; especially since a decompiled and deobfuscated version would be devoid of any sort of comments, variable naming, etc. Although that's more my reasons for not messing around with it, but even after deobfuscation, the code itself is still obfuscated (if that makes any sense).

come back and tell me with a straight eye that it is running as best as it can

of course it isn't. Everything can be improved. That fog issues is just weird. Maybe it's actually some stupid thing with LWGL.

I said, in its simplest form. It is obvious modern VM's have improved since then.

Well, yeah, but it sorta seemed like you were arguing against the ghost of what it was.

(replace C++ by any other compiled language really, it's just for context)
Visual Basic 6 compiles to native code. IT doesn't require you to perform allocations and deallocations manually. Delphi Compiles to native code. It doesn't require it either.
and

the difference is that you can actually use pointers.

Visual Basic 6 doesn't let you use pointers. In fact the best equivalent is to use rtlMoveMemory and a few hidden VBA routines to copy data to and from pointers. The closest native thing in VB6 to a pointer would be references (Delphi has Pointers, they aren't required but they are there). References are of course a type of pointer, but Java uses references for bloody well everything.

You need to handle those. And you NEED to use those in a game.

Wrong, you don't <need> to use pointers in a game. Also, Java uses pointers in the form of references. Thus NullPointerException. (Although I prefer the slightly more accurate .NET NullReferenceException)

Compared to a Java game with the same code, the only thing I was thinking of is "wtf is Java doing". And that was quite a while ago. Been there, done that.

It's job; I admittedly didn't read the entire thing but one of the links I posted in my previous post sort of explained that the design goals, use cases, and the language design for Java was a totally different direction from C++. Now, this may faciliate arguments to the chord of "well, clearly that direction doesn't facilitate game design", but really, it does. In fact, in many ways, it's better. Memory allocation is very fast as long as nothing needs to be paged out to make room, and the Garbage collector of Java intercepts various "System resources low" messages (on windows that is the WM_COMPACTING message) and will discard older generations of GC'd objects. The main problem isn't so much with the GC but with the design of classes that use it; many people design classes that are immutable; the java.String class being a prime example, where string objects are constantly becoming dead; just this segment here(which may not compile, haven't used java in a while, YMMV, etc):

public static void main(string[] args)
{
string string1="hello";
string string2="world";
system.out.Println(string1+string2);

}

when the procedure finishes, there are now three new string objects that need to be deallocated "hello" "world" and "helloworld"; thing is, rewriting the procedure as such:

public static void main(string[] args)
{
stringbuilder sb="hello";
sb.append("world");
system.out.Println(sb.ToString());

}

Will only add a string object and a Stringbuilder; scant savings, but the problem I'm demonstrating is that the construction and discarding of immutables in deep loops is the problem, not the garbage collector; with C and C++, because you are usually in control of the allocation and deallocation, immutables are no problem, just free it and set the value to null. The problem is that people try to do a similar design pattern in java and assume that it will work as well; essentially the garbage collector implies a necessary rethinking about memory allocation.

But the issue remains - Minecraft is poorly optimized and while it isn't Java's fault (it really isn't), it's impossible to deny the fact that it could, and should, run much faster on current computers.

Certainly no issue with that. And, to be fair, I really do not like java, but for a number of otherwise irrelevant reasons to what is being discussed here, (specifically, it worries me that it took so long for them to get Event handling working in a sensible manner, or that they took years to add lambda's/closures because they claimed "functional programming is a fad" which is ironic since the tagline against java in the mid nineties was that "Object oriented programming is a fad".

The basic point is, optimizing minecraft is better achieved by the very methods outlined; better use of available functionality and (in the case of fog) not writing invisible triangles to the pipeline. Thing is, aside from that, most of the more common-sense optimizations have been made; a square wall of blocks of the same type is a single texture, for example; and there is backface culling, so if anything more recent versions of MC are faster then the old (although I cannot remember when backface culling was added). I don't know it it uses view frustrum culling or any of the other methods of reducing triangles, but if not, they should be working on adding that; porting it to another language takes time for no gain and will only serve to add bugs.

Which brings me to another point; there is a common mindset- and it's a feeling programmers get as well, that at some point in development, a program feels so messy and unmaintainable that it "is better to rewrite it" thing is, that's never the case. The reason a program feels messy and unmaintainable is almost always because of those changes made during development to fix bugs and other errata; the single biggest mistake any software firm can do with their flagship product is rewrite it from scratch; and that is what will essentially occur if they are to "port" it to C++. It's happened before; The reason netscape failed was because they tried to rewrite it. Borland bought Arago and tried to turn it into Dbase for windows as opposed to forking their current dbase code) which utterly failed because Access ate them for lunch. Microsoft almost made the same mistake, trying to rewrite Word for Windows from scratch in a doomed project called Pyramid which was shut down, thrown away, and swept under the rug.

Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand. We're not excited by incremental renovation: tinkering, improving, planting flower beds. BORING.

There's a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: they are probably wrong. The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming:

It’s harder to read code than to write it.

This is why code reuse is so hard. This is why everybody on your team has a different function they like to use for splitting strings into arrays of strings. They write their own function because it's easier and more fun than figuring out how the old function works.
As a corollary of this axiom, you can ask almost any programmer today about the code they are working on. "It's a big hairy mess," they will tell you. "I'd like nothing better than to throw it out and start over."

Why is it a mess?

"Well," they say, "look at this function. It is two pages long! None of this stuff belongs in there! I don't know what half of these API calls are for."

Before Borland's new spreadsheet for Windows shipped, Philippe Kahn, the colorful founder of Borland, was quoted a lot in the press bragging about how Quattro Pro would be much better than Microsoft Excel, because it was written from scratch. All new source code! As if source code rusted.

The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed. There's nothing wrong with it. It doesn't acquire bugs just by sitting around on your hard drive. Au contraire, baby! Is software supposed to be like an old Dodge Dart, that rusts just sitting in the garage? Is software like a teddy bear that's kind of gross if it's not made out of all new material?

Back to that two page function. Yes, I know, it's just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I'll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn't have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Solaris.

Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it's like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters.

When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.

You are throwing away your market leadership. You are giving a gift of two or three years to your competitors, and believe me, that is a long time in software years.

With minecraft, what would happen if they rewrote minecraft in C++, is this:

All updates to Minecraft would stop. After all, there is no point maintaining the old sloppy java version. it's garbage now, the new C++ version will shine! So no new updates. You want basic weather? we aren't going back to that old icky java code, we're rewriting it in C++! they'll say. Days turn to weeks turn to months turn to years.

meanwhile, Manic Digger will likely have a revival as people miffed by being abandoned by Mojang rally behind it; new developers will strike into the fold, And it will become rampant with development. Each passing day, more people will "lose hope" that there will even be a C++ version of minecraft, as Manic Digger (or some other project) starts gaining more and more traction.

And what happens when Minecraft C++ edition is released? The best case scenario for Mojang is that it works exactly like the java version did, only slightly faster and with some new set of bugs. There won't have been any new content added, they were busy just duplicating what they already had. Meanwhile, Manic Digger (or again, whatever equivalent rises) will have passed what Minecraft was by leaps and bounds, very well making minecraft look to it as infiniminer does to minecraft. Now this isn't a bad thing at all; we'll still have "a minecraft" of sorts, and it will be open source and probably more easily modded. But I'm looking at this from Mojang's perspective.

God I love threads like this. A discussion between smart programmers always fills me with happy fuzzies cause as a n00b programmer, I learn a little bit.