You can specify the version of Java the game uses in the profile settings (click on "more options" and you'll see an option for the Java executable). Note that it is very strongly recommended to always run separate versions in separate profiles and game directories (this will also prevent settings from being reset as well as errors, crashes, and corrupted worlds from being opened in the wrong version. You can even run multiple modded instances in separate directories, each with its own "mods" folder) so this will not conflict with newer versions (1.12+ will not work with Java 7). Also, the latest version of Forge for 1.6.4 was patched for Java 8 (according to the creator themselves, if you really need an older version because a mod is incompatible there is a "LegacyJavaFixer" mod (see second link), not sure about a download but many 1.6-1.7 modpacks still include it).
- TheMasterCaver
- Registered Member
-
Member for 10 years, 5 months, and 12 days
Last active Mon, Mar, 18 2024 06:46:31
- 308 Followers
- 13,496 Total Posts
- 4842 Thanks
-
Oct 31, 2020TheMasterCaver posted a message on JAVA Account Migration: What You Need to KnowPosted in: News
-
Oct 24, 2020TheMasterCaver posted a message on JAVA Account Migration: What You Need to KnowPosted in: News
What's this "decline" that everybody is talking about? You mean the supposed "decline" that followed Microsoft's acquisition of Mojang back in 2014? Certainly not evident in player counts or sales, which have increased for the better part of a decade, if not since the game came out, especially player counts. You mean Google Trends? Not even close to a reliable source, as if it was correct it would still be far less popular right now than it was in 2013 - while player counts are around 10 times higher - likewise, the number of YouTube videos has little bearing on the number of players (and might even reduce play time if they spend more of their free time watching than playing; granted, I found Minecraft through YouTube but it has likely become less important as the game has become mainstream):
https://www.theverge.com/2016/6/2/11838036/minecraft-sales-100-million ("Microsoft's video games revenue has been climbing steadily since the Minecraft acquisition, and it increased by $367 million in the 2015 financial year "mainly due to sales of Minecraft.")
https://www.statista.com/statistics/680139/minecraft-active-players-worldwide/ (note that 2019 was skipped; recent growth is not much different from 2016-2018, the "dark days" according to some)
Of course, this is for all editions of Minecraft, of which Java is a tiny minority at this point, and has been since 2012 (the rise of other editions hasn't really hurt it though, but it hasn't seen their exponential growth):
https://www.gamesbrief.com/2013/01/minecraft-grosses-over-250-million-in-2012-but-which-platform-dominated/ (PC/Java was only 16% of end of the year sales, 28% for the entire year, despite Pocket Edition (now Bedrock) being in its infancy and only one console)
The only issue I have is that I'll have to make yet another account for a site/service which I never use, much like how I had to make a Twitch account to keep using these forums, which I've never touched for any other reason. Even the cape offer is useless since I play on an older version which can no longer access the skin server so I'll never be able to see it (I just replaced the default skin with my own, and even disabled the skin download code to prevent wasteful attempts at connecting).
-
Jul 14, 2020TheMasterCaver posted a message on Java Edition: SNAPSHOT 20W28APosted in: News
I always find it interesting when Mojang fixes "bugs" that I didn't even know were bugs; a while ago I modified how Thorns works so it only takes away durability (+1 or 2 total) when reflecting damage, along with lowering the cost from 8 to 4 per level to balance it (with the 1.6.4 repair mechanics it is insanely expensive, adding 24 levels to the repair cost by itself for something that only has a chance of dealing 1-4 damage), never having known about MC-34661 until now (I don't play newer versions but I look at the fixes for any potential bugs that I can fix in my own version as bugs can be far older than the report might indicate; I also previously fixed MC-185925, also without knowing that there was an actual report for it, only a mention on places like Reddit, in my own rewrite of the ore generator, along with many other examples of the form (double)((float)posX + 8.0F) instead of (double)posX + 8.0D, which based on other reports, e.g. MC-167042, somehow persists in newer versions (they knew about and fixed other issues caused by this long before they added campfires so there is no excuse).
-
Jun 18, 2020TheMasterCaver posted a message on JAVA EDITION: 1.16 PRE-RELEASE 8 & Release Date for Java and Bedrock!Posted in: News
I'm still wondering when/if Mojang will ever get around to fixing the following bugs, which I fixed myself, some many years ago and some quite serious (I'd never play on a game that can randomly corrupt the world), and many with community-provided and verified fixes?
MC-2025 Mobs going out of fenced areas/suffocate in blocks when loading chunks (perhaps the most infamous bug of all time based on the votes/duplicates - I used fixes given in this report, same for many others)
MC-9568 Mobs suffocate / go through blocks when growing up near a solid block (related to MC-2025, I literally just copied this code with a few changes to the names)
MC-43968 Ambient occlusion bug (With partial fix)
MC-138211 Incorrect Smooth Lighting (Ambient Occlusion)
MC-68129 Smooth lighting doesn't work properly underwater
MC-176743 Smooth Lighting doesn't work on water
("fabulous" graphics?)
MC-161823 Chunk corruption in 1.15 & 1.16 Snapshots (the release of 1.16 needs to be postponed indefinitely until this is fixed, as verified by extensive testing. Every day this report gets several more duplicates, soon it will have more than the far older MC-2025, and it is just the latest in a string of "resolved as fixed" reports going back 8 major releases, with most reports since 1.14. I've never actually experienced this in 1.6.4 but I've made fixes to chunk saving/game shutdown that may cause some forms of corrpution)
Of course, a cave update also can't happen until Mojang fixes MC-7200 and MC-125033 (these are much worse when you have huge caves, compare to my own fix, which might seem a bit odd when rivers float over them but I'd rather have intact caves) as well as serious issues with the seeding of the RNG (in particular, 1/3 of all seeds have 1/3 of all sign-reversed chunk coordinate pairs having the same chunk seed, meaning that if you explore around 0,0 a third of all caves you find to the north will be identical to the south, same for east vs west. It is also very easy to use a true 64 bit RNG instead of Java's obsolete Random class for improved randomness). -
Feb 9, 2020TheMasterCaver posted a message on JAVA Edition: Snapshot 20W06APosted in: News
Diamond used to be as good or better than Netherite - my Sharpness V diamond sword does 14.25 attack damage (displayed as +13.25 in vanilla 1.7-1.8 as this is added to your unarmed damage of 1) compared to 11 for Netherite, which also only deals the same amount of base damage (assuming Mojang doesn't nerf it, as a combat snapshot nerfed diamond down to 6 damage, so Netherite would then be 7). Likewise, armor has the same number of points and its higher "toughness" only reduces the effect of armor penetration (any damage at all will reduce it to below the constant 80% that versions before 1.9 had. For example, a creeper deals up to 49 damage on Normal difficulty, which will penetrate (damage / (totalToughness / 4 + 2) ) armor points, or 24.5 (limited to 80%) in most armor (0 toughness), 12.25 in full diamond (8 toughness), and 9.8 in full Netherite (12 toughness), the latter reduces the overall protection to 40.8%, allowing a lethal 29 damage through (49 * 0.592) - while prior to 1.9 you could survive a point-blank hit even on Hard (73 * 0.2 = 14.6 damage).
If anything, it isn't much different from TMCW's amethyst items, which mostly have the same stats as diamond in vanilla (more durability is the main difference, and even then the pre-1.8 repair system, which based costs on durability and enchantments, makes it so expensive I had to raise the anvil limit to 49 for these items only for them to get reasonable enchantments and be repairable), which was in turn nerfed along with everything else (e.g. all weapons do 1 less damage, diamond armor is only as protective as iron in vanilla, which in turn is worse, etc), requires finding an extremely rare ore/chest loot (8 times rarer than diamond in caves, 2 times rarer at y=1 (above flat bedrock at y=0), forcing you to mine below lava level in a world with double the lava-level caves as 1.7+), and is nonrenewable aside from very rare mob drops (only raw diamonds are nonrenewable in vanilla, I made Giants drop one when killed with Looting). You also need to keep finding more to maintain your gear since you have to repair them on the anvil, while now you can just slap Mending on your gear and call it a day (prior to 1.8 you could simply rename an item and the cost wouldn't increase; my own version of Mending works the same way). Of course, it is in the Overworld; the only thing I really do in the Nether is mine quartz for XP, which I only do once (after I'm done with them I delete the Nether and End to reduce the size of backups). -
Oct 16, 2018TheMasterCaver posted a message on Minecraft 1.13.2 Pre-ReleasePosted in: News
It is worth noting that MC-91621 is far older than indicated by the affected versions - pretty much any version of the game (even Alpha/Beta, if not earlier) with the current mob (de)spawning algorithm can be affected since it happens when mobs spawn more than 128 blocks from the player and immediately despawn, which will happen constantly when you are more than 128 blocks away from any water or land, with a theoretical maximum rate of 18,000 mobs per second for each of hostile, water, and ambient mobs (I inadvertently fixed this myself a couple years ago when I changed the mob despawn radius from a sphere to a cylinder for unrelated reasons, otherwise, I never noticed it since you must be high above the surface and older versions perform better).
Aside from that, "performance improvements" do not impress me when they need to improve performance by up to 1000% (10x faster) to offset the performance differences I saw with 1.13 and TMCW (e.g. startup and world generation time) - and that will certainly never happen with the current codebase (since 1.8), and when major releases are involved (e.g. 1.12 to 1.13) they always seem to translate to the opposite. -
Jun 15, 2018TheMasterCaver posted a message on Minecraft 1.13 Pre-Release 2Posted in: News
I haven't. The rarity of packed ice is what makes ice spikes biomes valuable...
Not everything should be craftable, farmable or automatable. Some resources like packed ice need to be left up to the player to get. If you can just craft packed ice, it's not rare anymore... (It'd be one thing if they added a compressing machine of some kind that required fuel, but just being able to craft a rare resource from a resource that you can get for pretty much free is not my idea of good gameplay design.)
I don't like the idea of having to destroy a biome just to get a rare resource though, which is why I made it craftable in my own mod years ago; I even reduced the recipe cost from 9 to 4 regular ice (2x2 instead of 3x3, which I first had). I don't see anything special about packed ice other than not melting and have never actually used it, nor have I ever found an ice spikes biome despite my modded worlds not having climate zones as 1.7+ does.
Likewise, I made various biomes replace stone, dirt, and gravel with biome-specific blocks - you'll never run out of them or have to strip the surface to get them, craftable or not (I've since added more than shown and made them extend deeper underground). You can also make ice and/or packed ice generators with dry ice in the same manner as a cobblestone generator (dry ice can only be found in Ice Plains Spikes though).
While they are at it they could also make podzol craftable (2 dirt + 2 spruce leaves = 2 podzol in my mod); they already made it easy to obtain by leaving in the bug where 2x2 spruces converted grass into podzol (marked as WAI so they consider it to be a feature). -
Oct 20, 2017TheMasterCaver posted a message on Merge Your Minecraft Forum Account With TwitchPosted in: News
The game is not even close to "dead" if you believe the stats that Mojang claims (122+ million sales and 55+ million active users per month, the latter up 37.5% over 9 months) - but the forums most certainly are - and have been dying for 5 years, even as the number of copies sold (including the supposedly even deader Java edition, which just hit 27 million sales) and players has increased by around 6-fold (and oddly enough, the forums continue to gain members at the very healthy rate of a quarter million+ per year - what do all of those members do? Or maybe they are just spam accounts).
I may soon stop posting as well, not because of the Twitch merge (seriously, it only took like a minute to create and merge an account) but because these forums have become incredibly boring - the only problem is there are no other forums like these that I know of and places like Reddit or chat sites/apps like Discord (or the forum chat, which I've never used) do not have the same attraction as a forum. -
Dec 14, 2013TheMasterCaver posted a message on Saturday with Sach: Whats In a NameMy name comes after my username on Totaljerkface.com, which as you can guess, comes from the game Happy Wheels, which I used to play a lot back when I registered for Minecraft; the clothing on my skin similarly comes from a character in that game.Posted in: News
- To post a comment, please login.
0
Any recent system updates? Many people have been having the same problem but nobody (so far) has provided enough information to pinpoint the cause (I asked one of them to check Windows Update and/or Event Viewer logs from the time it began but no response):
https://www.minecraftforum.net/forums/minecraft-java-edition/discussion/3195591-is-minecraft-now-unplayable-especially-legacy
https://www.minecraftforum.net/forums/mapping-and-modding-java-edition/minecraft-mods/1294926-themastercavers-world?comment=296
Assuming you are playing on an older version and do not have a dedicated GPU (meaning you are using the one built into your CPU) it might be this (one example, issues have been reported for all three GPU vendors):
Poor Performance in Older Versions of Minecraft* with Intel® Arc™ Graphics
Also, if you have a dedicated GPU make sure the game is actually using it:
https://windowsreport.com/minecraft-not-using-gpu/
My theory on these issues is that they are phasing out any attempt to optimize support for the many decades-old graphics API these versions use, ever since Minecraft, probably the only major application to still use it, was finally (with massive sighs of relief from driver vendors) updated to use modern rendering methods in 1.17 (coincidentally, right before issues began, some just took longer to manifest, and/or people only rely on automated updates to update drivers); if you come across old threads complaining about how Notch was a terrible coder, well, he deserves it, what was he even thinking using a long-obsolete graphics implementation from the 1990s (of course, they never coded the game with it being any more than a curiosity in mind, like all those long-dead Java and Flash games you could play in a browser).
0
This won't necessarily work because of seeds, assuming they are randomly generated, and the only way to get a set seed in older versions is to edit level.dat, deleting the chunks so they regenerate.
0
Don't click on the adfly links (even if they were still good I'd avoid any such links, especially since they seem to redirect you to completely different sites when they inevitably expire), use the "mirror", you also need to change the URL from "optifined.net" to "optifine.net" as I previously explained (post 98) or it will claim that the file doesn't exist when you try to download it.
Also, it is best to use a 3rd party launcher like MultiMC to install older versions that do not have an installer, or if the installer doesn't work (the launcher just launches vanilla); in the installation settings (I don't know exactly where as I don't use it) are options for mods, one of which is "add to Minecraft jar", which is the one you want to use. If you really want to use the official launcher you can follow the instructions I gave here to manually install it (all version jsons have the same stuff mentioned, the only change is the version "id", very old versions also only list client.jar in the downloads that must be deleted).
1
I know that they are probably aware of the issue since there are bug reports but Mojang can't really do much about it, I mean, imagine having to decompile (they probably no longer have such old source code) and recompile every affected version to fix a bug in the game, even one as simple as the Intel driver bug (one line); the complete lack of any fixes for version other than 1.6.4 (my own) and 1.7.10 (bugfix mods which used my fix) is quite telling, and that is with public modding tools like Mod Coder Pack. Even serious issues have simply been closed as "invalid" / "won't fix" / "update to a newer version", e.g. see the resolution and responses to MCL-10804.
It's just the way things work, do you expect Microsoft to fix issues with Windows 7, XP, 98 (even Windows 10 has long-running bugs which have never been fixed, e.g. sometimes I click on a window in the background, or on its taskbar icon, and it doesn't come to the front. If you resize the canvas in MSPaint and the zoom if greater than 100% it will cut off more than intended, etc. They probably just want to to use Windows 11, I've even heard they want to force you to upgrade).
Also, the use of fixed-function methods technically isn't even part of the OpenGL spec anymore, I don't think drivers are even required to include support for it (I've seen people get a crash due to "lack of OpenGL" in older versions only).:
Consider that the GeForce 7600 GS that I had in my first computer came out in 2006 and supported OpenGL 2.1 so it was probably already emulating it, and this is part of the reason why its behavior and performance varies so much among GPU vendors and models (in theory it can perform better since everything done to emulate it is handled within the driver; as somebody said here, "Nvidia's fixed function is aggressively optimized and even modern OpenGL has too many constraints for any shader-based reimplementation to match it in performance." (but with far fewer options / advanced rendering techniques, e.g. see the difficulties the game has had with translucent textures, which I do think the "fabulous" graphics setting is intended to fix*). The whole thread deals with paradoxically lower performance with modern rendering, it seems the most important thing when optimization rendering is exactly how you order render calls, and minimizing them and/or state changes (which is exactly how I've optimized it, this is even more important with Java due to the overhead of native API calls), but again, this also depends a lot on driver-specific implementations; e.g. the reason older versions do not have spherical fog on AMD and Intel is because they never bothered implementing it, although a comment on a bug report claimed it was very easy to fix so maybe there is some fog function for it).
*I'll note though that the only difference in the "Fancy" and "Fabulous" examples given in the Wiki is that you can see particles behind translucent blocks, a bug that I fixed with only some very simple changes to the rendering order (even Optifine for 1.6.4 partially fixes this; in vanilla 1.6.4 even particles in front of water are rendered behind it, which Optifine fixes; I also fixed particles behind water not rendering at all, I believe by removing "GL11.glDepthMask(false / true);" in EffectRenderer). Similar changes fixed issues with clouds making blocks above them invisible and block outlines/breaking textures (I actually use a separate set of breaking textures for translucent blocks, clouds still overlay the block outline as it is hard to get everything in the right order and this is an edge case I rarely encounter).
0
No idea, maybe they were testing the new animation system, which also does have some advantages (you can easily change the clock texture to anything else) but the old system is definitely something that I'd do; for example, I backported colored beds to 1.6.4 not by adding separate textures for every color but by separating them into "base" and "overlay" textures, the latter of which are recolored when rendering them, and means that there are only 10 individual textures instead of the 96 (6 per bed) that would otherwise be needed (the way Mojang implemented colored beds was to give each one its own 64x64 entity texture, rendering them as such instead of a basic block, and I'll note that while 1.8 added the ability to customize block models this (still) did not apply to entity models, so all you can do is retexture the existing model, but you can still give each color a distinct texture, unlike my system).
Example of how one side is rendered:
For another example, all these stalagmite and stalactite blocks (168 total variants)? There are far fewer textures used than you might think (48 instead of 336), stalactites are just flipped upside down (this isn't so obvious since I also flipped them side-side, the streaks on the packed ice stalactites go in the same direction as stalagmites, and the textures otherwise don't have obvious patterns) and all hardened clay variants are recolored to match the variant of hardened clay they are on (for comparison, Mojang appears to have used 10 textures for pointed dripstone, 5 each for up and down):
However, Mojang did later on add the ability to procedurally "blend" two frames together; if you look at the texture for magma blocks there are only a few frames, yet the animation looks smoother; as this did not exist yet in 1.6.4 I had to manually add more frames and the result probably still isn't as smooth:
The contents of magma_block.png.mcmeta:
By contrast, this is the one from vanilla, with only 3 frames:
The mcmeta file is a bit different; note the "interpolate" option, the frame time is also 4 times higher (both animations have a total length of 24 ticks or 1.2 seconds):
The Wiki says that "interpolate" automatically generates more frames, I'm guessing the total number is equal to 24 (7 additional frames); "frames" is not needed unless you want to display them in a different order (both unchanged from the default):
This will however not give the same results if used for clocks since the game is simply blending two images together (you'd see the previous frame slowly fade into the next frame, unlike both the old and new clock animations).
0
I really, seriously doubt that... if such a simple thing gave you issues then an actual world would be completely unplayable.
That's literally it, it just tiles a single texture across the screen (the texture itself is 16x16 and drawn at twice the resolution, wrapping around however many times necessary to fill the drawn area). Even a single item is likely much more expensive to render, much less the entire panorama, which actually has had reported performance issues in the past, especially when Mojang greatly increased the resolution in 1.13 (note that they say going into a menu dropped GPU usage from 60% to just 3%). Even the older one had been reported to cause issues (the dirt background had been used for the main menu prior to Beta 1.8):
1
The most likely explanation for a name like "Player#" (# = a number from 0-999) is that is the default username you get if one wasn't supplied; e.g. if you run the game in a mod development environment you'll get such a name unless you edit the files to set one (as I did to ensure the same player data files and statistics are always used when joining the same world multiple times); as for Alpha, it may be that the game is unable to read the name argument given to it by the launcher (they can't authenticate online anymore either; this means that in order to play on a multiplayer server the server must be "cracked" / "online-mode" set to false). If you want a custom skin in any version up to early release 1.7 you must use a texture or resource pack, as I do (I just replaced the default skin inside the jar, and long before the old skin server stopped working):
As for crashes, a decade+ of modern software and hardware, plus any existing issues (it is alpha software after all; "Alpha software may contain serious errors, and any resulting instability could cause crashes or data loss") leads to older versions being very unstable and having many issues, even more on newer systems; even more recent versions have had major issues, e.g. serious texture corruption on newer graphics drivers (Notch originally coded the game with deprecated rendering methods from the 1990s which already had to be emulated by modern drivers, to varying degrees of accuracy and performance (NVIDIA had traditionally been the best, even outperforming modern rendering methods, and have also actually fixed driver issues, unlike Intel and AMD, the latter has a memory leak so severe it makes old versions unplayable, "computer crashes after 20 minutes", AMD says, "well, we can't be bothered to make a patch for such an old game" (or so it seems, no fix for 2 years, same for Intel. Interestingly, most driver updates are patches for issues in various games, as opposed to issues with the driver itself, and this is why drivers are so large).
0
You have to use a tool like Mod Coder Pack, and any Forge, etc mods would all need to be re-written and only mods modified to be compatible with each other could be used together, which is entirely why mod loaders were created. Fabric is supposed to be much more lightweight than Forge and may have been created in part for this reason, they can also even update it for snapshots, while Forge can take weeks or even months (basically, an issue of baggage from being around for so long and tacking on new features instead of being a fresh rewrite).
Otherwise, most of the time taken to load mods is on setting them up and injecting them into the code (I don't know the exact details but basically a mod will scan the code for a certain bytecode sequence and add its own code there, more or less "compiling" itself, with the help of "ASM" libraries in the mod loader, there is something called called "mixins" which I've seen a lot of in the source for newer mods). There's also the fact that since 1.8 the game has to load model files for every block and item, construct and register blockstates, and so on (essentially, modern versions aren't even so much a game but a virtual machine which interprets data files - practically everything is now "data driven", which is also why they are so much larger and more complex internally than older versions - even 1.8 is larger than the jar for my own mod despite it having far more content (and the jar having a lot of dead code from vanilla classes which are no longer used); an update similar in size to a typical vanilla update adds far less to the size.
I've been told that in terms of file size many mods are nearly entirely models, sounds, etc (the models in particular, and all the data structures needed to support a "data driven" architecture, also heavily contribute to the memory requirements - when loaded chunks are excluded TMCW only uses about 20 MB for everything else; loaded chunks themselves only affected by the number of "sections" loaded, independent of what they contain, with entities and tile entities only contributing to a small percentage of the total (their impact is more on CPU and rendering, particularly for tile entities that use a "tile entity special renderer", or are rendered using entity models instead of block models, which is why chests are so hard on the game compared to barrels, a functionally identical block. I also think many mods now use TEs to bypass the forced need for block model files for complex blocks (I'd heard that some mods would have needed thousands of files to define every state of a single block, this is one reason why many mods stopped updating at or took so long to update past 1.7.10).
1
This was the result of flying around for about 10 minutes, far enough away from the origin (1280 blocks) so mineshafts were at their maximum frequency:
Note that all other structures didn't come even close to what mineshafts used (the next largest was strongholds, followed by villages, then temples. Only strongholds are comparable to mineshafts in complexity, the single stronghold was 37 KB compared to 30 KB for the largest mineshaft; for comparison, scattered features (temples and witch huts) were only around 400 bytes as each one only has a single component while the stronghold had 300 and largest mineshaft 255).
For comparison, this was after flying for a similar amount of time in TMCW; there were about half as many mineshafts registered (65 vs 138; on average they had 127.5 structure pieces and 15440 bytes in vanilla and 127.7 structure pieces and 14357 bytes in TMCW). Part of the difference in the number of mineshafts was due to differences in the number of chunks loaded but most was due to mineshafts being less common than in vanilla:
Another thing to note is that vanilla was using 3 times as much memory by the end; most of this was not due to structure data but other reasons, including a chunk memory leak, note that vanilla loads 441 chunks plus another 625 chunks around the spawn chunks (289 are guaranteed to remain loaded, the rest are loaded during world load) so there should be at most 1066 loaded on the client and server, yet this shows nearly twice as many chunks; a lot of these would be due to zombie pathfinding causing chunks to load outside of the player's loaded chunk area, which will never be removed, while TMCW is loading only 578 chunks, the number you'd expect for a view distance of 8 and no spawn chunks.
While this is one reason why TMCW is using less memory loaded chunks actually use a higher percentage of the total retained memory (66.1% vs 63.1% in vanilla) and even 16 chunks (loading 2178 chunks) uses less (that is to say, when excluding loaded chunks vanilla is using 67.8 MB and TMCW is using 19.4 MB, a factor of 3.5 less):
So, yes, the way the game stores structure data is an issue, especially on larger worlds (my first world would literally be unplayable in vanilla, not so much because of the memory usage but the game having to iterate through a list of some 1,500 mineshafts every time it generates a chunk and especially when it saves structure data (it not only goes through all 1,500 structures but every single piece of each one) - even on a much smaller Creative copy of the world I started having seconds-long server-side freezes during autosaves and had even recommended using 1.6.2 instead of 1.6.4 to host a server).
However, there are many other sources that lead to vanilla using more resources than it needs to, considering it was using over triple the memory outside of loaded chunks despite having a lot less content; for example, consider the following, vanilla has 484 instances of TextureAtlasSprite (block and item icons) while TMCW has 812, with correspondingly higher memory usage by the TextureMap (I'll also note that the actual number would be much greater if I didn't so extensively re-use textures, e.g. I added colored beds by adding only 4 more textures to vanilla's 6, which include 5 base textures and 5 overlay textures which are colored with one of 16 colors. If I'd just recolored the vanilla textures that would be 90 new textures, 96 total):
You may also notice something interesting with the Tessellator and TexturedQuad classes, they are much smaller in the case of TMCW, which is because I reduced the size of the vertex array by 8-fold, which still covers the vast majority of situations (it will resize itself up to half the size of vanilla is needed, past this point it simply stops accepting new vertices). In the case of TexturedQuad(Fix) I set the "vertexPositions" array to null after draw() has been called (this is only done once, so why keep the data around?) This also explains why the number of is slightly lower as had been freed up for entities that had been rendered (I flew well off the ground, expect for some higher mountains so most entities weren't being rendered). Aside from that, I removed some redundant models, others were changed to simplify textures (like, why do zombies need a 64x64 texture?), my fish and sign renderers don't use the vanilla entity renderer at all.
For another example, vanilla needlessly allocates a lot of world generator classes; why does every biome needs its own instances of every ore? Or features that they don't even use, such as huge mushrooms?
You can see that TMCW has far fewer instances, although I did make nearly all of them static so the same instance can be reused; the size of the WorldGenOre class, equivalent to WorldGenMinable, is due to a "vein mask" and lookup tables to get the size of a vein within the mask and other parameters. Many of these classes also generate several variants of a feature (e.g. there are 7 main types of lake, "small" (like vanilla), "big" (up to 30x30 blocks and placed so there is a 1 block border around them within the 32x32 populated area), "volcanic", a variant of small lake used in a Volcanic Wastelands biome, "tropical swamp", which has two distinct variants, used in a biome of the same name, and "small" and "big" variants of lakes in the Nether (different generation and valid blocks to generate in than Overworld lakes; all variants check the blocks they will replace to avoid generating in structures, e.g. stone bricks (strongholds and igloo basements), which vanilla only does for villages by checking if "generateStructuresInChunk" returns true).
Also, this:
Notice how much more memory BiomeCache is using in vanilla, since it stores references to biome objects while I use biome IDs (bytes) and it also stores "rainfall" and "temperature" data which is never even used! Even worse, it also generates the exact same biome data three times (they could have just looped over the biomes array and read the temperature/rainfall from them, I assume at one point they actually did use them, now they just read them from the biome object):
Mojang did eventually remove the useless temperature and precipitation data but not until 1.12 or so (source code I found for 1.8.9 shows that rainfallValues is still present). Also, the cache is mainly used by things that access biomes in unloaded chunks, including structures, and in my case, caves, and much more extensively than vanilla (e.g. mineshafts check 25 points within a 5x5 chunk area to determine the type of wood (based on the most common biome) and whether mesa mineshafts can generate; said "5x5 chunk area" is around the mineshaft's center chunk, which can be up to 9 chunks from the chunk being populated, one more than vanilla since mineshafts can get larger. I do set their maximum span first and use this to abort if the current chunk offset exceeds it, e.g. mesa mineshafts have a maximum spawn of less than 3 chunks so they are only actually checked within this range).
You can also see that BiomeDecoratorTMCW uses less memory for 127 instances than vanilla needs for just 23 (BiomeDecorator and BiomeEndDecorator), a direct consequence of not giving every biome its own ore generators, etc (while the memory usage isn't that high for many objects the total number of live instances does matter as the garbage collector has to go through all of them. Objects declared as static final may also receive special treatment since they can never be deallocated until the program terminates).
In addition, this shows MC-101232 in action; there are three "WorldServer"s present due to two still being referenced by WorldGenBigTree after I'd reloaded the same world twice; with memory usage being 232.5 and 309 MB after the second and third world loads (I made sure to generate new terrain in different biomes each time so at least one big oak tree was generated), oh, and MapGenStructureData was now using over 50 MB!:
As seen in this screenshot, taken just before a garbage collection, the peak used memory was reaching 90%; the next world load would likely cause the game to start hitching due to insufficient headroom, and after that, an out of memory crash (it is less severe in 1.6 since there are less biomes and you do have to actually generate new chunks with at least one attempt to generate a big oak tree):
1
Except, this does not occur in versions before 1.6.4 unless something caused the chunk to be repopulated, which is not a normal situation (either a tool like MCEdit was used, which has a function to "repopulate" chunks, often used so a map which contains only bare terrain can have custom or version-independent features, e.g. loading a map created in 1.6 in 1.7 will cause features added in 1.7 to be generated, same for using mods; or something caused a chunk to be deleted or regenerated, and due to the offset by half a chunk to the southeast when features are placed you end up with strips of unpopulated terrain to the north and west, like in these examples; if you delete a single chunk in a snowy biome you'll get an "L" shape free of snow with the corner of the "L" in the northwest (only the southeast quadrant of the chunk was populated). A similarly shaped area to the southeast will have been populated twice; if this includes structures and structure data was not saved (for villages) then the game will place the same buildings on top of the existing ones because they always generate on the highest ground* (structures like mineshafts and strongholds will simply regenerate over themselves, mineshafts will end up with two minecraft chests in the same locations as they are entities so two can exist in the same block).
*What I mean is, every village building has this line of code, the method:getAverageGroundLevel does as its name suggests, measuring the average ground level under the structure (though not necessarily the whole piece since it is confined to the 16x16 central area*).
In 1.6.4+ this is saved to NBT as seen here, otherwise, it is only remembered for the current session:
*I improved this by allowing it to access the entire 32x32 area that can be accessed during chunk population, ensuring that the ground level for a structure up to 9x9 blocks in size can be fully measured, otherwise at least a significant portion (in the wosrt-case vanilla may actually only measure a single block, hence why you can find village buildings with really strange placements, such as a house that was placed much lower or higher than most of the terrain under):
Note that this does not mean I made the entire structure be placed within the 32x32 area, just this single check.
The only change is that structure data is now saved within region files (chunks) instead of separate files, which have always been in the NBT format, e.g. you need a program like NBTExplorer in order to read them (as shown above), as you also do in order to read level.dat, and indeed, there are no actual files with the nbt extension (e.g. region files end with mcr or mca, depending on whether they used the "Region" or "Anvil" chunk format. Actually, region files themselves aren't NBT, the individual chunks inside them are).
Also, the NBT format is anything but efficient when it comes to in-memory storage, which is entirely why MC-33134 is/was an issue, as opposed to the data stored in "MapGenStructure.structureMap":
1
This won't work unless you disable backface culling; that is, this:
This is why you can't see the back side of blocks, like in this image? Without backface culling you'd be unable to see inside the caves, they would appear as if they were made out of the surrounding blocks:
This bug report has examples of what no culling looks like:
MC-220690 Block model faces are visible from behind in spectator mode on some graphics cards
The game does disable culling for translucent blocks but that causes its own issues (either they won't be visible behind water, before 1.7, or have rendering artifacts between blocks, since 1.7, unless some fancy rendering methods can fix that). The only other way to do this is to add a third render pass (meaning a chunk update would now have to make three passes to check if a block can render on each pass) since I don't think there is a way to toggle culling for individual blocks within a single draw call.
That said, I'm not sure how important culling the back sides of blocks actually is; it does nothing for the actual rendering of chunks (the game is rendering every visible face in a chunk anyway); I found a question on Stack Overflow which says they saw no difference in performance and an answer said it probably makes no difference with a lot of small polygons (which is exactly what Minecraft does) and only basic shaders/lighting (also Minecraft):
Also, apparently leaves do in fact render without culling on Bedrock Edition (I assume, as otherwise you are talking about at least twice as many faces being rendered, and I assume they do only render faces on e.g. the positive xyz axes when adjacent to each other, thus only half the number of faces as Java renders):
MC-171859 The back faces of leaves do not render
MCPE-31289 The Backfaces of leaves is visible, while in java it isnt, brings load on gpu
"Increased GPU load" would only be true if Bedrock is rendering faces on both blocks which are adjacent, this difference is very likely because they disabled backface culling so they can get away with only rendering half as many faces per block, halving the amount of data created.
1
This is caused by a bug where the game fails to remember to re-render a chunk after it attempted to update it and it was "empty"; the fix was very easy, just a single line of code, but unfortunately Mojang never bothered to fix it until 1.8 (so many bugfixes are this simple, IMO any game, or even mod, that has more than a handful of reported issues which have been unresolved for a significant time and which are not difficult to fix is not maintained well at all):
MC-129 Chunks not loading surface, revealing caves, etc.
(my changes to fix this are a bit different and more general but to the same end result; the sorting itself is not an issue, the game prioritizes rendering chunks closest to the player and on screen first, then further away, then off screen, which is why they render more slowly behind you, which all makes sense)
There is another bug with the way the game calculates how much time is available to perform chunk updates which results in only one chunk update per frame when Vsync is enabled, or the game is running at unlimited FPS; the latter might not be so much of a bug except it can result in low chunk updates when FPS itself is low (low FPS due to a low FPS limit increases chunk updates because the game uses the FPS limit to calculate how much time is available for chunk updates):
MC-32719 Chunk loading speed drastically decreases with Vsync
I fixed this, as well as allow you to change how much time chunk updates can take, by adding a "chunk update time" slider, which goes from 0-100% of the idle time between frames (Optifine simply lets you choose how much chunk updates are done per frame but this fails to adjust for changing frametimes; 5 updates per frame might work well in less complex scenes but causes FPS drops in more complex scenes, whereas my code will just do less chunk updates):
Some examples of chunk rendering performance, including an example from vanilla:
Also, the second to last line ("Relight") shows the number of relight checks performed per tick; the client only ticks 10 chunks per tick so 320 is equivalent to 32 updates per chunk (this is normally 64 and is halved in "mega tree biomes" to reduce potential lag); the server is ticking up to 2400 when flying at a constant speed, indicating it is completing them before the chunks move out of the 15x15 ticking area as this is only 2400 / 225 = 10.67 updates per chunk (at 11 m/s it takes about 22 seconds to cross 15 chunks while light updates take 6.4 seconds to complete so about a third should be updating. These numbers are independent of render distance since the ticking range is always 15x15 chunks):
Fast leaves:
Fancy (fast):
Fancy leaves:
These show a more normal situation with and without Vsync; in contrast to vanilla chunk updates are higher with Vsync, averaging about 8 per frame (so even better than Optifine set to 5) since I properly account for the fact that FPS is being limited, rather than unlimited (vanilla thinks there is no time to update chunks so it does the minimum of 1. I should note that vanilla 1.6.4 appears to still use the limit defined by the "performance" option, 35, 120, or unlimited, so keeping it on "balanced" may improve things). Even with less chunk updates the order in which chunks are prioritized still updates them fast enough to avoid seeing the edge of the world (no longer behind fog), I'll also note that chunk updates with Vsync are much more variable (as I noted before when traveling in a minecart chunk updates often alternate between 0 and a higher value since they all completed before the next set of chunks were loaded, depending on exactly when I crossed a chunk boundary in the past 2 seconds it might also show a more constant number between the min-max):
For comparison, these were from vanilla, including a persistent rendering glitch, these are also much more common on Far render distance since the game is trying to render chunks at a distance of about 12 but the server is only loaded and sending a distance of 10 so the outermost chunks are empty (this is also why there is insufficient fog on Far):
Also, the difference in performance implied by these screenshots is very real, considering that "Far" isn't even actually 12 chunks, as others have measured (notably, TMCW had the highest FPS despite vanilla 1.6.4 not being as good as newer versions until 1.20, the "GC" part is how high memory rises until a garbage collection; they most likely used the more modern, but more resource-intensive, G1GC collector as I wouldn't expect it to be using 500 MB, or vanilla 900 MB, even with more allocated):
Minecraft TMCW5 1.6.4 Mods (FPS 130-180 12 Chunks GC500)
Minecraft 1.6.4 (FPS 60-80 12 Chunks GC900)
Minecraft 1.8.9 (FPS 100-150 GC700 it cycles around 2 times per 10 seconds)
Minecraft 1.16 (FPS 80-130 GC1000 but the minimal memory is 900, constant GC)
Minecraft 1.20 (FPS 30-60 GC1000 starts at 600MB it cycles about 3 times per 10 seconds)
https://drive.google.com/file/d/1ecjhOKS5qki9Ku8E2-ZtmHr28nvfJ5DX/view
Also, it seems that Mojang considers chunk updates to take priority over framerate, with a minimum target of only 30 FPS, which is absolutely not what you want, especially with Vsync enabled (older versions did work like this as well, vanilla 1.6.4 only shows a steady 120 FPS when not updating a lot of chunks, which can drop it by around 30 FPS):
Yet, I showed that prioritizing a stable FPS can work very well, and this is absolutely necessary for a good experience with Vsync, even a single skipped frame is noticeable, much less a sudden drop to only half the frame rate, or less (75 would drop to 25 since Vsync only works in multiples of the refresh rate). Do other games do the same thing? I have to doubt it, unless they and Mojang handle Vsync differently.
1
The game re-renders the chunks which were formerly on the edge of the loaded area, which must be done anyway to take into account blocks like fences, and avoiding rendering a whole bunch of unnecessary block faces which used to be adjacent to air/empty chunks.
More specifically, when a single block changes within a chunk the game will update all sections in a 3x3x3 area around it, as seen in "RenderGlobal.markBlockForUpdate", there is also a method which marks a range of blocks for update, expanding it by 1 in every direction, which is called when a chunk update packet is received:
So this does mean that the number of chunk updates required when loading new chunks is higher than you'd expect, e.g. at a render distance of 8 chunks the game loads 17 chunks at a time, say they average 5 sections, then that's 85 chunk updates but in reality it is twice as high, and then you have to account for chunks that were unloaded; I see chunk updates peaking at 400 when traveling via Nether railway (17 x 8 x 2 = 272, but then you must double that as the game is un-rendering chunks behind you. The last row of chunks to drop out of render distance does end up back in front as the chunk renderer uses a circular cache so the real number might be 3 times the sections that were just loaded, i.e. 17 x 8 x 3 = 408, consistent with what I see, which often alternates between 400 and 0 due to a minecart taking 2 seconds to cross a chunk).
I avoid this by pulling the water surface up towards the blocks above it, with a slight incline over a block so it isn't as easy to see, best seen when next to a wall (due to perspective even a straight gap will appear to narrow down to a point in the distance):
This is with water placed in the hole, as you might see when breaking the ice from below:
Obviously, it isn't perfect since you get a 3x3 square of the water surface around a hole. A similar example is how I implemented "better snow"; Optifine's version renders an actual snow layer block while I just render the grass block below using the snow texture (with "better grass " also enabled in still case so it the sides are the same as the top), with the shading on the sides of adjacent snow layers set to the same as the top so they blend in, you can still see that it isn't flush from the side, but it is much simpler to render and doesn't cover up shorter plants and either way it looks a lot better than random patches of grass lacking snowcover (for the same reason I made it so snow is placed below trees during world generation):
1
I simply treat blocks below y=0 as solid, rather than air like vanilla does, in the "getBlockId" method in my "RenderChunkCache" class (equivalent to vanilla's "ChunkCache", which is also used by mob pathfinding so I split it apart as otherwise mobs would see the void as being able to be walked on; actually, they already do due to a bug in the pathfinding code, which I fixed):
You may notice that I also use a special method in Chunk which treats blocks in empty chunks (not loaded client-side) as solid as well so the sides of chunks at the edges of the loaded area aren't rendered either. As an aside, if applied to World.getBlockId (with the block returned being bedrock instead of stone) it would be impossible to fall into the void, it could even be rendered as a layer of bedrock to give one additional block of usable space in the world (256 instead of 255 + bedrock). The End would have to be handled separately so you can still fall into the void.
Water and lava work the same way as glass; you must check for adjacent blocks of the same type if you don't want them to render faces next to each other, this is also why water renders next to lava and vice-versa since they only check for themselves (or their material, which is how I added water plants which are functionally identical to water in every way, with some extra code to make water spread form them by placing flowing water net to them. I also had to modify the rendering code to allow for rendering a block on both the solid and translucent render passes).
This is the method I use to check if water and lava should render their sides, this includes checking whether the top should be rendered when below a solid block (or "water opaque", with glass and other full-cube blocks with transparent textures being treated in a special manner; instead of rendering the normal water texture over them I use the underwater overlay (the texture that tints the screen blue when underwater). Yes, more complicated but the additional time is still surpassed by the actual draw call, and other code changes and optimizations all down the line all benefit, plus I'm doing the extra checks at the same time as checking if the face should be rendered at all and they won't be called most of the time (e.g. water next to itself will skip the entire method past the first check for water):
Example of what it looks like when looking through glass underwater:
This shows how the top faces of lava below solid blocks are culled (only if a 3x3 area above is fully solid or lava source blocks, same for water); vanilla would be rendering them in every cave below y=11, adding up to many useless faces being rendered (I originally added it to water, as Mojang also did in 1.8, for aesthetical reasons, no weird air pockets below blocks; these are not visible with lava but culling hidden geometry improves overall performance):
Even 4096 block IDs seems like overkill to me, considering I still have over 50 IDs left despite adding nearly 400 new blocks, only counting "real" variants (using metadata and/or obtainable as legitimate items, as opposed to "render-states", e.g. the 168 variants of stalagmites I added only have 21 "real" variants across 3 block IDs, plus another 21 "technical" variants due to using metadata to determine whether they are stalagmites or stalactites. There are also tile entities, which can allow for a virtually infinite number of possible states, as I did with flower pots, via a single 32 bit integer; more recently I've done the same with buttons, doors, fence gates, etc; yes, TEs do use more resources but the game can easily handle thousands with no issues, especially since I fixed MC-117075 by simply changing an "ArrayList" to a "HashSet", and none of these use a "tile entity special renderer", which is why chests are so much worse than barrels despite otherwise being the same; I just extended TileEntityChest when I added barrels, with some changes to disable double chests and how the "lid" works).
In fact, I actually removed the support for extended block IDs in the chunk / save data in favor of increased performance due to not having to check if a block ID is above 255 or the "blockMSBArrray" exists. Aside from that, vanilla 1.6.4 (not Forge) needs a lot of work to properly use block IDs above 255, as I demonstrated here (they never fully implemented it across the entire codebase). If I did re-add it I'd probably do it a bit differently, and in some ways, more efficiently (a single 16 bit value can store a 12 bit ID and 4 bit metadata; while some operations might be slightly slower, such as only reading the ID, a simple bit operation, & 4095, is very cheap, and when both are needed you only need a single get/set call for both, hence why I added "block states". This also means only one array bounds check would be done by the JVM when accessing it, I haven't done this already since it would consume 33% more memory over separate ID and metadata arrays (the game stores metadata as 4 bit values packed 2 per byte so this does incur overhead to extract it. The memory usage may not actually be that significant considering 16 chunk render distance only needs around 160 MB. I'd also want to ensure saves are compatible with vanilla so this means splitting the 16 bit state into separate LSB/MSB/data arrays but those operations aren't necessarily expensive, I already extract the chunk heightmap from a custom map which stores multiple values in one array).
Fun fact: I have some old worlds laying around from back when I used Forge, including a mod which added an ore with the ID of 2000; I could actually safely load such a world without the extended ID support by adding a new block with an ID of 208 (11010000), the "base" ID for 2000 (011111010000), minus the upper 4 bits, and which is not used in vanilla 1.6.4, or even TMCW (much more problematic is the backpack mod I used, which would require using NBTExplorer to move all the items to a chest, as such I still haven't tried to make them playable again after a decade).
The only time I directly access the "storageArrays" is when reading block and light data, not setting blocks, except during initial chunk generation, as vanilla also does; everything else calls at least "Chunk.setBlock" or similar, which has various code to handle things like tile entities. Another special exception is a "setBlockFast" method I added, which is only supposed to be used when a block is changed to another similar block (such as when ores replace stone, but not stone replacing air or vice-versa. The reason is because it doesn't update lighting or the chunk heightmap or place/remove tile entities, causing major lighting errors (unfixable with normal relights) and leaving behind "orphaned" tile entities if this is done (the latter can cause issues like MC-163945), otherwise, it is the fastest possible way to change blocks, besides directly accessing sections but that can get rather complicated, what with the need to account for section boundaries and all).
I do something like this in TMCW; I completely bypass the "World.updateLight" method in favor of a much-simplified method which only updates the light level of the current block:
"this.update" is set to true when player-grown trees grow, which then uses the normal lighting methods as otherwise there will be more lighting errors; you'll also notice that I otherwise do not call "markBlockForUpdate", further speeding up world generation (I have a special method which marks an entire chunk as needing to be sent once world generation is complete).
As for the black spots during world generation, this is a limitation of the lighting engine which can only work if all neighboring chunks are loaded; the reason they persist is because the game fails to remember to continue the lighting updates after a chunk is unloaded, which I fixed by adding a NBT tag to the chunk format which is set to true once all checks have completed; i also made them run 8 times faster (taking 3.2 seconds instead of 25.6 second; you might have seen a comment by MCP that it takes 1.6 seconds but it is wrong; the time is (4096 blocks per section) / (8 blocks checked per tick) / (20 ticks/second) = 25.6 seconds. Furthermore, the client is a lot slower since of the 225 chunks within the ticking area only 10 are actually checked per tick, thus it takes 22.5 times longer (and yes, this means that vanilla takes nearly 10 minutes to complete all lighting checks! Since the server does not send light updates to the client it will take that long for all lighting glitches to disappear, while moving away and coming back after 25.6 seconds will also get rid of them). This has a negligible impact on performance, even when I enable "fast" relight checks which are 4 times faster still, as I also greatly optimized the whole lighting system (mostly by using a chunk cache for the fastest, most direct access of block and light data).
Here is a comparison of a vanilla Nether and from one of my modded worlds, showing the dramatic difference between them; vanilla is just filled with massive lighting errors (as well as some worldgen runaway due to MC-117810, on the northern and western sides, and some lavafalls spreading into unloaded chunks on the eastern and southern sides, which I fixed by adding a "chunksExist" check to scheduled block updates):
Note that you can still see unlit blocks near the edges, which is due to lighting updates not being run in the outermost chunks (much like chunk population, a light level 15 source can propagate up to 14 blocks away). I did add a special method which will update light all the way to the edge of loaded chunks but I only use it for light sources placed during world generation since the additional checks make it slower (even if probably still much faster than vanilla), and it will still cut off along the border between loaded and unloaded chunks, which is fixed by the relight checks.
Vanilla also tries to mask the lighting errors in the Nether by always having the client relight chunks every time they are loaded on the client (this is normally only done only after initial chunk generation). MC-80966 is another contributor as well; the game tries to "optimize" things by only sending chunk sections with any non-air blocks to the client, which can result in missing light information (chunks like this are uncommon enough* that the added overhead of just sending everything is negligible, plus again optimizations more than offset any impacts, e.g. I removed the entire "removeInvalidBlocks" method, which is executed every time a section is loaded form disk or received by the client, as it was rendered pointless by the removal of keeping track of the non-air block count, as well as assigning all unused IDs to a "placeholder block").
*A major exception: Vanilla 1.6.4 always creates all 16 sections in Superflat worlds, causing them to paradoxically use more memory, even when most aren't sent to the client, which will make it much worse (after fixing this I've seen a default Superflat world use as little as 20 MB. I also added code that periodically checks for and removes completely empty sections (no block or light data) from the top of a chunk column).
Another major change I made is that I defer updates to the sky light map until after world generation; that is, every time a new section is initialized the game calls a method to recalculate sky light over the chunk but I disable that, instead a flag is set ad if it is true then it will be recalculated all at once which can help a lot in biomes with giant trees, which may cause multiple sections to be created:
Within WorldGenChunkCache:
Within World; as noted before I make sure at least 64 blocks get updates to avoid lag spikes caused by the client placing each block one at a time:
All these changes I've made make world generation astoundingly fast, even in the most extreme situation imaginable:
This is what a "Mega Forest" looks like, you can't even begin to compare it to a vanilla jungle (note the Extreme Hills next to it, and that with a higher terrain height limit!) - yet there is no noticeable difference in the generation time of a normal world and a Superflat Mega Forest (with all normal features, including caves, other than the terrain height map, which does otherwise add some time):
For comparison, these are from vanilla 1.6.4 and 1.13.2 (the most recent version I've ever run), even vanilla 1.6.4 is slower despite being so much simpler overall (e.g. the "GenLayer" classes are 42 KB in vanilla and 160 KB in TMCW, and that understates the difference in complexity, e.g. I have 7 separate "edge" layers compared to vanilla's one and a whole complicated system of adding sub-biomes where a biome can register up to 6 sub-biomes in the main layer, plus several special layers; a more direct comparison might be my cave generator, which is 20 times larger than vanilla (World1 merges MapGenBase/Caves/Ravine into a single class, they are 21 KB separately, and is vanilla with some bugfixes):
2021-02-04 19:00:24 [SERVER] [INFO] Generating keypair
2021-02-04 19:00:24 [SERVER] [INFO] Converting map!
2021-02-04 19:00:24 [SERVER] [INFO] Scanning folders...
2021-02-04 19:00:24 [SERVER] [INFO] Total conversion count is 0
2021-02-04 19:00:24 [SERVER] [INFO] Preparing start region for level 0
2021-02-04 19:00:25 [SERVER] [INFO] Preparing spawn area: 9%
2021-02-04 19:00:26 [SERVER] [INFO] Preparing spawn area: 29%
2021-02-04 19:00:27 [SERVER] [INFO] Preparing spawn area: 57%
2021-02-04 19:00:28 [SERVER] [INFO] Preparing spawn area: 83%
2021-02-04 19:00:29 [SERVER] [INFO] TheMasterCaver[/127.0.0.1:0] logged in with entity id 223 at (226.5, 75.0, 256.5)
2021-02-04 19:00:29 [SERVER] [INFO] TheMasterCaver joined the game
Note that I consider the total time here to be 15 seconds, not 8.2:
[17:55:31] [Server thread/INFO]: Starting integrated minecraft server version 1.13.2
[17:55:31] [Server thread/INFO]: Generating keypair
[17:55:31] [Server thread/INFO]: Found new data pack vanilla, loading it automatically
[17:55:31] [Server thread/INFO]: Reloading ResourceManager: Default
[17:55:32] [Server thread/INFO]: Loaded 524 recipes
[17:55:33] [Server thread/INFO]: Loaded 571 advancements
[17:55:36] [Server thread/INFO]: Preparing start region for dimension minecraft:overworld
[17:55:37] [Server thread/INFO]: Preparing spawn area: 0%
[17:55:37] [Server thread/INFO]: Preparing spawn area: 4%
[17:55:38] [Server thread/INFO]: Preparing spawn area: 8%
[17:55:38] [Server thread/INFO]: Preparing spawn area: 12%
[17:55:38] [Server thread/INFO]: Preparing spawn area: 16%
[17:55:39] [Server thread/INFO]: Preparing spawn area: 20%
[17:55:39] [Server thread/INFO]: Preparing spawn area: 24%
[17:55:39] [Server thread/INFO]: Preparing spawn area: 28%
[17:55:40] [Server thread/INFO]: Preparing spawn area: 32%
[17:55:40] [Server thread/INFO]: Preparing spawn area: 36%
[17:55:40] [Server thread/INFO]: Preparing spawn area: 40%
[17:55:40] [Server thread/INFO]: Preparing spawn area: 44%
[17:55:41] [Server thread/INFO]: Preparing spawn area: 48%
[17:55:41] [Server thread/INFO]: Preparing spawn area: 52%
[17:55:41] [Server thread/INFO]: Preparing spawn area: 56%
[17:55:41] [Server thread/INFO]: Preparing spawn area: 60%
[17:55:42] [Server thread/INFO]: Preparing spawn area: 64%
[17:55:42] [Server thread/INFO]: Preparing spawn area: 68%
[17:55:42] [Server thread/INFO]: Preparing spawn area: 72%
[17:55:43] [Server thread/INFO]: Preparing spawn area: 76%
[17:55:43] [Server thread/INFO]: Preparing spawn area: 80%
[17:55:43] [Server thread/INFO]: Preparing spawn area: 84%
[17:55:43] [Server thread/INFO]: Preparing spawn area: 88%
[17:55:44] [Server thread/INFO]: Preparing spawn area: 92%
[17:55:44] [Server thread/INFO]: Preparing spawn area: 96%
[17:55:44] [Server thread/INFO]: Preparing spawn area: 100%
[17:55:44] [Server thread/INFO]: Time elapsed: 8520 ms
[17:55:45] [Server thread/INFO]: Changing view distance to 12, from 10
[17:55:46] [Server thread/INFO]: TheMasterCaver[local:E:c0336e00] logged in with entity id 754 at (58.5, 71.0, -104.5)
[17:55:46] [Server thread/INFO]: TheMasterCaver joined the game
Apparently Mojang recently did something to make world generation much faster (1-2 seconds) in the latest snapshot but that still relies on heavy multithreading (a thread per chunk being generated; I'd have expected 1.13 to have been much faster but if anything it was slower so I suspect the threads weren't being utilized properly, or attempting to use a resource which was only accessible by one thread at a time). I also noted that they said it seemed the world was still generating as it loaded in (normally the game waits until the entire spawn area has been generated before sending chunks to the client) so that is more like a work-around than a true speed-up.
In all, the changes I've made to the game are staggering - even my "World1 custom client", which only adds a few actual new features (a handful of storage blocks), is half the size of the vanilla codebase due to all the optimizations, bugfixes, and code refactorings I've made; TMCW, which is essentially a modded version of World1, has recently exceeded vanilla (though still smaller than 1.8 despite adding a lot more content), and Princess_Garnet is right when they say it can't be compared to vanilla (I still consider it perfectly valid to use it to show how vanilla should have been made; multithreading is going to disproportionately benefit those with many more CPU cores / overall performance, which varies a lot more than single-thread performance; most Minecraft players seem to have rather low-end systems, given the demographics, it is probably not unusual at all for them to have second-hand systems like I do, or a cheap laptop for school, which is another reason why you can't compare it to most games where, sure, you'll probably have a proper "gaming" computer).
0
That looks a lot like some code is incorrectly treating block coordinates as chunk coordinates, as in an example I'd shown before; the chunks will be at 16 times the distance of whatever feature is causing it. Even vanilla has had this issue, such as with fossil generation in 1.10 (fixed in 1.11):
MC-106524 Fossil generation causes chunks to be generated far away
The random chunks you may have seen around the edges in 1.6 was because the game did not check if chunks were loaded before ticking blocks (scheduled block updates, including flowing liquids, fires, and redstone). Fires in particular could cause performance issues due to constantly loading chunks and this was a likely contributor to the general lagginess in the Nether (this report mentions other causes but most aren't an issue in 1.6 because the view distance is always greater than the random ticking area; when Mojang added fine render distance control in 1.7 they just made them match, while I limit the view distance to at least 8, avoiding this issue, as well as buggy mob spawning on lower render distances due to entities spawning in "lazy" chunks so they are never ticked and thus never despawn):
MC-119994 Fires in the nether cause chunks to permanently load and cause lag
This is not present in any of my more recent worlds because I fixed it, along with cascading worldgen in the Nether due to a missing offset when placing hidden lava "traps", as seen in this comparison of the Nether of an older world (completely vanilla) and a recent world (this also shows the horrifically buggy lighting which also contributed to lag due to the client being told to relight chunks every time they were loaded, instead of actually fixing the issue server-side / in the saved data). Note that lava traps only caused chunks to load to the north and west, the relative handful to the south and east were due to lava springs:
MC-117810 Nether Lava Trap generation often loads new chunks
This bug report also claims that emerald ore can cause the same thing but it is never offset outside of the 2x2 chunk area and is only one block wide and notification of neighbor block updates is disabled during world generation (otherwise you'd need a 1 block margin around block changes):
MC-114332 Emerald ore generation can load new chunks
Also, this is an example of just how bad cascading world generation can be, which I caused by setting the size of dirt to 100 in 1.8's Customized world settings, which ended up crashing the game from a stack overflow error (this is because every single, or nearly so, chunk was loading more chunks, as opposed to the more occasional loading that usually occurs):
---- Minecraft Crash Report ----
// Would you like a cupcake?
Time: 5/5/16 6:13 PM
Description: Exception in server tick loop
java.lang.StackOverflowError: Exception in server tick loop
at lo.d(SourceFile:101)
at aht.a(SourceFile:298)
at aht.f(SourceFile:294)
at aht.o(SourceFile:675)
at aus.b(SourceFile:69)
at aij.a(SourceFile:329)
at aij.a(SourceFile:300)
at aij.a(SourceFile:93)
at aij.a(SourceFile:87)
at aig.a(SourceFile:245)
at ait.a(SourceFile:75)
at atm.b(SourceFile:473)
at ase.a(SourceFile:803)
at ase.a(SourceFile:777)
The wonders of multithreading, as I know that newer versions multithreaded the screenshot code and/or saving; the game freezes for me as well but it doesn't bother me (it would probably be easy to fix though; the code captures the pixel data from OpenGL, then processes it into a proper image and saves it and this is where most of the the lag likely occurs (saving a PNG is CPU intensive due to compression so it isn't just a disk performance issue, plus write-caching usually alleviates that), for the same reason even 1.6 uses a dedicated thread to save chunks, which was likely done to fix the "lag spike of death" issue that is a common complaint from those who play e.g. Beta 1.7.3 (I'm not actually sure what version multithreaded chunk saving but 1.3 would have alleviated it due to splitting the game logic and rendering into separate threads).
I know that mods like "Damage Screenshots" might become irritating though, considering that combat is one of the times when you least want freezes to occur (the classic "I died from a lag spike", though I've never experienced anything THAT severe), plus the server continues ticking while the client is frozen so the mobs get more time on you (I did fix this by making the server tick when the client tells it to in order to avoid various desyncs; the server uses the system time, which can be quite crude (tens of milliseconds) while the client uses a high resolution timer accurate to a fraction of a microsecond, necessary for a stable framerate and interpolation between frames).