I think that java edition should move over to C++ as it runs better and with C++ and optifine it could run even smoother than bedrock can.(this will be short)
Also Java should add the friends system so for the profile thing you could make a java profile with your username and your skin, you could even have a description! so yeah and you could friend people like on bedrock and have a friends tab in the multiplayer thing and you could join them if they have the setting for friends or friends of friends like on bedrock.
Language has nothing to do with performance - the coding of modern Java versions is simply awful beyond words; for example, consider my own version based on 1.6.4:
Only 80 MB of memory used?! That's simply insane when compared to the latest vanilla versions; it also uses practically no system resources, even at a higher render distance - only 3% CPU and 3 MB of memory allocated per second - and this has not noticeably changed at all despite adding hundreds of new features, maybe even over a thousand by now; if anything, vanilla 1.6.4 uses more resources:
By contrast, newer versions of Java were written as if objects are the only thing that matters and as a result they allocate insane amounts of memory, forcing the garbage collector to constantly work to clean it up:
tldr; When 1.8 is lagging and stuttering the garbage collector is working like crazy and is doing work which has nothing to do with the game itself (rendering, running the internal server, loading chunks, etc). Instead it is constantly cleaning the mess behind the code which thinks that memory allocation is "cheap".
The old Notch code was straightforward and relatively easy to follow. The new rendering system is an over-engineered monster full of factories, builders, bakeries, baked items, managers, dispatchers, states, enums and layers. Object allocation is rampant, small objects are allocated like there is no tomorrow. No wonder that the garbage collector has to work so hard.
Aside from that, over-use of abstraction - even something as basic as xyz coordinates now use an object with method calls required to perform operations on it, as opposed to simple int variables, and a simple block lookup is a long chain of hash table lookups in a block registry, as opposed to simply reading an int value from an array index, with no actual reference to a block object needed in many cases:
public static final boolean isStoneBlock(int block)
{
return (block == BlockStates.stone || block == BlockStates.biomeStone);
}
This is my own code, where "BlockStates" contains a list of int values corresponding to a block ID and/or combined ID and data value (what I call a "block state", not to be confused with 1.8+'s version, which is an object) to avoid the need to even reference block objects (compare to "Block.stone.blockID", which has to look up "Block.stone", then read the "blockID" field; for comparison, "BlockStates.stone" is compiled to "1" so all it needs to do is load the constant "1" into a CPU register). Only if the properties of a block are needed then is a reference needed (e.g. "block.blockMaterial").
Also, "with C++ and Optifine" doesn't even make sense - there should be no need for performance mods at all, not to mention that mods as we know it wouldn't even exist if the game were written in C++ - you can't decompile a C++ .exe as you can with Java class files, I don't even think an .exe even knows about the original source files that went into it, it is all one huge mess of assembly code and even if you could get source back out of it it would be nothing like the original since the C++ compiler performs compile-time optimizations (by contrast, the Java compiler produces intermediate bytecode which is for the most part directly translatable to the original source; only once it is loaded by the JVM is it compiled into native assembly). Plugins/add-ons/data packs/etc are not mods and can only alter what the game's API exposes (even mod APIs like Forge have limitations, forcing modders to make "core mods", or in the case of non-modloader-based mods, "jar mods", that directly modify parts of the game; this is one reason why I never got into Forge modding).
Also, they would need to compile a separate C++ version for Windows, Linux, and Mac, which may even require changes to the code, since as mentioned above the compiler produces platform-specific assembly code which is also optimized for a specific platform; this means that if CPUs add new instructions the game will have to be recompiled in order to take advantage of them (by contrast, with Java you only need to update the JVM). Either way, the majority of performance is down to how you write code, C++ allows you to be lazier but it is not entirely exempt and there are bug reports regarding performance issues on Bedrock:
Language has nothing to do with performance - the coding of modern Java versions is simply awful beyond words; for example, consider my own version based on 1.6.4:
Only 80 MB of memory used?! That's simply insane when compared to the latest vanilla versions; it also uses practically no system resources, even at a higher render distance - only 3% CPU and 3 MB of memory allocated per second - and this has not noticeably changed at all despite adding hundreds of new features, maybe even over a thousand by now; if anything, vanilla 1.6.4 uses more resources:
By contrast, newer versions of Java were written as if objects are the only thing that matters and as a result they allocate insane amounts of memory, forcing the garbage collector to constantly work to clean it up:
Aside from that, over-use of abstraction - even something as basic as xyz coordinates now use an object with method calls required to perform operations on it, as opposed to simple int variables, and a simple block lookup is a long chain of hash table lookups in a block registry, as opposed to simply reading an int value from an array index, with no actual reference to a block object needed in many cases:
public static final boolean isStoneBlock(int block)
{
return (block == BlockStates.stone || block == BlockStates.biomeStone);
}
This is my own code, where "BlockStates" contains a list of int values corresponding to a block ID and/or combined ID and data value (what I call a "block state", not to be confused with 1.8+'s version, which is an object) to avoid the need to even reference block objects (compare to "Block.stone.blockID", which has to look up "Block.stone", then read the "blockID" field; for comparison, "BlockStates.stone" is compiled to "1" so all it needs to do is load the constant "1" into a CPU register). Only if the properties of a block are needed then is a reference needed (e.g. "block.blockMaterial").
Also, "with C++ and Optifine" doesn't even make sense - there should be no need for performance mods at all, not to mention that mods as we know it wouldn't even exist if the game were written in C++ - you can't decompile a C++ .exe as you can with Java class files, I don't even think an .exe even knows about the original source files that went into it, it is all one huge mess of assembly code and even if you could get source back out of it it would be nothing like the original since the C++ compiler performs compile-time optimizations (by contrast, the Java compiler produces intermediate bytecode which is for the most part directly translatable to the original source; only once it is loaded by the JVM is it compiled into native assembly). Plugins/add-ons/data packs/etc are not mods and can only alter what the game's API exposes (even mod APIs like Forge have limitations, forcing modders to make "core mods", or in the case of non-modloader-based mods, "jar mods", that directly modify parts of the game; this is one reason why I never got into Forge modding).
Also, they would need to compile a separate C++ version for Windows, Linux, and Mac, which may even require changes to the code, since as mentioned above the compiler produces platform-specific assembly code which is also optimized for a specific platform; this means that if CPUs add new instructions the game will have to be recompiled in order to take advantage of them (by contrast, with Java you only need to update the JVM). Either way, the majority of performance is down to how you write code, C++ allows you to be lazier but it is not entirely exempt and there are bug reports regarding performance issues on Bedrock:
From what I was able to interpret, it's more to do with the virtual machine that makes Java a problem in the game.
The language itself theoretically shouldn't be a problem, not if it has direct access to the hardware.
this is a problem with all virtual machines, not just Java, because they're simulating an environment that isn't native to the system.
it's kind of like using emulators, sure they can be suitable for gaming, but they're not as efficient as native hardware.
This is why retro gamers often prefer the original systems the games were designed for, they don't have to deal with high latency and the extra glitches that come from emulation, especially poorly designed emulators in combination with cheap hardware that clearly aren't designed for video games.
In the end, no matter how the game is coded or what software it is using to run, you still need a suitable computer and display that at the bare minimum is meeting the requirements. Your mod may have cut out some unnecessary junk but I still wouldn't recommend playing this game on something below spec. You're plenty experienced at this though and you already know this, you've even suggested people use Nvidia dedicated GPU's, not integrated ones.
Your mod may have cut out some unnecessary junk but I still wouldn't recommend playing this game on something below spec.
Do you have any idea of what "below spec" means in the context of older versions of Java? No, do not show me the system requirements for the latest version; here are the system requirements as of July 6, 2013, shortly after the release of 1.6:
Minimum Requirements:
CPU : Intel P4/NetBurst Architecture or its AMD Equivalent (AMD K7)
RAM : 2GB
GPU : Intel GMA 950 or AMD Equivalent with OpenGL 1.2 Support
HDD : At least 90MB for Game Core and Sound Files
Java Runtime Environment (JRE) 6 or up is required to be able to run the game.
Recommended Requirements:
CPU : Intel Pentium D or AMD Athlon 64 (K8) 2.6 GHz
RAM : 4GB
GPU : GeForce 6xxx or ATI Radeon 9xxx and up with OpenGL 2 Support (Excluding Integrated Chipsets)
HDD : 150MB
Even the recommend requirements called for hardware that is currently nearly 20 years old! Does anybody even use such computers nowadays?! Even if they never upgraded they would have surely broken down by now.
Here is another comparison of the recommended CPUs (they only state 2.6 GHz with no specific models, the Pentium D is 2.66 GHz) for 1.6 to the "best value" CPU listed on CPUBenchmark - simply no comparison at all:
Fact is, 90% of the issues with Java stem from absolutely insane coding practices, as has been explained countless times not just by myself but by people like the developer of Optifine, who surely knows what they are talking about.
By the way, can you run 256 chunk render distance on bedrock? Somebody made a mod for Java that enables just that, with none of the sacrifices Bedrock makes, and on rather outdated hardware, including an Intel HD 2000, which can't even run 1.17:
You should see vastly improved frame rates and world render speeds, especially at large view distances. It comes with most of the usual improvements from the past, but also some major new work to simulation (server side), memory usage and startup. In my own tests FC2 could easily outperform everything else, including the W10 edition (MCPE/Bedrock).
The config allows increasing the view distance limit up to 256. Performance will likely tank once the game runs out of VRAM.
All rendering happens with full detail and for a view distance setting of d FC2 will render (d*2+1)2 chunks, some bugs around post-initial area and very large distances aside. The whole view distance is being simulated (ticked). MCPE doesn't do either.
My test environments are only a Nvidia GTX 780 and an Intel HD 2000, both with Intel quad core CPUs, your experience on other platforms may vary and is of elevated interest.
Here is another mod that claims up to a 10-fold performance improvement; the screenshot it includes shows FPS going from 35 in vanilla to 478, at 32 chunk render distance:
Do you have any idea of what "below spec" means in the context of older versions of Java? No, do not show me the system requirements for the latest version; here are the system requirements as of July 6, 2013, shortly after the release of 1.6:
How old is that hardware?
Even the recommend requirements called for hardware that is currently nearly 20 years old! Does anybody even use such computers nowadays?! Even if they never upgraded they would have surely broken down by now.
Here is another comparison of the recommended CPUs (they only state 2.6 GHz with no specific models, the Pentium D is 2.66 GHz) for 1.6 to the "best value" CPU listed on CPUBenchmark - simply no comparison at all:
Fact is, 90% of the issues with Java stem from absolutely insane coding practices, as has been explained countless times not just by myself but by people like the developer of Optifine, who surely knows what they are talking about.
By the way, can you run 256 chunk render distance on bedrock? Somebody made a mod for Java that enables just that, with none of the sacrifices Bedrock makes, and on rather outdated hardware, including an Intel HD 2000, which can't even run 1.17:
Here is another mod that claims up to a 10-fold performance improvement; the screenshot it includes shows FPS going from 35 in vanilla to 478, at 32 chunk render distance:
478 frames per second with 32 chunks rendering distance? that is very nice, honestly
with optimization this good, 32 chunks could definitely become mainstream or a common setting people use, Java or not.
I don't know about the 256 chunks thing, I suppose it depends on the amount of memory somebody has, I've found for whatever reason I'm not informed enough on, that the supported render distance is dependent on the device somebody is running bedrock edition on, and how much memory I'd assume.
The largest rendering distance I've been told that bedrock edition has supported is about 96 chunks, on somebody else's computer. I can set it to about 72 chunks render distance, but only in single player or free multiplayer if not on a dedicated server. In either case, I'd still say 32 was optimal, because any higher is likely going to cause severe lag spikes or server overload.
On Xbox One and series S/X it supports about 22 chunks and no further, easily testable, and on Nintendo Switch bedrock edition is capped at 14 chunks, but only if the Nintendo Switch is docked so the speed of the processor/GPU can get high enough to be stable.
I think that java edition should move over to C++ as it runs better and with C++ and optifine it could run even smoother than bedrock can.(this will be short)
Also Java should add the friends system so for the profile thing you could make a java profile with your username and your skin, you could even have a description! so yeah and you could friend people like on bedrock and have a friends tab in the multiplayer thing and you could join them if they have the setting for friends or friends of friends like on bedrock.
Language has nothing to do with performance - the coding of modern Java versions is simply awful beyond words; for example, consider my own version based on 1.6.4:
Only 80 MB of memory used?! That's simply insane when compared to the latest vanilla versions; it also uses practically no system resources, even at a higher render distance - only 3% CPU and 3 MB of memory allocated per second - and this has not noticeably changed at all despite adding hundreds of new features, maybe even over a thousand by now; if anything, vanilla 1.6.4 uses more resources:
By contrast, newer versions of Java were written as if objects are the only thing that matters and as a result they allocate insane amounts of memory, forcing the garbage collector to constantly work to clean it up:
Aside from that, over-use of abstraction - even something as basic as xyz coordinates now use an object with method calls required to perform operations on it, as opposed to simple int variables, and a simple block lookup is a long chain of hash table lookups in a block registry, as opposed to simply reading an int value from an array index, with no actual reference to a block object needed in many cases:
This is my own code, where "BlockStates" contains a list of int values corresponding to a block ID and/or combined ID and data value (what I call a "block state", not to be confused with 1.8+'s version, which is an object) to avoid the need to even reference block objects (compare to "Block.stone.blockID", which has to look up "Block.stone", then read the "blockID" field; for comparison, "BlockStates.stone" is compiled to "1" so all it needs to do is load the constant "1" into a CPU register). Only if the properties of a block are needed then is a reference needed (e.g. "block.blockMaterial").
Also, "with C++ and Optifine" doesn't even make sense - there should be no need for performance mods at all, not to mention that mods as we know it wouldn't even exist if the game were written in C++ - you can't decompile a C++ .exe as you can with Java class files, I don't even think an .exe even knows about the original source files that went into it, it is all one huge mess of assembly code and even if you could get source back out of it it would be nothing like the original since the C++ compiler performs compile-time optimizations (by contrast, the Java compiler produces intermediate bytecode which is for the most part directly translatable to the original source; only once it is loaded by the JVM is it compiled into native assembly). Plugins/add-ons/data packs/etc are not mods and can only alter what the game's API exposes (even mod APIs like Forge have limitations, forcing modders to make "core mods", or in the case of non-modloader-based mods, "jar mods", that directly modify parts of the game; this is one reason why I never got into Forge modding).
Also, they would need to compile a separate C++ version for Windows, Linux, and Mac, which may even require changes to the code, since as mentioned above the compiler produces platform-specific assembly code which is also optimized for a specific platform; this means that if CPUs add new instructions the game will have to be recompiled in order to take advantage of them (by contrast, with Java you only need to update the JVM). Either way, the majority of performance is down to how you write code, C++ allows you to be lazier but it is not entirely exempt and there are bug reports regarding performance issues on Bedrock:
MCPE-74696 The Nether Update brings unbelievable lag
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
From what I was able to interpret, it's more to do with the virtual machine that makes Java a problem in the game.
The language itself theoretically shouldn't be a problem, not if it has direct access to the hardware.
this is a problem with all virtual machines, not just Java, because they're simulating an environment that isn't native to the system.
it's kind of like using emulators, sure they can be suitable for gaming, but they're not as efficient as native hardware.
This is why retro gamers often prefer the original systems the games were designed for, they don't have to deal with high latency and the extra glitches that come from emulation, especially poorly designed emulators in combination with cheap hardware that clearly aren't designed for video games.
In the end, no matter how the game is coded or what software it is using to run, you still need a suitable computer and display that at the bare minimum is meeting the requirements. Your mod may have cut out some unnecessary junk but I still wouldn't recommend playing this game on something below spec. You're plenty experienced at this though and you already know this, you've even suggested people use Nvidia dedicated GPU's, not integrated ones.
Do you have any idea of what "below spec" means in the context of older versions of Java? No, do not show me the system requirements for the latest version; here are the system requirements as of July 6, 2013, shortly after the release of 1.6:
How old is that hardware?
Even the recommend requirements called for hardware that is currently nearly 20 years old! Does anybody even use such computers nowadays?! Even if they never upgraded they would have surely broken down by now.
Here is another comparison of the recommended CPUs (they only state 2.6 GHz with no specific models, the Pentium D is 2.66 GHz) for 1.6 to the "best value" CPU listed on CPUBenchmark - simply no comparison at all:
https://www.cpubenchmark.net/compare/Intel-Pentium-D-805-vs-AMD-Athlon-64-4000 -vs-AMD-Ryzen-5-1600X/1125vs73vs3000
https://www.cpubenchmark.net/cpu_value_available.html
Fact is, 90% of the issues with Java stem from absolutely insane coding practices, as has been explained countless times not just by myself but by people like the developer of Optifine, who surely knows what they are talking about.
By the way, can you run 256 chunk render distance on bedrock? Somebody made a mod for Java that enables just that, with none of the sacrifices Bedrock makes, and on rather outdated hardware, including an Intel HD 2000, which can't even run 1.17:
Here is another mod that claims up to a 10-fold performance improvement; the screenshot it includes shows FPS going from 35 in vanilla to 478, at 32 chunk render distance:
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
478 frames per second with 32 chunks rendering distance? that is very nice, honestly
with optimization this good, 32 chunks could definitely become mainstream or a common setting people use, Java or not.
I don't know about the 256 chunks thing, I suppose it depends on the amount of memory somebody has, I've found for whatever reason I'm not informed enough on, that the supported render distance is dependent on the device somebody is running bedrock edition on, and how much memory I'd assume.
The largest rendering distance I've been told that bedrock edition has supported is about 96 chunks, on somebody else's computer. I can set it to about 72 chunks render distance, but only in single player or free multiplayer if not on a dedicated server. In either case, I'd still say 32 was optimal, because any higher is likely going to cause severe lag spikes or server overload.
On Xbox One and series S/X it supports about 22 chunks and no further, easily testable, and on Nintendo Switch bedrock edition is capped at 14 chunks, but only if the Nintendo Switch is docked so the speed of the processor/GPU can get high enough to be stable.