Latest News Article

[Nose_Job_for_a_Cowboy]

Janx, on 20 November 2012 - 06:07 PM, said:

And to be clear, memory in computer parlance always means the Random Access Memory (RAM) installed on the machine and closely connected to the processors for execution of code and termporary holding of data.  Hard drives, USB drives are NOT Memory, though they are Random Access.  Sometimes the line can get blurred, with things like Virtual Memory or Virtual Disk  which is using storage or memory to act as the other.  Traditionally, Memory is fast, limited in size, and connected closely to the processor. Storage is slower, and much larger in size.  It's not impossible to design a machine that uses a hard-drive for memory, but the performance would suck.  Hence, the delineation in computer architecture.

Just wanted to clear it up ahead of time, that this part I understand. Obviously it will take longer to write-to/read-from a location on an HDD. For one, addressing a location on an HDD involves moving parts, a spinning disc, magnetic actuator arm etc. whereas electricity is practically instant. Then, of course, your hard drive will most likely be the farthest storage from your CPU, unless you're using a flash drive or something. Then again a flash drive may be faster, since it's solid-state storage, basically a really small SSD.

When it comes to the abstract aspect of computer science, I'm more or less clueless. I have very little experience with designing software, so it's difficult for me to think like a programmer. Everything I've posted up to this point is pure speculation, with some facts thrown in here and there. Like I said before, it will be quite some time before I know exactly what's going on inside a CPU while Minecraft is running.

Janx, on 20 November 2012 - 06:07 PM, said:

This all depends on how they modeled the data.

A block is going to be a class.  It will probably have properties for:
block type
facing (because some blocks do have a facing)

From there, the simplest data structure is a to define the map as being a 3d array (895,895,128)*

*technically, the game divides that map into chunks, so you only define and pay for map space the user has visited, regardless of other details of the model.

BlockType zero could be allocated as the "air" block, which means empty air really does take up space.  or they could have used NULL to mean an empty air block.  In the never-null model, the game size remains the same.  So if a block takes up 2 bytes to store, that's 2x895x895x128 blocks to store in RAM and on disk.

If they use nulls, it gets a bit more complicated.  in RAM, it still takes up the same space because they system allocates that space when the array is defined.  that's the point of an array.  When it gets saved, it is serialized to a flat file, and that's when the null cells don't take up any space.

Here's an alternative structure:
the block class would carry the BlockType and Facing, as well as X,Y,Z.  Instead using a 3d array of blocks, the blocks are stored in a 1d Collection of all the blocks.  The game then pulls out which block is where by the individual block.  Collections are expandable/shrinkable (unlike arrays).  This method would mean that fewer blocks means less memory consumed.  However, it would be much more CPU intensive to determine what blocks are in front of the player to display, than the 3d array model..

In any event, raising the sky limit means more potential blocks.  So in ANY model, that means consuming more memory.  Some models would be less efficient and make you pay for empty space, others might be more compact, but still, once people start filling this extra space, that'll take more memory.

Regarding the first model, I've thought about that. Just... in a less detailed and uninformed sort of way. So, if "air" was simply null data, it would still take up 2 bytes in RAM, it would just appear as [0000 0000 0000 0000], correct? I understand how that would still technically take up that space. But, I would think other blocks would use extra space for their special characteristics, things like chests, furnaces, redstone items, etc.

I'm not sure how much of an effect ANVIL will have on RAM usage, if any. All I know as of now is the optimization seems to be focused mostly on filesize reduction. I'm not 100% sure on that though, I still haven't looked into it too much. Either way, if you feel like posting more about this, I would be more than interested in reading it.

[PigMiner234]

How many GBs of storage does your Xbox carry? It would help to know that.

[Gishgeron]

My problem with this question, and its many replies, regards ANVIL.  I have not researched this in depth...but I assumed ANVIL was a programming improvement for PCMC that allowed it to make better use of memory.  Which means it was an improvement for the JAVA code, and how that code was delegating memory usage.  ANVIL would not be doing anything for the XBMC since the language is different.  In the very least WHAT it does would not be the same.  The reason PCMC needed those improvements was because Notch was simply not a professional programmer when he made MC.  He made mistakes, and had some sloppy code in parts.  4J is a team of experienced programmers that have had a good deal of experience working with C.

In short, a memory usage overhaul for our game would be a different animal entirely I'm guessing.  In fact, its probably not even really possible.  4J has very likely already done the best they can with the hardware specs that the xbox has.  The one thing ANVIL would have been great for is allowing the game to make use of, and better use of, resources the average user might have had on updated PC's.  You aren't getting hardware upgrades for an xbox.  Its completely set in stone.  A fact that lends weight to the ideal that 4J has most likely already done, or is doing, the best they can with that set up.

[DrAtomic1]

Dobasameen, on 19 November 2012 - 04:34 AM, said:

They said they would apply it on XBOX version in 1.2.3....

LINK to the news: http://www.oxm.co.uk...ail-on-the-way/

LINK to tweet: https://twitter.com/...028915922128898

Stop spreading false information, 4J said that they will probably move to the anvil format or at least PARTS of it. Translation: it may include the anvil format WITHOUT the height increase (or with it but nowhere in that tweet they said which way they'd go). The news article simply sums up the PC features that were anvil related.

[UpUp_Away95]

DrAtomic1, on 21 November 2012 - 01:14 PM, said:

Stop spreading false information, 4J said that they will probably move to the anvil format or at least PARTS of it. Translation: it may include the anvil format WITHOUT the height increase (or with it but nowhere in that tweet they said which way they'd go). The news article simply sums up the PC features that were anvil related.

Yes, the article goes on to sum up the PC features of ANVIL and obviously anticipates that the effects on the XBox game would be similar.  That could be erroneous.  However, 4J haven't said either that there would not be any height increase involved with the ANVIL conversion.  To me, the tweet means that they believe there would be benefits to the XBox game, making the switch worthwhile for them to do.  Those benefits may allow for a height increase and it may not.  I think that they have to get the format into the programming language used by the XBox and assess its effects on processing speed and RAM before they can make that decision.  I don't know much about the details of it, but I personally feel that there will be an improvement in how the game manages RAM that will allow for a height increase similar to what the PC got.  I think 4J are committed to getting as much of the PC game up to their 1.2.3 update onto the XBox.  I think that is what they were contracted to do from the outside and they are fulfilling that contract to the best of their ability.  ANVIL and the height increase came onto the PC with their update 1.2.1, so I think there is a very good chance we will get the height increase in some form.

Gishgeron, on 21 November 2012 - 05:38 AM, said:

My problem with this question, and its many replies, regards ANVIL.  I have not researched this in depth...but I assumed ANVIL was a programming improvement for PCMC that allowed it to make better use of memory.  Which means it was an improvement for the JAVA code, and how that code was delegating memory usage.  ANVIL would not be doing anything for the XBMC since the language is different.  In the very least WHAT it does would not be the same.  The reason PCMC needed those improvements was because Notch was simply not a professional programmer when he made MC.  He made mistakes, and had some sloppy code in parts.  4J is a team of experienced programmers that have had a good deal of experience working with C.

In short, a memory usage overhaul for our game would be a different animal entirely I'm guessing.  In fact, its probably not even really possible.  4J has very likely already done the best they can with the hardware specs that the xbox has.  The one thing ANVIL would have been great for is allowing the game to make use of, and better use of, resources the average user might have had on updated PC's.  You aren't getting hardware upgrades for an xbox.  Its completely set in stone.  A fact that lends weight to the ideal that 4J has most likely already done, or is doing, the best they can with that set up.

My problem is that 4J has said they will be implementing the ANVIL format or at least parts of it.  IF they saw no benefit to the XBox version in doing that, they wouldn't make the change at all.  Therefore, there must be some sort of benefit to the XBox version.

[DrAtomic1]

UpUp_Away95, on 21 November 2012 - 02:16 PM, said:

ANVIL and the height increase came onto the PC with their update 1.2.1, so I think there is a very good chance we will get the height increase in some form.

I agree, chances are we will get some height increase. But surely not 256, the render distance alone is far less then that. Personally I'm fine with the moved clouds and current height, but I can see some people wanting a little bit more for their castle/tower/fortress on top of mountains.

I reacted to someone posting that the height would be increased to 256 and used those sources which didn't say anything like it. Maybe that person just meant to say that Anvil was most likely coming but that is something entirely different as saying it is coming and here are sources confirming it.

[SnyderGuy]

Guys. I got an idea. Lets all get a twitter (or use your existing one) and go onto 4J's account. And SPAM a bunch of questions if height will be increased. Problem solved. If we each post about 100 tweets to them they are bound to reply.

[paspinall]

SnyderGuy, on 21 November 2012 - 02:54 PM, said:

Guys. I got an idea. Lets all get a twitter (or use your existing one) and go onto 4J's account. And SPAM a bunch of questions if height will be increased. Problem solved. If we each post about 100 tweets to them they are bound to reply.

Well sarcasm aside there's no need they said we would be getting the full ANVIL which includes the height increase.

[SnyderGuy]

paspinall, on 21 November 2012 - 02:58 PM, said:

Well sarcasm aside there's no need they said we would be getting the full ANVIL which includes the height increase.

Links? The closest thing to that which was forever ago was "We will not be getting bigger worlds due to limitations with RAM"

[UpUp_Away95]

DrAtomic1, on 21 November 2012 - 02:52 PM, said:

I agree, chances are we will get some height increase. But surely not 256, the render distance alone is far less then that.

... and how are you exactly coming to the conclusion that 256 is not possible?  IF 4J are not yet certain the effect ANVIL will have on RAM usage, how do YOU know this.  What are your sources that say this?  The render distance right now is sizably shorter than the world size, so why would it have anything to do with the outer boundary of the world height?

SnyderGuy, on 21 November 2012 - 03:03 PM, said:

Links? The closest thing to that which was forever ago was "We will not be getting bigger worlds due to limitations with RAM"

However, you're taking that quote out of the context of the questions about world size that were being asked at the time.  People wanted to know if there would be any world size increase including in the 1.8.2 update... not forever.  ANVIL was not scheduled to be put into the game in the 1.8.2 update.  The RAM limitations being referred to are relative to the McRegion format that would be still in use with the 1.8.2 update.  The application of ANVIL in the 1.2.3 MAY/POSSIBLY (i.e. not definite yet) free up enough RAM to increase the world height; but 4J hasn't said yet whether it will or it won't (probably because until they get it into the system and test it, they themselves won't know).

[DrAtomic1]

UpUp_Away95, on 21 November 2012 - 03:22 PM, said:

... and how are you exactly coming to the conclusion that 256 is not possible?  IF 4J are not yet certain the effect ANVIL will have on RAM usage, how do YOU know this.  What are your sources that say this?  The render distance right now is sizably shorter than the world size, so why would it have anything to do with the outer boundary of the world height?

I never said anywhere that 256 isnt possible. I said it's not logical given the render distance being 144-ish (less for split screen), which would then lead to people not seeing what they built (depending on their starting height), which in turn lead me to logically deduct that they wouldnt increase it to 256 but most likely somewhat to give people something. Anyway I'm just guessing like everyone else is doing, I merely entered this thred to point out that the guy that was saying or implying Anvil plus it's features was certain was spreading false information or misinterpreting information based on the quotes he provided as sources which turned out to say nothiing like Anvil being 100% sure let alone which features of it.

[UpUp_Away95]

DrAtomic1, on 21 November 2012 - 04:09 PM, said:

I never said anywhere that 256 isnt possible. I said it's not logical given the render distance being 144-ish (less for split screen), which would then lead to people not seeing what they built (depending on their starting height), which in turn lead me to logically deduct that they wouldnt increase it to 256 but most likely somewhat to give people something. Anyway I'm just guessing like everyone else is doing, I merely entered this thred to point out that the guy that was saying or implying Anvil plus it's features was certain was spreading false information or misinterpreting information based on the quotes he provided as sources which turned out to say nothiing like Anvil being 100% sure let alone which features of it.

OK, OK.  I stand corrected.  I still don't see how 256 up is any less logical than 864 (and people want infinitely more) laterally.  You can' t see everything you build on surface within the current render distance, so why should you have to be able to see everything you build upwards to the very top from the ground in order to validate the height being there?

[Nose_Job_for_a_Cowboy]

DrAtomic1, on 21 November 2012 - 04:09 PM, said:

I never said anywhere that 256 isnt possible. I said it's not logical given the render distance being 144-ish (less for split screen), which would then lead to people not seeing what they built (depending on their starting height), which in turn lead me to logically deduct that they wouldnt increase it to 256 but most likely somewhat to give people something. Anyway I'm just guessing like everyone else is doing, I merely entered this thred to point out that the guy that was saying or implying Anvil plus it's features was certain was spreading false information or misinterpreting information based on the quotes he provided as sources which turned out to say nothiing like Anvil being 100% sure let alone which features of it.

The render distance is not based on blocks, it's determined by chunks. And chunks are not bound vertically, until ANVIL is added, in which case the world is split into two layers of chunks. Ever notice how you can fly up and still see the ground until you're up to 300 - 350? (Not sure about that number, but I know it's higher than 144 meters.)

[electricblooz]

Nose_Job_For_a_Cowboy, on 21 November 2012 - 04:33 PM, said:

And chunks are not bound vertically, until ANVIL is added, in which case the world is split into two layers of chunks.

this is something I'd missed.  ANVIL creates 2 layers of chunks?  That alone defintely changes the calculus because the second layer will be (by and large, until people start building into it) only air (meaning the compression routines can gloss them).

[UpUp_Away95]

electricblooz, on 21 November 2012 - 05:32 PM, said:

this is something I'd missed.  ANVIL creates 2 layers of chunks?  That alone defintely changes the calculus because the second layer will be (by and large, until people start building into it) only air (meaning the compression routines can gloss them).

Not convinced that this is actually the case.  First, here's a couple of quotes from the Wiki:

"Packets for sending chunks have been optimized (a full 256-high chunk is smaller than the old format, and a chunk with lots of empty space is much smaller)."

then:

"Minecraft Snapshot 12w07a/b and 1.2 will automatically convert worlds to the new format, but a copy of the world files will be created in the previous formats for compatibility with older game versions. The world generator has not been changed, so there will be an additional 128 blocks of air above the usual terrain, making 192 blocks from sea level to the height limit."

http://www.minecraft...vil_file_format

It's not totally clear, but to me, this implies that the addition of a second layer of chunks only applied to those worlds generated before the ANVIL format was brought in; and that chunks in world's generated by the ANVIL format are the full 256 blocks high.

[Nose_Job_for_a_Cowboy]

electricblooz, on 21 November 2012 - 05:32 PM, said:

this is something I'd missed.  ANVIL creates 2 layers of chunks?  That alone defintely changes the calculus because the second layer will be (by and large, until people start building into it) only air (meaning the compression routines can gloss them).

vvvv

UpUp_Away95, on 21 November 2012 - 05:43 PM, said:

It's not totally clear, but to me, this implies that the addition of a second layer of chunks only applied to those worlds generated before the ANVIL format was brought in; and that chunks in world's generated by the ANVIL format are the full 256 blocks high.

This could be true. All I know is the research I saw in a YouTube video awhile back. They concluded that the top 128 meters of a chunk isn't even saved, nor technically loaded until a "real" block is placed within the volume of a top-chunk. This would mean a lot in terms of easing up on the hardware, and the plausibility we will in fact receive this raise on the height cap. I highly doubt anyone will build into the top half of every chunk on the map, unless for experimental purposes.

Keep in mind, I don't remember whether the uploader's world was pre-ANVIL or not. For all I know, he might not have even mentioned that detail. It has been some time since I've seen it and I have a terrible memory.