The Meaning of Life, the Universe, and Everything.
Join Date:
6/21/2012
Posts:
58
Minecraft:
Oswald The Catfish
Member Details
He most likely payed more money to get a pc that can run games well, and maybe if he was willing to spend money on a good pc he has a 120/144hz monitor. I dont get how hard it is to understand that he payed more money to get a better experience, and he is not getting one. There is definitely something wrong and it is something that should be complained about.
I have my fps set to max at 60, because why would I need more? I usually gave a fairly consistent 55-60 fps, but since 1.8 or any of its snapshots I can't go a full second without it randomly dropping to 0 fps for a moment. It's quite game-breaking, as it makes walking around into a struggle and fighting mobs impossible
It seems a lot of people have horrible lags I see.
But did you guys try to do this?:
-put "VBO" on ( I think this is for multi-threaded rendering )
-put "Alternate Blocks" off ( no idea what it does, but it seems to eat a ton of fps )
-put "Render distance" lower
There is also some CPU tricks you can do, but I have no idea if it is against the law. ( if someone can explain the computer law thing via pm or so, it would be helpful. )
There is nothing illegal about overclocking your CPU, at least not in the US, but it will void your warrantee and can damage your machine if you don't have adequate cooling.
Yeah, I just noticed today that I have significantly worse FPS in 1.8 (about 5-15 as opposed to 20-30). I hadn't noticed it before because I usually tested 1.8 in plain superflat worlds.
It's the lighting engine changes in week 30 snapshots that cause all these issues.
"Get new hardware?"
Not very helpful, are you?
What else can I say, my Minecraft works fine, I have no idea why yours don't.
If you're going to criticize a person that knows almost nothing about hardware, coding, Java, stuff like that, you should really learn that other people have different amounts of knowledge than you.
Rollback Post to RevisionRollBack
Geno: Blahblahblah, random sentence.
Firebrand is this color.
Shovel Knight is this color.
Memnon is this color
Cinder is this color.
Glacius is this color.
Jago is this color.
The Batter (or just Batter) is this color
Heatshade is this col- I CHOOSE MY OWN COLORS, BABY!!!
1.8 is awesome, I can finally run the goddang game, I guess it's your hardware or something.
I've always been able to run the game smoothly up until 1.8 was released, so I beg to differ.
Unless, of course, the changes in 1.8 were so taxing on performance that they completely choked our computers, but like I said, the updated features don't really justify such a huge performance drop. It's more likely a bad programming choice with a nasty side-effect, or possibly a bug somewhere.
It's the lighting engine changes in week 30 snapshots that cause all these issues.
Hmm, I hadn't thought of that. I've seen people mention the chunk rendering / update system, though, and I'm more inclined to believe that might actually be the cause.
Version 1.8 is actually supremely fast at rendering new chunks, which you can easily notice if you fly around on Creative. This was likely meant to fix that bug where some chunks would randomly not seem to render, creating holes in the landscape, and perhaps also to prevent people catching up to the rendering when flying around, and moving into yet unrendered space, which tends to cause problems.
The trade-off for this "fix" is that, of course, chunk rendering is now more resource-intensive (and more chunk updates are being done than in prior versions). This, I think, is what causes the lag, because you might notice that if you stand still, the FPS stop fluctuating and going down the drain; they tend to start acting up only when you start moving, thus loading new chunks.
Setting the render distance to the minimum helps, but it still doesn't remove the constant, game-breaking stutter, which is simply unacceptable (and even setting all options to the minimum with the vanilla texture pack won't do much).
If this is indeed the case, then hopefully OptiFine for version 1.8 will allow me to fix this, as it has an option to fine-tune chunk updates. I'd rather go back to 1.7.10 behaviour and have a somewhat slower chunk loading but still be able to play smoothly, than not being able to play at all (though I'm not sure if this option also affects chunk rendering - probably not - but I'll have to wait and see, as it's pretty much my only hope now).
I've been messing around with various chunk rendering distances and I can't see it making much difference.
What I found to be an absolute nightmare in 1.8 was a giant podzol forest. Holy crap it was a complete lag-fest. It rendered good in 1.7.4 and got a bit of slowdown in 14w29b but in 1.8 it was wait ... wait... wait.... oh look! Trees. Move. Wait... wait... wait...
Yea, I've been reading your other posts on the subject, and I've seen your performance tests, and really, everything points to the problem beginning in 14w30, probably with the lighting changes (although that snapshot also changed chunk sorting and added the advanced cave culling algorithm and threaded chunk rebuilding, so these might also be the culprit).
I saw people saying that the reduced GPU use was supposed to be beneficial, but like... that's only true up to a point; if a piece of software isn't using the full extent of your hardware and, instead, either overloads other components or simply refuses to function, then we have a problem. What good is having a lesser burden on my GPU if the game doesn't even work? Lol.
I haven't managed to find podzol forests but I experienced 2fps on an ocean while attempting to even enter a monument, so there's that. Also, for kicks, try making a customized ocean world preset and see how well that turns out (granted that's a lot of water, but still -- if it's there, it should theoretically work; it's not even amplified or anything, and I would think only the surface textures are animated, so it probably shouldn't lag as much as it does).
I'm beginning to see how it is possible that some people are seeing improvements while others see lag. It might be due to the biome where they are playing.
I have improvements regardless of biome. My problems, similar to the ones you described (lag, wait, step, lag, wait, step), only show up if I try to load too many chunks too quick. This only happens if I'm intentionally trying to load as many chunks as I can, and only if I'm zooming around in a boat or flying in Creative.
So maybe it's just amount of content that's the limiting factor. Meaning jungles would probably be the worst, for those in your situation?
Perhaps it is a result of memory allocated? I have some people suggest altering the Xmx?G arguments in their profile settings, and some people have said that it solved their problems. (I've allocated 2GB) Other people suggest turning VBOs on and VSync off, with many reporting that that worked.
One thing I noticed with my computer is that it takes it a little while to handle new things taking up RAM and CPU amounts. I dunno why, it's sort of weird that my computer "learns" to handle new things. I actually play most of the time in 1.7.2 because the server I play on is that version and the plugins aren't updated yet. Then I got around to actually playing on 1.7.10 with some friends and I was getting 50-60 fps after a while much like 1.7.2 and other versions my computer must have gotten used to. Seems very funny to me I have to say. So maybe playing on 1.8 for a while may help the machine slowly handle the game better as time goes on.
Rollback Post to RevisionRollBack
aviusmc.com OR avius.freeforums.org Highlight the area next to this arrow! --> Invisible text! Made you do it! ;-)
Word on the grapevine is that the fps issue can be resolved by installing Java 8 (any version except update 20). However, Java 8 is incompatible with Forge for some reason, so you'll lose that option. I have no idea why that is. (edit: maybe it was just Forge that didn't like Java 8u20. I should probably figure that out.)
As far as what could be causing the stuttering, Java 8 is supposed to have a different and improved garbage collector. In Minecraft 1.8, all Vec3s and AABBs have had their instance pool removed and are now immutable types. It's possible that Java 7 is not respecting the immutable attribute and is causing Minecraft to hemorrhage orphaned records every GC.
Other folk are blaming the VBOs. I have no idea what that setting does that it wasn't doing before, so I can't really say whether this might be the case. Bunch a magic and hoopla is what it is.
Yea, I've been reading your other posts on the subject, and I've seen your performance tests, and really, everything points to the problem beginning in 14w30, probably with the lighting changes (although that snapshot also changed chunk sorting and added the advanced cave culling algorithm and threaded chunk rebuilding, so these might also be the culprit).
I saw people saying that the reduced GPU use was supposed to be beneficial, but like... that's only true up to a point; if a piece of software isn't using the full extent of your hardware and, instead, either overloads other components or simply refuses to function, then we have a problem. What good is having a lesser burden on my GPU if the game doesn't even work? Lol.
I haven't managed to find podzol forests but I experienced 2fps on an ocean while attempting to even enter a monument, so there's that. Also, for kicks, try making a customized ocean world preset and see how well that turns out (granted that's a lot of water, but still -- if it's there, it should theoretically work; it's not even amplified or anything, and I would think only the surface textures are animated, so it probably shouldn't lag as much as it does).
Actually, VBO's reduce CPU usage by sending the data to the card all at once instead of using a costly function call per vertex attribute. They don't have much effect on GPU usage at all aside from possibly reducing the amount of time it spends loading things from RAM. If the code is causing you lag in 1.8 it has nothing to do with the VBOs and everything to do with the fact that they just rewrote the entire renderer from scratch. It's probably a weird edge case issue that didn't show up in any of the official testing machines.
There are a lot of people having fps issues, and lag issues.
One of the solutions has been to download and install 64bit java.
However, I have learned that Oracle directs you during the download process to 32bit version if you are using a 32bit browser, which most people do unless they use 64bit Internet Explorer, that comes with windows 7 and windows 8, which is not the default or they have manually installed 64bit versions of their favorite browser.
So, for those having issues, click task manager with the launcher running and see if it says 32bit or SE binary for 64bit. if you are indeed running 32bit, and most likely are running a 32bit browser, download the 64bit version for offline installs here:
Actually, VBO's reduce CPU usage by sending the data to the card all at once instead of using a costly function call per vertex attribute. They don't have much effect on GPU usage at all aside from possibly reducing the amount of time it spends loading things from RAM. If the code is causing you lag in 1.8 it has nothing to do with the VBOs and everything to do with the fact that they just rewrote the entire renderer from scratch. It's probably a weird edge case issue that didn't show up in any of the official testing machines.
I'm not talking about VBO's. I don't even have that option activated while running the game (and activating it makes no noticeable difference).
However, you will notice that, as per LeslieGilliams's observations and side-by-side graph comparisons, update 1.8 is making significantly less use of the GPU compared to the snapshots up to w29 IIRC, and the 1.7 versions -- and as far as I've noticed, this is true regardless of the VBO option.
I suppose if you have a better CPU than a GPU, or if both are great, you won't notice the performance drop, but for those who have better GPU than CPU, or overall weaker hardware, it's more noticeable.
Now, the question still stands: is the GPU being less used because some of the burden was shifted to the CPU instead (and, in that case, this should definitely be a toggle so that we can set that option depending on our hardware), or is it just not being used by anything at all, thus resulting in a performance drop due to the hardware not being used at its full potential?
Needless to say, if all of us can run 1.7 (and snapshots up to w29) without any issues, and 1.8 was supposed to improve, not reduce performance, then there is definitely a coding problem here (be it a bug or just a bad choice). Plus, it doesn't make sense to update hardware dramatically over internal changes on how the game works that don't actually improve the game's visual quality. If it ain't broken, then don't try to fix it -- and the game was definitely not broken in 1.7 compared to the way it is now, and nothing of value was gained by these changes (or, rather, whatever value was gained was highly offset by the losses experienced by others).
EDIT: Also, considering the sheer number of players that have been reporting this issue, I would hardly call it a "weird edge case". I know Mojang probably tests updates on powerful machines, but we don't all run similar machines -- in fact, I dare say that a huge chunk of Minecraft's player base has more humble computers, especially laptops -- but even that doesn't really excuse this mess up, because these things can be noticed.
If you notice significant changes in how the game handles your resources, and if you notice a performance drop, even if it doesn't affect you, you should be quite capable of realising that while on your machine the impact might be minimal, on the rest of the player base that might not be the case, and you need to code updates with those people in mind, not just the... edge case ones that have powerful, high end machines.
There are a lot of people having fps issues, and lag issues.
One of the solutions has been to download and install 64bit java.
However, I have learned that Oracle directs you during the download process to 32bit version if you are using a 32bit browser, which most people do unless they use 64bit Internet Explorer, that comes with windows 7 and windows 8, which is not the default or they have manually installed 64bit versions of their favorite browser.
So, for those having issues, click task manager with the launcher running and see if it says 32bit or SE binary for 64bit. if you are indeed running 32bit, and most likely are running a 32bit browser, download the 64bit version for offline installs here:
pls send help
There is nothing illegal about overclocking your CPU, at least not in the US, but it will void your warrantee and can damage your machine if you don't have adequate cooling.
Geno: Blahblahblah, random sentence.
Firebrand is this color.
Shovel Knight is this color.
Memnon is this color
Cinder is this color.
Glacius is this color.
Jago is this color.
The Batter (or just Batter) is this color
Heatshade is this col- I CHOOSE MY OWN COLORS, BABY!!!
Heatshade, please.
...Fine.
Anyway...
I am this color.
http://steamcommunity.com/id/Therealadrenalinerush/
What else can I say, my Minecraft works fine, I have no idea why yours don't.
If you're going to criticize a person that knows almost nothing about hardware, coding, Java, stuff like that, you should really learn that other people have different amounts of knowledge than you.
Geno: Blahblahblah, random sentence.
Firebrand is this color.
Shovel Knight is this color.
Memnon is this color
Cinder is this color.
Glacius is this color.
Jago is this color.
The Batter (or just Batter) is this color
Heatshade is this col- I CHOOSE MY OWN COLORS, BABY!!!
Heatshade, please.
...Fine.
Anyway...
I am this color.
http://steamcommunity.com/id/Therealadrenalinerush/
I've always been able to run the game smoothly up until 1.8 was released, so I beg to differ.
Unless, of course, the changes in 1.8 were so taxing on performance that they completely choked our computers, but like I said, the updated features don't really justify such a huge performance drop. It's more likely a bad programming choice with a nasty side-effect, or possibly a bug somewhere.
Hmm, I hadn't thought of that. I've seen people mention the chunk rendering / update system, though, and I'm more inclined to believe that might actually be the cause.
Version 1.8 is actually supremely fast at rendering new chunks, which you can easily notice if you fly around on Creative. This was likely meant to fix that bug where some chunks would randomly not seem to render, creating holes in the landscape, and perhaps also to prevent people catching up to the rendering when flying around, and moving into yet unrendered space, which tends to cause problems.
The trade-off for this "fix" is that, of course, chunk rendering is now more resource-intensive (and more chunk updates are being done than in prior versions). This, I think, is what causes the lag, because you might notice that if you stand still, the FPS stop fluctuating and going down the drain; they tend to start acting up only when you start moving, thus loading new chunks.
Setting the render distance to the minimum helps, but it still doesn't remove the constant, game-breaking stutter, which is simply unacceptable (and even setting all options to the minimum with the vanilla texture pack won't do much).
If this is indeed the case, then hopefully OptiFine for version 1.8 will allow me to fix this, as it has an option to fine-tune chunk updates. I'd rather go back to 1.7.10 behaviour and have a somewhat slower chunk loading but still be able to play smoothly, than not being able to play at all (though I'm not sure if this option also affects chunk rendering - probably not - but I'll have to wait and see, as it's pretty much my only hope now).
Yea, I've been reading your other posts on the subject, and I've seen your performance tests, and really, everything points to the problem beginning in 14w30, probably with the lighting changes (although that snapshot also changed chunk sorting and added the advanced cave culling algorithm and threaded chunk rebuilding, so these might also be the culprit).
I saw people saying that the reduced GPU use was supposed to be beneficial, but like... that's only true up to a point; if a piece of software isn't using the full extent of your hardware and, instead, either overloads other components or simply refuses to function, then we have a problem. What good is having a lesser burden on my GPU if the game doesn't even work? Lol.
I haven't managed to find podzol forests but I experienced 2fps on an ocean while attempting to even enter a monument, so there's that. Also, for kicks, try making a customized ocean world preset and see how well that turns out (granted that's a lot of water, but still -- if it's there, it should theoretically work; it's not even amplified or anything, and I would think only the surface textures are animated, so it probably shouldn't lag as much as it does).
I have improvements regardless of biome. My problems, similar to the ones you described (lag, wait, step, lag, wait, step), only show up if I try to load too many chunks too quick. This only happens if I'm intentionally trying to load as many chunks as I can, and only if I'm zooming around in a boat or flying in Creative.
So maybe it's just amount of content that's the limiting factor. Meaning jungles would probably be the worst, for those in your situation?
Perhaps it is a result of memory allocated? I have some people suggest altering the Xmx?G arguments in their profile settings, and some people have said that it solved their problems. (I've allocated 2GB) Other people suggest turning VBOs on and VSync off, with many reporting that that worked.
If you are planning to make a suggestion, please read this.
If you want to know more, you can read this.
For those who complain about post-Beta generation, you might want to see this.
aviusmc.com OR avius.freeforums.org Highlight the area next to this arrow! --> Invisible text! Made you do it! ;-)
Thats lag spikes, I've noticed lag spikes too with VBOs on. Seems to have gone away.
Which is then balanced by:
.
- The Cubic Chunks Mod is back! Be a part of it's rebirth and Development.
-- Robinton's Mods: [ Mirror ] for some of his Mods incl Cubic Chunks Mod, due to DropBox broken links.
- Dungeon Generator for the Open Cubic Chunks Mod
- QuickSAVE-QuickLOAD for the Open Cubic Chunks Mod
If you are planning to make a suggestion, please read this.
If you want to know more, you can read this.
For those who complain about post-Beta generation, you might want to see this.
No it doesn't. I have this problem and I have 2GB allocated. Anything more than 2GB is redundant.
Actually, VBO's reduce CPU usage by sending the data to the card all at once instead of using a costly function call per vertex attribute. They don't have much effect on GPU usage at all aside from possibly reducing the amount of time it spends loading things from RAM. If the code is causing you lag in 1.8 it has nothing to do with the VBOs and everything to do with the fact that they just rewrote the entire renderer from scratch. It's probably a weird edge case issue that didn't show up in any of the official testing machines.
One of the solutions has been to download and install 64bit java.
However, I have learned that Oracle directs you during the download process to 32bit version if you are using a 32bit browser, which most people do unless they use 64bit Internet Explorer, that comes with windows 7 and windows 8, which is not the default or they have manually installed 64bit versions of their favorite browser.
So, for those having issues, click task manager with the launcher running and see if it says 32bit or SE binary for 64bit. if you are indeed running 32bit, and most likely are running a 32bit browser, download the 64bit version for offline installs here:
http://www.java.com/en/download/manual.jsp
this is the most up to date version, and solved my issues. I hope it helps others.
I'm not talking about VBO's. I don't even have that option activated while running the game (and activating it makes no noticeable difference).
However, you will notice that, as per LeslieGilliams's observations and side-by-side graph comparisons, update 1.8 is making significantly less use of the GPU compared to the snapshots up to w29 IIRC, and the 1.7 versions -- and as far as I've noticed, this is true regardless of the VBO option.
I suppose if you have a better CPU than a GPU, or if both are great, you won't notice the performance drop, but for those who have better GPU than CPU, or overall weaker hardware, it's more noticeable.
Now, the question still stands: is the GPU being less used because some of the burden was shifted to the CPU instead (and, in that case, this should definitely be a toggle so that we can set that option depending on our hardware), or is it just not being used by anything at all, thus resulting in a performance drop due to the hardware not being used at its full potential?
Needless to say, if all of us can run 1.7 (and snapshots up to w29) without any issues, and 1.8 was supposed to improve, not reduce performance, then there is definitely a coding problem here (be it a bug or just a bad choice). Plus, it doesn't make sense to update hardware dramatically over internal changes on how the game works that don't actually improve the game's visual quality. If it ain't broken, then don't try to fix it -- and the game was definitely not broken in 1.7 compared to the way it is now, and nothing of value was gained by these changes (or, rather, whatever value was gained was highly offset by the losses experienced by others).
EDIT: Also, considering the sheer number of players that have been reporting this issue, I would hardly call it a "weird edge case". I know Mojang probably tests updates on powerful machines, but we don't all run similar machines -- in fact, I dare say that a huge chunk of Minecraft's player base has more humble computers, especially laptops -- but even that doesn't really excuse this mess up, because these things can be noticed.
If you notice significant changes in how the game handles your resources, and if you notice a performance drop, even if it doesn't affect you, you should be quite capable of realising that while on your machine the impact might be minimal, on the rest of the player base that might not be the case, and you need to code updates with those people in mind, not just the... edge case ones that have powerful, high end machines.
Yes, 64 bit Java doesn't remove the problem, but does reduce the severity.
From this thread:
This is data from LeslieGilliams' testing in this thread.
Get 64 bit Java here (you need 64 bit Windows): https://www.java.com/en/download/manual.jsp