• 0

    posted a message on SnapShot 14W33A - Iron Golem & Creeper
    Quote from LeslieGilliams

    THERE IS NOT ONE REASON FOR THIS aside from hostility from Mojang towards players.

    I'm almost certain this is not the reason.

    Mojang are removing automation and farms, they probably saw this as a middle ground for making iron-golem farms harder (Which it does if your Iron Golem farm is on the ground).
    Posted in: Recent Updates and Snapshots
  • 0

    posted a message on SnapShot 14W33A - Iron Golem & Creeper
    Quote from Nobody_1707

    The Oak and Iron doors are in fact two dimensional billboards, much like grass and flowers, and always have been. The new doors that were introduced in 32d were fully three dimensional models. When people complained that this was inconsistent (specifically that the old doors should be given 3D models too) Mojang decided to replace the new 3D doors with 2D ones.

    Hopefully Mojang did that simply because they didn't have time to implement replacement door models right away, but I doubt it.

    This is incorrect; in 3D graphics a billboard is aligned to the camera's view matrix, both the oak and iron doors align by the model view projection, it's the same deal with the grass and flowers, they are also not billboards.

    The grass and flowers are 2 quads with no backface culling (Although knowing Mojang, they're probably 4 quads with backface culling), the oak and iron doors are made up of a large number of quads.

    The grass, flowers and doors are technically game models, much like how the standard cube is it's own game model, but they are not "Minecraft" models, which are identified as entity models or .json constructed block models (As part of a texture pack).

    The new doors look more complex in design, I wouldn't be surprised if they are dedicated models now, the old block model look is terrible and pretty much everyone agrees.
    Posted in: Recent Updates and Snapshots
  • 0

    posted a message on 14w29b Stability and Performance Thread - Post information regarding performance with VBO and threaded chunk loading here
    You pretty much got it with the shifting of load from CPU to GPU.

    Advanced OpenGL won't change anything, it does a different (And old) technique for removing objects that aren't visible from being drawn.

    And I'd say your setup is very much CPU > GPU, you mentioned you consider it on par with 6870/6950, well the 6950 is a fair bit better than the 6870, I'd say your GPU is 6870 range and your CPU is a big leap above it, so your PC is weighted towards the CPU being held back by the GPU.

    Consider it a sign that you may need a new GPU, when you next build/buy a PC do a lot more research into complementary CPU and GPUs, a lot of people mistakenly pair parts that will choke each other (You said your CPU is common with your GPU, doesn't mean it's a good pair just means a lot of people don't understand the bottlenecks involved!).

    I'm at an advantage as I am a game engine programmer, so I know exactly what to look for in hardware, consumers tend to buy the fastest with the biggest numbers, the better move would be research the games you want to play, understand their engine and build a machine that compliments itself and the games you want to play (So my machine doesn't perform well with certain engines that favour CPU over GPU, yours would perform better).

    Make sure you also update your drivers to the latest version, for OpenGL 2.1 the VBOs is an extension, it's not part of the official OpenGL 2.1 specification, so you will need up to date drivers to be able to use it.

    Mojang probably won't make changes to support everyone, they would have to do tricks depending on machine setups which is costly and annoying, an example would be in addition to Advanced OpenGL for you (As you have NVidia), the engine would be better if it spent more time on the CPU removing stuff from drawing and preparing a good frame for rendering and then drawing the VBOs at the very end.

    There is also an optimisation that Mojang are missing out on still with texture switches, currently they draw based on chunk (Next snapshot they will draw based on chunk order) but they really need to sort on the CPU based on chunk and then draw based on texture, which would minimise GPU activity and focus on CPU activity.

    Those kind of small things they need to do, but it's likely that they'll add them and just have them as buttons to press in the options screen as different people will have different performance results.
    Posted in: Recent Updates and Snapshots
  • 3

    posted a message on [14w29b] "Multiplayer Reduced Debug Info" option
    The debugging features entirely are built for devs and not consumers, so really you shouldn't be opening it at all unless you are developing something :D

    The reduced features debug screen looks to be useful for debugging rendering and objects in memory, so handy for testing VBOs and threading (Two features that are now in 14w29b!).

    This is one of the fails of the current debug system, it should be made available only with a cheat and replaced with items that exist in the actual game world, like an item that will fill up like a thermometer to show what Y level you're at or have a second blip on the compass that shows NWSE or an item that will make a particular compass that points to a specific world coordinate.

    These changes are quite dangerous though as sadly too many users depends on the debug screen for general gameplay.
    Posted in: Future Updates
  • 0

    posted a message on 14w29b Stability and Performance Thread - Post information regarding performance with VBO and threaded chunk loading here
    Quote from Princess_Garnet

    Unfortunately, performance is down, and this VBO feature seems to bring it down more. I'm not sure if it's meant to help lower end hardware instead, but the laptop above lost performance with VBO too, it seems. I'll have to try and remember to give this all a go on my laptop. So far, though, it seems like this is another feature I'll toss aside like I did with mip-maps (the worse part of doing this was having to look at how Minecraft looks with that feature on).

    VBOs (Vertex Buffer Objects) is a feature where the benefits are felt if the CPU isn't very good but the GPU is good, it moves the vertex geometry creation from the fixed-function CPU draw call method to an object in the GPU memory.
    Ideally, this should boost performance on machines that have an optimal setup (GPU compliments CPU), if you're in the case where the CPU is powerful but the GPU is slow then VBOs won't help at all, it will bottleneck the system.

    VBOs are the better way to handle 3D graphics in games and it's how all modern games do it, if you have a performance drop it's an indication that your computer is being bottlenecked by your GPU (And that Minecraft still has some poor rendering engine design choices).


    As a comparison, I have an Intel i5-2400 at 3.3GHz and an AMD 6970HD 2GB, my CPU is worse than yours but my GPU is better, so VBOs for me give me a tiny performance boost (Indication that my CPU and GPU compliment each other quite well, which is exactly how I built my machine to be).

    If I had a good GPU but a bad CPU, then VBOs could give a massive performance boost.

    The reason is;
    The original fixed-function rendering used function calls from the CPU to start telling the GPU to prepare vertices for drawing 3D objects, the GPU would be told by the CPU "I'm about to give you vertex data" and then the CPU will give the GPU data while the GPU does other stuff, then when it's finished the CPU says "I'm done now" and then there is a big delay while the GPU finishes what it was doing while you were giving it vertex data before it goes "Okay I am ready to draw that now" and then it draws it, if your CPU is fast then the overhead of talking to the GPU would be lower.

    The new VBO method is so much better, the CPU says "Here are vertices for a cube, remember that" at the very start of the program, this is stored on the GPU video memory itself, the CPU can now say "Draw whatever the current VBO is" and the GPU will take whatever the bound VBO is and just draw it, no need to wait for draw lists to be completed. The CPU can tell the GPU to switch current VBOs within the GPU memory in 1 call and then draw the current VBO in 1 call, before it was something like 36 * 3 + 2 calls to the GPU to draw a cube.

    So you can identify the bottlenecks; GPU memory needs to be fast, GPU bandwidth needs to be fast, CPU can be any speed but if it is faster than the GPU then the CPU and GPU will have to hold and wait for each other before a VBO can be drawn, that's the bottleneck you are suffering with.

    Mojang can actually solve this on their end, they can hold the VBO in GPU memory, do lots of CPU operations, then right at the end of the update loop call the VBO draw, this means that the CPU isn't going to wait for the GPU to complete as it would have no jobs to do and the GPU has time to draw to the backbuffer while the frame is being flipped and prepared during the CPU's time updating the world. (This works weirdly because OpenGL's system will only lock and wait when the incoming commands conflict with the current commands, so you can say "draw this, then flip" and GL will happily do that while you use the CPU to do stuff, but if you said "Draw this, I'm going to do this here, then flip" GL will delay before flipping and drawing).
    Posted in: Recent Updates and Snapshots
  • 0

    posted a message on 14w29b problem
    Ah don't worry looks like I was mistaken, the Advanced OpenGL option exists only for NVidia GPU users now, for everyone who isn't using NVidia the Advanced OpenGL option actually slows down the game.

    But don't worry, there will be more optimisations in the future, Minecraft has a good 11 years of 3D graphics optimisations to catch up on.
    Posted in: Recent Updates and Snapshots
  • 0

    posted a message on New slimmer arms model being tested
    The latter, which is how capes and secondary layer toggling works.
    Posted in: Future Updates
  • 0

    posted a message on [14w29b] "Multiplayer Reduced Debug Info" option
    C is the number of blocks that are being rendered over the number of blocks in memory.

    F is the number of blocks outside of the view frustum.

    O is the number of blocks that are occluded by other blocks (Covered up, not visible).

    Add up the numbers and it should equal the number of blocks in memory.

    P are the number of particles that are live on the client

    T I don't know!

    All Number of entities in the world

    MultiplayerChunkCache is the number of chunks loaded on your client, compared to the number on the server


    The purpose is that showing co-ords and facing is sort of cheating, so this is the first step in finding a replacement for the old system.
    Posted in: Future Updates
  • 0

    posted a message on "Failed to create game" message coming up repeatedly
    This is a problem due to Minecraft's age rating, the subaccount that your son uses has an age restriction applied to it, this is to keep them safe with online play and because anyone can enter an online Minecraft world and use the chat it's safer to restrict access to online until they are within the age rating for the game.

    This is also designed to protect against strangers on the friend-list, so even if your world is private your child could still invite a stranger into it where they can chat.



    Two solutions;
    A - Not use his subaccount and only login with a full account that has no age restrictions
    B - Wait until he is old enough for his account to be within the age rating for the game
    Posted in: Discussion
  • 0

    posted a message on 14w29b problem
    Quote from Badprenup
    Yeah I misspoke there. I meant to ask if he supported a newer version of OpenGL

    Well because VBOs on 2.1 are an ARB extension, it doesn't matter what version of OpenGL he has, it's down to his graphics card and graphics card driver if VBOs are supported or not.

    The best advice is make sure your video drivers are up-to-date, if that doesn't help then sorry your GPU doesn't support the extension.
    Posted in: Recent Updates and Snapshots
  • 0

    posted a message on 14w29b Stability and Performance Thread - Post information regarding performance with VBO and threaded chunk loading here
    Quote from Ubbens

    Operating System: Mac OSX 10.9.4
    Java Version: Java 7 (Update 65)
    Processor Model and speed: 1.8 GHz Intel Core i5, Ivy Bridge
    Graphics Card: Intel HD Graphics 4000
    RAM: 8GB (I think 1015MB is currently allocated)

    Oh this is interesting, I forgot about Intel's terrible HD Graphics chips; they have a unique scenario where the GPU memory is shared with the system memory, so VBO's (Which are stored on GPU memory) would not gain any performance in terms of GPU memory clock and bandwidth gains, it's weird that it loses performance (Suggests that Intel have a stupid compatibility software mode for OpenGL 2.1 extensions).

    That 1.8GHz clock wouldn't help either as the GPU calls and CPU calls are on the same clock, there would be a bottleneck where on a dedicated GPU there wouldn't be one.


    The problem with "block updates" are infact not a problem with "block updates", it's a problem of the rendering threads needing to meet with the world thread and agreeing on the block state, if this meetup is not met in-time then it will have to wait for the next world update to potentially correct it, block update problems are where updates are lost entirely or sporadically occur.
    (So in a sense, the block DID update, but Minecraft wasn't told quickly enough that the graphics need refreshing).
    Posted in: Recent Updates and Snapshots
  • 0

    posted a message on 14w29b Stability and Performance Thread - Post information regarding performance with VBO and threaded chunk loading here
    If you're going to do this, provide a seed and tell everyone to set graphics to max with default texture pack, on a flat-world you'll get a bigger difference with vertex buffer objects than on a survival world.
    Posted in: Recent Updates and Snapshots
  • 0

    posted a message on 14w29b problem
    Quote from Badprenup

    Do you support OpenGL? To my knowledge VBO is an OpenGL feature.

    Well considering Minecraft is 100% built with OpenGL it's safe to assume that he does support OpenGL otherwise he wouldn't be here.

    Minecraft supports an old version of OpenGL, 2.1, where VBOs is an extension by the ARB committee that is optional for OpenGL 2.1 graphics cards to support (ARB extensions tend to get added into future OpenGL versions, so OpenGL 3.0 infact supports VBOs natively).

    You must be running an old GPU that does not have this ARB extension, which means no VBOs for you, which is a shame as it does boost performance for everyone (At the expense of a tiny bit of GPU memory).

    If you want to know more about VBOs just ask me in this thread and I can explain further (I'm currently uploading a boring video that explains Minecraft threading and VBOs in this new snapshot).

    EDIT: I see you edited to change to "Advance" OpenGL, the Advance OpenGL option has actually been removed as it relied on a lot of extensions and caused more problems than it solved, this new VBO setting has essentially replaced the old Advanced OpenGL setting, and future settings with further replace it.
    Posted in: Recent Updates and Snapshots
  • 1

    posted a message on New slimmer arms model being tested
    Quote from Knochenbowser
    I honestly don't think this is really necessary or even making new possibilities. All it does is change the players appearance, it doesn't affect skinners in any way, it just removes a few pixels from the front view.

    The original intention of every model in the game was to be genderless, this is not really following that intention, but whatever floats their boat.

    Dang I haven't posted here for a very long time. Hello everyone who remembers my ugly avatar and name!

    The benefits of this towards female skins was only my opinion, thinner arms could make better skins for any gender.

    Minecraft is supposed to be genderless but that doesn't extend to the player which defaults as Steve.
    Posted in: Future Updates
  • 0

    posted a message on New slimmer arms model being tested
    Quote from Xannot
    Does he want to change default Steve's texture? All of the comparison shots on twitted image show a player with the same skin, except the one with Steve.

    No this wouldn't happen, the Steve has too much iconography around it.
    He was probably trying to show that a male texture can look softer with thinner arms, the Steve skin is rather beefy and manly to begin with.
    Posted in: Future Updates
  • To post a comment, please .