I have no idea how to replicate the old lighting; the code that newer versions use to dynamically create the lightmap (done in code with no actual texture) doesn't seem to exist and they just appeared to change the brightness of blocks when rendering chunks (which is why day-night transitions involved chunk updates instead of a smooth transition).
Dear MasterCaver,
thank you so much for the quick, detailed response!
I did try changing the gamma offset, although there is no big noticable difference. Right now I am using an old monitor HP LP3065 which I bought second hand very cheap last year. I will definitely perform some other tests though.
I think I will also read more about the lightmap after my university exams in July. I'm aware that you probably get a lot of questions and requests from people, so I do not wish to bother you unnecessarily. I will check again what you've posted when I have time and see what I can learn from reading and testing things out.
Thank you for all of your efforts! Really appreciate your vision of minecraft!
OK -- I just installed TMCW and wow, this is some pretty good vanilla-esque stuff. I might start a little survival world on this. I really enjoy the variety of stuff in the overworld, without going too overboard. This looks pretty great!
I actually want to add; This performs amazingly well, even better than other versions coked up with optimization mods. What did you do!? My refresh rate is 144FPS and despite other versions often reporting that, I feel like the FPS stutters significantly at times. Not with TMCW, it's buttery smooth basically the whole time.
I actually want to add; This performs amazingly well, even better than other versions coked up with optimization mods. What did you do!? My refresh rate is 144FPS and despite other versions often reporting that, I feel like the FPS stutters significantly at times. Not with TMCW, it's buttery smooth basically the whole time.
I've basically rewritten large portions of the game to be more efficient, whether it is to reduce computations or memory allocations or speed up access to chunk/world data (probably one of the biggest ones). Rendering itself hasn't been changed much but benefits (chunk updates) from more efficient world access and mesh construction and the removal of various OpenGL state changes (when "fast render" is enabled, which does cause "jittering" at far distances but I assume most players will remain within 5-10k blocks) and better hidden face culling (affecting blocks like stairs, fences, snow layers, etc) and scheduling of chunk updates (there is a slider in video settings called "chunk update time" which controls how much of the idle time between frames can be spent on chunk updates), which is another major contributor (e.g. vanilla 1.6.4 allows for a significant decrease in FPS when set to balanced (120 FPS); Vsync doesn't have this issue but only updates 1 chunk per frame, and the game doesn't apply it at startup).
Chunk updates are probably the biggest performance bottleneck in the game (vanilla or TMCW, see MC-123584) and this can be easily be seen by placing flowerpots with "mega tree" saplings and right-clicking them while sneaking to set them to a full-size tree model; after a relatively small number you'll start to notice lag spikes when changing any blocks within the chunk; with 12 I measured a chunk update time of about 35 ms; a 16x16x16 cube of Fancy leaves is also quite expensive, even if I made the mesh construction 8 times faster since the bulk of the time in either case is spent on "Tessellator.draw" (uploading the data to OpenGL):
16x16x16 Fancy leaves in vanilla:
Chunk update took 35652 us (render: 16481, upload: 19170)
TMCW:
Chunk update took 20927 us (render: 1971, upload: 18955)
12x Mega Tree flower pots:
Chunk update took 35611 us (render 2071, upload: 33539)
Also, I've heard of a "trianguator" mod which claims to improve performance by rendering with triangles instead of quads (vanilla actually supports this via a flag) but any possible improvements to FPS (which I didn't observe) were far offset by the increased upload time (this may be GPU dependent, NVIDIA's driver at least seem pretty efficient at doing the conversion itself, suggesting the bottleneck is the memory transfer). I have not tried implementing multithreaded rendering, or multithreading in general (1.8 multithreaded it but only the Java-side code, which would have little benefit considering the numbers shown here; the OpenGL interface needs to be threaded, as Optifine did when using its multithreaded option, but this has caused issues with various drivers).
I've also significantly optimized world generation, which is about twice as fast as vanilla despite being far more complex, largely due to the use of a chunk cache (instead of accessing methods like World.setBlock it directly accesses chunks via a 2x2 cache, worldgen runaway, which is a major issue with many worldgen mods, is also ensured to never occur, and actually can't since the cache will cut it off). Even cave generation, which is dozens of times more complex than vanilla (the source code for "MapGenCavesRavines" is over 350 KB) is comparable to, if not faster, in large part due to using a much faster RNG (Java's Random is extremely slow due to being designed to be threadsafe but that is completely unnecessary for anything the game uses it for, and it isn't even fully 64 bit so seeds with the same lower 48 bits have much of the same world generation, and my "chunk seed" implementation avoids all the issues that vanilla has, i.e. "infinite mineshaft/cave" seeds, or odd repetition. Non-worldgen methods that reference "Random" still benefit from a subclass of Random which overrides the problematic methods).
Another significant improvement comes from making the integrated server effectively be ticked by the client, while still running on its own thread (the client uses is own high-resolution "Timer" class while the server uses "System.currentTimeMillis", which can have a quite coarse resolution and results in tick jitter / ticking 0-2 times within one client tick). I replaced the system time with a call from the client which increments the value by 50 per tick of the client world, with the server checking it every few ms when idle, this does require the combined client+server tick time to be less than 50 ms but that is generally not an issue and where I'd often have glitches like mined blocks briefly flickering (sort of like block lag but very brief) I haven't encountered it since, except when breaking a block while partially submerged (this one is quite odd because the block may not break for several seconds after I stopped mining it, with no other symptoms of lag). This by itself may have been enough to fixed MC-2025, perhaps the most notorious and still-unfixed bug in the game (it can even happen without reloading chunks, e.g. fences. I fixed it previously by adding a margin to AABB calculations and directing computing block bounding boxes instead of using setBlockBounds and the associated fields, which are shared between the client and server in singleplayer)
I've also made an innumerable number of bugfixes, some significantly impacting performance, such as MC-17630 (mob pathfinding in general is significantly improved) and various memory leaks when switching worlds (e.g. MC-101232; with 512 MB allocated vanilla crashes after loading several worlds due to the old ones remaining in memory), and for larger worlds, MC-33134 (I removed the structure saving for mineshafts as it is not needed).
Also, many of my changes are only possible to such an extent because I used MCP to directly modify the source, with no regard to compatibility with other mods, which limits what many other mods can do (Optifine often causes issues with other mods because of this). Otherwise, I've always found it very hard to believe the resource usage of many mods (I've seen figures like 4-8 GB being quoted for modern modpacks but no matter how large they might be I simply can't see how that is possible, for comparison, the baseline memory usage of TMCW is only around 25 MB, down from 50 MB in vanilla, and that is at a render distance that loads twice as many chunks, even when accounting fro vanilla loading spawn chunks):
Vanilla; total memory usage (based on "retained", which is how much memory is being referenced by an object) was about 111.3 MB, with 61.5 MB (55.3%) used by loaded chunks (1066 at 59 KB each) and 49.8 MB used by everything else. The render distance was set to "far", which is in theory 12 chunks but the internal server limits the view distance to 10:
TMCWv5; total memory usage was about 164.4 MB, with 137.6 MB (83.7%) used by loaded chunks (2178 chunks at 65 KB each, mainly due to higher terrain, averaging 6.06 vs 5.4 sections) and 26.8 MB used by everything else (render distance was 16, the number of loaded chunks is exactly twice (d * 2 + 1)^2 as I removed spawn chunks, except on initial world creation):
You can also see that many of my own classes have replaced vanilla classes (ExtendedBlockStorage -> ChunkSection, itself replacing the "NibbleArrays" with direct access to the metadata/light data and removing the "blockMSBArray", even with over 300+ block variants added I see no need for more than 256 IDs due to heavy use of metadata so I removed it for now). Likewise, ChunkRenderer replaces WorldRenderer; if you compare the per-object sizes you'll find that many are smaller (106 bytes per ChunkRenderer vs 126 bytes per WorldRenderer, this may not seem like much but it adds up. RednerGlobalTMCW combines with RenderGlobal and EntityRenderer (at first I had them separate but the amount of interaction between the two, and annoyances at having to trace code between them, led me to merge them, conversely, I moved the particle code into "ParticleRenderer", extending EffectRenderer).
The difference between TMCW and vanilla is also quite apparent when looking at CPU/memory usage (both were with Vsync and maximum settings, which is again about 2.5 times higher for TMCW):
Vanilla, the period of higher CPU usage in the first half was how long it took for chunk updates to settle down (this was mostly due to random light checks and leaf decay, an issue in vanilla which was bad enough to cause the removal of most big oak trees in 1.7, which I fixed by adding more logs and/or increasing the leaf decay distance to 6 blocks, as well as disabling the "breakBlock" code in BlockLog/Leaves during world generation (this alone is enough to fix it, and prevents neighboring block updates, which are normally disabled during world generation):
TMCW; the jump in CPU/memory near the beginning was due to increasing the render distance from 8 to 16, with a much faster recovery following, and similar memory usage and allocation rate:
Also, I should note that a lot of my fixes came from other mods or posts on the bug tracker, I've even used some code from "Et Futurum", such as the rabbit code and endermite model (with various modifications, the main reason I used it over a direct adaption from 1.8 is because it was already altered to make it compatible with the older codebase. Entity models are one of the reasons why I haven't added that many entities, or entities with unique models, you'd think they would have used an easier to understand model format).
Oh, one thing you may want to look into for skins is Ears. It's a mod that perfectly backports the new skin format, but also adds in the ability to add other neat features to your skin. I'm actually on the team for a different mod called New Frontier Craft, and Unascribed actually merged it directly in our mod. If you contact him he may be willing to allow you to add in the mod.
BTW one weird thing I noticed: You made the cauldron use the actual block model in the hand which is good, but the hopper didn't get this change?
Oh, one thing you may want to look into for skins is Ears. It's a mod that perfectly backports the new skin format, but also adds in the ability to add other neat features to your skin. I'm actually on the team for a different mod called New Frontier Craft, and Unascribed actually merged it directly in our mod. If you contact him he may be willing to allow you to add in the mod.
BTW one weird thing I noticed: You made the cauldron use the actual block model in the hand which is good, but the hopper didn't get this change?
I actually completely removed support for online skins since they didn't work (the skin server used by pre-1.7 versions was disabled years ago) and otherwise never thought of adding additional skin features (I haven't actually changed my own skin in a decade).
As for hoppers that is partly because I'd never made any modifications to them as I did with cauldrons so they can have more levels of water, hold lava, and fill when placed below a stalactite (thus extending/replacing the original class). Although looking at them again, I realized that the item is actually the block itself not a separate item as with cauldrons and other similar blocks and the fix may be as simple as ignoring the call to "getItemIconName" in the ItemBlock class if the block is a hopper (I could also extend the BlockHopper class but such a minor change doesn't warrant a whole new class, likewise, my ItemBlockFix class merges various other individual classes. I have not added the ability for items to use custom 3D models, which is why I made various blocks drop themselves instead of separate items (which also make more sense anyway, there was no reason why e.g. cake needed a separate item).
Having fun so far with this. One thing I've noticed is that it seems you have to fall much less far for fall damage to kick in. Did they change it in newer versions or am I just going insane?
Note: This is when jumping off of two block ledges. Just walking off them doesn't do fall damage.
Having fun so far with this. One thing I've noticed is that it seems you have to fall much less far for fall damage to kick in. Did they change it in newer versions or am I just going insane?
Note: This is when jumping off of two block ledges. Just walking off them doesn't do fall damage.
I can't find anything about this in the Wiki but the reason you take damage when jumping off a 2 block high ledge is because the total fall distance exceeds 3 blocks (measured from the apogee, which is 3.25 blocks) and the game rounds the distance up to the next whole block, 4 in this case:
Also, I fixed a bug where your calculated fall distance is too small (best seen when falling 23 blocks, which should be fatal but isn't in vanilla), but that shouldn't make a difference in this case; you do take damage from jumping off a 2 high ledge in vanilla 1.6.4:
While a 23 block fall should be fatal for a player at full health (23 - 3 = 20♥ × 10 of damage), due to the way fall distance is calculated, a 23.5 block fall is required instead, because the last tick of fall distance isn't added in when calculating fall damage. For certain heights, including 23-block falls, this discrepancy is enough to avoid an entire 1♥ of damage.
That said, I checked vanilla 1.6.4 and you actually don't take damage so it had to be something I changed, most likely the aforementioned bug fix; vanilla 1.6.4 thinks you fell only 2.7 blocks when jumping off a 2 high ledge, same for falling off a 3 high ledge (I also got the same distance until I fell at least 3.375 blocks, or 2 blocks + 4 layers of snow, i.e. the resolution is very coarse). For comparison, TMCW gave close to the actual distances fallen ("jump" was from a 2 block ledge):
So this seems to be an issue caused by making the game better, of all things (maybe I can change the damage threshold to something like 3.3, seeing that jumping gave about 3.25). Also, I'd actually noticed this before - I increased the maximum safe fall distance of slimes to 4 blocks since I noticed they took damage when jumping from a 2 block high ledge and since they always moved by jumping this gave them a disadvantage (I checked them as well and they don't take damage in vanilla). Otherwise, I never noticed a change in behavior with regards to player damage since you can still walk off a 3 block high ledge without taking damage and generally don't try jumping down hills.
"Open the launcher and edit the installation you made to choose TMCW from the versions list; select it and you should be able to launch the game; "
I can't find it in the list of versions, any idea what I might have done wrong?
Did you make sure to use the exact same name for all the files and folders (that is, "TMCWv5", in the instructions I use "TMCW" but note that it is a placeholder for the specific version name)? This may also only work with the official launcher (sorry, I don't use anything else or want to download a bunch of launchers to test them, I'm not even sure if the Microsoft Store launcher works the same way as the Windows 7.8 launcher, which is also generally recommended for other reasons).
Also, I thought to mention that if you want to use this as an alternative to the latest version (based on this comment) it is not meant as a substitute, even many of the features I backported are not always the same (many mods dedicated to backporting features do try to replicate them as closely as possible but that is not my intent). I also can't guarantee that it will perform better on all systems (the game has always had issues with inconsistent performance for whatever reasons; even as controversial as 1.8 was for lag 25% said it improved performance).
Did you make sure to use the exact same name for all the files and folders (that is, "TMCWv5", in the instructions I use "TMCW" but note that it is a placeholder for the specific version name)? This may also only work with the official launcher (sorry, I don't use anything else or want to download a bunch of launchers to test them, I'm not even sure if the Microsoft Store launcher works the same way as the Windows 7.8 launcher, which is also generally recommended for other reasons).
Also, I thought to mention that if you want to use this as an alternative to the latest version (based on this comment) it is not meant as a substitute, even many of the features I backported are not always the same (many mods dedicated to backporting features do try to replicate them as closely as possible but that is not my intent). I also can't guarantee that it will perform better on all systems (the game has always had issues with inconsistent performance for whatever reasons; even as controversial as 1.8 was for lag 25% said it improved performance).
Oh okay I didn't see you mention the bolded part in the notepad file. I'll go try that.
Never mind, I can't read apparently. But it still doesn't work. I'll try it from the top again.
Okay I forgot to rename the jar file as it was buried in other files. Trying again now...
Still not working...
Okay so I didn't update the version from the version picker in the launcher, that's why...
This is too complicated for me, too many moving parts...
Hi TMC, how did you get your water textures? I’m trying to accurately create a transformation of the result of dynamic vanilla texture generation (from pre-1.5/pre-13w02a Minecraft versions) into a texture that will match your texture.
In vanilla pre-1.5/pre-13w02a, the pixel colors are calculated after processing the cellular automaton (that does not require any changes) as:
float clampedSoupHeat = soupHeat;
if(clampedSoupHeat > 1.0F) {
clampedSoupHeat = 1.0F;
}
if(clampedSoupHeat < 0.0F) {
clampedSoupHeat = 0.0F;
}
float colorHeat = clampedSoupHeat * clampedSoupHeat;
int red = (int)(32.0F + colorHeat * 32.0F);
int green = (int)(50.0F + colorHeat * 64.0F);
int blue = 255;
int alpha = (int)(146.0F + colorHeat * 50.0F);
So here are the minimum and maximum RGBA values for water pixels in Minecraft 1.4.7/13w01b and older: red is 32–64, green is 50–114, blue is 255, alpha is 146–196. You may notice that this is different from 1.5+/13w02a+. While the new water is not as different as the new lava, it does have differences such as blue values different from 255 and a slightly higher average alpha value (the new water is slightly more opaque). However, I’m not going to take that into consideration just yet. Previously, I implemented your water textures by changing the minimum and maximum red and green values, without changing the transparency, since your textures have the same alpha values as vanilla Minecraft 1.6.4:
int red = (int)(111.0F + colorHeat * 76.0F)
int green = (int)(139.0F + colorHeat * 116.0F)
Obviously, this dynamic texture looks identical to yours, but now I want to redo it in a different way so that the texture is generated with vanilla colors and then post-processed, similar to the optional processing for 3D anaglyph in vanilla pre-1.5/pre-13w02:
int rr = (red * 30 + green * 59 + blue * 11) / 100; // double rr = 0.3 * red + 0.59 * green + 0.11 * blue
int gg = (red * 30 + green * 70) / 100; // double gg = 0.3 * red + 0.7 * green
int bb = (red * 30 + blue * 70) / 100; // double bb = 0.3 * red + 0.7 * blue
red = rr;
green = gg;
blue = bb;
My idea is that I will place the new post-process after getting the vanilla RGB values, but before the optional 3D anaglyph post-process, something like:
float[] hsb = Color.RGBtoHSB(red, green, blue, null);
hsb[1] = hsb[1] - 0.4F;
if(hsb[1] < 0.0F) {
hsb[1] = 0.0F;
} else if(hsb[1] > 1.0F) {
hsb[1] = 1.0F;
}
int color = Color.HSBtoRGB(hsb[0], hsb[1], hsb[2]) & 0xFFFFFF;
red = color >> 16 & 255;
green = color >> 8 & 255;
blue = color & 255;
I just have to find out how to get your water pixel colors from vanilla water.
Hi TMC, how did you get your water textures? I’m trying to accurately create a transformation of the result of dynamic vanilla texture generation (from pre-1.5/pre-13w02a Minecraft versions) into a texture that will match your texture.
I used Gimp to modify the vanilla water texture (changing the saturation, lightness, etc), i did not make it entirely grayscale since that caused the overall contrast to change; similar changes were made to underwater overlay (a single uniform color), water particle, and bubble textures. I also made a slight adjustment to the the flowing water texture to more closely match the still water texture (what I mean is, in vanilla there is a noticeable visual difference between the color/opacity/etc of still and flowing water).
The actual color itself (biome color) is applied by setting the vertex colors when rendering the texture (i.e. it is simply blended with the texture, much as grass and leaves are colored), I just used a set of hardcoded water values in the separate utility I used to create the biome colormap (grass and foliage colors are pulled from the vanilla textures using the biome's temperature and precipitation values, with the exception of special biomes like swamplands and mesa).
I used Gimp to modify the vanilla water texture (changing the saturation, lightness, etc)
I had a guess about this and was hoping to find out the exact values for the changes. I tried to find these values (saturation etc.), but it’s so difficult…
I don’t mean biome colors, I mean how to get your water_still.png from vanilla water_still.png. Precisely because it is not just grayscale.
I also made a slight adjustment to the the flowing water texture to more closely match the still water texture (what I mean is, in vanilla there is a noticeable visual difference between the color/opacity/etc of still and flowing water).
This also applies to dynamic textures in pre-1.5, it’s due to the fact that during the generation process they use one Math.random() value per cell (16×16=256 cells per frame) each, and these values are different. By the way, different random values is the reason for the existence of two fire textures: two dynamic texture slots in pre-1.5 use exactly the same code, but are initialized and tick in turn, and have different random values, and as a result have different shapes. The problem with the textures of water (and lava, since it also has temperature differences that differ between still and flowing textures) in pre-1.5 can be solved by using the same random values for ticking all 2 textures of the same liquid. That is, before ticking still water, an array of 256 Math.random() values is generated, which are then used both in ticking still water and in the subsequent ticking flowing water.
Dear MasterCaver,
thank you so much for the quick, detailed response!
I did try changing the gamma offset, although there is no big noticable difference. Right now I am using an old monitor HP LP3065 which I bought second hand very cheap last year. I will definitely perform some other tests though.
I think I will also read more about the lightmap after my university exams in July. I'm aware that you probably get a lot of questions and requests from people, so I do not wish to bother you unnecessarily. I will check again what you've posted when I have time and see what I can learn from reading and testing things out.
Thank you for all of your efforts! Really appreciate your vision of minecraft!
Kind regards,
OK -- I just installed TMCW and wow, this is some pretty good vanilla-esque stuff. I might start a little survival world on this. I really enjoy the variety of stuff in the overworld, without going too overboard. This looks pretty great!
Still playing 1.7.10? Download Et Futurum Requiem for highly configurable backported content!
I actually want to add; This performs amazingly well, even better than other versions coked up with optimization mods. What did you do!? My refresh rate is 144FPS and despite other versions often reporting that, I feel like the FPS stutters significantly at times. Not with TMCW, it's buttery smooth basically the whole time.
Still playing 1.7.10? Download Et Futurum Requiem for highly configurable backported content!
I've basically rewritten large portions of the game to be more efficient, whether it is to reduce computations or memory allocations or speed up access to chunk/world data (probably one of the biggest ones). Rendering itself hasn't been changed much but benefits (chunk updates) from more efficient world access and mesh construction and the removal of various OpenGL state changes (when "fast render" is enabled, which does cause "jittering" at far distances but I assume most players will remain within 5-10k blocks) and better hidden face culling (affecting blocks like stairs, fences, snow layers, etc) and scheduling of chunk updates (there is a slider in video settings called "chunk update time" which controls how much of the idle time between frames can be spent on chunk updates), which is another major contributor (e.g. vanilla 1.6.4 allows for a significant decrease in FPS when set to balanced (120 FPS); Vsync doesn't have this issue but only updates 1 chunk per frame, and the game doesn't apply it at startup).
Chunk updates are probably the biggest performance bottleneck in the game (vanilla or TMCW, see MC-123584) and this can be easily be seen by placing flowerpots with "mega tree" saplings and right-clicking them while sneaking to set them to a full-size tree model; after a relatively small number you'll start to notice lag spikes when changing any blocks within the chunk; with 12 I measured a chunk update time of about 35 ms; a 16x16x16 cube of Fancy leaves is also quite expensive, even if I made the mesh construction 8 times faster since the bulk of the time in either case is spent on "Tessellator.draw" (uploading the data to OpenGL):
Also, I've heard of a "trianguator" mod which claims to improve performance by rendering with triangles instead of quads (vanilla actually supports this via a flag) but any possible improvements to FPS (which I didn't observe) were far offset by the increased upload time (this may be GPU dependent, NVIDIA's driver at least seem pretty efficient at doing the conversion itself, suggesting the bottleneck is the memory transfer). I have not tried implementing multithreaded rendering, or multithreading in general (1.8 multithreaded it but only the Java-side code, which would have little benefit considering the numbers shown here; the OpenGL interface needs to be threaded, as Optifine did when using its multithreaded option, but this has caused issues with various drivers).
I've also significantly optimized world generation, which is about twice as fast as vanilla despite being far more complex, largely due to the use of a chunk cache (instead of accessing methods like World.setBlock it directly accesses chunks via a 2x2 cache, worldgen runaway, which is a major issue with many worldgen mods, is also ensured to never occur, and actually can't since the cache will cut it off). Even cave generation, which is dozens of times more complex than vanilla (the source code for "MapGenCavesRavines" is over 350 KB) is comparable to, if not faster, in large part due to using a much faster RNG (Java's Random is extremely slow due to being designed to be threadsafe but that is completely unnecessary for anything the game uses it for, and it isn't even fully 64 bit so seeds with the same lower 48 bits have much of the same world generation, and my "chunk seed" implementation avoids all the issues that vanilla has, i.e. "infinite mineshaft/cave" seeds, or odd repetition. Non-worldgen methods that reference "Random" still benefit from a subclass of Random which overrides the problematic methods).
Another significant improvement comes from making the integrated server effectively be ticked by the client, while still running on its own thread (the client uses is own high-resolution "Timer" class while the server uses "System.currentTimeMillis", which can have a quite coarse resolution and results in tick jitter / ticking 0-2 times within one client tick). I replaced the system time with a call from the client which increments the value by 50 per tick of the client world, with the server checking it every few ms when idle, this does require the combined client+server tick time to be less than 50 ms but that is generally not an issue and where I'd often have glitches like mined blocks briefly flickering (sort of like block lag but very brief) I haven't encountered it since, except when breaking a block while partially submerged (this one is quite odd because the block may not break for several seconds after I stopped mining it, with no other symptoms of lag). This by itself may have been enough to fixed MC-2025, perhaps the most notorious and still-unfixed bug in the game (it can even happen without reloading chunks, e.g. fences. I fixed it previously by adding a margin to AABB calculations and directing computing block bounding boxes instead of using setBlockBounds and the associated fields, which are shared between the client and server in singleplayer)
I've also made an innumerable number of bugfixes, some significantly impacting performance, such as MC-17630 (mob pathfinding in general is significantly improved) and various memory leaks when switching worlds (e.g. MC-101232; with 512 MB allocated vanilla crashes after loading several worlds due to the old ones remaining in memory), and for larger worlds, MC-33134 (I removed the structure saving for mineshafts as it is not needed).
Also, many of my changes are only possible to such an extent because I used MCP to directly modify the source, with no regard to compatibility with other mods, which limits what many other mods can do (Optifine often causes issues with other mods because of this). Otherwise, I've always found it very hard to believe the resource usage of many mods (I've seen figures like 4-8 GB being quoted for modern modpacks but no matter how large they might be I simply can't see how that is possible, for comparison, the baseline memory usage of TMCW is only around 25 MB, down from 50 MB in vanilla, and that is at a render distance that loads twice as many chunks, even when accounting fro vanilla loading spawn chunks):
TMCWv5; total memory usage was about 164.4 MB, with 137.6 MB (83.7%) used by loaded chunks (2178 chunks at 65 KB each, mainly due to higher terrain, averaging 6.06 vs 5.4 sections) and 26.8 MB used by everything else (render distance was 16, the number of loaded chunks is exactly twice (d * 2 + 1)^2 as I removed spawn chunks, except on initial world creation):
You can also see that many of my own classes have replaced vanilla classes (ExtendedBlockStorage -> ChunkSection, itself replacing the "NibbleArrays" with direct access to the metadata/light data and removing the "blockMSBArray", even with over 300+ block variants added I see no need for more than 256 IDs due to heavy use of metadata so I removed it for now). Likewise, ChunkRenderer replaces WorldRenderer; if you compare the per-object sizes you'll find that many are smaller (106 bytes per ChunkRenderer vs 126 bytes per WorldRenderer, this may not seem like much but it adds up. RednerGlobalTMCW combines with RenderGlobal and EntityRenderer (at first I had them separate but the amount of interaction between the two, and annoyances at having to trace code between them, led me to merge them, conversely, I moved the particle code into "ParticleRenderer", extending EffectRenderer).
The difference between TMCW and vanilla is also quite apparent when looking at CPU/memory usage (both were with Vsync and maximum settings, which is again about 2.5 times higher for TMCW):
Vanilla, the period of higher CPU usage in the first half was how long it took for chunk updates to settle down (this was mostly due to random light checks and leaf decay, an issue in vanilla which was bad enough to cause the removal of most big oak trees in 1.7, which I fixed by adding more logs and/or increasing the leaf decay distance to 6 blocks, as well as disabling the "breakBlock" code in BlockLog/Leaves during world generation (this alone is enough to fix it, and prevents neighboring block updates, which are normally disabled during world generation):
TMCW; the jump in CPU/memory near the beginning was due to increasing the render distance from 8 to 16, with a much faster recovery following, and similar memory usage and allocation rate:
Also, I should note that a lot of my fixes came from other mods or posts on the bug tracker, I've even used some code from "Et Futurum", such as the rabbit code and endermite model (with various modifications, the main reason I used it over a direct adaption from 1.8 is because it was already altered to make it compatible with the older codebase. Entity models are one of the reasons why I haven't added that many entities, or entities with unique models, you'd think they would have used an easier to understand model format).
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?
This is a very good write-up. Thank you.
Oh, one thing you may want to look into for skins is Ears. It's a mod that perfectly backports the new skin format, but also adds in the ability to add other neat features to your skin. I'm actually on the team for a different mod called New Frontier Craft, and Unascribed actually merged it directly in our mod. If you contact him he may be willing to allow you to add in the mod.
BTW one weird thing I noticed: You made the cauldron use the actual block model in the hand which is good, but the hopper didn't get this change?
Still playing 1.7.10? Download Et Futurum Requiem for highly configurable backported content!
I actually completely removed support for online skins since they didn't work (the skin server used by pre-1.7 versions was disabled years ago) and otherwise never thought of adding additional skin features (I haven't actually changed my own skin in a decade).
As for hoppers that is partly because I'd never made any modifications to them as I did with cauldrons so they can have more levels of water, hold lava, and fill when placed below a stalactite (thus extending/replacing the original class). Although looking at them again, I realized that the item is actually the block itself not a separate item as with cauldrons and other similar blocks and the fix may be as simple as ignoring the call to "getItemIconName" in the ItemBlock class if the block is a hopper (I could also extend the BlockHopper class but such a minor change doesn't warrant a whole new class, likewise, my ItemBlockFix class merges various other individual classes. I have not added the ability for items to use custom 3D models, which is why I made various blocks drop themselves instead of separate items (which also make more sense anyway, there was no reason why e.g. cake needed a separate item).
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?
Having fun so far with this. One thing I've noticed is that it seems you have to fall much less far for fall damage to kick in. Did they change it in newer versions or am I just going insane?
Note: This is when jumping off of two block ledges. Just walking off them doesn't do fall damage.
I can't find anything about this in the Wiki but the reason you take damage when jumping off a 2 block high ledge is because the total fall distance exceeds 3 blocks (measured from the apogee, which is 3.25 blocks) and the game rounds the distance up to the next whole block, 4 in this case:
https://www.minecraftforum.net/forums/minecraft-java-edition/survival-mode/2814167-falling-on-slabs?comment=3
Also, I fixed a bug where your calculated fall distance is too small (best seen when falling 23 blocks, which should be fatal but isn't in vanilla), but that shouldn't make a difference in this case; you do take damage from jumping off a 2 high ledge in vanilla 1.6.4:
MC-130639 Fall distance is not updated on the last tick of the fall
That said, I checked vanilla 1.6.4 and you actually don't take damage so it had to be something I changed, most likely the aforementioned bug fix; vanilla 1.6.4 thinks you fell only 2.7 blocks when jumping off a 2 high ledge, same for falling off a 3 high ledge (I also got the same distance until I fell at least 3.375 blocks, or 2 blocks + 4 layers of snow, i.e. the resolution is very coarse). For comparison, TMCW gave close to the actual distances fallen ("jump" was from a 2 block ledge):
So this seems to be an issue caused by making the game better, of all things (maybe I can change the damage threshold to something like 3.3, seeing that jumping gave about 3.25). Also, I'd actually noticed this before - I increased the maximum safe fall distance of slimes to 4 blocks since I noticed they took damage when jumping from a 2 block high ledge and since they always moved by jumping this gave them a disadvantage (I checked them as well and they don't take damage in vanilla). Otherwise, I never noticed a change in behavior with regards to player damage since you can still walk off a 3 block high ledge without taking damage and generally don't try jumping down hills.
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?
"Open the launcher and edit the installation you made to choose TMCW from the versions list; select it and you should be able to launch the game; "
I can't find it in the list of versions, any idea what I might have done wrong?
Did you make sure to use the exact same name for all the files and folders (that is, "TMCWv5", in the instructions I use "TMCW" but note that it is a placeholder for the specific version name)? This may also only work with the official launcher (sorry, I don't use anything else or want to download a bunch of launchers to test them, I'm not even sure if the Microsoft Store launcher works the same way as the Windows 7.8 launcher, which is also generally recommended for other reasons).
Also, I thought to mention that if you want to use this as an alternative to the latest version (based on this comment) it is not meant as a substitute, even many of the features I backported are not always the same (many mods dedicated to backporting features do try to replicate them as closely as possible but that is not my intent). I also can't guarantee that it will perform better on all systems (the game has always had issues with inconsistent performance for whatever reasons; even as controversial as 1.8 was for lag 25% said it improved performance).
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?
Oh okay I didn't see you mention the bolded part in the notepad file. I'll go try that.
Never mind, I can't read apparently. But it still doesn't work. I'll try it from the top again.
Okay I forgot to rename the jar file as it was buried in other files. Trying again now...
Still not working...
Okay so I didn't update the version from the version picker in the launcher, that's why...
This is too complicated for me, too many moving parts...
Aw man it's still not working...
Hi TMC, how did you get your water textures? I’m trying to accurately create a transformation of the result of dynamic vanilla texture generation (from pre-1.5/pre-13w02a Minecraft versions) into a texture that will match your texture.
In vanilla pre-1.5/pre-13w02a, the pixel colors are calculated after processing the cellular automaton (that does not require any changes) as:
float clampedSoupHeat = soupHeat; if(clampedSoupHeat > 1.0F) { clampedSoupHeat = 1.0F; } if(clampedSoupHeat < 0.0F) { clampedSoupHeat = 0.0F; } float colorHeat = clampedSoupHeat * clampedSoupHeat; int red = (int)(32.0F + colorHeat * 32.0F); int green = (int)(50.0F + colorHeat * 64.0F); int blue = 255; int alpha = (int)(146.0F + colorHeat * 50.0F);So here are the minimum and maximum RGBA values for water pixels in Minecraft 1.4.7/13w01b and older: red is 32–64, green is 50–114, blue is 255, alpha is 146–196. You may notice that this is different from 1.5+/13w02a+. While the new water is not as different as the new lava, it does have differences such as blue values different from 255 and a slightly higher average alpha value (the new water is slightly more opaque). However, I’m not going to take that into consideration just yet. Previously, I implemented your water textures by changing the minimum and maximum red and green values, without changing the transparency, since your textures have the same alpha values as vanilla Minecraft 1.6.4:
Obviously, this dynamic texture looks identical to yours, but now I want to redo it in a different way so that the texture is generated with vanilla colors and then post-processed, similar to the optional processing for 3D anaglyph in vanilla pre-1.5/pre-13w02:
My idea is that I will place the new post-process after getting the vanilla RGB values, but before the optional 3D anaglyph post-process, something like:
float[] hsb = Color.RGBtoHSB(red, green, blue, null); hsb[1] = hsb[1] - 0.4F; if(hsb[1] < 0.0F) { hsb[1] = 0.0F; } else if(hsb[1] > 1.0F) { hsb[1] = 1.0F; } int color = Color.HSBtoRGB(hsb[0], hsb[1], hsb[2]) & 0xFFFFFF; red = color >> 16 & 255; green = color >> 8 & 255; blue = color & 255;I just have to find out how to get your water pixel colors from vanilla water.
I used Gimp to modify the vanilla water texture (changing the saturation, lightness, etc), i did not make it entirely grayscale since that caused the overall contrast to change; similar changes were made to underwater overlay (a single uniform color), water particle, and bubble textures. I also made a slight adjustment to the the flowing water texture to more closely match the still water texture (what I mean is, in vanilla there is a noticeable visual difference between the color/opacity/etc of still and flowing water).
The actual color itself (biome color) is applied by setting the vertex colors when rendering the texture (i.e. it is simply blended with the texture, much as grass and leaves are colored), I just used a set of hardcoded water values in the separate utility I used to create the biome colormap (grass and foliage colors are pulled from the vanilla textures using the biome's temperature and precipitation values, with the exception of special biomes like swamplands and mesa).
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 had a guess about this and was hoping to find out the exact values for the changes. I tried to find these values (saturation etc.), but it’s so difficult…
I don’t mean biome colors, I mean how to get your water_still.png from vanilla water_still.png. Precisely because it is not just grayscale.
This also applies to dynamic textures in pre-1.5, it’s due to the fact that during the generation process they use one Math.random() value per cell (16×16=256 cells per frame) each, and these values are different. By the way, different random values is the reason for the existence of two fire textures: two dynamic texture slots in pre-1.5 use exactly the same code, but are initialized and tick in turn, and have different random values, and as a result have different shapes. The problem with the textures of water (and lava, since it also has temperature differences that differ between still and flowing textures) in pre-1.5 can be solved by using the same random values for ticking all 2 textures of the same liquid. That is, before ticking still water, an array of 256 Math.random() values is generated, which are then used both in ticking still water and in the subsequent ticking flowing water.