Because I don't know if it's a coincidence or not but today after my little brother installed the 1.7.3 snapshot things just got bad.... I switched over to 1.7.2 but now my fps is like at the 0-20 range and it's very rough and shaky..... like a filk that is pausing and unpausing.... This didn't happen yesterday.... Could my little brother installing 1.7.2 snapshot done this even though I switched to version 1.7.2? Or if not is there a way to fix this?
I had this same issue, which resulting from playing beta 1.7.3. The only way I have found to fix this is to back up all the files you want to keep in your .minecraft folder, delete the folder, and start over. While this did fix my performance in 1.7.2 I am forever stunted in how well I can run every version of the game prior to 1.6, so if you plan to play below that I cannot help you.
Wait, do you mean actual Beta 1.7.3 from mid-2011, or the 1.7.3 pre-release? I'm assuming you're talking about the pre-release, but leaving it up to an assumption isn't a good idea.
3. Give more memory to minecraft - in the launcher, edit your profile, and under Java, checkbox "JVM arguments" and put, for example,
-Xmx1G -Xms1G
...to allow it to use more memory. If you have 64 bit java, and have lots of spare RAM, you could set them even higher.
If there's not enough memory you will get the out of memory screen, not a decrease in framerate, unless your system RAM is the problem (paging to the hard drive). Optifine even suggests REDUCING memory for this very reason (only really a problem if you have less than the 2 GB minimum requirement or decide to run memory-intensive programs at the same time, but my computer only uses 2 GB (out of 3 GB total) when I run Minecraft and Firefox with several tabs open). Memory just doesn't work like that; 99% of programs simply crash or refuse an operation if there isn't enough memory (again, excluding the case of insufficient system RAM).
Conversely, allocating more RAM won't force Minecraft to use more memory than it needs and just ties up memory that could be used by other programs - I see this as a big flaw in Java; your ordinary program doesn't use more memory than it actually needs (never mind the overhead needed by Java itself).
FWIW, Minecraft runs very nicely in under 500 MB of memory for me (-Xms512M -Xmx768M, the latter just in case, but you can see it doesn't allocate more than the -Xms value, actually somewhat less for whatever reason), even with Forge and several mods and a world where the terrain height has been doubled (twice as much terrain relative to bedrock, even more overall than Amplified, but normal above ground), and in a jungle to top all of that (yes, that's 1.6.2 but I don't notice any significant difference in memory usage with 1.7). Of course, I use mostly default textures (just a few blocks changed) and at default resolution otherwise except for the sun and moon (I think a round sun and moon look better, and yes, you can mix texture sizes).
Because I don't know if it's a coincidence or not but today after my little brother installed the 1.7.3 snapshot things just got bad.... I switched over to 1.7.2 but now my fps is like at the 0-20 range and it's very rough and shaky..... like a filk that is pausing and unpausing.... This didn't happen yesterday.... Could my little brother installing 1.7.2 snapshot done this even though I switched to version 1.7.2? Or if not is there a way to fix this?
You should try backing up your saves and re-installing minecraft.
I saw a dramatic increase in memory usage after updating to 1.7.3 myself, earlier today I got an OutOfMemory exception crash and later saw in the F3 menu it was using almost 100% of the 494 MB capacity, previously it would be hovering around the 50% mark or so. Mojang did fix the render distance bug in 1.7.3 so those of us who set it to 16 actually get what is advertised, I'm guessing that is the reason for the sharp increase.
0-20 frames? Oh boo hoo. As of late, I can only get 0-15 FPS normally, so don't come crying to the average player like me with that crap.
But you are below average. To some players, going from 50 fps to 15 fps is a drastic change. You being used to those frames, it doesn't bother you as much.
Rollback Post to RevisionRollBack
Signature not available. Please check again later.
Mojang fix and improve the game, but that inevitably means it needs more memory/more CPU load/more disk space and so forth.
It was always meant to function like that though, memory usage grows consistently with number of rendered chunks. What many people don't realize is that each render distance step is more expensive than the previous one. I was simply surprised since I didn't actually realize the render distance was broken until I saw the changelog. I will have to allocate more to the virtual machine to rectify the situation I suppose, or lower the render distance, but hey why would I do that if I have 4 GBs of RAM to spare?
As for your statement, many improvements result in better performance with negligible or non-existent negative side effects, such as fixing memory leaks, which although don't occur in Java can be a vast problem in for example C if you don't take good care of your heap de/allocation. But yes, you usually need to pay some price for the good stuff, that's how the world rolls.
People forget that every update is an absolute total free bonus. I have never played any game where you buy it, and then they give you *totally* new versions, with *totally* new features, for free *forever*.
Imagine buying a car, and Ford contacting you a year later saying "hey, we made a new engine, so here's a new car!"... year after year.
"Oh, the old car? Sure, you can keep that too".
With hyperbole like this it's hard to take you seriously. What a load of nonsense!
New versions *may not run* on computers that could manage the old versions. There's PC's that could happily run Alpha which wouldn't even load up 1.7...and also, people update their Windows, and there may not be drivers for their years-old graphics cards for the new version of the OS.
So your new car isn't so free after all. People *may have to buy* a new computer to play a new version of Minecraft.
What's so distressing is that you simply stating the obvious. What you forget is that people are talking simply of a 1.7.2 to 1.7.3 transition. Get a hold on reality! Sheesh.
Rollback Post to RevisionRollBack
I was trying to think of a signature and this is what came up.
Oh, just shut up. You reek of irrational fanboyism. Bet you aren't even playing this for more than a few months. Some of the people you are addressing, with your poorly constructed patronizing arguments have been here since alpha. They know it. It's one thing to love this game. It's another to make everyone else who loves it feel embarrassed by your gibberish.
"It's a complex game. There be bugs". It's the only thing that anyone should know. If you can't feel even an ounce of empathy towards anyone having problems running the game, your place isn't on an online forum shooting verbal diarrhea through your mouth.
Rollback Post to RevisionRollBack
I was trying to think of a signature and this is what came up.
Important:
-Xmx2G at the beginning is how much RAM in GB you want to give to the game,
-XX:ParallelGCThreads=2 at the end is how many cpu cores you have. Set those parameters accordingly to your needs.
Save the changes to the profile and play.
If my whole computer only has 2g of memory, I presume I don't want to allocate all of it to Minecraft, even if that's the only thing I'm running, right? Overhead, and whatnot. How much would you recommend I use, then, ideally?
You should follow MasterCaver advise in #10 and use only the settings in his post. They will fit nicely in a 2GB or 4GB system running a 32bit version of Minecraft.
The settings provided by MazeCraft are of no use to you, even if you reduce -Xmx2G to something like -Xmx768M. In fact, his settings are really only of any use to 64bit machines running the game on a >4GB machine. And the optimizations it provides aren't that significant on such a machine that can theoretically already run Minecraft comfortably. So it's like trying to put a booster on an F1.
-XX:+UseLargePages: Makes use of Large Memory Pages. It has the potential to speed in memory page translation access and reduce cache misses. But it is really only meant for memory intensive applications, which Minecraft isn't (the game can run quite well on -Xmx500M, for instance). There won't be many benefits from this. It is essentially tell you to optimize memory use of an application that does not need memory optimization. In memory constrained systems (like your 2GB computer) it will actually be a bad idea to include this setting. It has the side effect of increasing memory fragmentation (each translation page can address more memory) and it refuses to give memory back to the system, raising the potential for regular memory paging that will reduce the performance of the whole system. Verdict: Don't bother with this whatever your system, unless probably you are a developer and running a debug version of the game.
-XX:+UseFastAccessorMethods: It's a pure JVM optimization for class accessor methods (the Get<primitive> field) that I frankly never saw much gain from in Minecraft. Still it's not a bad thing to have. Maybe one day it will do something. Verdict: Whatever...
-XX:+AggressiveOpts: Will turn on compiler optimizations already included in the JVM that are meant to become default in the next Java release. The impact on performance is like playing the lottery. Is Oracle developing a good optimization? is it included on this Java version? Is it tagged to be made default on Java next version? Will it affect Minecraft code? Answer yes to all these answers and you got yourself a winner... if you don't want to wait fot Java next version. Verdict: Not a bad thing to have. But a bit on the experimental side. AggressiveOpts is really intended only when you know the answer to the questions above before hand and you want to take immediate advantage of it before Java next version.
-XX:+UseAdaptiveGCBoundary -XX:MaxGCPauseMillis=500 -XX:SurvivorRatio=16 -XX:+UseParallelGC -XX:ParallelGCThreads=2: These are all garbage collection (GC) optimizations. And they are a mistake to be shown like this, since every system will require fine tuning for optimal settings. And every version of Minecraft may introduce new code that will render these settings less effective. The last two settings aren't even correct. ParallelGC is the parallel scavenge collector. It's fine tuned for heaps over 10GB in size and has no place in a game like Minecraft. There's no real gain from it. Much more efficient is using the parallel copying collector, UseParNewGC . Verdict: Don't use any of this. But if you have a 4, or more, cores machine, you will gain from using -XX:+UseParNewGC.
Wait, do you mean actual Beta 1.7.3 from mid-2011, or the 1.7.3 pre-release? I'm assuming you're talking about the pre-release, but leaving it up to an assumption isn't a good idea.
If there's not enough memory you will get the out of memory screen, not a decrease in framerate, unless your system RAM is the problem (paging to the hard drive). Optifine even suggests REDUCING memory for this very reason (only really a problem if you have less than the 2 GB minimum requirement or decide to run memory-intensive programs at the same time, but my computer only uses 2 GB (out of 3 GB total) when I run Minecraft and Firefox with several tabs open). Memory just doesn't work like that; 99% of programs simply crash or refuse an operation if there isn't enough memory (again, excluding the case of insufficient system RAM).
Conversely, allocating more RAM won't force Minecraft to use more memory than it needs and just ties up memory that could be used by other programs - I see this as a big flaw in Java; your ordinary program doesn't use more memory than it actually needs (never mind the overhead needed by Java itself).
FWIW, Minecraft runs very nicely in under 500 MB of memory for me (-Xms512M -Xmx768M, the latter just in case, but you can see it doesn't allocate more than the -Xms value, actually somewhat less for whatever reason), even with Forge and several mods and a world where the terrain height has been doubled (twice as much terrain relative to bedrock, even more overall than Amplified, but normal above ground), and in a jungle to top all of that (yes, that's 1.6.2 but I don't notice any significant difference in memory usage with 1.7). Of course, I use mostly default textures (just a few blocks changed) and at default resolution otherwise except for the sun and moon (I think a round sun and moon look better, and yes, you can mix texture sizes).
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?
You should try backing up your saves and re-installing minecraft.
Most people can get at least 25+ FPS, So you are not average.
My Github ด้้้้้็็็็็้้้้้็็็็็้้้้้็็็็็้้้้้็็็็็้้้้้็็็็็้้้้้็็็็็้้้้้็็็็็้้้้้дด็็็็็้้้้้็็็็้้้้้็็็็็้้้้้็็็็็้้้้้็็็็็้้้้้
But you are below average. To some players, going from 50 fps to 15 fps is a drastic change. You being used to those frames, it doesn't bother you as much.
It was always meant to function like that though, memory usage grows consistently with number of rendered chunks. What many people don't realize is that each render distance step is more expensive than the previous one. I was simply surprised since I didn't actually realize the render distance was broken until I saw the changelog. I will have to allocate more to the virtual machine to rectify the situation I suppose, or lower the render distance, but hey why would I do that if I have 4 GBs of RAM to spare?
As for your statement, many improvements result in better performance with negligible or non-existent negative side effects, such as fixing memory leaks, which although don't occur in Java can be a vast problem in for example C if you don't take good care of your heap de/allocation. But yes, you usually need to pay some price for the good stuff, that's how the world rolls.
With hyperbole like this it's hard to take you seriously. What a load of nonsense!
So your new car isn't so free after all. People *may have to buy* a new computer to play a new version of Minecraft.
What's so distressing is that you simply stating the obvious. What you forget is that people are talking simply of a 1.7.2 to 1.7.3 transition. Get a hold on reality! Sheesh.
"It's a complex game. There be bugs". It's the only thing that anyone should know. If you can't feel even an ounce of empathy towards anyone having problems running the game, your place isn't on an online forum shooting verbal diarrhea through your mouth.
If my whole computer only has 2g of memory, I presume I don't want to allocate all of it to Minecraft, even if that's the only thing I'm running, right? Overhead, and whatnot. How much would you recommend I use, then, ideally?
Village Mechanics: A not-so-brief guide - Update 2017! Now with 1.8 breeding mechanics! Long-overdue trading info, coming soon!
You think magic isn't real? Consider this: for every person, there is a sentence -- a series of words -- which has the power to destroy them.
The settings provided by MazeCraft are of no use to you, even if you reduce -Xmx2G to something like -Xmx768M. In fact, his settings are really only of any use to 64bit machines running the game on a >4GB machine. And the optimizations it provides aren't that significant on such a machine that can theoretically already run Minecraft comfortably. So it's like trying to put a booster on an F1.
-XX:+UseLargePages: Makes use of Large Memory Pages. It has the potential to speed in memory page translation access and reduce cache misses. But it is really only meant for memory intensive applications, which Minecraft isn't (the game can run quite well on -Xmx500M, for instance). There won't be many benefits from this. It is essentially tell you to optimize memory use of an application that does not need memory optimization. In memory constrained systems (like your 2GB computer) it will actually be a bad idea to include this setting. It has the side effect of increasing memory fragmentation (each translation page can address more memory) and it refuses to give memory back to the system, raising the potential for regular memory paging that will reduce the performance of the whole system. Verdict: Don't bother with this whatever your system, unless probably you are a developer and running a debug version of the game.
-XX:+UseFastAccessorMethods: It's a pure JVM optimization for class accessor methods (the Get<primitive> field) that I frankly never saw much gain from in Minecraft. Still it's not a bad thing to have. Maybe one day it will do something. Verdict: Whatever...
-XX:+AggressiveOpts: Will turn on compiler optimizations already included in the JVM that are meant to become default in the next Java release. The impact on performance is like playing the lottery. Is Oracle developing a good optimization? is it included on this Java version? Is it tagged to be made default on Java next version? Will it affect Minecraft code? Answer yes to all these answers and you got yourself a winner... if you don't want to wait fot Java next version. Verdict: Not a bad thing to have. But a bit on the experimental side. AggressiveOpts is really intended only when you know the answer to the questions above before hand and you want to take immediate advantage of it before Java next version.
-XX:+UseAdaptiveGCBoundary
-XX:MaxGCPauseMillis=500
-XX:SurvivorRatio=16
-XX:+UseParallelGC
-XX:ParallelGCThreads=2: These are all garbage collection (GC) optimizations. And they are a mistake to be shown like this, since every system will require fine tuning for optimal settings. And every version of Minecraft may introduce new code that will render these settings less effective. The last two settings aren't even correct. ParallelGC is the parallel scavenge collector. It's fine tuned for heaps over 10GB in size and has no place in a game like Minecraft. There's no real gain from it. Much more efficient is using the parallel copying collector, UseParNewGC . Verdict: Don't use any of this. But if you have a 4, or more, cores machine, you will gain from using -XX:+UseParNewGC.