Exactly what am I doing wrong to make Optifine slow down Minecraft no matter what I try?
I have:
-Quad Core Intel i7 2ghz 2nd gen processor
-8gb ram
-64bit OS
-GeForce 525M using 301.42 (updated) drivers
I get 100~ fps easily when I load the Vanilla client, but I would like to use optifine for some of it's features such as smooth textures, water features, longer rendering distances, etc. but it kills my client down to a max of 30fps.
I've tried using both normal and 64bit java from Magic Launcher, tried different Java parameters, tried jrw6 and 7, and I even lowered all the performance things on Optifine but it still slugs everything down and I don't know why.
I'm also using Ultra this time in case that's helpful.
So I found that the problem seems to be with Magic Launcher. It is loading my minimum and maximum java parameters at 1024mb and I can't seem to figure out how to change it and still allowing the client to launch. I will check guides, in the meantime, unless somebody has an easy fix.
I've been having problems with optifine. It worked great for the first few days, good fps, smooth running, no crashes. Then, all of the sudden, yesterday as I was overlooking the mods on the "Magic Launcher", the status of Optifine said "11 errors". Now, when I try to launch minecraft with optifine activated, the game quickly flashes the Mojang logo and name, then stays on a black screen. Could anyone possibly give me some insight into fixing this? I'd really appreciate it.
Noticed a class conflict with Optifine and CJB's X-Ray. Would you be able to fix this? If I use the class for X-Ray as is, I lose Better Grass. i don't use MCPatcher as I found a program called MultiMC that resolved my ID conflicts.
how come according to magic launcher, ultra is the only version of optifine that is compatible with my mods in 1.3.1?
they all work in there respective versions for 1.2.5
how come according to magic launcher, ultra is the only version of optifine that is compatible with my mods in 1.3.1?
they all work in there respective versions for 1.2.5
Because Ultra is the only one that has been updated.
I hope nobody minds some copypasta. I made a rather well-received suggestion thread, and most of my suggestions would fit wonderfully into Optifine.
With the new trends in online play, I suggest a minor overhaul of how terrain data is communicated from the server to the client. I have divided my ideas (which work together and are therefore part of a single suggestion, moderators.) into four sections. Now including a TL;DR at the end of each section!
Chunk Pre-Generation:
One of the biggest sources of lag is the tedious task of sending the map's chunk data from the server to the client. Sending a whole chunk means sending the IDs and metadata values for thousands of blocks, and doing so over and over again as the player moves across the map. Many servers combat this by setting the maximum view distance very low, much to the dismay of players who can run at higher render distances, especially using Optifine to grossly increase the view distance. The fact is, on many servers the client could actually predict what block is where. Why?
Most servers, with some exceptions, use the default, Vanilla terrain generator. As we all know, this terrain is derived from using a fixed seed in a set algorithm. There is fairly little that is actually random. This means that, in some areas of most maps, the server does not need to send the client the actual chunk data, but could instead let the client predict the contents of that chunk. How?
First, the server would need to know what chunks need to be sent a which do not. When the server creates a new world, it generates the spawn chunk and a specific radius around it. All chunks within this radius (or more or less, configured by the server owner) would be marked as "send". When the server has to generate a new chunk, it is instantly marked as "don't send", until a certain number of blocks above y=64 or with a light value above a certain threshold are changed and the chunk is marked as "send". All of these variables would be configurable, but the defaults would be very conservative. Possible defaults would be 1 block above y=64 or with light value above 0.
When a player approaches a chunk marked as "don't send", the server simply won't send the chunk data, instead sending a simple flag telling the client to generate that chunk itself. When the player gets close to the chunk, configurable but perhaps defaulting to 2 chunks away, the server will send that chunk's data, regardless of marker. This fail-safe ensures that, no matter what values are used, the player will definitely see the correct terrain when up close.
This procedure would greatly diminish chunk sending-related lag on many servers, and lay the ground work for my other components.
TL;DR: Let the clients generate the terrain themselves sometimes, instead of waiting for the server to send it.
Chunk Pre-Fetching and Caching:
Another source of lag and player irritation on many servers is the delay caused by sending a chunk to the client. While Pre-Generation will help that, there is still more that can be done to decrease the delay on sending chunks marked as "send". How?
When a player's client has finished loading all the chunks in the visible range, it decreases the chunk-sending traffic greatly because the server is now longer sending a nearly constant stream of chunk data. This can happen when a player has stopped to do some crafting, sleep, eat, or is just moving very slowly (like swimming) While the client is no longer receiving a constant stream of chunk data, it could send a request to the server to load a chunk outside the visible range. The server would then choose to respond to that request based on factors such as CPU and RAM usage, volume of chunk data being sent to other players, etc. The server could respond in one of three ways to a pre-fetch request: "Yes" (sending the chunk), "No" (client doesn't request again for 60 seconds), or "Not That One" (declining the request but allowing the client to request a different chunk after 1 second). When this chunk is received, the client stores the chunk in a cache. Before the client needs to request a chunk, it checks if that chunk is already cached. If it is, the client instantly renders the cached copy of the chunk while it waits for the server to send a more recent copy of the data. The client then scans the incoming data and updates that chunk only if there is a difference. The client would request chunk pre-fetches systematically, in a growing spiral around the player's location, until it hits either the maximum cache size (set by the player) or the maximum radius (set by the server). Setting the maximum radius on a server to 0 would cause the server to deny all pre-fetch requests.
Pre-Generation, Pre-Fetching, and Caching would all serve to reduce or make more efficient use of server-client traffic, but add a security flaw. A modded client, for example, could rapidly spam the server with pre-fetch requests, essentially a form of DDoS attack. If a server detects a client making requests sooner than it should (60 seconds after a "No" or 1 second otherwise), the server will ignore all pre-fetch requests from that client until the connection is reset (by the client logging out and back in again). The admin-configurable limits put upon pre-fetching protect it from any other attacks.
TL;DR: Have client store terrain so they don't have to ask for it again so soon, then let the server send extra terrain to clients when it has nothing better to do.
Reverse Mipmapping:
This is not directly related to the other components, but it is a part of letting more powerful clients get the most from their game while playing online.
For those who are not sure, mipmapping is the process where, upon loading a texture from storage into memory, the computer makes high-quality lower resolution versions of the texture and then applying the lower resolution versions to surfaces farther from the camera (player's view). Minecraft Vanilla does not have this, but it is used very effectively in Optifine to increase render speed (FPS).
Many games use mipmapping so that they can use higher resolution textures without majorly decreasing performance. This makes object look better up close in such games. Minecraft does not typically enjoy having textures that look great up close. Instead, Minecraft, even with most texture packs, only really looks very detailed from a distance. This can be fixed if you use a very high-resolution texture pack, but suppose a player wants to use the official server texture pack, as 1.3 now allows? Should he have to choose between HD and properly themed? I don't think so. How?
I first suggest adding mipmapping to the renderer, since it helps so many machines using Optifine. I then suggest adding a process I cam up with myself: Reverse Mipmapping.
To put it simply, instead of just making lower resolution copies of each texture, the client also makes higher resolution copies. Anyone who has tried resizing small images will tell you that this doesn't typically work well, resulting in blurry images, but for the generally super-low resolutions of Minecraft textures, there is a solution. There are many algorithms designed specifically for scaling up sprite art (http://en.wikipedia....ling_algorithms), and can make for some very impressive results. For those who don't want to read the article:
Before and After:
While I do not have any images to prove it ("pics or it didn't happen", I know), I have experimented before with applying the "hq3x" algorithm to Minecraft's default x16 textures to enlarge them up to x64, with fantastic results. Actually, they looked a lot like... http://www.minecraft...13-support-131/. (In no way implying that Vattic uses a filter to make his awesome pack.)
The result would be that Minecraft textures would look smoother and less pixelated up close, letting those with the horsepower to do so feast their eyes on silky smooth textures, while still using the lower resolution pack suggested by the server.
TL;DR: Use a fancy filter to make any texture pack HD, but do so in a way that isn't so hard on FPS. This lets people with beast-like computers enjoy super HD versions of low-res server texture packs without forcing hi-res low-FPS on other users.
This is my suggestion for adjusting both the server and client to better fill the performance gap between single player and online.
Rollback Post to RevisionRollBack
The Internet is a big place, friend. I've been places you've n͍̺e̩v̦e̦̰͍͓̩ͅr̜̭̝̬̬͉̤̬ ͙ịm̖͇a͍͇̤͙̥g̤̘i͔͖̤̼̪̬n͖͔̳̬̯e̩̘ḓ͈͔̠̙͇̼̯.͎
Got to agree with you. MC seriously needs a graphics rendering and terrain loading overhaul. Not sure how much sp614x would be able to implement most of those suggestions without rewriting the whole entirety of the game code.....lol
MC is seriously going to hit a brick wall while still being in Java and IMO need to look at making their own engine, being something other than Java.....uuugh.
I'll catch flack for this, but IMO Java SUCKS for games, other than on portable devices. It was a good platform to start off on but it's time to move on and forward if they want to succeed.
Got to agree with you. MC seriously needs a graphics rendering and terrain loading overhaul. Not sure how much sp614x would be able to implement most of those suggestions without rewriting the whole entirety of the game code.....lol
MC is seriously going to hit a brick wall while still being in Java and IMO need to look at making their own engine, being something other than Java.....uuugh.
I'll catch flack for this, but IMO Java SUCKS for games, other than on portable devices. It was a good platform to start off on but it's time to move on and forward if they want to succeed.
This mod is amazing!! Before I got around 35 fps and now I get 1000 fps on fancy!
I never understood why people are so obsessed with frame rate.....lol
Use that gpu horsepower for eye candy! 60fps is plenty, crank up the AA!...
Here is mine for example. I have absolutely no jaggies what so ever. Everything is nice and smoooooth......
ETA: Just in case someone tries these settings, in game AA through OF has to be turned on to at least 2x when "Enhance the application setting" is selected. Speaks for itself....
Got to agree with you. MC seriously needs a graphics rendering and terrain loading overhaul. Not sure how much sp614x would be able to implement most of those suggestions without rewriting the whole entirety of the game code.....lol
MC is seriously going to hit a brick wall while still being in Java and IMO need to look at making their own engine, being something other than Java.....uuugh.
I'll catch flack for this, but IMO Java SUCKS for games, other than on portable devices. It was a good platform to start off on but it's time to move on and forward if they want to succeed.
I 100% agree with you. use something else other then Java...like maybe the Crytec 3 or Unreal Graphic engines. And make the game look for a sound device as OpenAL sucks even worse. You try walking away from150 squaking chickens and tel me you don't have any lag.
Rollback Post to RevisionRollBack
Life is a Learning Curve.... Unfortunately, you're stuck on the bottom...amongst the bones of the stupid.
I 100% agree with you. use something else other then Java...like maybe the Crytec 3 or Unreal Graphic engines. And make the game look for a sound device as OpenAL sucks even worse. You try walking away from150 squaking chickens and tel me you don't have any lag.
Yeah they see that brick wall heading their way, and you can see it in the way they changed the rendering. Chunks are constantly disappearing while still in render limit flushing them out all the time. It's horrible IMO and a huge distraction as it takes away from the game.
ITt was fantantastic my computer has a very good grafic card but i had outlines on every block but i fixed it with optifine and i like the hd feature feature and better grass i insted of having 200 fps i use them up i only need 24 and now i used all the cool features and i still have 50 fps good job this is the best mod that ehances things.
So I found that the problem seems to be with Magic Launcher. It is loading my minimum and maximum java parameters at 1024mb and I can't seem to figure out how to change it and still allowing the client to launch. I will check guides, in the meantime, unless somebody has an easy fix.
Life is a Learning Curve....
Unfortunately, you're stuck on the bottom...amongst the bones of the stupid.
they all work in there respective versions for 1.2.5
Go Planet Minecraft!
Seriously. How do you expect anyone to help you? Please give a little more information.
Because Ultra is the only one that has been updated.
As long as you don't use any of McPatcher's HD features (Which, for the most part, Optifine has anyway)
Two possibilities:
1.) You didn't delete meta-inf.
2.) You have black paint on your screen.
You mean you can't find it in the MC options menu, or you can't find it on your PC?
You have to set it using the Nvidia Control Panel... if I understand your question.
With the new trends in online play, I suggest a minor overhaul of how terrain data is communicated from the server to the client. I have divided my ideas (which work together and are therefore part of a single suggestion, moderators.) into four sections. Now including a TL;DR at the end of each section!
Chunk Pre-Generation:
One of the biggest sources of lag is the tedious task of sending the map's chunk data from the server to the client. Sending a whole chunk means sending the IDs and metadata values for thousands of blocks, and doing so over and over again as the player moves across the map. Many servers combat this by setting the maximum view distance very low, much to the dismay of players who can run at higher render distances, especially using Optifine to grossly increase the view distance. The fact is, on many servers the client could actually predict what block is where. Why?
Most servers, with some exceptions, use the default, Vanilla terrain generator. As we all know, this terrain is derived from using a fixed seed in a set algorithm. There is fairly little that is actually random. This means that, in some areas of most maps, the server does not need to send the client the actual chunk data, but could instead let the client predict the contents of that chunk. How?
First, the server would need to know what chunks need to be sent a which do not. When the server creates a new world, it generates the spawn chunk and a specific radius around it. All chunks within this radius (or more or less, configured by the server owner) would be marked as "send". When the server has to generate a new chunk, it is instantly marked as "don't send", until a certain number of blocks above y=64 or with a light value above a certain threshold are changed and the chunk is marked as "send". All of these variables would be configurable, but the defaults would be very conservative. Possible defaults would be 1 block above y=64 or with light value above 0.
When a player approaches a chunk marked as "don't send", the server simply won't send the chunk data, instead sending a simple flag telling the client to generate that chunk itself. When the player gets close to the chunk, configurable but perhaps defaulting to 2 chunks away, the server will send that chunk's data, regardless of marker. This fail-safe ensures that, no matter what values are used, the player will definitely see the correct terrain when up close.
This procedure would greatly diminish chunk sending-related lag on many servers, and lay the ground work for my other components.
TL;DR: Let the clients generate the terrain themselves sometimes, instead of waiting for the server to send it.
Chunk Pre-Fetching and Caching:
Another source of lag and player irritation on many servers is the delay caused by sending a chunk to the client. While Pre-Generation will help that, there is still more that can be done to decrease the delay on sending chunks marked as "send". How?
When a player's client has finished loading all the chunks in the visible range, it decreases the chunk-sending traffic greatly because the server is now longer sending a nearly constant stream of chunk data. This can happen when a player has stopped to do some crafting, sleep, eat, or is just moving very slowly (like swimming) While the client is no longer receiving a constant stream of chunk data, it could send a request to the server to load a chunk outside the visible range. The server would then choose to respond to that request based on factors such as CPU and RAM usage, volume of chunk data being sent to other players, etc. The server could respond in one of three ways to a pre-fetch request: "Yes" (sending the chunk), "No" (client doesn't request again for 60 seconds), or "Not That One" (declining the request but allowing the client to request a different chunk after 1 second). When this chunk is received, the client stores the chunk in a cache. Before the client needs to request a chunk, it checks if that chunk is already cached. If it is, the client instantly renders the cached copy of the chunk while it waits for the server to send a more recent copy of the data. The client then scans the incoming data and updates that chunk only if there is a difference. The client would request chunk pre-fetches systematically, in a growing spiral around the player's location, until it hits either the maximum cache size (set by the player) or the maximum radius (set by the server). Setting the maximum radius on a server to 0 would cause the server to deny all pre-fetch requests.
Pre-Generation, Pre-Fetching, and Caching would all serve to reduce or make more efficient use of server-client traffic, but add a security flaw. A modded client, for example, could rapidly spam the server with pre-fetch requests, essentially a form of DDoS attack. If a server detects a client making requests sooner than it should (60 seconds after a "No" or 1 second otherwise), the server will ignore all pre-fetch requests from that client until the connection is reset (by the client logging out and back in again). The admin-configurable limits put upon pre-fetching protect it from any other attacks.
TL;DR: Have client store terrain so they don't have to ask for it again so soon, then let the server send extra terrain to clients when it has nothing better to do.
Reverse Mipmapping:
This is not directly related to the other components, but it is a part of letting more powerful clients get the most from their game while playing online.
For those who are not sure, mipmapping is the process where, upon loading a texture from storage into memory, the computer makes high-quality lower resolution versions of the texture and then applying the lower resolution versions to surfaces farther from the camera (player's view). Minecraft Vanilla does not have this, but it is used very effectively in Optifine to increase render speed (FPS).
Many games use mipmapping so that they can use higher resolution textures without majorly decreasing performance. This makes object look better up close in such games. Minecraft does not typically enjoy having textures that look great up close. Instead, Minecraft, even with most texture packs, only really looks very detailed from a distance. This can be fixed if you use a very high-resolution texture pack, but suppose a player wants to use the official server texture pack, as 1.3 now allows? Should he have to choose between HD and properly themed? I don't think so. How?
I first suggest adding mipmapping to the renderer, since it helps so many machines using Optifine. I then suggest adding a process I cam up with myself: Reverse Mipmapping.
To put it simply, instead of just making lower resolution copies of each texture, the client also makes higher resolution copies. Anyone who has tried resizing small images will tell you that this doesn't typically work well, resulting in blurry images, but for the generally super-low resolutions of Minecraft textures, there is a solution. There are many algorithms designed specifically for scaling up sprite art (http://en.wikipedia....ling_algorithms), and can make for some very impressive results. For those who don't want to read the article:
Before and After:
While I do not have any images to prove it ("pics or it didn't happen", I know), I have experimented before with applying the "hq3x" algorithm to Minecraft's default x16 textures to enlarge them up to x64, with fantastic results. Actually, they looked a lot like... http://www.minecraft...13-support-131/. (In no way implying that Vattic uses a filter to make his awesome pack.)
The result would be that Minecraft textures would look smoother and less pixelated up close, letting those with the horsepower to do so feast their eyes on silky smooth textures, while still using the lower resolution pack suggested by the server.
TL;DR: Use a fancy filter to make any texture pack HD, but do so in a way that isn't so hard on FPS. This lets people with beast-like computers enjoy super HD versions of low-res server texture packs without forcing hi-res low-FPS on other users.
This is my suggestion for adjusting both the server and client to better fill the performance gap between single player and online.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumVery nice writeup...
Got to agree with you. MC seriously needs a graphics rendering and terrain loading overhaul. Not sure how much sp614x would be able to implement most of those suggestions without rewriting the whole entirety of the game code.....lol
MC is seriously going to hit a brick wall while still being in Java and IMO need to look at making their own engine, being something other than Java.....uuugh.
I'll catch flack for this, but IMO Java SUCKS for games, other than on portable devices. It was a good platform to start off on but it's time to move on and forward if they want to succeed.
i actually agree with you.
My Signature Is Better Then Yours, Don't Hate
I never understood why people are so obsessed with frame rate.....lol
Use that gpu horsepower for eye candy! 60fps is plenty, crank up the AA!...
Here is mine for example. I have absolutely no jaggies what so ever. Everything is nice and smoooooth......
ETA: Just in case someone tries these settings, in game AA through OF has to be turned on to at least 2x when "Enhance the application setting" is selected. Speaks for itself....
I 100% agree with you. use something else other then Java...like maybe the Crytec 3 or Unreal Graphic engines. And make the game look for a sound device as OpenAL sucks even worse. You try walking away from150 squaking chickens and tel me you don't have any lag.
Life is a Learning Curve....
Unfortunately, you're stuck on the bottom...amongst the bones of the stupid.
Yeah they see that brick wall heading their way, and you can see it in the way they changed the rendering. Chunks are constantly disappearing while still in render limit flushing them out all the time. It's horrible IMO and a huge distraction as it takes away from the game.