It's a pretty commonly known fact that the PC Anvil update caused more problems for people perfomance wise than it did help. Yes they fixed some memory leak problems, but it didnt help the people who's games already had perfomance problems before the update whatsoever. It generally only fixed things for people who had $1000 gaming rigs who complained of performance issues when a pc like that shouldnt be having said issues.
Truth is we could go back and forth all day we are comparing to diffrent platforms, with two diffrent coding languages. We can only speculate at this point. 4J maybe able to optimize it even better given this fact. They already are doing wonders given how smoothly Minecraft runs on 10 year old hardware. I don't think it's outside the realm of possibility to think they can get this to work also.
I disagree. I think air's transparency is it's texture and the ability to walk through it represents it's collision data. Air is not the null state of the system, the void is.
I think it's safe to say there's air in the void. Everything I've read states that air is simply the absence of a block. Nothingness in a would-be block's location. Transparency is just the lack of an opaque texture.
As a block, air doesn't exist. It has an ID, but that's only for the chunk information to know where "air" is to be located.
The reason it runs so smoothly is because they've nerfed the world size though. The game would run a hell of a lot faster on many peoples PC's if the world was the same size as the XBLA one. This is why I don't hold much hope for a world size increase.
They nerfed world size to keep all chunks partially loaded. Which was probably for smoother split-screen gameplay where a player can drop in without a loading screen. PC version completely unloads chunks after you travel 18 chunks away. That's why they have ridiculously large worlds, which are just as strenuous on hardware as a world of MCXBLA's size. If they had the same chunk loading mechanics, you would have to have a PC 32,000 times more powerful than the 360, just to play Minecraft.
I think it's safe to say there's air in the void. Everything I've read states that air is simply the absence of a block. Nothingness in a would-be block's location. Transparency is just the lack of an opaque texture.
As a block, air doesn't exist. It has an ID, but that's only for the chunk information to know where "air" is to be located.
Doesn't there have to be something there for it to have a "location"? I just don't think it's completely null. There is an interaction between air and bedrock fog, which has particles that float in it. I'm not saying it's as much information as the other blocks, just that there is some sort of information there. I think I'm going to run some further tests on the file size. I'm going to start a superflat world with no villages in it, explore it by flying over it and filling in the whole square, checking the file size at that point. Then, I'm going to start to fill it with, say, only wood blocks. I'll let you know how much the file size increases as I get each layer full. Should eventually give us some sort of ratio - air vs. a solid block. It will take me some time though.
They nerfed world size to keep all chunks partially loaded. Which was probably for smoother split-screen gameplay where a player can drop in without a loading screen. PC version completely unloads chunks after you travel 18 chunks away. That's why they have ridiculously large worlds, which are just as strenuous on hardware as a world of MCXBLA's size. If they had the same chunk loading mechanics, you would have to have a PC 32,000 times more powerful than the 360, just to play Minecraft.
I think this difference is what also gives us the ability/option to turn autosave off. My understanding is that the PC version does not allow autosave to be turned off or adjusted.
Doesn't there have to be something there for it to have a "location"? I just don't think it's completely null. There is an interaction between air and bedrock fog, which has particles that float in it. I'm not saying it's as much information as the other blocks, just that there is some sort of information there. I think I'm going to run some further tests on the file size. I'm going to start a superflat world with no villages in it, explore it by flying over it and filling in the whole square, checking the file size at that point. Then, I'm going to start to fill it with, say, only wood blocks. I'll let you know how much the file size increases as I get each layer full. Should eventually give us some sort of ratio - air vs. a solid block. It will take me some time though.
Well, maybe "null" wasn't the best word to use earlier. I think there is indeed information for air, but it's more of a (I guess you could say universal) statement for: "There is nothing in this location" The way I'm seeing it, there is still data used to tell the chunk where this "nothing" should be when the chunk is loaded. So, I guess there is data for "air", in a way, but it doesn't really compare to the necessary information of a "real" block.
I'm kind of contradicting myself at this point, but that tends to be a large part of education for me. To be honest, I don't know Java well enough to understand it in low-level terms. Even then, I don't know programming in general well enough to understand something as complex as Minecraft. I'm going to continue to look into it though. In 20 - 30 years I may be able to understand exactly what the hardware is doing, in every aspect, while Minecraft is running.
Well, maybe "null" wasn't the best word to use earlier. I think there is indeed information for air, but it's more of a (I guess you could say universal) statement for: "There is nothing in this location" The way I'm seeing it, there is still data used to tell the chunk where this "nothing" should be when the chunk is loaded. So, I guess there is data for "air", in a way, but it doesn't really compare to the necessary information of a "real" block.
I'm kind of contradicting myself at this point, but that tends to be a large part of education for me. To be honest, I don't know Java well enough to understand it in low-level terms. Even then, I don't know programming in general well enough to understand something as complex as Minecraft. I'm going to continue to look into it though. In 20 - 30 years I may be able to understand exactly what the hardware is doing, in every aspect, while Minecraft is running.
Could another fly in the ointment may also just be the fact that the XBox version is not in Java? I don't personally know much about any programming languages, so you're world's ahead of me. I have to rely on snippets of theoretical conversations over the dinner table whenever we do manage to get together as an extended family.
Another thought on "air" being nothing... as graphical color information goes, wouldn't no information be arbitrarily "blackness" rather than transparency?
Could another fly in the ointment may also just be the fact that the XBox version is not in Java? I don't personally know much about any programming languages, so you're world's ahead of me. I have to rely on snippets of theoretical conversations over the dinner table whenever we do manage to get together as an extended family.
Another thought on "air" being nothing... as graphical color information goes, wouldn't no information be arbitrarily "blackness" rather than transparency?
The language doesn't really matter too much. The point of high-level languages (like Java or C++) is to make it easier and more time efficient to write a program. At the end of the day, a compiler converts these to roughly the same program, but represented in machine code, which is low-level and the only thing a CPU can actually read. Different programming languages have pros and cons compared to others, but they all serve the same purpose.
As for color, that's true, as far the light spectrum goes. I'm not exactly sure how it would work in a 3D realm though.
The language doesn't really matter too much. The point of high-level languages (like Java or C++) is to make it easier and more time efficient to write a program. At the end of the day, a compiler converts these to roughly the same program, but represented in machine code, which is low-level and the only thing a CPU can actually read. Different programming languages have pros and cons compared to others, but they all serve the same purpose.
As for color, that's true, as far the light spectrum goes. I'm not exactly sure how it would work in a 3D realm though.
Thanks for the run down on computer languages. Interesting stuff. I'll try to remember to ask "the kids" about color vs. transparency in a 3D realm whenever we get together next time.
Well, maybe "null" wasn't the best word to use earlier. I think there is indeed information for air, but it's more of a (I guess you could say universal) statement for: "There is nothing in this location" The way I'm seeing it, there is still data used to tell the chunk where this "nothing" should be when the chunk is loaded. So, I guess there is data for "air", in a way, but it doesn't really compare to the necessary information of a "real" block.
I'm kind of contradicting myself at this point, but that tends to be a large part of education for me. To be honest, I don't know Java well enough to understand it in low-level terms. Even then, I don't know programming in general well enough to understand something as complex as Minecraft. I'm going to continue to look into it though. In 20 - 30 years I may be able to understand exactly what the hardware is doing, in every aspect, while Minecraft is running.
Sorry I left the thread last night - got the kids to bed and then Mommy and Daddy got some adult conversation time (get your minds out of the gutter )
Anyway, this is pretty much where I was trying to end up. (so "wholeheartedly disgree" was also not the best word). I can't point to specific source because my thoughts on the matter come from a single comment here and there, etc. coupled with what I know of db compression tech. I agree that tracking "air" blocks in the world db must take up less "memory" then other kinds of blocks. The easiest way to prove this is to compare the size of a fully explored regular world to a fully explored superflat. Without even doing such, based on Nosejob's other work I can guarantee you'll find superflats are much "smaller" save files which means the amount of data the system must manage in working memory must be smaller too.
At the same time, air blocks cannot be "nulls" in the world db in the same sense of "no memory address that these coordinates." (Which is what I was trying to imply (abeit poorly) with my "block is a block is a block" statement. Because, through the advent of duping, creative or generators, any air block might be transformed into a block of another type. Thus, the world db must have an entry for every block within it, even if some entries compress better than others.
Which leads me to the point I was actually trying to make.
ANVIL does not add compression to the worlddb management and loading systems, it merely optimizes it. We know this because world save files are different sizes. Right now, all MCXBLA worlds are exactly the same size (895x895x128), yet even fully explored worlds have different save files sizes. Functionally, it doesn't really matter whether non-air blocks take up "more memory" or whether air blocks "compress-better;" the net result is the same either way.
But, here's the key. We don't know how close the current system (McRegion) is to exceeding the capabilites of the xBox for our given world size and we also don't know how much more it would add to our world size to double the number of blocks within it by doubling the height (because we don't know the proportional memory cost of air to non-air).
In short we have a problem with two unknowns. 1. the ratio of available memory after all necessary processes to available memory after processes plus world db. 2. the additional gain in world db compression due to the ANVIL changes.
So, I think we've ended up in the same place. It's certainly possble we'll be getting the world height change. If we presume that our world size is as big as it possibly could be, then the answer to that question falls squarely into the realm of "Does the change to ANVIL provide enough of a boost in world db optimization to offset the unknown increase in system demands created by doubling the number of potential blocks in a world."
I say yes, as Anvil is more memory friendly, something to do with how the chunks are handled.
From wiki.
Empty sections of the world are not loaded into memory or saved to disk.
Block ordering has been changed from XZY to YZX in order to improve compression.
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).
So all in all, that means better memory management will be possible & online play should be faster for clients (not host) at rendering terrain.
I honestly think the the height limit will not be increased. Instead i think there going to do a few more major updates, then when the Xbox 720 comes out their going to make a seperate version which will open up a ton of possibilities. I hope anyways :/
But then again maybe ANVIL will help? Iv read over some docs when i was messing with pc version. It sounds promising.
I honestly think the the height limit will not be increased. Instead i think there going to do a few more major updates, then when the Xbox 720 comes out their going to make a seperate version which will open up a ton of possibilities. I hope anyways :/
But then again maybe ANVIL will help? Iv read over some docs when i was messing with pc version. It sounds promising.
Since ANVIL was added to the PC and the build height was increased in their 1.2.1 update, I think there is a possibility that the advent of ANVIL being added with the 1.2.3 update on the XBox and increaisng the build height is something that was likely taken into consideration when the deal porting the game onto the XBox was first agreed upon among Mojang, 4J, and Microsoft. That is, I believe that they believed from the beginning that they can squeeze this feature onto the XBox with a world that is sized laterally as it is (abt. 1026 x 1026 blocks, including nether). For that reason, I think that, unless they find now that they simply don't have the room they anticipated they would, the new build height will come into effect with the 1.2.3 update.
I think it's safe to say there's air in the void. Everything I've read states that air is simply the absence of a block. Nothingness in a would-be block's location. Transparency is just the lack of an opaque texture.
As a block, air doesn't exist. It has an ID, but that's only for the chunk information to know where "air" is to be located.
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.
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.
Man you guys crack me up. All this tech stuff about height raising and possibly world size increases. Things are going to work out. We are going to get increased height and YES we are going to get bigger worlds. I dont know when, but its going to happen. I do enjoy reading some of this stuff. As a guy who actually has a degree in computers I love seeing how pretty darn smart some people on here are. I still think everything is going to work out though.
Man you guys crack me up. All this tech stuff about height raising and possibly world size increases. Things are going to work out. We are going to get increased height and YES we are going to get bigger worlds. I dont know when, but its going to happen. I do enjoy reading some of this stuff. As a guy who actually has a degree in computers I love seeing how pretty darn smart some people on here are. I still think everything is going to work out though.
Always happy to help make someone smile. I agree, some of these young whipper snappers are pretty darned smart... and it's a pleasure asking them questions on this sort of stuff even when a lot of it goes right over my head.
Janx - Does this mean I don't have to actually undertake filling in layers on a superflat world? (lol) I'd probably rather spend my Minecraft time looking for my lost spelunking animals (even though that might be an equally useless endeavor)
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.
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.
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.
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.
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.
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.
Rollback Post to RevisionRollBack
Religion, has actually convinced people, that there's an invisible man, living in the sky, who watches everything you do every minute of the day, and the invisible man has a special list. Of 10 things he doesn't want you to do. And if you do ANY of these ten things he has a special place, full of fire, and smoke, and burning, and torture, and will send you there to suffer and choke and scream for all of eternity... But he still loves you.
To post a comment, please login or register a new account.
Truth is we could go back and forth all day we are comparing to diffrent platforms, with two diffrent coding languages. We can only speculate at this point. 4J maybe able to optimize it even better given this fact. They already are doing wonders given how smoothly Minecraft runs on 10 year old hardware. I don't think it's outside the realm of possibility to think they can get this to work also.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffI think it's safe to say there's air in the void. Everything I've read states that air is simply the absence of a block. Nothingness in a would-be block's location. Transparency is just the lack of an opaque texture.
As a block, air doesn't exist. It has an ID, but that's only for the chunk information to know where "air" is to be located.
Have a look for yourself:
http://code.google.com/p/minerpg/source/browse/trunk/src/Block.java?r=16
-
View User Profile
-
View Posts
-
Send Message
Retired StaffThey nerfed world size to keep all chunks partially loaded. Which was probably for smoother split-screen gameplay where a player can drop in without a loading screen. PC version completely unloads chunks after you travel 18 chunks away. That's why they have ridiculously large worlds, which are just as strenuous on hardware as a world of MCXBLA's size. If they had the same chunk loading mechanics, you would have to have a PC 32,000 times more powerful than the 360, just to play Minecraft.
Doesn't there have to be something there for it to have a "location"? I just don't think it's completely null. There is an interaction between air and bedrock fog, which has particles that float in it. I'm not saying it's as much information as the other blocks, just that there is some sort of information there. I think I'm going to run some further tests on the file size. I'm going to start a superflat world with no villages in it, explore it by flying over it and filling in the whole square, checking the file size at that point. Then, I'm going to start to fill it with, say, only wood blocks. I'll let you know how much the file size increases as I get each layer full. Should eventually give us some sort of ratio - air vs. a solid block. It will take me some time though.
I think this difference is what also gives us the ability/option to turn autosave off. My understanding is that the PC version does not allow autosave to be turned off or adjusted.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffWell, maybe "null" wasn't the best word to use earlier. I think there is indeed information for air, but it's more of a (I guess you could say universal) statement for: "There is nothing in this location" The way I'm seeing it, there is still data used to tell the chunk where this "nothing" should be when the chunk is loaded. So, I guess there is data for "air", in a way, but it doesn't really compare to the necessary information of a "real" block.
I'm kind of contradicting myself at this point, but that tends to be a large part of education for me. To be honest, I don't know Java well enough to understand it in low-level terms. Even then, I don't know programming in general well enough to understand something as complex as Minecraft. I'm going to continue to look into it though. In 20 - 30 years I may be able to understand exactly what the hardware is doing, in every aspect, while Minecraft is running.
Could another fly in the ointment may also just be the fact that the XBox version is not in Java? I don't personally know much about any programming languages, so you're world's ahead of me. I have to rely on snippets of theoretical conversations over the dinner table whenever we do manage to get together as an extended family.
Another thought on "air" being nothing... as graphical color information goes, wouldn't no information be arbitrarily "blackness" rather than transparency?
-
View User Profile
-
View Posts
-
Send Message
Retired StaffThe language doesn't really matter too much. The point of high-level languages (like Java or C++) is to make it easier and more time efficient to write a program. At the end of the day, a compiler converts these to roughly the same program, but represented in machine code, which is low-level and the only thing a CPU can actually read. Different programming languages have pros and cons compared to others, but they all serve the same purpose.
As for color, that's true, as far the light spectrum goes. I'm not exactly sure how it would work in a 3D realm though.
Thanks for the run down on computer languages. Interesting stuff. I'll try to remember to ask "the kids" about color vs. transparency in a 3D realm whenever we get together next time.
Sorry I left the thread last night - got the kids to bed and then Mommy and Daddy got some adult conversation time (get your minds out of the gutter
Anyway, this is pretty much where I was trying to end up. (so "wholeheartedly disgree" was also not the best word). I can't point to specific source because my thoughts on the matter come from a single comment here and there, etc. coupled with what I know of db compression tech. I agree that tracking "air" blocks in the world db must take up less "memory" then other kinds of blocks. The easiest way to prove this is to compare the size of a fully explored regular world to a fully explored superflat. Without even doing such, based on Nosejob's other work I can guarantee you'll find superflats are much "smaller" save files which means the amount of data the system must manage in working memory must be smaller too.
At the same time, air blocks cannot be "nulls" in the world db in the same sense of "no memory address that these coordinates." (Which is what I was trying to imply (abeit poorly) with my "block is a block is a block" statement. Because, through the advent of duping, creative or generators, any air block might be transformed into a block of another type. Thus, the world db must have an entry for every block within it, even if some entries compress better than others.
Which leads me to the point I was actually trying to make.
ANVIL does not add compression to the worlddb management and loading systems, it merely optimizes it. We know this because world save files are different sizes. Right now, all MCXBLA worlds are exactly the same size (895x895x128), yet even fully explored worlds have different save files sizes. Functionally, it doesn't really matter whether non-air blocks take up "more memory" or whether air blocks "compress-better;" the net result is the same either way.
But, here's the key. We don't know how close the current system (McRegion) is to exceeding the capabilites of the xBox for our given world size and we also don't know how much more it would add to our world size to double the number of blocks within it by doubling the height (because we don't know the proportional memory cost of air to non-air).
In short we have a problem with two unknowns. 1. the ratio of available memory after all necessary processes to available memory after processes plus world db. 2. the additional gain in world db compression due to the ANVIL changes.
So, I think we've ended up in the same place. It's certainly possble we'll be getting the world height change. If we presume that our world size is as big as it possibly could be, then the answer to that question falls squarely into the realm of "Does the change to ANVIL provide enough of a boost in world db optimization to offset the unknown increase in system demands created by doubling the number of potential blocks in a world."
From wiki.
So all in all, that means better memory management will be possible & online play should be faster for clients (not host) at rendering terrain.
But then again maybe ANVIL will help? Iv read over some docs when i was messing with pc version. It sounds promising.
Since ANVIL was added to the PC and the build height was increased in their 1.2.1 update, I think there is a possibility that the advent of ANVIL being added with the 1.2.3 update on the XBox and increaisng the build height is something that was likely taken into consideration when the deal porting the game onto the XBox was first agreed upon among Mojang, 4J, and Microsoft. That is, I believe that they believed from the beginning that they can squeeze this feature onto the XBox with a world that is sized laterally as it is (abt. 1026 x 1026 blocks, including nether). For that reason, I think that, unless they find now that they simply don't have the room they anticipated they would, the new build height will come into effect with the 1.2.3 update.
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.
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.
Always happy to help make someone smile.
Janx - Does this mean I don't have to actually undertake filling in layers on a superflat world? (lol) I'd probably rather spend my Minecraft time looking for my lost spelunking animals (even though that might be an equally useless endeavor)
-
View User Profile
-
View Posts
-
Send Message
Retired StaffJust 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.
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.
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.
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.
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.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium