Every news outlet is citing a single Wallstreet Journal article, which relays a rumor from an unidentified source. No way to confirm any of it and it doesn't mean anything right now. Mojang has been offered buyouts before and they've always turned them down.
Also, if they are getting an offer, it's likely they won't be able to publicly disclose its details or "set the record straight" while negotiations are still underway, so don't expect to hear anything from any official source for a while.
That slashdot post sounds like complete ********. On top of Notch having always been strongly protective of indie development and in particular Mojang's autonomy, and on top of Mojang having been offered numerous buyouts over the years, we're still talking about the same guy who back in 2011 gave his employees a $120K Christmas bonus each out of his share of the company profit, which was effectively his entire share.
That doesn't sound like the sort of guy who would throw his own people under the bus for any amount of money.
Chances are Microsoft made a buyout offer, as they often do, and Mojang is going to turn it down, as they often do. If WSJ didn't say anything, it would have passed by completely unnoticed.
I'm thinking we maintain a 2D cache of all the interesting stuff that can happen in column pertaining to unbounded height objects. For sunlight, there would be the first block with a hitbox, the first block that interferes with the light beam (including leaves and water), and the first fully opaque block. For beacons in the column, it would be the height of the beacon, any colored glass in the path of the beam, and if present, the first block obstructing the beam.
There's other tricks you might use to accelerate identifying changes when blocks are added or removed, but for passively deciding what to render when you approach an area, that ought to be sufficient information.
With my proposed lighting model (which isn't a requirement for CC), you would also want to know roughly which blocks directly border any light beams, but that could be as simple as a bunch of 16-bit maps arranged vertically (A value of 0 would mean no obstructions in that column).
Someone experiencing the water problem, post a screen cap of what the shift-F3 pie chart looks like when it is happening under root.gameRenderer.level and root.gameRenderer.level.translucent.
If it's directly related to water, the translucent section should be disproportionately high while the lag is present, assuming the new threading isn't skewing the numbers. If that's not the case, the water itself might be a red herring for some other underlying process.
Finally got home, so now I can test stuff. Unfortunately, I'm part of the majority that doesn't have any performance issues. Java 7 and Java 8 ran about the same for me. Java 8 might be a little better, but the new occlusion culling is so twitchy it's hard to pin down an average framerate. I still had ~30 fps at around a 24 chunk draw distance.
I will say that one time the memory peaked once to 100% somehow and things got ugly, but as long as it stayed at 99% or lower I never spotted the GC in either version.
Another weird thing I just discovered is that I can't turn on AA. Even overriding the global settings via the nVidia control panel doesn't have any affect on the game. It definitely used to. The only thing I can think is it might have something to do with the launcher. Has anyone else messed with this?
If marching Minecraft into the modern age happens to alienate some Mac users, well I call that two birds with one stone.
But in seriousness, we already make tons of compromises to support ancient and underpowered hardware no other modern game would ever humor, and that is plenty of a pain in the ass on its own. If upgrading to Java 8 is merely an inconvenience, then I vote it's a necessary inconvenience.
Edit:
I don't see what's so hard about this. This link has all the runtime installers for 8u11. Best I can tell, installation of this is just a double-click on OS X. This link has several methods of configuring the default JRE version when multiple are present. That should be cake.
Back in my day, you had to build these libraries from tarballs, along with 6 other requisite libraries to fix the compile errors, and re-roll your kernel to enable experimental functionality to compile those (true story). Lost a lot of good men to the gcc...
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.
The best way to look at it is that any geometry which is drawn to screen must be transformed from world coordinates into screen coordinates by the GPU. The GPU can't tell if anything is in front of that polygon, or if the polygon is even on screen until after this transformation. However, that transformation is the most expensive part of the pipeline in vanilla Minecraft, so simply attempting to draw something will ding the fps.
The only way to avoid the draw costs is to programatically chose not to draw that geometry before the command reaches the GPU. Minecraft draws chunks in 16^3 grids. The old Advanced OpenGL would testfit 16^3 cubes against the previously drawn frame to decide which chunks to draw on the following frame. The new occlusion culling method relies on a graph search to eliminate drawing chunks which a camera ray is guaranteed to be unable to reach.
What you are describing with the interior face is a decision by the engine not to record interior polygons when the chunk is first loaded from storage. This saves GPU cycles every time the chunk is drawn, so it's a good idea, but this won't influence the decision of whether or not to draw the chunk either way.
I'm kind of interested in how their coordinate system works on a spherical planet. It should be theoretically impossible to deform a square mesh into a sphere without affecting connectivity.
Edit: checked the source. Haven't been able to figure it out. All the chunk interaction is 2D or 3D. The LOD stuff looks like it's entirely procedurally generated and doesn't reflect the 1:1 layer and isn't saved, though I could have missed something. Also of note, it looks like LOD blocks are made using the geometry shader to create rectangular prisms. You don't normally see that in blockworld games due to its inability to handle interior face culling. The 1:1 layer is meshed normally.
Also, to those suggesting using stuff from that game, it's written in C++11 and is fundamentally different from how Minecraft works. It wasn't built to accommodate the sheer amount of content and sophistication of Minecraft's procedural generation, and would likely not work particularly well if you tried to apply it to Minecraft. It's a promising start, but at this stage in the game, there's nothing worth taking away from it.
1
0
Got it, boss. You don't want us to copy mappings from MCP.
0
Sooner or later.
In other news, MCP 9.10 is out. I now predict a completely unexpected and coincidental windfall in object mappings coming soon. *wink wink*
2
Not to worry. I'm sure we can use this thread to keep you in the loop.
1
Also, if they are getting an offer, it's likely they won't be able to publicly disclose its details or "set the record straight" while negotiations are still underway, so don't expect to hear anything from any official source for a while.
0
That doesn't sound like the sort of guy who would throw his own people under the bus for any amount of money.
Chances are Microsoft made a buyout offer, as they often do, and Mojang is going to turn it down, as they often do. If WSJ didn't say anything, it would have passed by completely unnoticed.
1
Noooooo, muh lambdas...
3
There's other tricks you might use to accelerate identifying changes when blocks are added or removed, but for passively deciding what to render when you approach an area, that ought to be sufficient information.
With my proposed lighting model (which isn't a requirement for CC), you would also want to know roughly which blocks directly border any light beams, but that could be as simple as a bunch of 16-bit maps arranged vertically (A value of 0 would mean no obstructions in that column).
1
If it's directly related to water, the translucent section should be disproportionately high while the lag is present, assuming the new threading isn't skewing the numbers. If that's not the case, the water itself might be a red herring for some other underlying process.
1
I will say that one time the memory peaked once to 100% somehow and things got ugly, but as long as it stayed at 99% or lower I never spotted the GC in either version.
Another weird thing I just discovered is that I can't turn on AA. Even overriding the global settings via the nVidia control panel doesn't have any affect on the game. It definitely used to. The only thing I can think is it might have something to do with the launcher. Has anyone else messed with this?
0
But in seriousness, we already make tons of compromises to support ancient and underpowered hardware no other modern game would ever humor, and that is plenty of a pain in the ass on its own. If upgrading to Java 8 is merely an inconvenience, then I vote it's a necessary inconvenience.
Edit:
I don't see what's so hard about this. This link has all the runtime installers for 8u11. Best I can tell, installation of this is just a double-click on OS X. This link has several methods of configuring the default JRE version when multiple are present. That should be cake.
Back in my day, you had to build these libraries from tarballs, along with 6 other requisite libraries to fix the compile errors, and re-roll your kernel to enable experimental functionality to compile those (true story). Lost a lot of good men to the gcc...
1
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.
3
The only way to avoid the draw costs is to programatically chose not to draw that geometry before the command reaches the GPU. Minecraft draws chunks in 16^3 grids. The old Advanced OpenGL would testfit 16^3 cubes against the previously drawn frame to decide which chunks to draw on the following frame. The new occlusion culling method relies on a graph search to eliminate drawing chunks which a camera ray is guaranteed to be unable to reach.
What you are describing with the interior face is a decision by the engine not to record interior polygons when the chunk is first loaded from storage. This saves GPU cycles every time the chunk is drawn, so it's a good idea, but this won't influence the decision of whether or not to draw the chunk either way.
1
3
Edit: checked the source. Haven't been able to figure it out. All the chunk interaction is 2D or 3D. The LOD stuff looks like it's entirely procedurally generated and doesn't reflect the 1:1 layer and isn't saved, though I could have missed something. Also of note, it looks like LOD blocks are made using the geometry shader to create rectangular prisms. You don't normally see that in blockworld games due to its inability to handle interior face culling. The 1:1 layer is meshed normally.
Also, to those suggesting using stuff from that game, it's written in C++11 and is fundamentally different from how Minecraft works. It wasn't built to accommodate the sheer amount of content and sophistication of Minecraft's procedural generation, and would likely not work particularly well if you tried to apply it to Minecraft. It's a promising start, but at this stage in the game, there's nothing worth taking away from it.