Those little things that irk you about Minecraft
- Thread starter Ripley
- Start date
-
The FTB Forum is now read-only, and is here as an archive. To participate in our community discussions, please join our Discord! https://ftb.team/discord
Though the design/architecture of Minecraft needs a lot of TLC, a good chunk of the problem also rests with the modders/modpack authors/plugin developers/server owners themselves:
- A lot of modders do not go through the extra effort to "scale test" their mod and do the necessary work to streamline application behavior. A lot of small mods start this way, and when the mod hits the mainstream the wheels fall off.
- Modpack authors have a tendency to create kitchen sink modpacks. I keep seeing stuff show up on launchers, forums, and OpenEye where more is somehow better.
- You can't forget server side plugins. Players tend to blame modpacks when server performance suffers. They forget there is other software running on the server stack.
- Server Owners - problems range from under powered servers, over configured server, servers not having proper infrastructure, and not doing enough testing before opening the doors. I have seen a server imploded because the server owner thought it was a good idea to turn on all possible block logging to catch griefing.
Java's memory management model is rather weird in how it decouples from the memory available via the OS.
But the bulk of the performance problems stem from the difficulty inherent in writing performant games in managed languages, so a re-write in C# would doubtless demonstrate the same performance issues at the cost of being much less accessible to modding.
Lets also me quite clear - modded minecraft did not take off because Mojang included a powerful modding api. It took off because jar files are easy to open and consequently its easy to add additional .class files, and bytecode patch the existing ones. This gave modders unrestricted access to *everything*. Written in C# or C++, modders would perforce only have had access to a walled garden of things accessible via the approved api, the maintenance and extension of which would have (and indeed continues to be) a very very secondary priority at Mojang.
Minecrafts Java implementation is both its performance curse, and the very blessing that made modded minecraft what it is.
Last edited:
Java, as a language, only suffers from one serious deficiency (*): the programmer cannot say "Hey, I know this is now junk for collection". The JVM has to find 100% of the garbage, and cannot accept any hints from the programmer.
Retain/release counting may take more CPU overhead (GC can use generational tricks to only collect small pools with the assumption that it's mostly garbage; retain/release doesn't have that, and has the overhead of tracking "autorelease"), but sometimes it is really cheap for the programmer.
(*): Ok, 2 deficiencies: the JVM does not put enough information on the stack for the error handling routines to resend a failed message to a new target. In other words, when you catch an exception for "this message cannot be sent to that object", you do not have all of the arguments and original receiving object, and cannot say, "Handle this by sending this message to that object instead". This primarily affect the "extend a class by having an instance variable" pattern instead of "extend a class by inheriting from it" pattern (which is the only viable way in java, at least as of java 5/6)
Retain/release counting may take more CPU overhead (GC can use generational tricks to only collect small pools with the assumption that it's mostly garbage; retain/release doesn't have that, and has the overhead of tracking "autorelease"), but sometimes it is really cheap for the programmer.
(*): Ok, 2 deficiencies: the JVM does not put enough information on the stack for the error handling routines to resend a failed message to a new target. In other words, when you catch an exception for "this message cannot be sent to that object", you do not have all of the arguments and original receiving object, and cannot say, "Handle this by sending this message to that object instead". This primarily affect the "extend a class by having an instance variable" pattern instead of "extend a class by inheriting from it" pattern (which is the only viable way in java, at least as of java 5/6)
Interesting.
I've seen something like this. Massive lags, long delays before getting responses, etc.
We tracked it down. I was working with Draco on testing for Reasonable Realism. It was tracked down to the behavior of volatile gas. And we found a rather strange bug in his code, and a bug in loaded chunk detection.
He had implemented code to let gas flow through "hollow" blocks, like open doors, or fence posts. Well, fence posts occur in mineshafts. He didn't check if there was solid blocks past that, so once a mineshaft had gas, gas would flow through solid stone (that was his bug). But he was constantly checking the chunks he was looking at to see if they were loaded, and they were constantly returning true.
We found very, very long, single-chunk wide sections of created terrain, sometimes going over 1,000 chunks. Because, in 1710, caves are less frequent -- and now it's possible to go that far before finding a cave in that straight line.
Apparently, chunks always returning "loaded" isn't just us -- Reika's had that same problem with reactors (his reactor tiles get ticked, can't tell unloaded, so generate a fission entity ... which sits and piles up).
Draco solved this, and the massive problems with gas delays went bye-bye.
Ping times, as far as I can tell, don't require a round-trip through the server's processing queue, but is handled by the network layer. So ... it's a low-level, "probably is not <synonym for useful beginning with g>" number
Well, there are many garbage collected langs that are more preformant than Java or C#. Haskell comes to mind, can be very fast if done right and threaded...although that wouldn't be easy for game dev, or in the hands of Mojang. But I agree, manual collection should be an option for all langs, but not required. Or for MC you could drop down to C++ (does Java have C interop?) for any extremely preformance intensive parts
It can thunk to native, but then you start having potential problems with cross platform compatibility.
Just to give this some concrete dimension: Minecraft uses the following "platform native" Java libraries: lwjgl, openAl, libmp3lame and the twichsdk. Just check the "natives" folder under your versions folder in ~/.minecraft/versions/1.7.10 to see the .dll / .dylib / .so used on your platform.
Well, you could setup a build script to compile c++ to the different natives and put it in...that shouldn't have platform-specific problems because c++ is cross-platform, although any if platform stuff in c++ could break
Just gonna say this was educational to read and what irks me is no good Aussie servers for minecraft ftb 
Sent from my iPhone using Tapatalk
Sent from my iPhone using Tapatalk
Eh, saying the language doesn't matter at all is a bit idealistic for my liking. Some languages will do strange things if you try to stick them where they don't belong, and other languages are just extremely limited. JavaScript and ActionScript are both examples of languages that should be used carefully, as is Haskell.
The concern here is not just the people who wrote the original code, but those who also write the new code. Would you be happy to write mods in Netlogo?
I'm not sure if this is directed at me, but I wasn't implying a direct relationship between C# and performance, rather:
- Minecraft should be rewritten from the ground up;
- rewriting it should be done with care towards performance;
- it should be rewritten in C# rather than Java. I would also accept C++ but I don't know how necessary that is given that MC already runs okay on badly written Java.
I don't really know if C# or Java is faster, they were about equal last I checked, but I believe C# is just a more powerful language in terms of development. It's more frequently updated and better supported, has better core libraries, multi threading support, etc. + multiple languages on an open source runtime. I don't expect Mojang to rewrite it, I expect Microsoft to rewrite it. I don't expect people to ferry around .jar files or mess with some API, I expect Microsoft to provide a powerful modding toolkit. For a game as simple as Minecraft, and a company as big as Microsoft, this would be beyond trivial.
While it's true that Java doesn't cause bad performance by itself, it definitely doesn't help either. For example, it has no support for value types, so if you want to do something like BlockPos, you have to rely on JVM optimizations to "fix" it for you - and sometimes the JVM won't be able to do those optimizations for some weird and unrelated reason, and then you get horrible lag.
An open-source C++ clone would probably enable modding to the same degree, except that instead of coremods, you'd have to merge source file changes (which Git does decently already). Likely there would be a source-file-mod like Forge, to perform all the source file changes needed by various mods and then provide a mechanism to load plugins at load-time.
No, not specifically. I have seen other posts on these forums as well as other places advocating ditching Java for C# as if it would cure the ills of Minecraft. The language isn't the problem, its the fundamental design/architecture.
As for C++ I think it has its own set of issues. Yes, it could help tremendously with performance and provides a high degree of flexibility for getting things done. Downside memory management becomes a real big issue. Of course, C++/CLR (or whatever MSFT calls it now a days) could be used, but then you are talking managed execution environments, again.
As for things I dislike about Java - type erasure with generics. :\ As mentioned prior I have done quite a bit of C# and C++ development and I find Java's type erasure disconcerting.
Language matters, but not as much as how plain terrible Mojang is at optimization...
Also, insulting haskell...for shame
- Agreed MC should be rewritten
- Amen
- I don't agree here. While I can agree that I don't want to see Java, I don't think taking the plunge and rewriting it just for the switch from Java to C# is worth it. As far as what I would like to see, I would think something like Rust or C++, preferably Rust. Even if it was rewritten in Java the rewrite would be much more performant
Another thing about C# and .NET. Althought the runtime is becoming cross-platform, that does not mean that all the libraries will be, some of the harder to port libs are crucial to MC. For example, a lot of file stuff is handled extremely differently between windows and OS X, and some things may not be ported or even portable. Thus using .NET on a project that has so many Mac and Linux users, around 15% are *nix users IIRC, which for a game as big as minecraft is huge, is impractical.
That might work, but then each modpack has to be literally compiled, which might be a hassle and would probably require a lot of libraries to be available on the host system. And when it rains compilation problems, it pours.
In this case probably, someone who makes a modpack for other people to use will need to compile it, and cross-compile it to different targets if sensible, and distribute binaries. Only techically adept people would be able to do that. And I don't even want to think about mod licenses there...
It was already difficult enough for me to get a rendering engine going on my Windows system, and setting up a compiler on Windows isn't a cakewalk either.
Horror stories, mate. Let's stay at Java or a similar language if we ever want modding on the scale that we have now
Actually, you could have an official build script to build for different targets for modpacks. And forge would be the only mod that would have to be doing the actual merging. So not as bad, still bad, but not as badThat might work, but then each modpack has to be literally compiled, which might be a hassle and would probably require a lot of libraries to be available on the host system. And when it rains compilation problems, it pours.
In this case probably, someone who makes a modpack for other people to use will need to compile it, and cross-compile it to different targets if sensible, and distribute binaries. Only techically adept people would be able to do that. And I don't even want to think about mod licenses there...
It was already difficult enough for me to get a rendering engine going on my Windows system, and setting up a compiler on Windows isn't a cakewalk either.
Horror stories, mate. Let's stay at Java or a similar language if we ever want modding on the scale that we have now
Don't forget crossplatform requirement, java is out of the box cross-platform
With C++ each mod (or modpack) would need to be recompiled for each platform and there are enough mac and unix users playing MC to make that a requirement. Though having mods be DLLs that get loaded and hooked would be "simpler" than doing source or binary patches. Or hook in a scripting engine
With C# you can turn to Mono for *nix compatibility. And you can use .net DLLs to plug in your mods (Kerbal Space Program does that)
With C++ each mod (or modpack) would need to be recompiled for each platform and there are enough mac and unix users playing MC to make that a requirement. Though having mods be DLLs that get loaded and hooked would be "simpler" than doing source or binary patches. Or hook in a scripting engine
With C# you can turn to Mono for *nix compatibility. And you can use .net DLLs to plug in your mods (Kerbal Space Program does that)
That's what we are talking about by compiling to different targets
Problem with that is Mono isn't all .Net libraries...