I wanted to tell you that I've been busy irl and that's why I haven't made any videos. I can't wait to at one point have more time and make "decent" ones though.
I do read on and off what you post and check if there's any updates on TMCW. The fix you made fully works and I've tested it on several older intel devices (some of which intel macbooks). As always, thank you for sharing your wonderful mod(s) with us!
I do read on and off what you post and check if there's any updates on TMCW.
I haven't made any major changes but have made some small updates, such as allowing Blast and Fire Protection to stack (knockback and burn time), as Mojang did in 1.21 (e.g. two pieces with level 2 are equivalent to one with level 4, up to a max of 4 total) and smoothening the movement of mobs* (including fixing most cases of mobs appearing to fall, but then snapping back to their actual location, similar to the item glitch, which I improved earlier).
*Somebody showed me how to completely smooth out movement (most noticeable when falling) but I tested it and thought it added too much delay, e.g. punch a mob and it takes a noticeable amount of time to start moving, and some mobs moved weirdly (e.g. besides chickens rabbits didn't touch the ground between consecutive jumps), thus I haven't added it yet, or might make it toggleable (I'd already made changes to make mobs smoother, more noticeable with swimming and flying mobs as they handle increased interpolation delay better).
I've also thought of some other features, like enabling game rules to be changed when creating a new world, like in modern versions (no need to enable cheats or open to LAN to change them initially), and making player skins tied to their username (not a full online fix, you'd add skins to a resource pack or separate skins folder).
First of all, many, many thanks for sharing your creation as TMCW. I first discovered it over a year or so ago (sometime in October, 2023); I have played it on and off since then. Sadly I don't have anything worth sharing from those worlds as I was mostly dabbling and observing.
I really like your vision on the game; most of the changes you have made, including all the bugs you have fixed. And it's really mind-boggling at how optimized it is; I mean `-Xmx512M`, come on!
And another thing; ever since I have played TMCW, I cringe at the memory consumption of any other version that I open; not to mention another modded instance. And this PC I'm currently using isn't a potato computer by any means; but after seeing this difference, it makes me scratch my head and wonder (What in the #@*% is actually being loaded into memory!)?
Well, I appreciate your efforts, and I'll second what Akrios has said … TMCW "has become my one and only Minecraft" as well.
It runs surprisingly well on a Pentium Dual-Core with GMA 4500MHD and 4GB RAM (Windows XP SP3). Inconsistent framerate, but it's stable enough to suffice on this ancient Dell Inspiron 1545 I'm using for the time being.
Two minor caveats however:
- The lighting on things like player hands is screwed up, but this also extends to quite a few other things, too. It's also screwed up in vanilla 1.2.5 as well (but not in Beta 1.7.3), so this seems to be a very old bug involving these iGPUs and the lighting engine.
- I can't find the setting that disables the sky, which I found greatly improved performance on this machine in B1.7.3. Did you remove it or was it just never an option to start with?
Also, I see v5.10 fixes the incredibly annoying bug where the door sound would creak twice. Thank you, because that was getting on my nerves, and wasn't something that existed in vanilla.
- The lighting on things like player hands is screwed up, but this also extends to quite a few other things, too. It's also screwed up in vanilla 1.2.5 as well (but not in Beta 1.7.3), so this seems to be a very old bug involving these iGPUs and the lighting engine.
- I can't find the setting that disables the sky, which I found greatly improved performance on this machine in B1.7.3. Did you remove it or was it just never an option to start with?
Does this still happen in the latest version? It seems like Intel drivers are just so screwed up, I thought I'd fixed the issue a year ago, based on the fact that only Beta 1.9-1.7.10 had graphical issues, and somebody showed me the code differences between Beta 1.8 and 1.9, then more recently somebody else said they had rendering errors (parts of entities being invisible and/or incorrectly shaded, depending on the driver version), so I changed the fix to one somebody else had come up with based on my original fix, which seemed to fix the issues for them*.
*While TMCW no longer has the original fix you can find both in this download (the "OpenGlHelper" version should work with TMCW and vanilla 1.6.4, if added to TMCW it will effectively apply the fixes twice (I haven't tested what doing does, or have the proper system to test any of them), TMCW has its own custom "Tessellator" so that fix can't be removed):
As for the sky, I've only seen that as part of Optifine, or vanilla behavior at low render distances (MC-123654, I made them always render since they didn't seem to make much of a difference, I also made changes that should optimize it).
As for the sky, I've only seen that as part of Optifine
I noticed a lot of settings in your mod that were similar to Optifine's, so I kind of just assumed the sky settings were also there too, but they weren't... And on this iGPU it seems to make an incredibly drastic change, for some reason. The 4500MHD (ICH9M chipset), also known as an X4500 HD, is 'marginally better than a GMA950', in other words, it's probably about as 'good' as an S3 ViRGE or something.
I tried two different driver versions (the one for this device and the other was from like 2011 or so) so it's clearly just Intel OpenGL support being its usual self. In other words, shite.
Does this still happen in the latest version?
Given it doesn't even run anything above 1.6.4, that's a big ask.
*While TMCW no longer has the original fix you can find both in this download (the "OpenGlHelper" version should work with TMCW and vanilla 1.6.4, if added to TMCW it will effectively apply the fixes twice (I haven't tested what doing does, or have the proper system to test any of them), TMCW has its own custom "Tessellator" so that fix can't be removed):
Given it doesn't even run anything above 1.6.4, that's a big ask.
Unrelated but do you happen to have the java arguments you use on hand?
I meant the latest version of TMCW, which includes an improved version of the Intel Intel fix, but it is entirely possible this issue is something completely different (the issue I fixed started with drivers released in late 2021).
These are the JVM arguments that I use, a modification of the "original" ones (2013?), which originally included Xmx1G and "CMSIncrementalMode" (which was mainly intended for single-core CPUs):
I'm not actually sure if the last two actually do anything, if anything, I was able to get TMCW running with as little as 96 MB by removing them (yes, 96 MB); given that it never actually uses more than 256 MB at default settings, e.g. I took this screenshot after playing for a couple hours, that would work just as well (I think the intent was to prevent the new generation from becoming too large to help with garbage collection performance, it seems the JVM will default it to 1/3 of the heap, so a 1 GB heap will use 2-3x more than if not set).
I'll note that the "CMS" collector is generally regarded as low-performance and isn't even supported by modern Java versions but is still seen as a more lightweight option for older versions and computers, and allocation rates on these versions are much lower (I highly disagree with the post saying that 1.13 and below should use this, that should be no newer than 1.7.10 as 1.8 is when GC demands skyrocketed; TMCW itself is significantly lower than vanilla 1.6.4, similar to pre-1.3 versions according to sp614x):
I also originally reduced the default allocation to 512-768 MB since my old 32 bit system would give "out of memory" errors (not crashes but a screen) despite plenty of free heap and system RAM, which came down to the 32 bit process size limit (I've seen it reach 1.5 GB on max settings with 512 MB allocated so this makes sense since that is about the max a 32 bit process can use, albeit I never actually used 16 chunks back then (the 1.6.4 version of Optifine, likely others, doesn't even work properly at 11-16, it keeps the server's view distance at 10 until you set it to 17 or more).
I added the ability to turn the sky and sun/moon/stars off, via a couple settings in the options file (I haven't added in-game settings yet); these work pretty much the same way as Optifine (I checked), note that you'll probably want to add these manually (else you'll have to change some settings for the game to write them to the file):
skyEnabled:true
sunEnabled:true
Although it is interesting how the sky can have such a big impact, all it does is render a couple "grids" using a handful of draw calls, each a fraction of the complexity of a single chunk section (or one side of, basically 8x8 blocks without textures), one for the "sky" and one for the "void".
I also noticed some interesting effects of disabling the sky and an additional layer that is visible around sunrise/sunset; terrain seamlessly blends into the distance (not visible against the sky unless the sun is behind it), including underground:
Normal sunrise; you can see the silhouettes of trees in the distance:
With the sky disabled (and sun but that doesn't matter here):
A cave with Night Vision or direct sunlight, the black area below the "horizon" (as it would be at sea level) sharply contrasts with the sky above it:
The same cave with the sky disabled:
For comparison, this is without Night Vision or sky light, which looks the same either way:
Interestingly, this bug report is marked as "won't fix", although disabling the sky does make sunrise/sunset a lot duller and I have no idea how to make fog render with multiple colors/color gradient to match the sky (likely impossible with basic OpenGL fog, which also only renders as a flat plane on non-NVIDIA GPUs; "won't fix" in this case may simply mean "too difficult to implement"):
Also, speaking of fog, Optifine says it can have a big impact but I never noticed it (including the difference between "fast" and "fancy", the latter the vanilla fog and only supported by NVIDIA GPUs), "void fog" did have a noticeable impact but that was due to the particles, as noted here (FPS doubled without particles but completely disabling fog had little impact. The main reason I disabled/removed it was the visibility, especially with caves being 7 layers deeper, with the darkening effect that otherwise occurs improved).
I'm curious as to which OS you are (and were) using during your time creating TMCW?
I had Windows 7, though the system (before my father gave it to me) likely originally had XP since the CPU/GPU were from 2005/2006; I got in in 2010 and used it until 2016; as noted in threads like "why do I still play in 1.6.4" this was a major factor in not updating to newer versions, it ran 1.6 decently well, mainly limited by VRAM (only 256 MB), Optifine reduced stutters due to chunk updates but otherwise had no impact on FPS (the "Advanced OpenGL" option did though, doubling it when enabled). Versions since 1.7 introduced a strange stuttering issue where every 10th frame seemed to take half the total frametime, halving FPS from 1.6, with a very noticeable stutter, which worsened in 1.8 due to generally lower FPS (at the time a majority said that 1.8 worsened performance, though these days it seems to be the opposite (at least when it comes to chunk rendering performance, it is true that 1.7.10 and earlier had issues, e.g. with Vsync enabled and a bug where the game simply forgot to render chunks, but I think some people place way too much importance on that single metric, plus the bugs are easy to fix). 1.7 itself also had a known issue that caused freezes and lag spikes, influencing perspectives since most would probably be comparing 1.7 and 1.8):
I'll note that even my "double / triple height terrain" mods didn't have a significant impact on performance despite having 2-3 times the ground depth and volume of caves (back then they were still mostly vanilla tunnels, which are more intensive to generate and render than a large open area, which dominate the additional volume in TMCW over vanilla), these were on "Far" (vanilla and DHT), I've used this as a counter-argument to 1.18 being significantly more demanding (Amplified didn't cause the claimed issues either, despite saying you needed a "beefy" computer, maybe slower terrain generation, back then TMCW took about half a minute to generate a Superflat "Mega Forest" world, albeit without any of the optimizations I've made since them (really only since TMCWv4.5, you could still use Optifine with it until then but it only optimizes rendering, mainly via more options):
Another example from "double height terrain", early on I also used Forge with a handful of mods (backpacks, amethyst armor/tools, mini map, plus my own "jar" mods; apparently I thought you made Forge mods by directly editing the source it provides but they obviously didn't work in the mods folder, but did when added manually, and they had the necessary Forge patches so there were no compatibility issues (Optifine does a similar thing to make itself compatible, it is a bit complicated though since you can't just directly reference Forge if you want to be compatible with vanilla by itself):
An example of VRAM exhaustion due to setting leaves to Fancy (even now I still set them to Fast because I prefer their appearance, with some tweaks to the textures so they are more vivid, the black spaces are colored. There is also the option to remove ambient occlusion (shadows) from leaves, as some say they prefer this look (older Alpha/Beta versions didn't have smooth lighting on leaves, making them brighter):
The 1.7+ stuttering was completely independent of any settings, suggesting some weirdness going on in the code or how something the game does interacts with the system/driver (aside from the single frame spikes there was also a distinct sine wave pattern of frametime rising and falling, also visible as a speedup/slowdown):
One thing I find quite interesting about this is that the "C: rendered/total" value is so high, in 1.8 Mojang replaced "Advanced OpenGL" (hardware occlusion queries, albeit not supported well on non-NVIDIA hardware) with their own "Advanced Cave Culling Algorithm", yet it didn't seem to actually cull that much (in fact, there are more sections being rendered than in any of the previous three images, all at the same render distance. the cave I'm in isn't exactly vanilla but not really that big either):
Perhaps the oddest thing about 1.8 is the insane performance drop when going underwater, all the way down to 1-2 FPS, with no possible explanation I could think of (somebody said it had to do with changes to water physics due to ocean monuments, but what changes? The change so water no longer renders its top face below solid blocks? If anything, that should help by culling those faces, though I later heard it had to do with particle rendering, but such a drop never occurred in older versions:
For comparison, this is with and without void fog and/or particles, only the particles caused a significant drop, but still nowhere near as much as water in 1.8 (the particles are essentially the same, void particles are also created much faster and consistently reach the particle limit, the game is creating many more that are just discarded):
Void fog and particles (the apparent decline in memory usage with each successive screenshot is coincidental, though particle creation does increase allocation rate):
No fog (but particles):
Neither (or no particles, fog itself had no noticeable impact, I also disabled all fog, not just void fog, as Optifine didn't have an option for just the latter without also disabling particles):
I've since upgraded computers twice, if still behind current technology; I have Windows 10 (on the last two systems) and it tells me I can't update to Windows 11 but I'm not interested in doing so; likewise, my reason for not updating to newer versions of the game is the lack of any content that interests me, and all the changes I dislike; sure, some could be easily changed with mods (until 1.13 I made "old caves" mods that reverted the changes to caves in 1.7, I also made a mod for 1.8 that reverted the changes to anvils (they removed renaming to keep the cost down), and a "random biomes" mod that removed the "climate" system) but at that point, considering how I play, I may as well just mod any version and it is much easier to stay on the same code base (e.g. all the mods that stopped updating at 1.7.10, 1.12.2, etc), even versions like Beta and older are popular for similar reasons (the most famous example of a "total conversion" / "alternate development path" / "fork" mod being "Better Than Wolves", which did update to 1.5.2 before staying on it until the original creator discontinued it, the Beta 1.7.3 version seems to be the most popular though).
I remember reading your post somewhere about being limited by hardware for quite some time, and so then I was curious about the transitions of hardware (and OSes) during version progress of TMCW.
Yep, same experience for me with all of those issues you describe during the 1.7 versions; and when I go back and look, there was absolutely nothing useful (for me) added during those versions either. Even to this day, I go back and play a version from 1.7; I think because of certain (minimal) mods I enjoyed similar to your selection (mini map, etc). Once the stutters and screen tearing begin, I get frustrated then switch back to TMCW.
Thanks to the way you improved the in-game maps; and they don't completely replace mini map mods, but mapping things out is much easier for me.
Speaking of those effects at bedrock (the particles and void fog), I kinda miss them in TMCW. I didn't see an obvious setting, so I figured you had good reason to remove them. I have been okay without that though.
It's funny- when I watch someone playing in TMCW, that's the first thing they go for- changing to the fancy leaves. However, I do the same thing so; probably because the versions I started playing in already had them enabled. I will revisit this again since you mention some of those options.
Mmm- Windows 10 huh. Okay.
Well thanks, and I'll call again sometime or another.
Big edit: turns out that no, it's not the sky causing lag, it seems to be related more to chunk loading being taxing on this PC, if anything else.
Leaving the settings on default performs almost identically to on 'fastest' settings. In other words, I should have bought a more powerful laptop, I just didn't exactly have money at the time among other things.
I meant the latest version of TMCW, which includes an improved version of the Intel Intel fix, but it is entirely possible this issue is something completely different (the issue I fixed started with drivers released in late 2021).
TMCWv5 included the bma.class (net/minecraft/src/OpenGlHelper.java) fix. TMCWv5.10 made changes to bfq.class (net/minecraft/src/Tessellator.java), moving two blocks of code and adding an unused private field (`private int lastError = -1;`). But TMCWv5.10 does not include any bma.class. This means that if you install the mod on vanilla 1.6.4, you will have vanilla behavior of OpenGlHelper, without the client active texture merge.
TMCWv5 included the bma.class (net/minecraft/src/OpenGlHelper.java) fix. TMCWv5.10 made changes to bfq.class (net/minecraft/src/Tessellator.java), moving two blocks of code and adding an unused private field (`private int lastError = -1;`). But TMCWv5.10 does not include any bma.class. This means that if you install the mod on vanilla 1.6.4, you will have vanilla behavior of OpenGlHelper, without the client active texture merge.
I replaced my original fix with an improved version made by CoreTweaks (more or less, they simply add a call to OpenGlHelper.setClientActiveTexture at the beginning of the "draw" method while I added it in a more intuitive way, only being set if texture is enabled and the lightmap/brightness is not used, as its associated block of code resets the texture unit to default anyway and I thus moved it before the one that handles texture):
I assume this is also the more proper way to fix it as it sets the texture unit during the actual draw call, not whenever it might be set within OpenGlHelper, which can be at any time outside of draw calls (and I assume whenever the corresponding display list is used, not sure exactly what happens when they get compiled), hence the erratic behavior seen on some systems with the original fix (I'm referring to this post and the following replies; the original fix did fix the graphics completely breaking down but parts of entities were invisible and/or black, depending on driver version. I assume that the bug itself is due to Intel drivers not persisting the state of the active texture unit, since I'd intuitively expect it is correctly reset back to default, as it is after any calls that deal with the lightmap).
Also, I assume you decompiled TMCW itself; the unused field and (others elsewhere) are due to debug code which is removed at compilation, leaving such seemingly unused fields and/or methods (it gets set to the value of "BlocksMined.getDisplayMode()", i.e. the value that controls what the "inventory stats" display, when an error condition is detected, so it only dumps a single stack trace until I toggle it, same for various other errors. Vanilla simply crashes the game here and in many other areas):
if (DebugHelper.DEBUG_TESSELLATOR)
{
if (this.isDrawing && this.hasData())
{
if (this.lastError != BlocksMined.getDisplayMode())
{
this.lastError = BlocksMined.getDisplayMode();
System.out.println("Warning: Called Tessellator.startDrawing() while a draw call was in progress!");
Thread.dumpStack();
}
}
else
{
this.isDrawing = true;
}
}
Also, incorrect shading, without any other issues, seems to have been a common problem back in the day, with a lot of threads like this, suggesting some obscure bug, as well as a bug report of what looks like the same issue, resolved as "incomplete" (last affected version listed is 1.8.4, said to happen at least as far back as Beta 1.8):
The bug report also leads to a related issue which was marked as fixed in a 1.8 snapshot, and a comment links to a mod which claims to fix it, the download to which is luckily still up, and it is a simple jar mod (class file, bam.class for the 1.7.10 version, which matches RenderHelper after searching for files with the same specific lines as decompiled with Java Decompiler, and a comparison shows some differences; a value was changed from 0.4 to 1.0 and some code was duplicated with the duplicate having the original value):
At the same time, I looked at online source for 1.12 and it seems to be the same as 1.6.4 (as are the OpenGlHelper methods) so it is likely that some other change fixed both of these in newer versions (the 1.12 source I have is actually a decompiled version of Optifine so it may not be entirely vanilla, OpenGlHelper is definitely modified (it seems completely unnecessary in 1.6.4 as all it does is call a method of Optifine's own class to initialize some stuff, which could have been put elsewhere, and adds a couple unused (only set but never read) fields; the 1.12 version does make various other changes, at least stuff like "Config.isMultiTexture()". Standard decompilers also don't replace OpenGL constants with their original names, as does the 1.12 Optifine source (otherwise deobfuscated), so they are just numbers but I think they are unchanged).
Also, I did previously find causes for a lot of shading issues which should affect any system, thus I was able to reproduce them (or more like discover them and figure out how to fix them); many were due to the game using "RenderHelper.enableStandardItemLighting" instead of simply using "GL11.glEnable(GL11.GL_LIGHTING)" and the corresponding disable methods to enable/disable lighting (the former will reinitialize lighting with the transformations that were applied to the entity being rendered, not the original unaltered matrix, hence shading that varies as you/the entity rotate, e.g. MC-10135 and when the ender dragon is healing/dying (MC-91761 seems to describe this), I've also found some other sources with different causes, such as heads/skulls causing lighting errors on signs and possibly other tile entities due to omitting "GL11.glDisable(GL12.GL_RESCALE_NORMAL)" after rendering them).
It seems that the Intel lighting fix I found is just a hack which disables entity shading entirely (except for items in the inventory) as I tested it and entities were uniformly fully lit, with many details lost as a result (I even copied the decompiled bam.java file and renamed the methods just to be sure everything was correct as the OpenGL constants were just numbers):
Dear MasterCaver,
I hope you're doing well.
I wanted to tell you that I've been busy irl and that's why I haven't made any videos. I can't wait to at one point have more time and make "decent" ones though.
I do read on and off what you post and check if there's any updates on TMCW. The fix you made fully works and I've tested it on several older intel devices (some of which intel macbooks). As always, thank you for sharing your wonderful mod(s) with us!
I haven't made any major changes but have made some small updates, such as allowing Blast and Fire Protection to stack (knockback and burn time), as Mojang did in 1.21 (e.g. two pieces with level 2 are equivalent to one with level 4, up to a max of 4 total) and smoothening the movement of mobs* (including fixing most cases of mobs appearing to fall, but then snapping back to their actual location, similar to the item glitch, which I improved earlier).
*Somebody showed me how to completely smooth out movement (most noticeable when falling) but I tested it and thought it added too much delay, e.g. punch a mob and it takes a noticeable amount of time to start moving, and some mobs moved weirdly (e.g. besides chickens rabbits didn't touch the ground between consecutive jumps), thus I haven't added it yet, or might make it toggleable (I'd already made changes to make mobs smoother, more noticeable with swimming and flying mobs as they handle increased interpolation delay better).
I've also thought of some other features, like enabling game rules to be changed when creating a new world, like in modern versions (no need to enable cheats or open to LAN to change them initially), and making player skins tied to their username (not a full online fix, you'd add skins to a resource pack or separate skins folder).
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?
As always, I'm sorry for the sort of late reply (never on purpose, of course).
Thank you for sharing!
Regardless of what you decide to add or not, this has become my one and only Minecraft. Nothing comes even close.
I'm really happy to hear from you and just happy to know you're still so passionate about Minecraft and TMCW.
I have TMCW installed on almost every device I own (if possible) and I don't even know what's going on with current Minecraft.
TMCW is a true (hidden) gem!
Anyways, happy halloween and have a great weekend!
Just another TMCW fan here.
First of all, many, many thanks for sharing your creation as TMCW. I first discovered it over a year or so ago (sometime in October, 2023); I have played it on and off since then. Sadly I don't have anything worth sharing from those worlds as I was mostly dabbling and observing.
I really like your vision on the game; most of the changes you have made, including all the bugs you have fixed. And it's really mind-boggling at how optimized it is; I mean `-Xmx512M`, come on!
And another thing; ever since I have played TMCW, I cringe at the memory consumption of any other version that I open; not to mention another modded instance. And this PC I'm currently using isn't a potato computer by any means; but after seeing this difference, it makes me scratch my head and wonder (What in the #@*% is actually being loaded into memory!)?
Well, I appreciate your efforts, and I'll second what Akrios has said … TMCW "has become my one and only Minecraft" as well.
It runs surprisingly well on a Pentium Dual-Core with GMA 4500MHD and 4GB RAM (Windows XP SP3). Inconsistent framerate, but it's stable enough to suffice on this ancient Dell Inspiron 1545 I'm using for the time being.
Two minor caveats however:
- The lighting on things like player hands is screwed up, but this also extends to quite a few other things, too. It's also screwed up in vanilla 1.2.5 as well (but not in Beta 1.7.3), so this seems to be a very old bug involving these iGPUs and the lighting engine.
- I can't find the setting that disables the sky, which I found greatly improved performance on this machine in B1.7.3. Did you remove it or was it just never an option to start with?
Also, I see v5.10 fixes the incredibly annoying bug where the door sound would creak twice. Thank you, because that was getting on my nerves, and wasn't something that existed in vanilla.
Thanks in advance~
Does this still happen in the latest version? It seems like Intel drivers are just so screwed up, I thought I'd fixed the issue a year ago, based on the fact that only Beta 1.9-1.7.10 had graphical issues, and somebody showed me the code differences between Beta 1.8 and 1.9, then more recently somebody else said they had rendering errors (parts of entities being invisible and/or incorrectly shaded, depending on the driver version), so I changed the fix to one somebody else had come up with based on my original fix, which seemed to fix the issues for them*.
*While TMCW no longer has the original fix you can find both in this download (the "OpenGlHelper" version should work with TMCW and vanilla 1.6.4, if added to TMCW it will effectively apply the fixes twice (I haven't tested what doing does, or have the proper system to test any of them), TMCW has its own custom "Tessellator" so that fix can't be removed):
https://www.dropbox.com/scl/fi/cnhayr0rwbkh9d7h7j6h4/1.6.4_opengl_fix.zip?rlkey=vkyn73bzwiiao7t7tag589t4z&dl=0
As for the sky, I've only seen that as part of Optifine, or vanilla behavior at low render distances (MC-123654, I made them always render since they didn't seem to make much of a difference, I also made changes that should optimize it).
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?
I noticed a lot of settings in your mod that were similar to Optifine's, so I kind of just assumed the sky settings were also there too, but they weren't... And on this iGPU it seems to make an incredibly drastic change, for some reason. The 4500MHD (ICH9M chipset), also known as an X4500 HD, is 'marginally better than a GMA950', in other words, it's probably about as 'good' as an S3 ViRGE or something.
I tried two different driver versions (the one for this device and the other was from like 2011 or so) so it's clearly just Intel OpenGL support being its usual self. In other words, shite.
Given it doesn't even run anything above 1.6.4, that's a big ask.
What would installing the same fix twice to TMCWv5.10 achieve? Sorry if I'm misunderstanding.
Unrelated but do you happen to have the java arguments you use on hand?
I meant the latest version of TMCW, which includes an improved version of the Intel Intel fix, but it is entirely possible this issue is something completely different (the issue I fixed started with drivers released in late 2021).
These are the JVM arguments that I use, a modification of the "original" ones (2013?), which originally included Xmx1G and "CMSIncrementalMode" (which was mainly intended for single-core CPUs):
-Xmx512M -XX:+UseConcMarkSweepGC -XX:-UseAdaptiveSizePolicy -Xmn128M
I'm not actually sure if the last two actually do anything, if anything, I was able to get TMCW running with as little as 96 MB by removing them (yes, 96 MB); given that it never actually uses more than 256 MB at default settings, e.g. I took this screenshot after playing for a couple hours, that would work just as well (I think the intent was to prevent the new generation from becoming too large to help with garbage collection performance, it seems the JVM will default it to 1/3 of the heap, so a 1 GB heap will use 2-3x more than if not set).
I'll note that the "CMS" collector is generally regarded as low-performance and isn't even supported by modern Java versions but is still seen as a more lightweight option for older versions and computers, and allocation rates on these versions are much lower (I highly disagree with the post saying that 1.13 and below should use this, that should be no newer than 1.7.10 as 1.8 is when GC demands skyrocketed; TMCW itself is significantly lower than vanilla 1.6.4, similar to pre-1.3 versions according to sp614x):
https://www.reddit.com/r/technicalminecraft/comments/n9pbqe/minecrafts_default_jvm_arguments/
I also originally reduced the default allocation to 512-768 MB since my old 32 bit system would give "out of memory" errors (not crashes but a screen) despite plenty of free heap and system RAM, which came down to the 32 bit process size limit (I've seen it reach 1.5 GB on max settings with 512 MB allocated so this makes sense since that is about the max a 32 bit process can use, albeit I never actually used 16 chunks back then (the 1.6.4 version of Optifine, likely others, doesn't even work properly at 11-16, it keeps the server's view distance at 10 until you set it to 17 or more).
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?
I added the ability to turn the sky and sun/moon/stars off, via a couple settings in the options file (I haven't added in-game settings yet); these work pretty much the same way as Optifine (I checked), note that you'll probably want to add these manually (else you'll have to change some settings for the game to write them to the file):
Although it is interesting how the sky can have such a big impact, all it does is render a couple "grids" using a handful of draw calls, each a fraction of the complexity of a single chunk section (or one side of, basically 8x8 blocks without textures), one for the "sky" and one for the "void".
I also noticed some interesting effects of disabling the sky and an additional layer that is visible around sunrise/sunset; terrain seamlessly blends into the distance (not visible against the sky unless the sun is behind it), including underground:
With the sky disabled (and sun but that doesn't matter here):
A cave with Night Vision or direct sunlight, the black area below the "horizon" (as it would be at sea level) sharply contrasts with the sky above it:
The same cave with the sky disabled:
For comparison, this is without Night Vision or sky light, which looks the same either way:
Interestingly, this bug report is marked as "won't fix", although disabling the sky does make sunrise/sunset a lot duller and I have no idea how to make fog render with multiple colors/color gradient to match the sky (likely impossible with basic OpenGL fog, which also only renders as a flat plane on non-NVIDIA GPUs; "won't fix" in this case may simply mean "too difficult to implement"):
MC-130265 Fog color does not match with sky color, causing players to be able to see things that should be completely obscured by the fog
Also, speaking of fog, Optifine says it can have a big impact but I never noticed it (including the difference between "fast" and "fancy", the latter the vanilla fog and only supported by NVIDIA GPUs), "void fog" did have a noticeable impact but that was due to the particles, as noted here (FPS doubled without particles but completely disabling fog had little impact. The main reason I disabled/removed it was the visibility, especially with caves being 7 layers deeper, with the darkening effect that otherwise occurs improved).
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?
I'm curious as to which OS you are (and were) using during your time creating TMCW?
I'm guessing that your "old 32 bit system" was probably Windows XP?
And so your current OS now is (I won't even guess)?
I'm asking because I have an interest in tinkering with the JDK and learning MCP; I found the links to that version (v8.11).
Thank you.
I had Windows 7, though the system (before my father gave it to me) likely originally had XP since the CPU/GPU were from 2005/2006; I got in in 2010 and used it until 2016; as noted in threads like "why do I still play in 1.6.4" this was a major factor in not updating to newer versions, it ran 1.6 decently well, mainly limited by VRAM (only 256 MB), Optifine reduced stutters due to chunk updates but otherwise had no impact on FPS (the "Advanced OpenGL" option did though, doubling it when enabled). Versions since 1.7 introduced a strange stuttering issue where every 10th frame seemed to take half the total frametime, halving FPS from 1.6, with a very noticeable stutter, which worsened in 1.8 due to generally lower FPS (at the time a majority said that 1.8 worsened performance, though these days it seems to be the opposite (at least when it comes to chunk rendering performance, it is true that 1.7.10 and earlier had issues, e.g. with Vsync enabled and a bug where the game simply forgot to render chunks, but I think some people place way too much importance on that single metric, plus the bugs are easy to fix). 1.7 itself also had a known issue that caused freezes and lag spikes, influencing perspectives since most would probably be comparing 1.7 and 1.8):
Another example from "double height terrain", early on I also used Forge with a handful of mods (backpacks, amethyst armor/tools, mini map, plus my own "jar" mods; apparently I thought you made Forge mods by directly editing the source it provides but they obviously didn't work in the mods folder, but did when added manually, and they had the necessary Forge patches so there were no compatibility issues (Optifine does a similar thing to make itself compatible, it is a bit complicated though since you can't just directly reference Forge if you want to be compatible with vanilla by itself):
An example of VRAM exhaustion due to setting leaves to Fancy (even now I still set them to Fast because I prefer their appearance, with some tweaks to the textures so they are more vivid, the black spaces are colored. There is also the option to remove ambient occlusion (shadows) from leaves, as some say they prefer this look (older Alpha/Beta versions didn't have smooth lighting on leaves, making them brighter):
The 1.7+ stuttering was completely independent of any settings, suggesting some weirdness going on in the code or how something the game does interacts with the system/driver (aside from the single frame spikes there was also a distinct sine wave pattern of frametime rising and falling, also visible as a speedup/slowdown):
One thing I find quite interesting about this is that the "C: rendered/total" value is so high, in 1.8 Mojang replaced "Advanced OpenGL" (hardware occlusion queries, albeit not supported well on non-NVIDIA hardware) with their own "Advanced Cave Culling Algorithm", yet it didn't seem to actually cull that much (in fact, there are more sections being rendered than in any of the previous three images, all at the same render distance. the cave I'm in isn't exactly vanilla but not really that big either):
Perhaps the oddest thing about 1.8 is the insane performance drop when going underwater, all the way down to 1-2 FPS, with no possible explanation I could think of (somebody said it had to do with changes to water physics due to ocean monuments, but what changes? The change so water no longer renders its top face below solid blocks? If anything, that should help by culling those faces, though I later heard it had to do with particle rendering, but such a drop never occurred in older versions:
For comparison, this is with and without void fog and/or particles, only the particles caused a significant drop, but still nowhere near as much as water in 1.8 (the particles are essentially the same, void particles are also created much faster and consistently reach the particle limit, the game is creating many more that are just discarded):
Void fog and particles (the apparent decline in memory usage with each successive screenshot is coincidental, though particle creation does increase allocation rate):
No fog (but particles):
Neither (or no particles, fog itself had no noticeable impact, I also disabled all fog, not just void fog, as Optifine didn't have an option for just the latter without also disabling particles):
I've since upgraded computers twice, if still behind current technology; I have Windows 10 (on the last two systems) and it tells me I can't update to Windows 11 but I'm not interested in doing so; likewise, my reason for not updating to newer versions of the game is the lack of any content that interests me, and all the changes I dislike; sure, some could be easily changed with mods (until 1.13 I made "old caves" mods that reverted the changes to caves in 1.7, I also made a mod for 1.8 that reverted the changes to anvils (they removed renaming to keep the cost down), and a "random biomes" mod that removed the "climate" system) but at that point, considering how I play, I may as well just mod any version and it is much easier to stay on the same code base (e.g. all the mods that stopped updating at 1.7.10, 1.12.2, etc), even versions like Beta and older are popular for similar reasons (the most famous example of a "total conversion" / "alternate development path" / "fork" mod being "Better Than Wolves", which did update to 1.5.2 before staying on it until the original creator discontinued it, the Beta 1.7.3 version seems to be the most popular though).
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?
I remember reading your post somewhere about being limited by hardware for quite some time, and so then I was curious about the transitions of hardware (and OSes) during version progress of TMCW.
Yep, same experience for me with all of those issues you describe during the 1.7 versions; and when I go back and look, there was absolutely nothing useful (for me) added during those versions either. Even to this day, I go back and play a version from 1.7; I think because of certain (minimal) mods I enjoyed similar to your selection (mini map, etc). Once the stutters and screen tearing begin, I get frustrated then switch back to TMCW.
Thanks to the way you improved the in-game maps; and they don't completely replace mini map mods, but mapping things out is much easier for me.
Speaking of those effects at bedrock (the particles and void fog), I kinda miss them in TMCW. I didn't see an obvious setting, so I figured you had good reason to remove them. I have been okay without that though.
It's funny- when I watch someone playing in TMCW, that's the first thing they go for- changing to the fancy leaves. However, I do the same thing so; probably because the versions I started playing in already had them enabled. I will revisit this again since you mention some of those options.
Mmm- Windows 10 huh. Okay.
Well thanks, and I'll call again sometime or another.
Big edit: turns out that no, it's not the sky causing lag, it seems to be related more to chunk loading being taxing on this PC, if anything else.
Leaving the settings on default performs almost identically to on 'fastest' settings. In other words, I should have bought a more powerful laptop, I just didn't exactly have money at the time among other things.
TMCWv5 included the bma.class (net/minecraft/src/OpenGlHelper.java) fix. TMCWv5.10 made changes to bfq.class (net/minecraft/src/Tessellator.java), moving two blocks of code and adding an unused private field (`private int lastError = -1;`). But TMCWv5.10 does not include any bma.class. This means that if you install the mod on vanilla 1.6.4, you will have vanilla behavior of OpenGlHelper, without the client active texture merge.
I replaced my original fix with an improved version made by CoreTweaks (more or less, they simply add a call to OpenGlHelper.setClientActiveTexture at the beginning of the "draw" method while I added it in a more intuitive way, only being set if texture is enabled and the lightmap/brightness is not used, as its associated block of code resets the texture unit to default anyway and I thus moved it before the one that handles texture):
https://github.com/makamys/CoreTweaks/blob/master/src/main/java/makamys/coretweaks/mixin/bugfix/intelcolor/MixinTessellator.java
I assume this is also the more proper way to fix it as it sets the texture unit during the actual draw call, not whenever it might be set within OpenGlHelper, which can be at any time outside of draw calls (and I assume whenever the corresponding display list is used, not sure exactly what happens when they get compiled), hence the erratic behavior seen on some systems with the original fix (I'm referring to this post and the following replies; the original fix did fix the graphics completely breaking down but parts of entities were invisible and/or black, depending on driver version. I assume that the bug itself is due to Intel drivers not persisting the state of the active texture unit, since I'd intuitively expect it is correctly reset back to default, as it is after any calls that deal with the lightmap).
Also, I assume you decompiled TMCW itself; the unused field and (others elsewhere) are due to debug code which is removed at compilation, leaving such seemingly unused fields and/or methods (it gets set to the value of "BlocksMined.getDisplayMode()", i.e. the value that controls what the "inventory stats" display, when an error condition is detected, so it only dumps a single stack trace until I toggle it, same for various other errors. Vanilla simply crashes the game here and in many other areas):
if (DebugHelper.DEBUG_TESSELLATOR) { if (this.isDrawing && this.hasData()) { if (this.lastError != BlocksMined.getDisplayMode()) { this.lastError = BlocksMined.getDisplayMode(); System.out.println("Warning: Called Tessellator.startDrawing() while a draw call was in progress!"); Thread.dumpStack(); } } else { this.isDrawing = true; } }Also, incorrect shading, without any other issues, seems to have been a common problem back in the day, with a lot of threads like this, suggesting some obscure bug, as well as a bug report of what looks like the same issue, resolved as "incomplete" (last affected version listed is 1.8.4, said to happen at least as far back as Beta 1.8):
https://www.minecraftforum.net/forums/archive/legacy-support/1827145-random-shadows-on-chests-and-hand
MC-206 lighting bug (chests, signs, minecarts, skin)
The bug report also leads to a related issue which was marked as fixed in a 1.8 snapshot, and a comment links to a mod which claims to fix it, the download to which is luckily still up, and it is a simple jar mod (class file, bam.class for the 1.7.10 version, which matches RenderHelper after searching for files with the same specific lines as decompiled with Java Decompiler, and a comparison shows some differences; a value was changed from 0.4 to 1.0 and some code was duplicated with the duplicate having the original value):
https://www.minecraftforum.net/forums/mapping-and-modding-java-edition/minecraft-mods/1286643-minecraftlfm-fixes-colored-signs-entity-rendering
At the same time, I looked at online source for 1.12 and it seems to be the same as 1.6.4 (as are the OpenGlHelper methods) so it is likely that some other change fixed both of these in newer versions (the 1.12 source I have is actually a decompiled version of Optifine so it may not be entirely vanilla, OpenGlHelper is definitely modified (it seems completely unnecessary in 1.6.4 as all it does is call a method of Optifine's own class to initialize some stuff, which could have been put elsewhere, and adds a couple unused (only set but never read) fields; the 1.12 version does make various other changes, at least stuff like "Config.isMultiTexture()". Standard decompilers also don't replace OpenGL constants with their original names, as does the 1.12 Optifine source (otherwise deobfuscated), so they are just numbers but I think they are unchanged).
Also, I did previously find causes for a lot of shading issues which should affect any system, thus I was able to reproduce them (or more like discover them and figure out how to fix them); many were due to the game using "RenderHelper.enableStandardItemLighting" instead of simply using "GL11.glEnable(GL11.GL_LIGHTING)" and the corresponding disable methods to enable/disable lighting (the former will reinitialize lighting with the transformations that were applied to the entity being rendered, not the original unaltered matrix, hence shading that varies as you/the entity rotate, e.g. MC-10135 and when the ender dragon is healing/dying (MC-91761 seems to describe this), I've also found some other sources with different causes, such as heads/skulls causing lighting errors on signs and possibly other tile entities due to omitting "GL11.glDisable(GL12.GL_RESCALE_NORMAL)" after rendering them).
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?
It seems that the Intel lighting fix I found is just a hack which disables entity shading entirely (except for items in the inventory) as I tested it and entities were uniformly fully lit, with many details lost as a result (I even copied the decompiled bam.java file and renamed the methods just to be sure everything was correct as the OpenGL constants were just numbers):
With the "fix:
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?