I understand what you're talking about man, I totally know what you mean by disappointment. However, I don't think that everything was a disappointment, I feel that someone will make use of what was given to us. (Someone made a working computer in Minecraft, give it a couple years, someone will be able to give us a trick with armor stands or something. lol) If I have to be honest, it feels that in 1.8, while a lot was added, there were subtractions too. A good example of this is performance, which is a key role in game play. I'm disappointed that we waited for almost a year, and we got a shaky game in return, in which patches are needed to correct. You'd think that after almost a year, those issues would be ironed out. I'm not a programmer, I know what programming language requires and looks like, but I don't think that it's that hard to fix old problems when you're easily adding new ones...
Mojang, I hope you can make 1.9 interesting, can you please fix the performance issues?
I understand what you're talking about man, I totally know what you mean by disappointment. However, I don't think that everything was a disappointment, I feel that someone will make use of what was given to us. (Someone made a working computer in Minecraft, give it a couple years, someone will be able to give us a trick with armor stands or something. lol) If I have to be honest, it feels that in 1.8, while a lot was added, there were subtractions too. A good example of this is performance, which is a key role in game play. I'm disappointed that we waited for almost a year, and we got a shaky game in return, in which patches are need to correct. You'd think that after almost a year, those issues would be ironed out. I'm not a programmer, I know what programming language requires and looks like, but I don't think that it's that hard to fix old problems when you're easily adding new ones...
Mojang, I hope you can make 1.9 interesting, can you please fix the performance issues?
If this was the first post, then this thread would be a heck of a lot more civilized.
I understand what you're talking about man, I totally know what you mean by disappointment. However, I don't think that everything was a disappointment, I feel that someone will make use of what was given to us. (Someone made a working computer in Minecraft, give it a couple years, someone will be able to give us a trick with armor stands or something. lol) If I have to be honest, it feels that in 1.8, while a lot was added, there were subtractions too. A good example of this is performance, which is a key role in game play. I'm disappointed that we waited for almost a year, and we got a shaky game in return, in which patches are need to correct. You'd think that after almost a year, those issues would be ironed out. I'm not a programmer, I know what programming language requires and looks like, but I don't think that it's that hard to fix old problems when you're easily adding new ones...
Mojang, I hope you can make 1.9 interesting, can you please fix the performance issues?
There's always going to be performance issues that Mojang needs to correct, every update adds new content to the game which "fills the blank spots in the various lists" so to speak, so as new content is being added, the game is gradually being pushed further and further, that's what 1.8 tried to change. 1.8 brought in a rendering engine rewrite, the old rendering engine was big and clunky (basically, each block had a value assigned that stood as a rendering ID, if the ID was 0, it would render as a normal cube, if it was -1, the block renderer wouldn't render anything and instead call the tile entity renderer assigned for that block, if it was 1 or something, all the way up until 30 something I think, the block renderer would call different methods to render different block types, like one would be crossed squares, which is used for plants, another would be a torch renderer, another would be a cauldron renderer, etc), the new one is nice and dynamic, instead of hardcoding each render, they're assigned in model files, which is much better in terms of "code clunkiness", but is bad because the resources are now bigger, and some models that mods use are insanely big with the new model format (Skyboy, one of the devs of MineFactory Reloaded, said that one of the models for MFR was like 50GB in size, another modder theorised that another block would total up to 9 petabytes or something like that, due to the amount of JSON files needed for each type of model (basically it was a block, with 9 squares on each face, each square could be independently hidden from the others, so that's 54 squares, I don't know how many possibilities it was off the top of my head, but the number was huge, and JSON files needed to be made for each and every possibility, and a single JSON file cannot be used for 2 or more possibilities.
Rollback Post to RevisionRollBack
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
I'm aware of the new rendering engine, as it was partially added in 1.7, which was quite nice. Even then, it's hard for me to believe that adding a new entity, regardless of size, causes black spots to come/become more prevalent than before the update. That's like (Mind my jargon, as I am a 3d animator/modeler after all...) me adding a another object to my scene that I built, depending on how many polygons I have/surface color and intensity of that color (You know, the properties of the RGB that color it has), it's going to affect the lighting around the object, simple, we all saw that coming. However, the fact that I'm supposed to believe that the object/mesh I just created is going to affect lighting 50 feet away from it is plain silly (Unless the object is really that big to begin with...), whilst I don't blame the performance issues on the fact of poor programming, I do find it hard to believe that every small addition effects the processing in every way, even if it's something so small and low-poly. (Armor stands, as an example.) I doubt that the addition of armor stands cause that many performance issues.
Then again, I don't know much about the intricacies of programming, so all of that could be steam coming out of my ass.
Rollback Post to RevisionRollBack
Ever wanted to play Minecraft on your own difficulty? I did too, and now I'm getting better by practicing at my own pace!
If this was the first post, then this thread would be a heck of a lot more civilized.
Really? Wow, thanks, but I really feel it is undeserving for me to accept that, as I haven't read the negativity in this post... (Please tell me it's not as bad as I think it is...)
Rollback Post to RevisionRollBack
Ever wanted to play Minecraft on your own difficulty? I did too, and now I'm getting better by practicing at my own pace!
I'm aware of the new rendering engine, as it was partially added in 1.7, which was quite nice. Even then, it's hard for me to believe that adding a new entity, regardless of size, causes black spots to come/become more prevalent than before the update. That's like (Mind my jargon, as I am a 3d animator/modeler after all...) me adding a another object to my scene that I built, depending on how many polygons I have/surface color and intensity of that color (You know, the properties of the RGB that color it has), it's going to affect the lighting around the object, simple, we all saw that coming. However, the fact that I'm supposed to believe that the object/mesh I just created is going to affect lighting 50 feet away from it is plain silly (Unless the object is really that big to begin with...), whilst I don't blame the performance issues on the fact of poor programming, I do find it hard to believe that every small addition effects the processing in every way, even if it's something so small and low-poly. (Armor stands, as an example.) I doubt that the addition of armor stands cause that many performance issues.
Then again, I don't know much about the intricacies of programming, so all of that could be steam coming out of my ass.
It affects it in big ways, but to answer your point of an object affecting light 50 feet away, because Minecraft renders the world chunk-by-chunk, all it takes is one block that screws up some OpenGL code to instantly break the rendering for the entire chunk. One example is trying to render a model in an ISimpleBlockRenderingHandler (a type of Forge block renderer that is designed for the upmost simple renderers, those fancy ores you see that glow in the dark use ISimpleBlockRenderingHandler's (shortened to ISBRH)). Attempt to do that and the textures are all converted into flat colours in the entire chunk. So, instead of the top of grass being what it usually is, many different shades of green, it instead renders as a single shade of green. I'm fairly certain this is because of one of the OpenGL flags that ISBRH automatically sets before the actual rendering method is called. Anyways.
Adding one new thing affects Minecraft in a huge way, the specific way it affects Minecraft is dependent on the type of thing it is, if it's say a new decoration block, it won't affect the game in a big way, but if it's a new tile entity, then it affects the game in a huge way due to the mapping and such that the tile entity goes through, and if said tile entity is generated in the terrain, it affects the game in an even bigger way.
This is because Java is not a concurrently processed language, what this means is Java does not by default execute code simultaneously. You can make your code execute concurrently, but that's going to introduce more things to worry about. So, what this means for Minecraft is this. Each tile entity loaded in the world has a method called updateEntity(), that is called every tick. A tile entity can add code in this method to introduce logic to itself, this is how a furnace can count down a smelting operation or the fuel durability. The game needs to iterate / loop over every single tile entity loaded, and cannot move on to a new tile entity until the current one has finished. How does this affect performance? If the tile entity has a large amount of code to run through, it takes longer to complete execution of the current tile entity and move on to the next one, so the world updates slightly slower. This isn't intensive in small proportions, but upsize it, say an ore is a tile entity that say looks at it's surroundings and performs logic on it's surroundings, and lets say there's an average of 30 generate per chunk. That's 30 intensive tile entities that the game needs to tick, wait for execution, then move on to the next one. Add the other tile entities, say furnaces, and it's more stuff for the game to calculate.
Other things also operate in the exact same way, all entities (creatures, the player, minecarts, boats, dropped items, arrows, particles, snowballs, etc) tick in the same way, rendering happens the same way, and as you add it all up, as things are added, it can affect performance in a big way. This is what optimisation fixes. One of the ways to optimise a program is to go over some code and rewrite portions of code so that they take less time to execute. Instead of say checking if a boolean is true like this:
if(someBoolean == true) {
// Do stuff
}
We can do this:
if(someBoolean) {
// Do stuff
}
In a compiled language like Java, I don't think this changes much, but in an interpreted language like Python, it means less stuff for the interpreter to read, thus slightly faster execution.
A better example:
int x = 8;
double d = x - (x / 2);
Optimises into:
int x = 8;
double d = x / 2;
Less work during execution (pretty sure the compiler optimises that, but it's the same principle).
Rollback Post to RevisionRollBack
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
Damn, I had no idea that Minecraft actually gets affected by every tiny little detail. What you said about the code being what it is makes sense. I take it that if this game were written in a form of one of the "C" programming languages, this would render much faster?
Thanks for the explanation on that. I just wish that things were like Minecraft 1.0, 'cause when I played it then, there were no lighting issues/performance drops or anything, that is until Minecraft 1.2 came along...
Rollback Post to RevisionRollBack
Ever wanted to play Minecraft on your own difficulty? I did too, and now I'm getting better by practicing at my own pace!
I actually didn't mind the 1.8 update, even tho it took long for it to update it introduced stuff that were actually pretty cool, the new fish was a good idea since there was nothing hostile in the water, it gave more of a challenge and that's what I like about games is the challenge and the effort you need to put in to survive!
Damn, I had no idea that Minecraft actually gets affected by every tiny little detail. What you said about the code being what it is makes sense. I take it that if this game were written in a form of one of the "C" programming languages, this would render much faster?
Thanks for the explanation on that. I just wish that things were like Minecraft 1.0, 'cause when I played it then, there were no lighting issues/performance drops or anything, that is until Minecraft 1.2 came along...
Writing it in C would make the game run faster, but the same issues would still occur, and things would also be more prone to issues. Minecraft largely relies on Java now, because of how many libraries it depends on and how the code is set up.
Minecraft relies heavily on a library called LWJGL (Lightweight Java Gaming Library), which is a library which includes several smaller libraries that help in game development, including an OpenGL package, keyboard input tools, mouse input tools, etc, it also relies on several other libraries such as Netty and Paulscode, which AFAIK don't have C-supported library versions.
Minecraft also relies heavily on how Java works with object-oriented programming, and Forge relies even more so with reflection and the ASM library (reflection is the basic principle that a program can examine and manipulate the internals of the program during runtime. In Java, there is a built in library that allows reflection to occur, using this you can view and work with any object without knowing any explicit information about said object, so using the reflection API you can say grab a generic Class instance of a class loaded into the environment, then say look at the methods, find a specific method using it's name and parameter types, then invoke it, all without having to directly reference said class and method. This is how ForgeModLoader can load mods without the mod directly telling FML where to find it's main class, FML uses reflection to view each class as it's being loaded into the JVM, and then look to see if the current class instance has the @Mod annotation, if it does, it knows that class is the main mod class and FML can now work with said class, and this is the basic principle of how most mods can use classes from other mods without having the other mod as a dependency. I'm not sure if C has a native built in library that allows this type of reflection to occur).
As I said, moving to C won't fix the issue of optimisation, sure, the code would be executed quicker as C is a lower-level language, meaning it is closer to the CPU, Java compiles down into something called JVM bytecode, which the JVM then executes (fun fact, and you may not understand this but eh, but the Java code you write is more so treated as a template for the compiler to use, take another JVM-based language like say Scala, when Scala is compiled down, it is compiled down into the exact same bytecode as Java code is, so you can take a Scala-programmed class file, and AFAIK the JRE should be able to execute it fine, this is the reason why you can use either Java or Scala, or surprisingly both, to write mods). So, what happens is you write your high-level code (search up Java source code, you should be looking at some source code which you should at least understand a tiny bit, at least the simplest relationships going on, ie what each thing is) into a standard text document with the .java extension, then you compile it and if your code is error-free and good for execution, you will be given a .class file out. If you open the .jar file for Minecraft up, these files are what you can see. What's inside them? These files store the bytecode instructions. JVM bytecode is close to the same form of code your CPU executes (I will include some examples at the bottom, I don't expect you to understand them, but this is a glimpse into what code is stored inside those .class files and what exact code is actually being executed, I'll also include some optimisation examples too), however, they are not exactly the same as the code your CPU executes. Think of JVM bytecode as a "middle man" form of code, some portions are custom instructions that your CPU does not know how to execute, but how are they executed? The JVM (Java Virtual Machine) reads the bytecode and interprets it, then translates it into machine code (the final code your CPU executes) just before the program is actually started. This form of bytecode compilation is known as Just-In-Time compilation (or JIT compilation), you can read this for a detailed explanation of JIT compilation and bytecode in general.
C languages on the other hand are not compiled using JIT compilation, the class files that you get from compiling C source code actually store the exact code your CPU is executing, this is why C is referred to as being faster than Java, Java compiles down into bytecode that must be translated for the CPU to execute it, however C compiles down into bytecode that your CPU can execute without translation.
Both languages still go through the same issue as optimisation however, optimisation is an issue that trumps every single language and every single programmer, the only way to get rid of it is to optimise your code as well as you can, rewrite portions of your code to perform the same function, but be smaller in size and thus quicker to compile and execute.
JVM Bytecode Examples:
I don't expect you to understand these, but it's probably interesting to look at what code the JVM actually executes. Do note that these are translated into mnemonics, which basically are textual names for instructions that are actually stored as bytes (a byte is a group of 8 binary bits, or single values, in case you don't know, so yes, each instruction is stored in a single byte, sometimes instructions can carry over to two bytes, but most of the time it's a single byte.
Java source code:
public static void helloWorld()
{
System.out.println("Hello World");
}
A Cat program is basically a program that continuously takes user input, then prints the input back out to the user. I have modified mine to include a function where you can type 'exit' to exit the loop, thus stopping the program.
Java source code:
public static void catProgram()
{
boolean running = true;
Scanner in = new Scanner(System.in);
while (running)
{
String input = in.nextLine();
System.out.println(input);
if (input.equalsIgnoreCase("exit"))
{
running = false;
}
}
}
Oh NO you did not. This is a horrid, shortsighted overview of 1.8.
1.8 altered a ton of Minecraft code in preparation for the modding API, which is why it took so long mostly. The commands, though you are a *shudder* casual player. Players like me LOVE the new design and commands, because of all the things we can do. Armor Stands? They're some cool decoration, but there's much more. May I introduce to you the {Pose:} tag, the {ShowArms:} tag, the {NoGravity:} tag, the {NoBasePlate:} tag, and the {Invisible:} tag? These make ArmorStands can be used MANY ways. I can take a screenshot of a world if you want. They can be NPCs, enemies, detailed decorations, and MUCH more things that you can barely imagine.
There is a ton of stuff 1.8 added, way below the surface of what you've described. There was a ton of code added and changed, which is what took the most of it.
And lastly: the whole mods fiasco.
Minecraft doesn't "rip" anything from mods. They see a mod that they think is good enough to be added into the game, and then they do it. There are tons of people who don't use mods. I think Minecraft taking things from mods is a GREAT idea. It means it's been added into the core game and people don't have to install mods or mod loaders or anything to get the stuff in their own game.
Rollback Post to RevisionRollBack
(It's "VMod" when used in a title or beginning of a sentence, and "vmod" otherwise. LEARN IT)
Maker of multiple vanilla mods, like these:
Link Removed - Overhauls survival with steeper difficulty curve
Java enthusiasts are not a great source of objective information on Java programming. Suffice it to say, there's a reason that 3D games are not coded in Java.
Moving away from Java, to a combination of C++ and a dedicated rendering engine (Unreal, etc.) would allow the game to break some serious performance barriers, enable cubic chunks (or equivalent), and dramatically improve rendering times, reduce lag and utilize GPUs better. Infinite height, insanely far rendering distances, and improved creature AI.
Shoving it all in Java classes is nuts. It is like trying to fill a beercan with a firehose. Even the math processing in Java is limited.
The reality is that Microsoft will probably recode the thing from scratch at some point anyway, as they slowly push out the old Mojangsters, and I would bet it is considering it right now. But I wouldn't expect to see that version for 3-4 years.
Java enthusiasts are not a great source of objective information on Java programming. Suffice it to say, there's a reason that 3D games are not coded in Java.
Moving away from Java, to a combination of C++ and a dedicated rendering engine (Unreal, etc.) would allow the game to break some serious performance barriers, enable cubic chunks (or equivalent), and dramatically improve rendering times, reduce lag and utilize GPUs better. Infinite height, insanely far rendering distances, and improved creature AI.
Shoving it all in Java classes is nuts. It is like trying to fill a beercan with a firehose. Even the math processing in Java is limited.
The reality is that Microsoft will probably recode the thing from scratch at some point anyway, as they slowly push out the old Mojangsters, and I would bet it is considering it right now. But I wouldn't expect to see that version for 3-4 years.
I usually hate Microsoft, but they would do Minecraft some serious justice doing that.
Java enthusiasts are not a great source of objective information on Java programming. Suffice it to say, there's a reason that 3D games are not coded in Java.
Moving away from Java, to a combination of C++ and a dedicated rendering engine (Unreal, etc.) would allow the game to break some serious performance barriers, enable cubic chunks (or equivalent), and dramatically improve rendering times, reduce lag and utilize GPUs better. Infinite height, insanely far rendering distances, and improved creature AI.
Shoving it all in Java classes is nuts. It is like trying to fill a beercan with a firehose. Even the math processing in Java is limited.
The reality is that Microsoft will probably recode the thing from scratch at some point anyway, as they slowly push out the old Mojangsters, and I would bet it is considering it right now. But I wouldn't expect to see that version for 3-4 years.
The game is way too far into development for a move to another language / engine to be effective and efficient, that's the point I was mainly trying to make. Rewriting the game would bring in many advantages, but it would introduce loads of problems too, a lot of the code would have to be rewritten because it relies on Java utilities, it would take a long time to actually rewrite the game to the point where it's on par with what it is currently, modability would be thrown out the window, moving to a mainstream rendering engine would not allow Mojang to customise their engine to suit the game better, and more. Yes, using Java is a horrendously bad idea for game development, but this far into the game, moving to another language would be a worse idea.
On top of that, AFAIK MS is only in as business partners with Mojang, they aren't touching the game unless Mojang gives it up. Both sides have confirmed they're only in it as business partners, Mojang is here to stay, it is still Mojang's property.
Rollback Post to RevisionRollBack
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
Java enthusiasts are not a great source of objective information on Java programming. Suffice it to say, there's a reason that 3D games are not coded in Java.
Moving away from Java, to a combination of C++ and a dedicated rendering engine (Unreal, etc.) would allow the game to break some serious performance barriers, enable cubic chunks (or equivalent), and dramatically improve rendering times, reduce lag and utilize GPUs better. Infinite height, insanely far rendering distances, and improved creature AI.
Shoving it all in Java classes is nuts. It is like trying to fill a beercan with a firehose. Even the math processing in Java is limited.
The reality is that Microsoft will probably recode the thing from scratch at some point anyway, as they slowly push out the old Mojangsters, and I would bet it is considering it right now. But I wouldn't expect to see that version for 3-4 years.
To add even more perspective to this I've tested Minecraft vs Block Story in a new clean free VMWare Player 7 (ws11) VM under Windows 7 Ultimate 64bit.
- The VM was given 2 cores at 3.0 Ghz each, 8GB Ram and plenty of HD space. It ran 64bit Windows 7 Home Premium and had NO JAVA installed.
- Minecraft was downloaded and installed directly from minecraft.net from within the VM. The Windows installers at minecraft.net are the new one that set up their ideal version of JAVA themselves.
- Block Story was installed via Steam (Yes, happily I have found that Steam can work in at least a VMWare VM, though the games with Securom and worse DRM will likely crash since they don't like being in a VM). VMWare VM's since VMWare Workstation 7 have full support for DX9, the only VM I know to do so.
Minecraft 1.8.1 (with it's launcher provided perfect Java) and all Default settings ran at 1 to 2 fps in seed "1710" created with mc1.8.1.
Block Story (current version from Steam) with all Video settings pushed to maximum except render distances left at default 40h/40v ran at over 360 fps.
Block Story (current version from Steam) with all Video settings pushed to maximum and render distances pushed up to 200h/100v ran at over 165 fps.
I was blown away.. Not only was Block Stories fps at least 110 x Faster but it was smooth and just worked. It's graphics capabilities are so much better too and it has piles of content and mobs. It already has cubic chunks and colored lighting and much more. If I understand correctly this game was coded by 1 or 2 Russian "kids", and the PC version at least written using C# in Unity of all things.. The Mobile cellphone version of Block Story existed before the Minecraft mobile version and also had cubic chunks and virtually unlimited worlds and ran smooth as silk on cellphones way back in the day...
I think we have all at one time or another spent far too much time making excuses for why Minecraft is so slow compared to everything else. But Block Story is hitting me with a hard dose of reality. This "kid" is making the mojang crew look like they couldn't code their way out of a wet paper bag..
* What I would dearly hope Microsoft will do, and what notch could have done early on, is to buy Block Story and hire it's coder or at the very least license it's engine in perpetuity. They could then rebuild the famous look and operation of Minecraft on top of that engine so that it remains Minecraft but BETTER! Heck, they could call if Minecraft 2.0 for all I care.
Here's a link to an old 2012 blog (multi-page) by Block Story's programmer "Paul" where he talks a bit about how he has optimized BlockStory. He doesn't give away all of his secrets but does touch on some interesting points. Please remember that English is not his native language.
Rollback Post to RevisionRollBack
- The Cubic Chunks Mod is back! Be a part of it's rebirth and Development.
-- Robinton's Mods: [ Mirror ] for some of his Mods incl Cubic Chunks Mod, due to DropBox broken links.
To add to the above: I will test them both on that system outside of the VM too, but it's my hope to be able to play as many of my games from within VM as possible and this test has shown me that Minecraft will sadly not be one I can do that with.
Frankly I was very surprised by those results, I fully expected Minecraft to get at least 30-60 fps minimum which would have been enough for me.
EDIT-- VMWare is supposed to support Hardware OpenGL acceleration, but these results are making me think it isn't active for some reason. When I get home I will poke around in the settings and see what I can find. I dearly hope this Minecraft performance can be improved!
EDITx2-- VMware supports OpenGL 2.1
Rollback Post to RevisionRollBack
- The Cubic Chunks Mod is back! Be a part of it's rebirth and Development.
-- Robinton's Mods: [ Mirror ] for some of his Mods incl Cubic Chunks Mod, due to DropBox broken links.
Mojang, I hope you can make 1.9 interesting, can you please fix the performance issues?
If this was the first post, then this thread would be a heck of a lot more civilized.
There's always going to be performance issues that Mojang needs to correct, every update adds new content to the game which "fills the blank spots in the various lists" so to speak, so as new content is being added, the game is gradually being pushed further and further, that's what 1.8 tried to change. 1.8 brought in a rendering engine rewrite, the old rendering engine was big and clunky (basically, each block had a value assigned that stood as a rendering ID, if the ID was 0, it would render as a normal cube, if it was -1, the block renderer wouldn't render anything and instead call the tile entity renderer assigned for that block, if it was 1 or something, all the way up until 30 something I think, the block renderer would call different methods to render different block types, like one would be crossed squares, which is used for plants, another would be a torch renderer, another would be a cauldron renderer, etc), the new one is nice and dynamic, instead of hardcoding each render, they're assigned in model files, which is much better in terms of "code clunkiness", but is bad because the resources are now bigger, and some models that mods use are insanely big with the new model format (Skyboy, one of the devs of MineFactory Reloaded, said that one of the models for MFR was like 50GB in size, another modder theorised that another block would total up to 9 petabytes or something like that, due to the amount of JSON files needed for each type of model (basically it was a block, with 9 squares on each face, each square could be independently hidden from the others, so that's 54 squares, I don't know how many possibilities it was off the top of my head, but the number was huge, and JSON files needed to be made for each and every possibility, and a single JSON file cannot be used for 2 or more possibilities.
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
My Github page.
The entire Minecraft shader development community now has its own Discord server! Feel free to join and chat with all the developers!
OH BABY A TRIPLE
Then again, I don't know much about the intricacies of programming, so all of that could be steam coming out of my ass.
Really? Wow, thanks, but I really feel it is undeserving for me to accept that, as I haven't read the negativity in this post... (Please tell me it's not as bad as I think it is...)
Well, no. This has been a large coil. That is to say, it has been going in circles, and getting longer each time.
I give up. This debate is endless.
Ah, well we are just stating our opinions. (I at least hope we are, no need to be hostile here.)
This statement covers all discussions about anything on Internet.
It affects it in big ways, but to answer your point of an object affecting light 50 feet away, because Minecraft renders the world chunk-by-chunk, all it takes is one block that screws up some OpenGL code to instantly break the rendering for the entire chunk. One example is trying to render a model in an ISimpleBlockRenderingHandler (a type of Forge block renderer that is designed for the upmost simple renderers, those fancy ores you see that glow in the dark use ISimpleBlockRenderingHandler's (shortened to ISBRH)). Attempt to do that and the textures are all converted into flat colours in the entire chunk. So, instead of the top of grass being what it usually is, many different shades of green, it instead renders as a single shade of green. I'm fairly certain this is because of one of the OpenGL flags that ISBRH automatically sets before the actual rendering method is called. Anyways.
Adding one new thing affects Minecraft in a huge way, the specific way it affects Minecraft is dependent on the type of thing it is, if it's say a new decoration block, it won't affect the game in a big way, but if it's a new tile entity, then it affects the game in a huge way due to the mapping and such that the tile entity goes through, and if said tile entity is generated in the terrain, it affects the game in an even bigger way.
This is because Java is not a concurrently processed language, what this means is Java does not by default execute code simultaneously. You can make your code execute concurrently, but that's going to introduce more things to worry about. So, what this means for Minecraft is this. Each tile entity loaded in the world has a method called updateEntity(), that is called every tick. A tile entity can add code in this method to introduce logic to itself, this is how a furnace can count down a smelting operation or the fuel durability. The game needs to iterate / loop over every single tile entity loaded, and cannot move on to a new tile entity until the current one has finished. How does this affect performance? If the tile entity has a large amount of code to run through, it takes longer to complete execution of the current tile entity and move on to the next one, so the world updates slightly slower. This isn't intensive in small proportions, but upsize it, say an ore is a tile entity that say looks at it's surroundings and performs logic on it's surroundings, and lets say there's an average of 30 generate per chunk. That's 30 intensive tile entities that the game needs to tick, wait for execution, then move on to the next one. Add the other tile entities, say furnaces, and it's more stuff for the game to calculate.
Other things also operate in the exact same way, all entities (creatures, the player, minecarts, boats, dropped items, arrows, particles, snowballs, etc) tick in the same way, rendering happens the same way, and as you add it all up, as things are added, it can affect performance in a big way. This is what optimisation fixes. One of the ways to optimise a program is to go over some code and rewrite portions of code so that they take less time to execute. Instead of say checking if a boolean is true like this:
if(someBoolean == true) { // Do stuff }We can do this:
if(someBoolean) { // Do stuff }In a compiled language like Java, I don't think this changes much, but in an interpreted language like Python, it means less stuff for the interpreter to read, thus slightly faster execution.
A better example:
Optimises into:
Less work during execution (pretty sure the compiler optimises that, but it's the same principle).
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
My Github page.
The entire Minecraft shader development community now has its own Discord server! Feel free to join and chat with all the developers!
Thanks for the explanation on that. I just wish that things were like Minecraft 1.0, 'cause when I played it then, there were no lighting issues/performance drops or anything, that is until Minecraft 1.2 came along...
Writing it in C would make the game run faster, but the same issues would still occur, and things would also be more prone to issues. Minecraft largely relies on Java now, because of how many libraries it depends on and how the code is set up.
Minecraft relies heavily on a library called LWJGL (Lightweight Java Gaming Library), which is a library which includes several smaller libraries that help in game development, including an OpenGL package, keyboard input tools, mouse input tools, etc, it also relies on several other libraries such as Netty and Paulscode, which AFAIK don't have C-supported library versions.
Minecraft also relies heavily on how Java works with object-oriented programming, and Forge relies even more so with reflection and the ASM library (reflection is the basic principle that a program can examine and manipulate the internals of the program during runtime. In Java, there is a built in library that allows reflection to occur, using this you can view and work with any object without knowing any explicit information about said object, so using the reflection API you can say grab a generic Class instance of a class loaded into the environment, then say look at the methods, find a specific method using it's name and parameter types, then invoke it, all without having to directly reference said class and method. This is how ForgeModLoader can load mods without the mod directly telling FML where to find it's main class, FML uses reflection to view each class as it's being loaded into the JVM, and then look to see if the current class instance has the @Mod annotation, if it does, it knows that class is the main mod class and FML can now work with said class, and this is the basic principle of how most mods can use classes from other mods without having the other mod as a dependency. I'm not sure if C has a native built in library that allows this type of reflection to occur).
As I said, moving to C won't fix the issue of optimisation, sure, the code would be executed quicker as C is a lower-level language, meaning it is closer to the CPU, Java compiles down into something called JVM bytecode, which the JVM then executes (fun fact, and you may not understand this but eh, but the Java code you write is more so treated as a template for the compiler to use, take another JVM-based language like say Scala, when Scala is compiled down, it is compiled down into the exact same bytecode as Java code is, so you can take a Scala-programmed class file, and AFAIK the JRE should be able to execute it fine, this is the reason why you can use either Java or Scala, or surprisingly both, to write mods). So, what happens is you write your high-level code (search up Java source code, you should be looking at some source code which you should at least understand a tiny bit, at least the simplest relationships going on, ie what each thing is) into a standard text document with the .java extension, then you compile it and if your code is error-free and good for execution, you will be given a .class file out. If you open the .jar file for Minecraft up, these files are what you can see. What's inside them? These files store the bytecode instructions. JVM bytecode is close to the same form of code your CPU executes (I will include some examples at the bottom, I don't expect you to understand them, but this is a glimpse into what code is stored inside those .class files and what exact code is actually being executed, I'll also include some optimisation examples too), however, they are not exactly the same as the code your CPU executes. Think of JVM bytecode as a "middle man" form of code, some portions are custom instructions that your CPU does not know how to execute, but how are they executed? The JVM (Java Virtual Machine) reads the bytecode and interprets it, then translates it into machine code (the final code your CPU executes) just before the program is actually started. This form of bytecode compilation is known as Just-In-Time compilation (or JIT compilation), you can read this for a detailed explanation of JIT compilation and bytecode in general.
C languages on the other hand are not compiled using JIT compilation, the class files that you get from compiling C source code actually store the exact code your CPU is executing, this is why C is referred to as being faster than Java, Java compiles down into bytecode that must be translated for the CPU to execute it, however C compiles down into bytecode that your CPU can execute without translation.
Both languages still go through the same issue as optimisation however, optimisation is an issue that trumps every single language and every single programmer, the only way to get rid of it is to optimise your code as well as you can, rewrite portions of your code to perform the same function, but be smaller in size and thus quicker to compile and execute.
JVM Bytecode Examples:
I don't expect you to understand these, but it's probably interesting to look at what code the JVM actually executes. Do note that these are translated into mnemonics, which basically are textual names for instructions that are actually stored as bytes (a byte is a group of 8 binary bits, or single values, in case you don't know, so yes, each instruction is stored in a single byte, sometimes instructions can carry over to two bytes, but most of the time it's a single byte.
Java source code:
public static void helloWorld() { System.out.println("Hello World"); }JVM bytecode:
// access flags 0x9 public static helloWorld()V L0 LINENUMBER 23 L0 GETSTATIC java/lang/System.out : Ljava/io/PrintStream; LDC "Hello World" INVOKEVIRTUAL java/io/PrintStream.println (Ljava/lang/String;)V L1 LINENUMBER 24 L1 RETURN MAXSTACK = 2 MAXLOCALS = 0Java source code:
public static void addition() { int answer = 7 + 3; System.out.println(answer); }JVM bytecode:
// access flags 0x9 public static addition()V L0 LINENUMBER 16 L0 BIPUSH 10 ISTORE 0 L1 LINENUMBER 18 L1 GETSTATIC java/lang/System.out : Ljava/io/PrintStream; ILOAD 0 INVOKEVIRTUAL java/io/PrintStream.println (I)V L2 LINENUMBER 19 L2 RETURN L3 LOCALVARIABLE answer I L1 L3 0 MAXSTACK = 2 MAXLOCALS = 1A Cat program is basically a program that continuously takes user input, then prints the input back out to the user. I have modified mine to include a function where you can type 'exit' to exit the loop, thus stopping the program.
Java source code:
public static void catProgram() { boolean running = true; Scanner in = new Scanner(System.in); while (running) { String input = in.nextLine(); System.out.println(input); if (input.equalsIgnoreCase("exit")) { running = false; } } }JVM bytecode:
// access flags 0x9 public static catProgram()V L0 LINENUMBER 28 L0 ICONST_1 ISTORE 0 L1 LINENUMBER 30 L1 NEW java/util/Scanner DUP GETSTATIC java/lang/System.in : Ljava/io/InputStream; INVOKESPECIAL java/util/Scanner.<init> (Ljava/io/InputStream;)V ASTORE 1 L2 LINENUMBER 32 L2 GOTO L3 L4 LINENUMBER 34 L4 FRAME APPEND [I java/util/Scanner] ALOAD 1 INVOKEVIRTUAL java/util/Scanner.nextLine ()Ljava/lang/String; ASTORE 2 L5 LINENUMBER 36 L5 GETSTATIC java/lang/System.out : Ljava/io/PrintStream; ALOAD 2 INVOKEVIRTUAL java/io/PrintStream.println (Ljava/lang/String;)V L6 LINENUMBER 38 L6 ALOAD 2 LDC "exit" INVOKEVIRTUAL java/lang/String.equalsIgnoreCase (Ljava/lang/String;)Z IFEQ L3 L7 LINENUMBER 40 L7 ICONST_0 ISTORE 0 L3 LINENUMBER 32 L3 FRAME SAME ILOAD 0 IFNE L4 L8 LINENUMBER 43 L8 RETURN L9 LOCALVARIABLE running Z L1 L9 0 LOCALVARIABLE in Ljava/util/Scanner; L2 L9 1 LOCALVARIABLE input Ljava/lang/String; L5 L3 2 MAXSTACK = 3 MAXLOCALS = 3You will see the IF conditional statement is automatically optimised by the compiler, however the double is not.
Java source code:
public static void optimisationExampleUnoptimised() { boolean b = true; if (b == true) { int x = 8; double d = x - x / 2; } }JVM bytecode:
// access flags 0x9 public static optimisationExampleUnoptimised()V L0 LINENUMBER 47 L0 ICONST_1 ISTORE 0 L1 LINENUMBER 49 L1 ILOAD 0 IFEQ L2 L3 LINENUMBER 51 L3 BIPUSH 8 ISTORE 1 L4 LINENUMBER 53 L4 ILOAD 1 ILOAD 1 ICONST_2 IDIV ISUB I2D DSTORE 2 L2 LINENUMBER 55 L2 FRAME APPEND [I] RETURN L5 LOCALVARIABLE b Z L1 L5 0 LOCALVARIABLE x I L4 L2 1 MAXSTACK = 3 MAXLOCALS = 4Java source code:
public static void optimisationExampleOptimised() { boolean b = true; if (b) { int x = 8; double d = x / 2; } }JVM bytecode:
// access flags 0x9 public static optimisationExampleOptimised()V L0 LINENUMBER 59 L0 ICONST_1 ISTORE 0 L1 LINENUMBER 61 L1 ILOAD 0 IFEQ L2 L3 LINENUMBER 63 L3 BIPUSH 8 ISTORE 1 L4 LINENUMBER 65 L4 ILOAD 1 ICONST_2 IDIV I2D DSTORE 2 L2 LINENUMBER 67 L2 FRAME APPEND [I] RETURN L5 LOCALVARIABLE b Z L1 L5 0 LOCALVARIABLE x I L4 L2 1 MAXSTACK = 2 MAXLOCALS = 4Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
My Github page.
The entire Minecraft shader development community now has its own Discord server! Feel free to join and chat with all the developers!
1.8 altered a ton of Minecraft code in preparation for the modding API, which is why it took so long mostly. The commands, though you are a *shudder* casual player. Players like me LOVE the new design and commands, because of all the things we can do. Armor Stands? They're some cool decoration, but there's much more. May I introduce to you the {Pose:} tag, the {ShowArms:} tag, the {NoGravity:} tag, the {NoBasePlate:} tag, and the {Invisible:} tag? These make ArmorStands can be used MANY ways. I can take a screenshot of a world if you want. They can be NPCs, enemies, detailed decorations, and MUCH more things that you can barely imagine.
There is a ton of stuff 1.8 added, way below the surface of what you've described. There was a ton of code added and changed, which is what took the most of it.
And lastly: the whole mods fiasco.
Minecraft doesn't "rip" anything from mods. They see a mod that they think is good enough to be added into the game, and then they do it. There are tons of people who don't use mods. I think Minecraft taking things from mods is a GREAT idea. It means it's been added into the core game and people don't have to install mods or mod loaders or anything to get the stuff in their own game.
Like them? Post on them! Say your opinion, or suggest more features!
Moving away from Java, to a combination of C++ and a dedicated rendering engine (Unreal, etc.) would allow the game to break some serious performance barriers, enable cubic chunks (or equivalent), and dramatically improve rendering times, reduce lag and utilize GPUs better. Infinite height, insanely far rendering distances, and improved creature AI.
Shoving it all in Java classes is nuts. It is like trying to fill a beercan with a firehose. Even the math processing in Java is limited.
The reality is that Microsoft will probably recode the thing from scratch at some point anyway, as they slowly push out the old Mojangsters, and I would bet it is considering it right now. But I wouldn't expect to see that version for 3-4 years.
I usually hate Microsoft, but they would do Minecraft some serious justice doing that.
The game is way too far into development for a move to another language / engine to be effective and efficient, that's the point I was mainly trying to make. Rewriting the game would bring in many advantages, but it would introduce loads of problems too, a lot of the code would have to be rewritten because it relies on Java utilities, it would take a long time to actually rewrite the game to the point where it's on par with what it is currently, modability would be thrown out the window, moving to a mainstream rendering engine would not allow Mojang to customise their engine to suit the game better, and more. Yes, using Java is a horrendously bad idea for game development, but this far into the game, moving to another language would be a worse idea.
On top of that, AFAIK MS is only in as business partners with Mojang, they aren't touching the game unless Mojang gives it up. Both sides have confirmed they're only in it as business partners, Mojang is here to stay, it is still Mojang's property.
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
My Github page.
The entire Minecraft shader development community now has its own Discord server! Feel free to join and chat with all the developers!
To add even more perspective to this I've tested Minecraft vs Block Story in a new clean free VMWare Player 7 (ws11) VM under Windows 7 Ultimate 64bit.
- The VM was given 2 cores at 3.0 Ghz each, 8GB Ram and plenty of HD space. It ran 64bit Windows 7 Home Premium and had NO JAVA installed.
- Minecraft was downloaded and installed directly from minecraft.net from within the VM. The Windows installers at minecraft.net are the new one that set up their ideal version of JAVA themselves.
- Block Story was installed via Steam (Yes, happily I have found that Steam can work in at least a VMWare VM, though the games with Securom and worse DRM will likely crash since they don't like being in a VM). VMWare VM's since VMWare Workstation 7 have full support for DX9, the only VM I know to do so.
Minecraft 1.8.1 (with it's launcher provided perfect Java) and all Default settings ran at 1 to 2 fps in seed "1710" created with mc1.8.1.
Block Story (current version from Steam) with all Video settings pushed to maximum except render distances left at default 40h/40v ran at over 360 fps.
Block Story (current version from Steam) with all Video settings pushed to maximum and render distances pushed up to 200h/100v ran at over 165 fps.
I was blown away.. Not only was Block Stories fps at least 110 x Faster but it was smooth and just worked. It's graphics capabilities are so much better too and it has piles of content and mobs. It already has cubic chunks and colored lighting and much more. If I understand correctly this game was coded by 1 or 2 Russian "kids", and the PC version at least written using C# in Unity of all things.. The Mobile cellphone version of Block Story existed before the Minecraft mobile version and also had cubic chunks and virtually unlimited worlds and ran smooth as silk on cellphones way back in the day...
I think we have all at one time or another spent far too much time making excuses for why Minecraft is so slow compared to everything else. But Block Story is hitting me with a hard dose of reality. This "kid" is making the mojang crew look like they couldn't code their way out of a wet paper bag..
* What I would dearly hope Microsoft will do, and what notch could have done early on, is to buy Block Story and hire it's coder or at the very least license it's engine in perpetuity. They could then rebuild the famous look and operation of Minecraft on top of that engine so that it remains Minecraft but BETTER! Heck, they could call if Minecraft 2.0 for all I care.
Here's a link to an old 2012 blog (multi-page) by Block Story's programmer "Paul" where he talks a bit about how he has optimized BlockStory. He doesn't give away all of his secrets but does touch on some interesting points. Please remember that English is not his native language.
- The Cubic Chunks Mod is back! Be a part of it's rebirth and Development.
-- Robinton's Mods: [ Mirror ] for some of his Mods incl Cubic Chunks Mod, due to DropBox broken links.
- Dungeon Generator for the Open Cubic Chunks Mod
- QuickSAVE-QuickLOAD for the Open Cubic Chunks Mod
Frankly I was very surprised by those results, I fully expected Minecraft to get at least 30-60 fps minimum which would have been enough for me.
EDIT-- VMWare is supposed to support Hardware OpenGL acceleration, but these results are making me think it isn't active for some reason. When I get home I will poke around in the settings and see what I can find. I dearly hope this Minecraft performance can be improved!
EDITx2-- VMware supports OpenGL 2.1
- The Cubic Chunks Mod is back! Be a part of it's rebirth and Development.
-- Robinton's Mods: [ Mirror ] for some of his Mods incl Cubic Chunks Mod, due to DropBox broken links.
- Dungeon Generator for the Open Cubic Chunks Mod
- QuickSAVE-QuickLOAD for the Open Cubic Chunks Mod