Mace Madunusus

1.5.2pre has this note in the changelog: Improvements to FPS when using high-resolution texture packs. So it is a possibility it is not a concern, but I have not tested it myself.

This has returned for me in 1.5.1 on my GTX 280.

I also tested this on 3 other graphics cards including my new one. These cards are an 8800GTS 640mb, GTX 550 TI, GTX 660 2gb all of which have the same result.

Why wouldn't it be possible? MC only runs on a single core, and mods like optifine have shown it can at the very least do chunk loading multi-core and improving overall performance and quality at the same time. Things like Spigot and Spout have shown that current chunk formats are inefficient and are often prone to memory leaks. In-game MC usually says its only using 300 or so MB out of 1gb using F3 yet checking task manager it is clearly using a lot more. So its largely things Mojang has to do because Java is capable of it.

I don't currently have a tool to check vram as I usually used in-game profiling.

Its more or less logical, most of the texture data for MC is miniscule in comparison to other games. I've designed multiple scenes in the engines that I mentioned, with way more high res textures with normals, specular, etc maps as well on top of that and I didn't get more than 500mb on the vram on an entire 40,000 unit x 40,000 unit level. I haven't done any specific tests on MC, but this is based on previous game experience.

There also shouldn't be a lot of overlay in the buffers because well they're solid box objects and there isnt a lot of transparency, especially with the fact that MC uses voxels and not polygons. So that shouldn't be taking up a ton of video memory either. I don't know about the chunk format, and that could be partially saved in video memory as well as ram, but the data within them for a normal view distance still shouldn't cause the whole thing to surpass 400mb of video memory.

And yes, I do know the difference between video memory and RAM. I wouldn't even be able to run BF3 on 1gb of ram as that is what I said I only have, but I was talking about video memory instead.

In the end though, if it does take more than 400mb of the vram (we already know MC can be a ram hog, but vram is a different story) that Mojang has some optimizations to do because it really shouldn't even get that high.

It shouldn't in this game. Theoretically most computers should be able to handle up to 1024x texture packs for a game like this without any issue at all. For example, my PC can do texture settings for Battlefield 3 on High without any FPS drops, and its 6-7 years old now. That uses almost 1GB of video memory, while MC shouldn't go above 400mb of video memory, hell, I'd even be inclined to say 200mb or 100mb, but I don't know how everything in MC is stored.

Usually in games, texture settings have minimal impact on performance so long as you have a decent amount of video memory. The only reason I cannot go to ultra on BF3 for textures is that you need 1.5gb of video memory and I only have 1.

There is something Mojang could do for textures, but it wouldn't make the game run much higher as it only increases loading times. Though, what I am about to say is more related related to engines like UDK, Cryengine, and Quake 3 Engine (ID Tech 3) and may not fully apply here as there is hardly the same amount of textures to be loaded. That is converting the PNG images to TGA. I have found, as well as other developers, that PNG reduces load times because it has to decompress the image twice, vs once. This is because the PNG is packaged usually inside a compressed file like a JAR or ZIP. It has to decompress one before decompressing the PNG for rendering. With TGA it only has to do the zip/jar decompression and with a TGA being in a compressed package, it compresses itself very well, almost to the point of a PNG. In terms of loading efficiency: TGA>JPG>PNG. In terms of quality: TGA>PNG>JPG at least in my tests. The only problem with TGA is that it does not automatically create an alpha channel. Though that can be considered as a good thing, as people are less likely to steal content from other texture packs as it requires a little bit of effort to create that alpha channel.

Idk, enough rambling. 😛

Just updated Geforce GFX drivers to the latest 314.09 release and updated Java to update 17 64-bit and still had the same performance drop switching between the two.

Edit: Just tried two completely different texture packs that were not my own. Switching between their different resolutions gave the same large performance drop while playing the same in 1.4.7 versions would result in normal FPS.

Edit 2: Seemed my MC was still on the pre-release when I told it to update. It seems to be fixed in the official 1.5 release. Feel free to close this!

Hmm, that's weird. Think it could be related to Java 7 update 7? Since java is at update 17 or so right now.

I also had two others test this with me as well. Their performance drops were as follows: 200 > 80... and 90>45. While theirs were still playable, they noticed those big drops as well. I'll ask them later to see what version of Java they could be on.

Edit: Just tested on the official 1.5 release as this was on the pre-release. Same result on my PC. I'll try updating Java next. Also tried turning off smooth lighting as I saw that some people noticed low FPS as a result, but no change in performance there.

Added zips of partial texture packs for testing.

Added two in-game screenshots of FPS. The only difference is adding the mycel_top image which changes the stitched terrain from 2048x2048 to 4096x2048. The FPS is currently limited by Dxtory to 30 because it likes to keep resetting that limit on me. However, the performance decrease is still large.

Sure they could, for one, you've got corner stairs the update when stairs are placed next to it to another shape or model. You also had plugins for bukkit which allow for editing signs. An entity doesn't have to be updated every tick (more or less a guess) like they have now, which is causing all of the lag. These should be set into some sort of new entity class that only updates when a player is within that chunk, or most preferably interacts with it via clicking or block update.

In addition to that, that small amount of entities still should not cause that much lag no matter what. There are plenty of other games which have higher entity counts on screen. We all know that minecraft is fairly unoptimized with its single core CPU usage and next to no GPU usage.

This is a room where the number of item frames causes lag

This is something I would like to see changed/fixed. Or having the smooth stone slabs created into an official (but uncraftable) block for the next releases as 43:7 and 44:7 so that such additions will no longer affect it.

This change also affected many other things than just worlds, but plugins like dynmap which a lot of servers use. While dynmap is upgradeable, as well as worlds, it really is a lot of effort for the Minecraft community to do so, when Mojang barely has to do anything to change this.

While I know these are entities, there has to be a way around it. There really isnt any point in having static items like paintings and item frames as an entity.

For example, we have signs, they have custom text on them, are less than 1/4th the size of a block, and break off instantly when the attaching block is destroyed (if on wall).

A small room such as this: http://i.imgur.com/HqWLB.jpg lags the entire area of the server, with very few item frames. With the 1.4.6 update adding 3D items, I have also noticed z-fighting within the item frames items suggesting the possibility of duplicate entities within the same location, but that is unconfirmed.

This does need to be fixed or changed, because it renders a lot of uses for the item frames useless. It nearly makes a particular part of the world unplayable.