Minecraft Forums

I find the new 1.8+ worlds just lack something. They just all seem alike and predictable. The tree density in forests is reasonable, but its standard deviation is too low, and in grasslands I'm lucky if I can find a single tree. There are way too many waterfalls/lava fountains pouring out from mountains, desert biomes look ugly, snow biomes are basically just grasslands but with snow on top of it. Mushroom biomes are.. well I don't even see the point. I find ocean biomes pretty cool and well-sized, however there must be some kind of failsafe mechanism to prevent the player spawning on a tiny speck of land surrounded by miles of ocean. After all if I'm on a fairly large continent surrounded by ocean, once I get bored/run out of resources I'll have to move - it's called expansion and colonization (well not really since you're alone but you get my drift - and in SMP it would work well) and this would give oceans a purpose. Also put some cool stuff underwater, perhaps aquatic dungeons or something, make some aquatic navigation craftables to allow the player to explore underwater and you're all set.

Last but not least, there are WAY too many cavern entrances scattered on the surface (especially in forests). Same thing for those random lava pools (except when they set entire forest biomes on fire - that's cool).

I really miss the crazy snow mountains I used to see back in 1.6, and I would also like to see continental biomes expand below the sea limit.

If anything, a thing I would want Mojang to implement is let the user decide which structures he wants generated, for instance I love mineshafts but I don't really like villages (they kind of break the lonely feeling, especially with the braindead NPC's I've seen last time I found a village).

The weather also needs an overhaul, namely better transitions and more common weather changes. For instance, in the tempered zone of the Earth, it rains on average once every four days. In Minecraft it feels more like once every three months.

Also, as someone else on this forum said, allowing snowing in every biome except ocean and desert would remove the need for a snow biome and would allow for MUCH more interesting landscapes (provided it doesnt snow too often, say once every two or three Minecraft months?)

Also make weather interactive, i.e. when it rains, make crops grow faster (not sure if this is the case already? I imagine so), allow for the possibility of floods, make mobs move slower when it's snowing, etc... all of this adds variety to the game and gives it more depth without being obnoxious (if the mechanics are intuitive and match real life expectations reasonably well, they will not require the player to adapt)

Mathematically:
Dividing by zero is meaningless. There is nothing special when you divide by zero, the world doesn't collapse or anything. I can write "1/0". But I cannot assign a definite value to it, such as 0, 5 or 42, because of the very nature of mathematics. The undefinability of division by zero is required for the completeness of mathematics. The closest thing you can do is come up with an actual way to represent division by zero in an abstract way that could be used in other contexts to solve otherwise undecidable problems. For example, considering division by zero not as a numerical constant but as a limit is much more useful in function analysis.

In a computer:
When the CPU executes code which requires dividing by zero, it simply returns immediately a NaN value (Not A Number, special constant which defines an undefined number) and sets a FPU hardware error bit for the software to take care of. If it didn't do error checking, the hardware division algorithm would most likely iterate forever, or return the numerator, or output gibberish, depending on the algorithm used.

That's all there is to it.

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

Indeed. It really depends, if you're on top of a mountain on far distance you'll have quite a few triangles to draw before hitting the far-culling. And HL2 wasn't the best example as well, the source engine is quite efficient.

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.

It is, indeed. For some reason, in SSP the fog system seems to cull appropriately but in SMP at it is right now, anything below far view distance just kills the performance.

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

Indeed, although you can still kind of see in which direction the code is going, even when it is obfuscated. Still, I don't like that closed source philosophy as well - mods have existed for as long as Minecraft has, Mojang might just as well release the code and make everyone's life easier (right?). Note that with another programming language, mods would still be doable if the code was released along with the game, but it would attract a totally different community of modders.

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

Maybe, although that would be strange coming from such a big library. It probably is just some bad code in the networking engine (with regard to the SMP issues above), maybe a typo?

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

Yeah I got a bit carried away with this particular model. My bad.

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)

Yes, but I meant actually using them to make the game run faster. You can argue that anything is a pointer, since basically a variable such as a longword (in Delphi for instance) is just a pointer with one level of indirection. A method within a class is a pointer with two, sometimes more (if the method is virtual) levels of indirection.

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

Well, it depends what you are aiming for. If you are just hacking up a game (like Minecraft in its current state), you're just going to be allocating when you need and let the GC do its stuff. But if I'm coding something that needs to work as fast as possible, you better bet I'll ensure every GetMem or VirtualAlloc or whatever is paired with one, and only one, FreeMem or VirtualFree or whatever. No-one likes having an out of memory exception when even the pagefile can't take it anymore.

But I agree - in many ways it simplifies the game development process, and helps game developers focus on the game and not on some crappy arcane object that just won't free itself properly. But IMO it's just not a sustainable development model, and code needs to be reviewed and cleaned up every once in a while. With Minecraft I just get the nasty feeling the development team just kept adding more and more stuff on the base code until it became basically impossible to maintain and optimize - in this case there are two paths of action:
- "perhaps we should rewrite this"
- "it's working anyway, the hell with it"

Which brings us to your next point..

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.

Rewriting from scratch is not an option once the project gets too big - if they are going to rewrite it, they are going to focus on optimization, and as someone (forgot the name) put it well, "premature optimization is the root of all evil" and they will produce an even bigger mess. And also for the reasons you outline above - complete rewrite is not really the best idea, yet I think some portions of code would benefit from a rewrite while others are best left alone.

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.

Actually I think Minecraft handles the rendering part very well - at least on my systems. The real problem is not there, it's in the chunk update code, which takes too much processor time - and since Minecraft is fully singlethreaded, rendering is severely affected once this happens. This is where parallelization of the chunk update process comes in handy - but it requires rewriting a fair bit of the code, which may not be an option. Yet it needs to be done eventually, as CPU's are hitting thermal limits right now, while the Minecraft rendering distance may increase in the future i.e. more (and bigger) chunk updates. We have a problem.

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.

I think we both agree on a point: complete rewrite is obviously not the way to go and will cause Minecraft to fail as proven many times in the past. But it's not binary, it's not either complete rewrite either nothing - it is also possible to have a look in the code, profile it, see where the biggest bottleneck is, and try and figure out how to get those fifty lines of code or so working faster (I'm thinking of the chunk update code here). Obviously any programmer worth his salt knows that when a program is running slowly, it's not because of the whole code - in any given program there's probably only 5% of the *total* code that is actually slowing down the whole of it. AFAIK the only complaints I have ever had and seen for Minecraft concern the chunk update & the SMP networking code. This is all that, apparently, needs to be looked over. And a couple of bugs such as the interface being unresponsive when going from fullscreen to windowed mode. All the rest works well and should be left alone.

Did you know BUMP stands for Bring My Post Up?

(failed attempt at stealthed bumping)

Why?

Because it does not require even close to the amount of power required by even mid-range games such as Half-Life 2. Say what you want but it is inferior in every way in terms of computational power - less vertices, less textures, etc ... and even if I turn out to be wrong and you still need a somewhat decent processor for MC, what I'm really saying is that TINY VIEW DISTANCE SHOULD NOT SLOW DOWN MORE THAN FAR DISTANCE. Optimisation is the key. Go have a look at the MC source code, come back and tell me with a straight eye that it is running as best as it can (putting Java aside).

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.

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

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.

Fine on that.

(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

In these languages, the difference is that you can actually use pointers. You need to handle those. And you NEED to use those in a game. Conclusion?

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?

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.

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

Fair enough.

---

You make some good points and corrected my post, I stand corrected on the GC. 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.

Complete rewrite is eventually going to happen, regardless. Maybe not in another language but at least it will be rewritten with performance in mind. It will have to when even the most powerful CPU's out there won't be able to absorb the poor performance of the current algorithms used (currently they are still able to, hence why only people below the 2.4GHz mark or such are having some issues). I'm looking forward to that actually - I'm seriously going to laugh when all of you who were saying "omg stop whining ur computer sux, MC haz system requirements" today are going to complain about bad framerates on your state-of-the-art computers. Mark my words.

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

Also, if the code gets ported eventually, it should open up a panel of new improvements such as better graphics (not crysis-like but like with improved physics & lighting), where Java might indeed not cut it.

And here is a little tutorial on Garbage Collection for dummies, to help people understand what memory leaks are: basically one of the differences between C++ and Java (replace C++ by any other compiled language really, it's just for context) is that C++ requires the programmer to manage memory appropriately by allocating and freeing it properly, while Java simply lets the programmer allocate and essentially frees it "later".

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.

The pros of this method is that the programmer doesn't need to worry about memory management and memory leaks - Java does it!

The cons is that it doesn't do it well at all. The Garbage Collector is only called every X seconds (or when system memory is running low) meaning that within this interval, nothing gets freed, hence why memory in Minecraft grows so quickly. And another con is that when it is called, it slows down the game by quite a bit (although this is mostly negligible).

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. However, your hard drive is immensely slower than your memory, and when this happens, you're pretty much doomed, and the game slows to a crawl, until the Garbage Collector cleans it up (and then it starts again). And if you're wondering, no, the garbage collector doesn't kick in fast enough when the system runs out of memory and can't quickly clean up some space before the system dumps to the hard drive.

This is especially a problem on 32-bit Java, where Java programs can't allocate more than 1 gigabyte of memory (shouldn't it be 2? I can't allocate more than one on my laptop and I have 4 gigs, not sure here).

Personally I prefer the C++ way of doing it, because it is basically better. And managing memory isn't that hard, really. 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.

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

Bump.

Once minecraft is finished, its true brilliance will be the mods people will create. SMP is and always will be buggy, and unfit for pvp.

Pessimism much? No, SMP will not always be buggy, Mojang just needs to pull its fingers out and repair code that is obviously not working. And to be honest when I managed to actually play SMP smoothly on a good server I found a great experience - trying to survive a night with a couple of friends in a dark cave, with lots of mobs and enemy player gangs trying to kill us is thrilling. Although the implementation does need some working on, the concept is obviously there and has great potential.

check if other players are having the same lag on this server
i think the server is the problem,the owner probably tried to install some plugins that aren't compatible,and that is causing you lag(your minecraft is trying to understand wtf is the server talking about,basically)

I polled eight of them and six of them had the same massive lag. Two of them didn't for some reason but one told me he had a really high end PC, so it might just've worked through the lag somehow. However I connected to another couple servers and I get the same lag there aswell so I think it's not an issue with this particular server but with SMP as a whole.

Thanks for sharing. I am posting this on my facebook page.

Awesome..

Ok guys, this thread is going in the wrong direction, let's get things straight. Minecraft is not, not, not a complex game, for ****'s sake. Stop saying it requires much more power than a modern game, etc... each cube in Minecraft requires eight vertices, and you hardly see more than a few thousand cubes at once even on far view distance (and even that is ridiculously exaggerated - try and see for yourself). On the other hand, a single character model from a relatively old game such as COD4 or whatever has several hundred thousand vertices - and you usually have a few models displayed at any given time).

The real problem with Minecraft is not the programming language, in all honesty, and although I voted "convert it" just for the sake of having an actual executable to work on instead of relying on Java, it's not Java that's making the game so slow, regardless of how much you all hate Java. The real problem is how Notch's code for chunk management is absolutely ****ing horrible and that each time the game needs to update a chunk, it slows down to a crawl while some poorly written greedy (read: unnecessarily slow) algorithm plows through data that would be nearly instantly processed using a better algorithm. Just for the example, on one of my older crappy laptops with an integrated GPU and a 1.8GHz celeron, I can get on top of a mountain on far view distance, wait for the damn chunk update code to finish, then move a bit without any chunk updates at a silky 71 frames per second roughly, which proves beyond all doubt it is not a rendering problem. But as soon as I move into loading range? Drops to less than two frames per second - find the culprit.

Face it guys - your opinion is absolutely meaningless in the matter, you have to face the fact that despite the looks, Minecraft is not a complex game at all in terms of processing power, and that this myth of "you need a better computer to play MC than you'd expect" comes from the fact that Notch has done a very bad job with the game's code. And you just cannot deny it. As much as I respect Notch for getting this game idea (this is not the subject of my post), he really needs to get on with it and optimize code that should've been optimized months ago. This wouldn't even be hard, Notch and his team could probably sit at their desks and work on it for the whole day, and get back home in the evening happy knowing that with this tiny time investment, the game has suddenly become much more enjoyable for anyone that was having issues (tbh, most Minecraft players). But instead, he takes vacations. Find the error.

I am a software developer - I have out of curiosity read Minecraft's source code - and believe me when I say that the chunk update code section is quite possibly the absolute worst code I have ever seen in my entire life.

Thanks for reading.

PS: and to people who say that updates keep getting added with new items which would make the conversion process longer, I do hope you realize that adding new items and blocks simply consists of adding an element to an array within the code and throwing an additional texture in the .jar file? Programming isn't complex guys, that's all there is to your so-called MC updates. Face it. I've looked at the code - I know how it works, you don't, if you did you wouldn't be claiming the above in the first place.

Bump.

It's not ATI drivers - I've got an nVidia card (GTX570) on my desktop, and my laptop has a GMA4500MHD (Intel Integrated) and has the same issue.

Hello,
I just downloaded 1.4 a few hours ago and gave SSP and SMP a go. SSP worked flawlessly, it was really enjoyable. Then, I join SMP on my favorite server which just got updated, and for some reason, I get immense, mark my words, stuttering fps-wise. I have never made it above 4 frames per second since the new update and most of the time I'm just frozen, waiting for whatever MC is doing to finish.

Now, my hardware definitely is not the problem - SSP is working smoothly at all times, and before the update SMP was very smooth as well. My internet connection is stable and as I say it worked well before.

If I don't move for a while, the stuttering stops completely and the game is smooth again if I just look around, but if I even move in any direction it starts again. If I change the game's state, such as switching full screen on and off, changing a graphics setting, etc... the stuttering subsides for a bit but quickly comes back. This renders the game simply unplayable.

As a software developer & MC enthusiast myself, I'm not going to hide what I strongly believe the issue is - I am quite sure a flaw in the networking code causes MC to enter an infinite loop as soon as it needs to update a chunk - the chunk gets updated but for some reason the game keeps working aimlessly, gradually slowing down the game to a crawl (because more and more chunks get updated when the player moves). Then, at some point, the garbage collector kicks in, sees these infinite loops, and breaks (kills) them, making the game smooth again. This fits perfectly with the observations made above, as changing a game setting will cause all chunks to be reloaded, therefore killing these loops and, well, starting them again, and as not moving causes no additional chunks to be loaded, allowing the garbage collector to end the offending loops and making the game smooth until the player moves, creating more chunk updates.

I've browsed many forums including this one and it seems I am not the only one experiencing this problem - a substantial fraction of the Minecraft player base is affected by this issue and this is getting quite annoying. So although the chances of Notch or his team reading this are.. slim to say the least, I'm still giving it a try and see if this changes things. To conclude, get on with it, Mojang, we honestly don't need new features or pets right now, we need you to correct and optimize code that is making the game unplayable for most of us. Hell, from experience I know it's probably about fifty lines of code to work with, but no-one seems to care.

And as a final word, it's a bit too easy to say that "the game is in beta". Beta means players are meant not to enjoy the game but to find bugs in it and report them - we've got a pretty massive bug here, and we're doing our best to report it (we're trying, we really are), but it seems no-one is listening. We're not complaining about the game not being playable - we're complaining about why it isn't fixed yet.

Thanks for reading.

PS: and for those of you who are inevitably going to reply "stop whining", I'll answer this: this thread is meant to help find a solution to a very annoying issue that could potentially affect you at any new update - if you can't understand this and realize the importance of such threads, you've got some problems.

Yes, I understand. Hopefully versions to come will finally get multithreading. It would require rewriting the code almost entirely but I'm confident Notch will get to it eventually. It would also allow for monster view distances for those who can afford quad cores which would get quite interesting.

PS: speaking of terminology, to be exact it does use all of the cores, but not in a parallel fashion, that is, it will only do one thing at a time, but Windows will put the load on the first available core. So it does use all cores, but not at the same time (this is a pointless distinction as far as MC is concerned but is fundamental to how the operating system can itself multitask, which is why I'm pointing it out).