So... with one of the new updates (not that new now), Mojang added features that were supposed to "improve performance". However, I felt that my performance fell a lot since the last update. This new render thing (that only renders chunks in front of you) seems to cause me more fps drops than improve it, especially when I turn to the sides in-game, causing it to load other chunks. Im already using Optifine, but I only get 23~24 fps, that keep dropping every time I turn around. Is there anyway I can improve this performance? Is there a way to deactivate this new "chunk rendering" feature that seems to make things worse?
I'm using the New minecraft launcher, the one with Java included
My PC specs:
Dell Studio 1558
Windows 7 Home Premium 64-bit
4GB ram DDR3
Intel Core i5 450M @ 2.40GHz (2 cores, 4 threads)
Intel HD Graphics (have no idea which one, but it has 64MB) - Yep, it's pretty terrible
Yeah, and people say it's not really well optimized... the weird thing is that it ran better before they added this rendering thing, with the same specs
Ever since 1.8.6-1.8.7 I've been lagging quite a bit running on a Win 8.1 16GB CPU with 1 GB nVidia card with 4 cores. It hasn't been helping at all when I'm playing UHC or on Play Mindcrack. Even boosting with the nVidia control panel thing. First time with this game I've had this much lag ever since the much MUCH earlier updates.
With 1.8.7 I took a HUGE hit to fps. In some cases the frame rate is almost as good as before, but quite often my fps will suddenly drop to 3 or 4, or even 1 or 0 in forest or jungle.
I'll be walking across the room in my base and suddenly, for no reason I can discover, my frame rate drops drastically. In the last couple of days I've already died three times due to not being able to fight back. Death by sneaky creeper is bad enough, but death by lag really sucks!
Granted, I'm not running a high-power gaming system (Samsung laptop 3.53 GHz Intel HD on-board graphics) but it used to run very smoothly prior to 1.8.7.
Yeah, that's the problem... but people with really high-end PCs have been also saying that the fps got better, but I only see this game becoming laggier and laggier
I hope mojang does some good optimization or adds an option to turn off this new render engine...
Meanwhile, has anyone found any other solution to this, other than optifine?
Their experimenting trying to optimise the game. Don't expect that the moment you hear optimised and render engine in the same change log, it will immediately result in improved FPS. Especially considering the game is targeted at such a wide range of PCs.
Rollback Post to RevisionRollBack
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
As I pointed out many months ago the cause of lag in 1.8.x is the water.
Generate a world with no water and you'll have no lag (i.e. custom world with ocean level of 1).
That seems to go double for MOVING water. I put a MOB trap around a village wall with moving water and my lag went WAY up. I replaced the moving water with still water and it improved a bit. I removed all the water and it was better.
That seems to go double for MOVING water. I put a MOB trap around a village wall with moving water and my lag went WAY up. I replaced the moving water with still water and it improved a bit. I removed all the water and it was better.
I wonder if the same applies to lava?
Probably it's even worse, considering the light updates and stuff, but idk for sure
Water is most certainly not the (only) cause of lag for me; in my case it seems like everything needs like 10 times the resources to do.
In fact, if I generate a Superflat world (which oddly generates basic terrain faster than in, say, 1.6.4), as soon as I reach a village chunks actually stop loading, then the game stutters and the server skips around 100 ticks trying to catch up - really, 5 seconds to generate a village? This is even a known issue ("community consensus", so it isn't just me.
I also used to hear that jungles gave people a lot of lag, yet I never had any lag prior to a later 1.7 release (see this issue), then in 1.8 the server runs as slow as molasses, even with a minimal render distance. Now try that with something like this:
Speaking of which, here is a comparison I once made between server tick times (the time taken to process entities, chunk updates and all of that); this is from a long time ago and uses a prerelease but I've seen the same performance since the earliest snapshots; around 1.8.2 or so the stuttering when moving did improve though, I haven't even downloaded 1.8.7, or 1.8.4 for that matter, yet though:
That is worse than it looks; 1.6.4 loads 441 chunks no matter what the actual render distance is (equivalent to a render distance of 10 chunks in 1.7.4+, avoiding this bug) while I had 1.8 set to a render distance of 8 (the same as Normal in 1.6.4), which loads up to 289 chunks (variable depending on position) - in other words, 1.6.4 was running 9 times faster while handling 1.52 times as many chunks - 13.7 times faster overall! Both of these were also after idling for a few minutes (not really necessary in 1.6.4, which only has a brief instant of noticable lag when generating new chunks; 1.8 seems to take forever to settle down).
I mean, imagine trying to play as I do if this happened every time I tried to mine a block (which I mine a lot of); either that, or have almost no mobs spawning (they never bothered to fix this bug, known since forever (the bug tracker only goes back to 1.4.2) before forcing it upon singleplayer in 1.7.4):
Also, did you know that they removed/reduced some features because of lag? For example, ever notice that there are no big oak trees in forests since 1.7? Yep, they removed those because, according to Jeb himself, "I basically doubled my FPS in forests by removing these" - true, they did have problems with leaf decay (easily fixed by adding some extra logs, the branches that generate only reach the bases of the leaf clusters) but more significant is that chunk updates became much more resource intensive. Perhaps also why they made jungles so rare; they are basically "no man's land" for me now; either make a customized world that doesn't have them (very limited; with "plains" you have some variations of plains and forests but nothing else) or use AMIDST to make sure there are none within a reasonable distance. Similarly, they may have reduced the density of caves due to performance issues as well (the new culling algorithm in 1.8 made it possible to add caves to PE, replacing Advanced OpenGL, which worked just fine for me, if not for everybody, but they could have let you choose which one to use; never mind that PE uses hardware which is different from PC hardware).
Also, for all of their claims that the game would run better, especially on older computers, they actually significantly increased the system requirements - in fact, the old recommended requirements called for a GPU that doesn't come even close to the current recommended (see my post here)! My computer falls between those - it would be one thing if I no longer met the recommended, but to not even meet the minimum? What did they add to the game, besides some new blocks, commands, and all the usual stuff? I've also seem people say they can run 200+ mods (many of which are not exactly optimized) on an older version with better performance than vanilla 1.8.x so it certainly isn't that.
In fact, if I generate a Superflat world (which oddly generates basic terrain faster than in, say, 1.6.4), as soon as I reach a village chunks actually stop loading, then the game stutters and the server skips around 100 ticks trying to catch up - really, 5 seconds to generate a village?
The village generation check in 1.7 has a strange inefficiency where every time it generates a chunk it checks all the chunks in a considerable range around it to see if they have a village start. That's probably unavoidable, but the result isn't cached in any way and so it redoes the check something like 441 (or is it 1764?) times for every chunk. I tried hashcaching the data in 1.7 and it only sped up generation by a few percent, but if that code or similar code for village generation now sets off something really intensive in 1.8 it could easily explain your pause.
Rollback Post to RevisionRollBack
Geographicraft (formerly Climate Control) - Control climate, ocean, and land sizes; stop chunk walls; put modded biomes into Default worlds, and more!
RTG plus - All the beautiful terrain of RTG, plus varied and beautiful trees and forests.
The village generation check in 1.7 has a strange inefficiency where every time it generates a chunk it checks all the chunks in a considerable range around it to see if they have a village start. That's probably unavoidable, but the result isn't cached in any way and so it redoes the check something like 441 (or is it 1764?) times for every chunk. I tried hashcaching the data in 1.7 and it only sped up generation by a few percent, but if that code or similar code for village generation now sets off something really intensive in 1.8 it could easily explain your pause.
This also occurs in earlier versions, and also happens for other structures and caves; for example, this is some of the code I use to generate caves in TMCW; vanilla uses a range of +/- 8 chunks (289 chunks checked); as you can see, I reduced the number of checks based on the fact that a circular area can be checked; using just one class also likely has a small improvement since only one pass is made through the loops (the vanilla class that has similar code is MapGenBase, used separately by each structure type; I combined caves and ravines mainly because of interdependence and avoiding excessive redundant code):
for (int x = -12; x <= 12; ++x)
{
for (int z = -12; z <= 12; ++z)
{
// Reduces number of chunks compared to a square range
int x2z2 = x * x + z * z;
if (x2z2 <= 145)
{
int varChunkX = chunkX + x;
int varChunkZ = chunkZ + z;
this.chunkSeed = ((long)varChunkX * this.seedX) ^ ((long)varChunkZ * this.seedZ) ^ this.worldSeed;
this.validCaveLocation(x, z);
if (this.genCaves) this.generateCaves(varChunkX, varChunkZ, chunkX, chunkZ, x2z2 <= 40, par5ArrayOfByte);
if (this.genColossalCaves) this.generateColossalCaves(varChunkX, varChunkZ, chunkX, chunkZ, par5ArrayOfByte);
if (this.genRavines) this.generateRavines(varChunkX, varChunkZ, chunkX, chunkZ, x2z2 <= 20, par5ArrayOfByte);
// Filler caves use a range that is 1 chunk less, due to checking 1 chunk around
if (this.genFillerCaves && x2z2 <= 122) this.generateFillerCaves(varChunkX, varChunkZ, chunkX, chunkZ, x, z, x2z2 <= 40, par5ArrayOfByte);
}
}
}
The fact that I generate caves based on whether certain other caves generate, which requires checking yet another range (a +/- 6 chunk radius) makes this more important; by caching the "size" data I was able to reduce world/cave generation time (for 625 chunks) by 3 seconds; additional optimizations knocked off another second or so for an overall reduction of about 75% (6 to 1.5 seconds):
// Initializes array used to store cave data, used to significantly increase performance by avoiding
// recalculations due to overlapping chunks within the ranges of each chunk checked.
private void initializeCaveData(int chunkX, int chunkZ)
{
for (int z = -18; z <= 18; ++z)
{
int zIndex = (z + 18) * 37 + 18;
long chunkSeedZ = ((long)(chunkZ + z) * this.seedZ) ^ this.worldSeed;
for (int x = -18; x <= 18; ++x)
{
if (x * x + z * z <= 325)
{
byte data = 0;
this.rand.setSeed(((long)(chunkX + x) * this.seedX) ^ chunkSeedZ);
if (this.rand.nextInt(15) == 0) data = (byte)this.rand.nextInt(this.rand.nextInt(this.rand.nextInt(40) + 1) + 1);
// 64 used as a flag value for colossal cave systems
if (this.validColossalCaveLocation(chunkX + x, chunkZ + z)) data = 64;
this.caveDataArray[zIndex + x] = data;
}
}
}
}
I've also found that caves produce disproportionate lag in 1.8 as well, as there is a noticeable slowdown if I mod 1.6.4 caves into 1.8, far in excess of the fraction of a second it should take (1.7 actually has only about 25% less caves than 1.6.4, the biggest change being much less clustering and less variation, as evident in this comparison of 4000x4000 worlds; more significant is a 60% reduction in the number of abandoned mineshafts, though they are only a small portion of the underground, perhaps 10% of air blocks when more than 80 chunks away from the origin in 1.6.4).
Also, in MapGenStructure there is a check for whether an entry already exists in a hashmap, so it very well may be already caching data; also, changing the generation of a structure will have no effect on structures that were already partly generated since it reads from their corresponding structure.dat file; for example, here is the result when I loaded a world I created with my "double height terrain" mod in vanilla - notice the abandoned mineshafts that fully generated despite existing at an elevation impossible in vanilla; this also means that for 8 chunks around existing chunks 1.6.4-1.7 worlds will continue to have 1.6.4 mineshaft generation (otherwise, aside from the 60% that are missing they are identical in location and structure; the "ocean bubbles" bug fix in 1.8 had no other effect on the structure):
protected final void recursiveGenerate(World par1World, int par2, int par3, int par4, int par5, byte[] par6ArrayOfByte)
{
if (!this.structureMap.containsKey(Long.valueOf(ChunkCoordIntPair.chunkXZ2Int(par2, par3))))
{
this.rand.nextInt();
try
{
if (this.canSpawnStructureAtCoords(par2, par3))
{
StructureStart var7 = this.getStructureStart(par2, par3);
this.structureMap.put(Long.valueOf(ChunkCoordIntPair.chunkXZ2Int(par2, par3)), var7);
}
}
Note also that when I say chunk generation is much slower that is in general; it takes 3-4 times longer for 1.8 to generate a new world; in fact, Amplified in 1.7 is faster than a default 1.8 world!
So... with one of the new updates (not that new now), Mojang added features that were supposed to "improve performance". However, I felt that my performance fell a lot since the last update. This new render thing (that only renders chunks in front of you) seems to cause me more fps drops than improve it, especially when I turn to the sides in-game, causing it to load other chunks. Im already using Optifine, but I only get 23~24 fps, that keep dropping every time I turn around. Is there anyway I can improve this performance? Is there a way to deactivate this new "chunk rendering" feature that seems to make things worse?
I'm using the New minecraft launcher, the one with Java included
My PC specs:
Dell Studio 1558
Windows 7 Home Premium 64-bit
4GB ram DDR3
Intel Core i5 450M @ 2.40GHz (2 cores, 4 threads)
Intel HD Graphics (have no idea which one, but it has 64MB) - Yep, it's pretty terrible
About right for those specs.
Game really hates intel HD graphics.
Yeah, and people say it's not really well optimized... the weird thing is that it ran better before they added this rendering thing, with the same specs
Ever since 1.8.6-1.8.7 I've been lagging quite a bit running on a Win 8.1 16GB CPU with 1 GB nVidia card with 4 cores. It hasn't been helping at all when I'm playing UHC or on Play Mindcrack. Even boosting with the nVidia control panel thing. First time with this game I've had this much lag ever since the much MUCH earlier updates.
With 1.8.7 I took a HUGE hit to fps. In some cases the frame rate is almost as good as before, but quite often my fps will suddenly drop to 3 or 4, or even 1 or 0 in forest or jungle.
I'll be walking across the room in my base and suddenly, for no reason I can discover, my frame rate drops drastically. In the last couple of days I've already died three times due to not being able to fight back. Death by sneaky creeper is bad enough, but death by lag really sucks!
Granted, I'm not running a high-power gaming system (Samsung laptop 3.53 GHz Intel HD on-board graphics) but it used to run very smoothly prior to 1.8.7.
Yeah, that's the problem... but people with really high-end PCs have been also saying that the fps got better, but I only see this game becoming laggier and laggier
I hope mojang does some good optimization or adds an option to turn off this new render engine...
Meanwhile, has anyone found any other solution to this, other than optifine?
Their experimenting trying to optimise the game. Don't expect that the moment you hear optimised and render engine in the same change log, it will immediately result in improved FPS. Especially considering the game is targeted at such a wide range of PCs.
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
My Github page.
The entire Minecraft shader development community now has its own Discord server! Feel free to join and chat with all the developers!
To be perfectly honest my frames have improved with the new 1.8 terrain generation.
"The only way to do great work is to love what you do" - Steve Jobs
ok
What are your pc specs? Cause I've only heard people with high-end PCs say their frames improved...
That seems to go double for MOVING water. I put a MOB trap around a village wall with moving water and my lag went WAY up. I replaced the moving water with still water and it improved a bit. I removed all the water and it was better.
I wonder if the same applies to lava?
Probably it's even worse, considering the light updates and stuff, but idk for sure
Water is most certainly not the (only) cause of lag for me; in my case it seems like everything needs like 10 times the resources to do.
In fact, if I generate a Superflat world (which oddly generates basic terrain faster than in, say, 1.6.4), as soon as I reach a village chunks actually stop loading, then the game stutters and the server skips around 100 ticks trying to catch up - really, 5 seconds to generate a village? This is even a known issue ("community consensus", so it isn't just me.
I also used to hear that jungles gave people a lot of lag, yet I never had any lag prior to a later 1.7 release (see this issue), then in 1.8 the server runs as slow as molasses, even with a minimal render distance. Now try that with something like this:
Speaking of which, here is a comparison I once made between server tick times (the time taken to process entities, chunk updates and all of that); this is from a long time ago and uses a prerelease but I've seen the same performance since the earliest snapshots; around 1.8.2 or so the stuttering when moving did improve though, I haven't even downloaded 1.8.7, or 1.8.4 for that matter, yet though:
That is worse than it looks; 1.6.4 loads 441 chunks no matter what the actual render distance is (equivalent to a render distance of 10 chunks in 1.7.4+, avoiding this bug) while I had 1.8 set to a render distance of 8 (the same as Normal in 1.6.4), which loads up to 289 chunks (variable depending on position) - in other words, 1.6.4 was running 9 times faster while handling 1.52 times as many chunks - 13.7 times faster overall! Both of these were also after idling for a few minutes (not really necessary in 1.6.4, which only has a brief instant of noticable lag when generating new chunks; 1.8 seems to take forever to settle down).
I mean, imagine trying to play as I do if this happened every time I tried to mine a block (which I mine a lot of); either that, or have almost no mobs spawning (they never bothered to fix this bug, known since forever (the bug tracker only goes back to 1.4.2) before forcing it upon singleplayer in 1.7.4):
Also, did you know that they removed/reduced some features because of lag? For example, ever notice that there are no big oak trees in forests since 1.7? Yep, they removed those because, according to Jeb himself, "I basically doubled my FPS in forests by removing these" - true, they did have problems with leaf decay (easily fixed by adding some extra logs, the branches that generate only reach the bases of the leaf clusters) but more significant is that chunk updates became much more resource intensive. Perhaps also why they made jungles so rare; they are basically "no man's land" for me now; either make a customized world that doesn't have them (very limited; with "plains" you have some variations of plains and forests but nothing else) or use AMIDST to make sure there are none within a reasonable distance. Similarly, they may have reduced the density of caves due to performance issues as well (the new culling algorithm in 1.8 made it possible to add caves to PE, replacing Advanced OpenGL, which worked just fine for me, if not for everybody, but they could have let you choose which one to use; never mind that PE uses hardware which is different from PC hardware).
Also, for all of their claims that the game would run better, especially on older computers, they actually significantly increased the system requirements - in fact, the old recommended requirements called for a GPU that doesn't come even close to the current recommended (see my post here)! My computer falls between those - it would be one thing if I no longer met the recommended, but to not even meet the minimum? What did they add to the game, besides some new blocks, commands, and all the usual stuff? I've also seem people say they can run 200+ mods (many of which are not exactly optimized) on an older version with better performance than vanilla 1.8.x so it certainly isn't that.
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?
The village generation check in 1.7 has a strange inefficiency where every time it generates a chunk it checks all the chunks in a considerable range around it to see if they have a village start. That's probably unavoidable, but the result isn't cached in any way and so it redoes the check something like 441 (or is it 1764?) times for every chunk. I tried hashcaching the data in 1.7 and it only sped up generation by a few percent, but if that code or similar code for village generation now sets off something really intensive in 1.8 it could easily explain your pause.
Geographicraft (formerly Climate Control) - Control climate, ocean, and land sizes; stop chunk walls; put modded biomes into Default worlds, and more!
RTG plus - All the beautiful terrain of RTG, plus varied and beautiful trees and forests.
This also occurs in earlier versions, and also happens for other structures and caves; for example, this is some of the code I use to generate caves in TMCW; vanilla uses a range of +/- 8 chunks (289 chunks checked); as you can see, I reduced the number of checks based on the fact that a circular area can be checked; using just one class also likely has a small improvement since only one pass is made through the loops (the vanilla class that has similar code is MapGenBase, used separately by each structure type; I combined caves and ravines mainly because of interdependence and avoiding excessive redundant code):
The fact that I generate caves based on whether certain other caves generate, which requires checking yet another range (a +/- 6 chunk radius) makes this more important; by caching the "size" data I was able to reduce world/cave generation time (for 625 chunks) by 3 seconds; additional optimizations knocked off another second or so for an overall reduction of about 75% (6 to 1.5 seconds):
I've also found that caves produce disproportionate lag in 1.8 as well, as there is a noticeable slowdown if I mod 1.6.4 caves into 1.8, far in excess of the fraction of a second it should take (1.7 actually has only about 25% less caves than 1.6.4, the biggest change being much less clustering and less variation, as evident in this comparison of 4000x4000 worlds; more significant is a 60% reduction in the number of abandoned mineshafts, though they are only a small portion of the underground, perhaps 10% of air blocks when more than 80 chunks away from the origin in 1.6.4).
Also, in MapGenStructure there is a check for whether an entry already exists in a hashmap, so it very well may be already caching data; also, changing the generation of a structure will have no effect on structures that were already partly generated since it reads from their corresponding structure.dat file; for example, here is the result when I loaded a world I created with my "double height terrain" mod in vanilla - notice the abandoned mineshafts that fully generated despite existing at an elevation impossible in vanilla; this also means that for 8 chunks around existing chunks 1.6.4-1.7 worlds will continue to have 1.6.4 mineshaft generation (otherwise, aside from the 60% that are missing they are identical in location and structure; the "ocean bubbles" bug fix in 1.8 had no other effect on the structure):
Note also that when I say chunk generation is much slower that is in general; it takes 3-4 times longer for 1.8 to generate a new world; in fact, Amplified in 1.7 is faster than a default 1.8 world!
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?