Minecraft Forums

Quote from Princess_Garnet»

I was waiting to hear the opinions and reasons of someone who played Bedrock to do more than add another reply saying "Java" and then you didn't even say Bedrock, haha.

I wonder what the increased rail speed was for.

The first two can be achieved on Java (and maybe Bedrock on PC?) but it may require some care. You just delete the associated folder in the save file holding those dimensions.

The limited world size as well as the next few you mention was because the consoles of the time were simply too limited (same reason Bedrock has a lot of "does less things than Java" these days too).

As an explorer, I'd dislike finite worlds (especially of incredibly tiny sizes like that) or finite resources. I mean they're technically finite even with the world sizes we have now but they're practically infinite given how large they are. Interestingly, a few of the things you mentioned liking (blazes dropping glowstone and nether warts being out in the nether) seem like they were specifically to counteract the limited world size and finite resources, so you say you like finite resources but then say you liked some of the things turning finite resources renewable. I'd definitely dislike markedly smaller biomes. It would also force too many things to need to be way common and close together. I've seen images of multiple woodland mansions on older console versions and that's seems silly. All in all, for someone who wants to stick to a world very long term and build it way up over time and explore a lot, that all sounds bad.

Looking up TU22 for the Xbox 360, it seems this was based on Java 1.6, so terrain generation shouldn't have changed with it (?), but I'm aware the console versions mixed and matched a bit. It doesn't mention anything about a change though. The only terrain generation change that happened around then on the Java side was the following 1.7 so I'm presuming this is what you're referring to (though it wasn't until TU25 that things were based on 1.7 so I'm not sure). In either case, that terrain generation change had mixed reception. The aggressive climate zoning led to repetitive regions (the massive amount of new biomes it brought was the good part), but beta 1.8 to release 1.6 did not have what most would call amazing generation that got your attention either. That period of time was criticized by beta and older players for having generation that ruined variety and the desire to explore. I believe the very early Xbox 360 versions would have had the beta terrain generation (despite the game already being well into release versions by the time).

I did alot of World Generation loading up alot of seeds from Title Update 9 until Title Update 25. It was around Title Update 22 when it seemed the random amazing landscape terrain generation started becoming more predictable and cookie cutter if you will from personal observation. Couldn't get cliffsides as frequently where I would want to build a lighthouse, or having the game throw a generation anamoly at me that I wasn't expecting. Most of the gems for world terrain generation came from TU 22 and back, especially those from TU 9 through TU 14. For example, one map on Console Legacy Xbox 360 Edition in TU 14 (Which I have converted over to Bedrock Edition), using the seed murrpurrmaid generated five mushroom islands within an 864 X 864 space, which is really cool.

As for liking smaller biomes, I felt it gave the world more diversity, that I wasn't stuck in a biome for hundreds to thousands of blocks like in current Gen Minecraft. Not to say that Console Legacy couldn't do this (As I do have a Console Legacy world where 75% of it is a Mega Spruce Taiga), but it wasn't as common.

And as for the finite world size and resources, it taught me how to build compact while also being detailed with my builds all while also being conservative with my resources from the Overworld (Nether could be reset if need be). It's just personal preference.

Quote from TheMasterCaver»

There were other weird restrictions like a global limit on the number of various mobs/entities in the world (not to be confused with the current mob caps which only limit natural spawning in loaded chunks; you couldn't even breed more passive mobs once the limit was reached), which I believe came down to the fact that the entire world was always loaded, as otherwise the disk storage space (which is the only other reason for a limited world size) required to store entities is negligible (e.g. the region file that contains my main base hasn't increased in size in many years despite the addition of and filling of vast numbers of chests, each of which contains a lot more data than a mob entity; the lack of any change is because chunks are aligned to 4 KB "sectors" within a region file, much like an actual file system, and none have grown past a 4 KB boundary. The data is also compressed and many instances of the same mob (or in my case, chest tile entity, many of which have the same content), usually only differing in position, will compress well):

Yes, this is infact correct, my friend figured out how to bypass this using Nether Portals, though crashed his world doing so XD. It was quite funny.

I have no idea about the Xbox 360 version because I'm not personally familiar with it. I admit I have nothing to go on but the Wiki, but it from what it states for what Java version they were around parity with, TU22 doesn't seem like it should be a terrain generation cutoff? These are the ones I'm seeing that I would expect to be.

TU4 to TU5, TU11 to TU12 (no change to terrain generation itself per se, but the addition of jungles), and TU24 to TU25.

That approximately correlates with beta 1.7.3 to beta 1.8, release 1.x to release 1.2, and release 1.6 to release 1.7 on the Java side, and those are the ones where notable terrain changes happened.

That being said, the console versions didn't copy Java 1:1 but did some things in differently sprinkled orders in some cases. Given that terrain generation is a big thing though, I would have expected it to happen with the update that was based on it. But they also did their own thing (the custom world size alone probably meant there were other changes), so maybe they did their own things between other versions that changed seeds for those versions.

Quote from Princess_Garnet»

I have no idea about the Xbox 360 version because I'm not personally familiar with it. I admit I have nothing to go on but the Wiki, but it from what it states for what Java version they were around parity with, TU22 doesn't seem like it should be a terrain generation cutoff? These are the ones I'm seeing that I would expect to be.

TU4 to TU5, TU11 to TU12 (no change to terrain generation itself per se, but the addition of jungles), and TU24 to TU25.

That approximately correlates with beta 1.7.3 to beta 1.8, release 1.x to release 1.2, and release 1.6 to release 1.7 on the Java side, and those are the ones where notable terrain changes happened.

That being said, the console versions didn't copy Java 1:1 but did some things in differently sprinkled orders in some cases. Given that terrain generation is a big thing though, I would have expected it to happen with the update that was based on it. But they also did their own thing (the custom world size alone probably meant there were other changes), so maybe they did their own things between other versions that changed seeds for those versions.

Oh, there were differences. As you stated, not everything was 1:1 to it's Java Counterpart. Some of it was as explained limited world size. Some of it is also due to Console Legacy using C++, whereas Java Edition uses Java. I have a clean copy of my first two Xbox 360 Worlds, from TU 9 and TU 12 respectively. As an example, when I show people the TU 9 world, they seem really shocked that there is a huge crater that naturally generated and how smooth and carved out it is.

Seed to that world from the Xbox 360 is 8746098682988666831, which I did try in Java Beta 1.8 and 1.8.1, which is a partial like 70% translation compared to Console Legacy. Some of the Swamp and the Forest area where the Crater would be as well as a small Plains area is missing and is Ocean instead. Some of the Caving is different as well. This isn't counting the world being Infinite instead of being 864 x 864 which also creates differences.

My second Xbox 360 World from Title Update 12 with seed 1668899441 I loaded up in Release 1.2.1 which has even less of a translation, I would say about 40%. A Massive Fissure exists on Java on the map that didn't in Console Legacy, the lake in the middle of the map is smaller on Java than on Console Legacy, the two villages present on Console Legacy are not present on Java Edition, and the Plains that should exist are Forest or Tundra since it seems the Biome Distribution is different in certain spots.

So I can say it isn't a true 1:1 translation probably due to C++ instead of Java, and I'm not seeing that amazing generation from the Java that I did on Console Legacy as the Hills and Mountains are more rugged which suggests the translation does differ.

It should also be noted that Title Update 21 had some tweaks and fixes to generation:

• Fixed an issue with village generation.
• Fixed an issue where blaze spawners and chests do not appear in the Nether after a Nether reset.

So it could've been a bug allowing for some of wacky generation in the older versions and was fixed here, which is why I didn't see that very often from TU 22 forward.

Quote from chaptmc»

So I can say it isn't a true 1:1 translation probably due to C++ instead of Java,

This is almost certainly never the reason for any of the differences between Java Edition and anything else - any competent programming language is only limited by the underlying hardware in what can be done; an "int" variable is the same either way, so are basic concepts like arithmetic operations, loops, arrays, bit operations, etc - indeed, once the JVM has compiled Java bytecode to native assembly they may as well be exactly the same.

This is even more true for all the odd differences in features between Java and Bedrock; there is absolutely no reason for this to exist:

https://minecraft.fandom.com/wiki/Minecraft_Wiki:Parity_issue_list

Example:

Player's hand and held item sway a lot more than in Java when view bobbing is enabled

This is literally only because a value which controls how much the screen is tilted or how much the arm/held item sways is larger on Bedrock Edition (code from 1.6.4):

float angle = player.getViewBobbingFactor(par1);
float yaw = player.prevCameraYaw + (player.cameraYaw - player.prevCameraYaw) * par1;
float pitch = player.prevCameraPitch + (player.cameraPitch - player.prevCameraPitch) * par1;
GL11.glTranslatef(MathHelper.sin(angle) * yaw * 0.5F, -Math.abs(MathHelper.cos(angle) * yaw), 0.0F);
GL11.glRotatef(MathHelper.sin(angle) * yaw * 3.0F, 0.0F, 0.0F, 1.0F);
GL11.glRotatef(Math.abs(MathHelper.cos(angle - 0.2F) * yaw) * 5.0F + pitch, 1.0F, 0.0F, 0.0F);

Both Java and Bedrock have the same basic math functions (sine/cosine; java uses a "MathHelper" class which stores precalculated values in a lookup table to improve performance) - the only possible difference can be the values used to modify the pitch/way and angle (e.g. change * 0.5 to * 1.0 to double the amount of change applied - you could even add a slider that goes from e.g. 0-2 and scales these values from no view bobbing to 2x the normal - in fact, that just gave me the idea to do that, replacing the "on/off" button).

Also, java actually derived its syntax from C++ and a lot of code can literally be copied+pasted between the languages with no changes (otherwise, most changes would be with changes to the APIs used, e.g. OpenGL vs DirectX, or C++'s use of pointers which may affect how variables are used, and lack of garbage collection so you need to be sure to free memory when done):

The syntax is mostly derived from C and C++. Unlike in C++, in Java there are no global functions or variables, but there are data members which are also regarded as global variables. All code belongs to classes and all values are objects. The only exception is the primitive types, which are not represented by a class instance for performance reasons (though can be automatically converted to objects and vice versa via autoboxing). Some features like operator overloading or unsigned integer types are omitted to simplify the language and to avoid possible programming mistakes.

https://en.wikipedia.org/wiki/Java_syntax

The last part mentioned could possibly cause issues; the game has to use code like the following to read block IDs from a byte array, where & 255 effectively casts the signed byte to a unsigned int (from 8 to 32 bits) but that is only a slight performance disadvantage over being able to directly read an unsigned byte array (Java's checking the array bounds on every access is probably costlier; in C++ you'll get an access violation or corrupt memory if you go outside the bounds of an array while Java will just throw an exception which can be safely caught and dealt with, same for if you attempt to access a null reference):

public int getBlockID(int posX, int posY, int posZ)
{
    return this.blockArray[posY << 8 | posZ << 4 | posX] & 255;
}

However, all code from Java Edition that relies on the behavior of signed vs unsigned variables can be ported to C++ with no changes to account for this, other than to make sure you are using signed variables, and most code wouldn't be affected either way (e.g. block/item/biome IDs and block metadata/item damage/stack size are always positive, as are the coordinates in the method seen above since they are section-relative, 0-15).

Quote from TheMasterCaver»

This is almost certainly never the reason for any of the differences between Java Edition and anything else - any competent programming language is only limited by the underlying hardware in what can be done; an "int" variable is the same either way, so are basic concepts like arithmetic operations, loops, arrays, bit operations, etc - indeed, once the JVM has compiled Java bytecode to native assembly they may as well be exactly the same.

This is even more true for all the odd differences in features between Java and Bedrock; there is absolutely no reason for this to exist:

https://minecraft.fandom.com/wiki/Minecraft_Wiki:Parity_issue_list

Example:

This is literally only because a value which controls how much the screen is tilted or how much the arm/held item sways is larger on Bedrock Edition (code from 1.6.4):

float angle = player.getViewBobbingFactor(par1);
float yaw = player.prevCameraYaw + (player.cameraYaw - player.prevCameraYaw) * par1;
float pitch = player.prevCameraPitch + (player.cameraPitch - player.prevCameraPitch) * par1;
GL11.glTranslatef(MathHelper.sin(angle) * yaw * 0.5F, -Math.abs(MathHelper.cos(angle) * yaw), 0.0F);
GL11.glRotatef(MathHelper.sin(angle) * yaw * 3.0F, 0.0F, 0.0F, 1.0F);
GL11.glRotatef(Math.abs(MathHelper.cos(angle - 0.2F) * yaw) * 5.0F + pitch, 1.0F, 0.0F, 0.0F);

Both Java and Bedrock have the same basic math functions (sine/cosine; java uses a "MathHelper" class which stores precalculated values in a lookup table to improve performance) - the only possible difference can be the values used to modify the pitch/way and angle (e.g. change * 0.5 to * 1.0 to double the amount of change applied - you could even add a slider that goes from e.g. 0-2 and scales these values from no view bobbing to 2x the normal - in fact, that just gave me the idea to do that, replacing the "on/off" button).

Also, java actually derived its syntax from C++ and a lot of code can literally be copied+pasted between the languages with no changes (otherwise, most changes would be with changes to the APIs used, e.g. OpenGL vs DirectX, or C++'s use of pointers which may affect how variables are used, and lack of garbage collection so you need to be sure to free memory when done):

The last part mentioned could possibly cause issues; the game has to use code like the following to read block IDs from a byte array, where & 255 effectively casts the signed byte to a unsigned int (from 8 to 32 bits) but that is only a slight performance disadvantage over being able to directly read an unsigned byte array (Java's checking the array bounds on every access is probably costlier; in C++ you'll get an access violation or corrupt memory if you go outside the bounds of an array while Java will just throw an exception which can be safely caught and dealt with, same for if you attempt to access a null reference):

public int getBlockID(int posX, int posY, int posZ)
{
    return this.blockArray[posY << 8 | posZ << 4 | posX] & 255;
}

However, all code from Java Edition that relies on the behavior of signed vs unsigned variables can be ported to C++ with no changes to account for this, other than to make sure you are using signed variables, and most code wouldn't be affected either way (e.g. block/item/biome IDs and block metadata/item damage/stack size are always positive, as are the coordinates in the method seen above since they are section-relative, 0-15).

Most of what you said is correct. An int is an int at the end of the day, however it's how each compiler/language itself interprets that int is different. If every programming language interpreted the int the same way, then why would we have more than one? If Console Legacy through C++ interpreted these ints the same way as Java Edition did, then save the World Border, what is in the original 864 X 864 blockspace on Console Legacy should be the same 1:1 as it would be through Java Edition.

So either the int is being interpreted differently between the two versions or some generation code itself within the language/complier is written differently to some degree for one reason or another between the two versions, both of which support what I stated, the differences being caused by Console Legacy using C++ and Java Edition using Java, showing the differences with TU 9 - Java Beta 1.8.1 and TU 12 - Java Release 1.2.1 translations.

If you have a console or mobile or don't want to mess with Java and other browsing the internet for things go legacy/bedrock, if have a PC go Java over Windows 10 Bedrock. If achievements well........ Depends what you want of that. Them to reset then Java, if completed then well any Bedrock version with achievements/trophies.

Legacy Console made sense if you wanted the game to just 'work' want how to play, sure, want host options easily then commands/parity then sure go Legacy Console. Bedrock is fine but I want it more tedious (also no pause why..... I know Java singleplayer is treated like a server but still it does pause the session still).

I don't think console versions have keyboard support other than what commands/chat I think maybe? While you can get controller mods on Java. They aren't anywhere near the feel of console/windows 10/pocket edition if it supports controllers but 'you have the controller mod option' even if it has gotten better between the ones that exist but they don't feel as refined (at least years ago) compared to the official controller support. Even if with the mods you have more controller support options so that can be a deal breaker over 'how it feels to play and what you can and can't rebind'.

The differences make each version interesting from animations/controls/redstone/map marking with the player positions then banners and more differences that make them good, bad, interesting. I find it fun.

I go to legacy console for the old experience. I can 1.0 to 1.2 Jungle Update again with a physical copy and no updates. Or I can 1.13 with all updates if I want. Or well trophies/achievements. Bedrock good luck with that. Unless Bedrock physical has somewhat recent at certain points then sure but otherwise updates for some consoles are forced so good luck there unless you can PS4 (easy to avoid updates, somewhat even if offline console of course), maybe Switch just ignore it each time the option comes up or well offline state. Good luck on Xbox with the offline is possible pretty sure but is annoying with an online detected console where it forces updates.

If value of things to consider the game for then Java. You want all versions to play on go Java. Free fan content Java (Mods, resource packs, maps, skins, whatever, sure you have to know the safe website but many are so easy to find and the rest to ignore as scams/reposts). And if youtubers do the right thing about redirecting to places too.

If were talking performance then Bedrock. Java has mods or vanilla over time but it's like "master caver or others" will say you can tell which versions for performance, resource changes and more. I'm not one that digs that deep so those people can cover those details where I can't/haven't.

The differences over time of Java edition besides the hardware changes in 1.10, and whatever since I don't know I haven't played 1.17+ versions I went to wiki making these days and other games to play instead. Been busy.

If were talking animations (I hate the way swimming feels. I get creative mode flight lacking drift for nausea I totally get that or just if you can even do that in C++/C# then you can Java with the way the code works). I'd say it depends how the game controls/physics/animations feel and look to you of timing and flow.

But otherwise want mods, Java, any free other fan content (no paying for it on the marketplace because the Java EULA says no but Bedrock EULA says yes that part aside) you want to import them go to Bedrock Pocket Edition/Windows 10 for Behaviourpacks/Addons/Bedrock Mods there not console accessible only every other form of fan content.

Bedrock's marketplace moderation I assume can be very hit and miss.

Quote from chaptmc»

If Console Legacy through C++ interpreted these ints the same way as Java Edition did, then save the World Border, what is in the original 864 X 864 blockspace on Console Legacy should be the same 1:1 as it would be through Java Edition.

This is an extremely poor example to use - the size of the world border has absolutely nothing to do with datatypes - just an entirely artificial limitation that was coded in. In 1.6.4 there is no hard "border" but you'll fall through the world once you go past 30 million blocks since while blocks still render they behave like air. Why?

public int getBlockId(int par1, int par2, int par3)
{
    if (par1 >= -30000000 && par3 >= -30000000 && par1 < 30000000 && par3 < 30000000)
    {
        // get block ID from chunk
    }
    else
    {
        return 0;    // air
    }
}

What about the world border that was added in 1.8? Same thing (they set it to 1 chunk less than the older value, which itself used to be 32 million in a still older version according to the Wiki; extremely old versions of java Edition were actually limited to just 256x256 blocks):

public WorldBorder()
{
    this.endDiameter = this.startDiameter;
    this.worldSize = 29999984;
    this.damageAmount = 0.2D;
    this.damageBuffer = 5.0D;
    this.warningTime = 15;
    this.warningDistance = 5;
}

You can clearly see that the actual limit is coded into the game, same for any other limit, except for a few (e.g,. items supported damage values from 0-32767 because they uses a signed short and only positive values were allowed; this is a case where Bedrock could have used an unsigned short and allowed 0-65535).

I even removed the hard-coded limits myself, enabling interaction with terrain ad (mostly) normal world generation up to the 32 bit integer limit - this is the only time variable limits actually come into play, but I added an actual hard limit (invisible barrier) of +/- 30 million to the player's position (otherwise, terrain generation breaks down since I removed the fix for the Far Lands, which still occur well past the old limit due to various code changes, and the game ends up crashing once loaded chunks start wrapping around the 32 bit limit):

Interestingly, not only the game but a C++ based mapping tool both crashed when they went past the 32 bit limit (for different reasons, but ultimately both due to some piece of code being unable to handle coordinates wrapping around to negative and vice-versa. Even the exact error could be seen as the same, a "NullPointerException" can cause an access violation (exception 0xc0000005) in C++. And actually, due to JVM optimizations it may completely remove null checks if it thinks it is safe, so an actual access violation (or segfault) occurs if null does happen, which it then detects (yes, they can be caught but it is normally discouraged) and if it occurred due to null check elimination it handles it as a NPE):

Also, an interesting example of a difference that currently exists between Bedrock and Java but did not always exist:

MCPE-74963 Experience orbs don't drop instantly on death

Java Edition 1.15
Experience orbs now appear immediately when a mob is killed (similar to loot), instead of when its corpse disappears.

https://minecraft.fandom.com/wiki/Experience#History

This is something I recently changed myself (it actually makes a huge difference, especially as one who always uses Knockback, as this removes its main disadvantage), and only involved changing where the "drop XP" method is called from (just before equipment is dropped, as I also fixed an issue where it did not visually drop, which would negate the XP given if it dropped first) - absolutely no reason why they couldn't make the same change in Bedrock.

Likewise, there is absolutely no way this can possibly be due to "differences in programming languages" - no, they intentionally coded in additional ores. Same for mob drops having a higher chance (just a very basic "random(0-1) < chance"):

In Bedrock Edition, coal ore also has the third batches, which attempts to generate 20 times per chunk in blobs of size 0-37, evenly from levels 128 to 256, within any type of mountains biomes.

https://minecraft.fandom.com/wiki/Coal_Ore#Natural_generation