Many of you have been putting hate threads towards the recent updates saying they are either breaking the game or useless. That may just be because you do not know what these updates are really about. Yeah, they are adding a bigger skin file and support for 3d textures and map maker crap. But the real thing Mojang is aiming for is OPTIMIZATION. No they will not recode the game due to the fact that java is the MOST compatible thing they could code a game in. If you look back to the 1.6.4 and 1.7 update, there is a MAJOR and I mean MAJOR FPS difference. Mojang is fixing the mistakes they made when they first created the game as a garage team.
Why?-
Put it this way, If someone created a game in 2009. Would you think they would be able to improve it 5 years later? ofcourse they would be able to improve it in some way or another. Unlike many AAA game titles out there, that are made from massive groups of coders, Minecraft was made from only ~20. 20 Close friends who can talk to each other about ideas and coding help. Therefore the game will be A- More polished overtime, B- Have the majority pleased, C- Happier developers and clients. Their updates that are coming out seem to only getting better and better overtime. Mojang talking about a new block rendering system could even bring bigger changes to the world of minecraft. (Possibly higher-block-limites :3)
Modding-
They are not thinking of adding every mod into the game, but allowing them to be easily configured so more people will have access to those mods. You may have the perfect mod to add into the game, but you have to see it from a broader point of view. Will it work with - Creative, modded, custom, survival, and Roleplay servers? Will the majority think it was the right thing to do?? That is why mojang is pushing towards the modding Api. They want the end user to be your son, or your daughter. So She/He can click a button and have the game she wants to play. Enough with these hate threads about ignorant kids saying their opinion is correct. No opinion is correct, not even mine. An opinion is an opinion. Take this thread with a massive grain of salt and enjoy your evening.
~moose
I agree with everything except the Java statement.
If Java was really "most compatible", there would be ONE code version for all the platforms, instead, we have exactly the exact same number of versions than if it had been coded in any other language such as say C# or example: *1* version of the game per each platform. No more, no less.
Java's promise and hype was initially "Code once, run everywhere". However it didn't quite deliver on that promise.
However, the HUGE benefit of Java for MC is that it opened the door to huge community modding, which is definitely a big part of MC's success.
I agree with most things said, but not with the length of time it took to actually optimize the game, with Mojang's available resources theres no excuse for not hiring people at least for hammering out bugs and inefficiencies. 5 years is way too long to make any excuses or defend.
If Java was really "most compatible", there would be ONE code version for all the platforms, instead, we have exactly the exact same number of versions than if it had been coded in any other language such as say C# or example: *1* version of the game per each platform. No more, no less.
There is only one version for all Platforms. the Windows version is provided in a packaged .jar though (exe) as a shim, since .jar files are not executables in the strictest sense.
Java's promise and hype was initially "Code once, run everywhere". However it didn't quite deliver on that promise.
technically it was "write once, run anywhere". The reality is more along the lines of "Compile once, test anywhere".
However, it is definitely a step ahead C and C++. Java code can be compiled once and run on a variety of platforms, whereas with C and C++ you compile it specifically for each platform. The only problem for Java is that programmers don't consider the cross-platform requirements and will end up depending on OS-specific capabilities. In fact it's quite common to see Java code that say hard-codes a path separator or other OS-specific construct, which will fail on other systems. Other differences can cause issues as well, such as *nix systems having case-sensitive file systems, whereas Windows file systems are typically case insensitive.
However, the HUGE benefit of Java for MC is that it opened the door to huge community modding, which is definitely a big part of MC's success.
Perhaps ironically, I think, is that part of the reason Java was so moddable is partly because of that "write once, run anywhere" mantra. One of the advantages is very much in it's intermediate bytecode, which keeps a lot of information about the structure of the program, through reflection; better still, this information can be accessed at run-time and bytecode can be loaded dynamically. Most modloading frameworks (Forge, ModLoader, etc) take advantage of this quite thoroughly, to the point of directly modifying the java bytecode to inject method calls. There is no doubt in my mind that if Minecraft was written in C++ the modding community would be far more specialized because it would be a case of directly editing executable machine code for specific platforms.
I agree with most things said, but not with the length of time it took to actually optimize the game, with Mojang's available resources theres no excuse for not hiring people at least for hammering out bugs and inefficiencies. 5 years is way too long to make any excuses or defend.
This is a very common misunderstanding of software development teams and methodology.
Bringing new talent on board requires an investment from existing staff, which will cause them to lose productivity. It also requires that the new employees be brought up to speed with how they do things. These are non-zero costs to development time, and add in personal disagreements with how things are done and things can be very troublesome. The idea that a company can just hire more developers to become more productive is about as valid as suggesting that 9 women should be able to deliver a baby in one month.
For example, "hammering out bugs and inefficiencies" ignoring the fact that the existing staff are doing that pretty much full time (the move to the new version of OpenGL more or less spear-headed by TheMogMiner is essentially the biggest single speed improvement that can be made, and it's not even really the software's fault but the fact that hardware is not really designed to be performant with the old versions and interfaces. Ignoring that, 'hammering out bugs' is not something that anybody can do.
As an example, With my company there are some programs I wrote, some programs my co-workers wrote, and of course many that many of us have committed changes to. Some of us have better understandings of how those programs work than others. If there is a bug in our Update program, I usually have a good idea what might be causing it, because I wrote the bulk of the logic that it executes.
My co-workers are less likely to have a very good idea, at least, in the same way as myself, simply because they aren't as familiar with the layout. So if they were tasked with fixing a bug in it it would probably end up taking them longer than it would take me, and that isn't even to consider that there might be unforeseen regressions or side effects, for example "I fixed it by simply incrementing the flibble count" could cause a problem if that flibble count needs to be in sync with the number of flooblies that are in the list of flapples. So bringing on new developers to "fix bugs" is going to have a negative impact for a rather long time as they become familiar with it, and those new developers will, as a result, require the help of the existing developers to come up to speed, which negatively affects the development process of pretty much everybody.
As far as "inefficiencies" I've yet to hear a single, citable case based on say the MCP decompiled source code of non-trivial 'inefficiencies' so I find the claims specious at best; the only real case would be the OGL version and they are moving that forward as it is. The rest is just messy code. Messy code does not affect performance. the Java Virtual Machine doesn't care if code is messy or if it happens to use confusing structures. Programming source code is meant to be read by humans, and happens to incidentally also be executed by a computer. Their current refactorings are for "efficiency" but that efficiency is for the humans, not for the computer.
There is no doubt in my mind that if Minecraft was written in C++ the modding community would be far more specialized because it would be a case of directly editing executable machine code for specific platforms.
I don't think Starcraft was coded in Java, yet it has an good modding community. This is because the game features a built-in map editor that supports some amount of basic logic "programming" protocol. Kind of like a "peusdo-code" language. No need to modify binary executable files.
I'd think such a feature, providing a rather "large" way to mod the game directly from within the game, can work very well if added in right from the start, and will be a requisite for any game that hopes to compete in MC's '"backyard'" so to speak.
If for the end user player it is simply a matter of downloading a single file, putting it in a folder somewhere, and from within the game's launcher you just drag n drop the file or open - add - up / down, then yeah, mods would be way more popular. It is already much easier than a few versions ago, but still quite a ways to go. MultiMC is an example of an alternate launcher that does it relatively well, albeit could still be a tiny bit simpler, but I think such a capability should be built-in right in the vanilla launcher. Modders have the know-how and patience, but mere mod users are, more often than not, really not all that good at configuring game files, so yeah, the overall modding process itself would greatly benefit from being much more "moron proof". And for the modders, it would only mean much more players are trying their mods.
As far as "inefficiencies" I've yet to hear a single, citable case based on say the MCP decompiled source code of non-trivial 'inefficiencies' so I find the claims specious at best
I've got one: TileEntities are stored in a ArrayList, not a hash table. That's why the game gets so slow with a lot of TileEntities about.
Messy code (which Minecraft has in spades) tends not to be *locally* inefficient, but it's often *globally* inefficient because it's hard to identify and change the chokepoints. These problems aren't things you can point to in the code, because the fact that the messiness hides them is the reason they're there. But with a very complex system messily coded by a small set of programmers, and constrained by the early decisions of *one* programmer, you can be certain the inefficiencies are there.
The Meaning of Life, the Universe, and Everything.
Join Date:
3/28/2014
Posts:
648
Member Details
I think they're on the way to improving the game and fixing up the minors errors there. It seems like they've really been putting in an effort recently. What are your thoughts?
The idea that a company can just hire more developers to become more productive is about as valid as suggesting that 9 women should be able to deliver a baby in one month.
I highly doubt Mojang will be heading in the "Lets polish our game up!" route any time soon. All they've done for the last 3 years is dangle sparkly things in front of us hoping we wont realize that sparkly things come first and fixing the game comes second.
And in one post you've proven that you don't know a damn thing about what all of these technical changes are actually for.
The Meaning of Life, the Universe, and Everything.
Join Date:
7/25/2012
Posts:
61
Location:
Philippines
Minecraft:
XenonCreeper
Member Details
This pretty much sums things up from the video "The Story of Mojang". Mojang is a small group so it does make sense that it will take a long time for the game to get polished but the fact that Mojang is a small group makes the development easier. Like what MiniMoose12 said, the developers know each other very well. Because of this, they can plan and agree with each other easily, making updates better and faster in the long run.
PS: I suggest you watch "The Story of Mojang". Its a long video but you'll learn a lot about them and you'll also see how they slowly but surely improve Minecraft even with not much members in the team.
Also, I think the quote "Quality over Quantity" makes alot of sense in developing games. Anyone agree?
Yet most of the fanbase has proven themselves more competent coders at times. It's java, not rocket science. People that know java code will be able to sift through inefficiencies in coding, fix bugs, and rework things without offsetting something else and causing more issues. If they cannot work with a slightly bigger team to cover more options at once then it doesn't say much for their ability for teamwork now does it?
I don't think Starcraft was coded in Java, yet it has an good modding community. This is because the game features a built-in map editor that supports some amount of basic logic "programming" protocol. Kind of like a "peusdo-code" language. No need to modify binary executable files.
I'd think such a feature, providing a rather "large" way to mod the game directly from within the game, can work very well if added in right from the start, and will be a requisite for any game that hopes to compete in MC's '"backyard'" so to speak.
If for the end user player it is simply a matter of downloading a single file, putting it in a folder somewhere, and from within the game's launcher you just drag n drop the file or open - add - up / down, then yeah, mods would be way more popular. It is already much easier than a few versions ago, but still quite a ways to go. MultiMC is an example of an alternate launcher that does it relatively well, albeit could still be a tiny bit simpler, but I think such a capability should be built-in right in the vanilla launcher. Modders have the know-how and patience, but mere mod users are, more often than not, really not all that good at configuring game files, so yeah, the overall modding process itself would greatly benefit from being much more "moron proof". And for the modders, it would only mean much more players are trying their mods.
This basically describes the "Mod API" Mojang is moving towards. (Examples of this can be seen in the model files and the customizable world generation that MogMiner recently previewed.)
Yet most of the fanbase has proven themselves more competent coders at times. It's java, not rocket science. People that know java code will be able to sift through inefficiencies in coding, fix bugs, and rework things without offsetting something else and causing more issues. If they cannot work with a slightly bigger team to cover more options at once then it doesn't say much for their ability for teamwork now does it?
Teamwork has little to do with it. Think of it like a car engine. No matter how well the mechanics get along, there can only be so many people working under the hood at a time before they start getting in each other's way.
Rollback Post to RevisionRollBack
Tis far better to be a witty fool than a foolish wit.
The 1.7 update decreased my already-low FPS, so I personally do not feel very swayed by the MAJOR negative difference.
The updates are getting better and better how, exactly? FPS-wise? I'd say no. Content-wise? Arguable, subjective. Code-wise? How?
The content people are hating on is not the optimization, it's the changes they can see. People will not be swayed by this to stop complaining about how enchanting, aesthetics, trading, commands, etcetera are breaking the game or useless. All you are doing is trying to distract them with something that's irrelevant to any of their arguments and that I'm fairly certain almost everyone already agrees on (yes, improving code is good).
And do you really need "Moosey Talks" in large, fancy letters? It's overly grand for an argument that fails to address the true reasons of the subject of its own first sentence and is stating what is completely obvious.
The 1.7 update decreased my already-low FPS, so I personally do not feel very swayed by the MAJOR negative difference.
The updates are getting better and better how, exactly? FPS-wise? I'd say no. Content-wise? Arguable, subjective. Code-wise? How?
The content people are hating on is not the optimization, it's the changes they can see. People will not be swayed by this to stop complaining about how enchanting, aesthetics, trading, commands, etcetera are breaking the game or useless. All you are doing is trying to distract them with something that's irrelevant to any of their arguments and that I'm fairly certain almost everyone already agrees on (yes, improving code is good).
And do you really need "Moosey Talks" in large, fancy letters? It's overly grand for an argument that fails to address the true reasons of the subject of its own first sentence and is stating what is completely obvious.
How did it decrease your already low FPS? 1.7 FPS put my usual ~60 fps to ~560 fps ......... Don't blame a company about a game that you can't run. Even minecraft runs on 400$ laptops like cake. IDK what dinosaur your running it on, but I would suggest upgrading if you think their coding is at blame.
My post is a simple blog post about what I believe the updates are headed for. Ofcourse after several hours of research on their recent postings and tweets. If you don't like my formatting, don't read it. It's that simple.
Then again an ArrayList is the better option if the size isn't massive and only few lookups are done. Hash tables are useful, but the hashing overhead compared with avoiding collisions if keys end up in the same bucket only makes them slower on smaller data sets.
Every container has cons and pros. Perhaps they could have used a hash map instead of a vector, but it might as well decrease performance when there are few tile entities.
You cannot simply make this claim without posting something like a profiler result to accurately indicate it actually makes a difference.
Lots of tile entities are a well-known speed problem. Speed when there's just a few doesn't matter because - there's just a few.
Rollback Post to RevisionRollBack
Geographicraft (formerly Climate Control) - Control climate, ocean, and land sizes; stop chunk walls; put modded biomes into Default worlds, and more!
RTG plus - All the beautiful terrain of RTG, plus varied and beautiful trees and forests.
I can't comment on code because I know nothing about it. I will say this, though. My computer is old but when I first bought minecraft it ran fast even with Misa's 64x64 realism texture pack (this was back in alpha). Generally speaking, it's gotten slower with every update. I can't run it at any reasonable framerate at normal render distance now even WITH optifine. No, I don't know what it is they're doing, exactly, but I can see the results. Our server is a top-of-the-line machine and we STILL have problems with things like tile entities and entities in general. I don't need to know everything about coding to be able to say something's not right here. I really don't care how long it takes between updates but things should be getting fixed at any rate and it seems obvious that they're not.
Allow me to play the conspiracy theorist for a moment. I think that the speed of updates is increasing in part because they (and by they I mean Jeb) deliberately want to make it impossible for modders to keep up so they can dictate exactly how we play. They can't stop everyone but they're doing a good job trying. Don't believe me? Go check how many mods are up-to-date. You can argue the reason but not the result.
Rollback Post to RevisionRollBack
Freedom is more important than health, more important than safety or security. A life's worth is not measured by its length but by the length it is lived with liberty. Freedom above all.
I agree with everything except the Java statement.
If Java was really "most compatible", there would be ONE code version for all the platforms, instead, we have exactly the exact same number of versions than if it had been coded in any other language such as say C# or example: *1* version of the game per each platform. No more, no less.
Java's promise and hype was initially "Code once, run everywhere". However it didn't quite deliver on that promise.
However, the HUGE benefit of Java for MC is that it opened the door to huge community modding, which is definitely a big part of MC's success.
Yeah, I don't really know about that whole "Easier cross-compatability" part of it, since I don't have much experience with Java. Honestly, I feel Minecraft is coded in Java because that is what Notch felt most comfortable working with, which is fine as well.
Rollback Post to RevisionRollBack
The problem with the truth, is that it never lies.
Many of you have been putting hate threads towards the recent updates saying they are either breaking the game or useless. That may just be because you do not know what these updates are really about. Yeah, they are adding a bigger skin file and support for 3d textures and map maker crap. But the real thing Mojang is aiming for is OPTIMIZATION. No they will not recode the game due to the fact that java is the MOST compatible thing they could code a game in. If you look back to the 1.6.4 and 1.7 update, there is a MAJOR and I mean MAJOR FPS difference. Mojang is fixing the mistakes they made when they first created the game as a garage team.
Why?-
Put it this way, If someone created a game in 2009. Would you think they would be able to improve it 5 years later? ofcourse they would be able to improve it in some way or another. Unlike many AAA game titles out there, that are made from massive groups of coders, Minecraft was made from only ~20. 20 Close friends who can talk to each other about ideas and coding help. Therefore the game will be A- More polished overtime, B- Have the majority pleased, C- Happier developers and clients. Their updates that are coming out seem to only getting better and better overtime. Mojang talking about a new block rendering system could even bring bigger changes to the world of minecraft. (Possibly higher-block-limites :3)
Modding-
They are not thinking of adding every mod into the game, but allowing them to be easily configured so more people will have access to those mods. You may have the perfect mod to add into the game, but you have to see it from a broader point of view. Will it work with - Creative, modded, custom, survival, and Roleplay servers? Will the majority think it was the right thing to do?? That is why mojang is pushing towards the modding Api. They want the end user to be your son, or your daughter. So She/He can click a button and have the game she wants to play. Enough with these hate threads about ignorant kids saying their opinion is correct. No opinion is correct, not even mine. An opinion is an opinion. Take this thread with a massive grain of salt and enjoy your evening.
~moose
If Java was really "most compatible", there would be ONE code version for all the platforms, instead, we have exactly the exact same number of versions than if it had been coded in any other language such as say C# or example: *1* version of the game per each platform. No more, no less.
Java's promise and hype was initially "Code once, run everywhere". However it didn't quite deliver on that promise.
However, the HUGE benefit of Java for MC is that it opened the door to huge community modding, which is definitely a big part of MC's success.
So yeah: Yay anyway!
Oh, and is that amount of salt sufficient?
http://graphics8.nytimes.com/images/2009/01/26/world/salt_600.1.jpg
There is only one version for all Platforms. the Windows version is provided in a packaged .jar though (exe) as a shim, since .jar files are not executables in the strictest sense.
technically it was "write once, run anywhere". The reality is more along the lines of "Compile once, test anywhere".
However, it is definitely a step ahead C and C++. Java code can be compiled once and run on a variety of platforms, whereas with C and C++ you compile it specifically for each platform. The only problem for Java is that programmers don't consider the cross-platform requirements and will end up depending on OS-specific capabilities. In fact it's quite common to see Java code that say hard-codes a path separator or other OS-specific construct, which will fail on other systems. Other differences can cause issues as well, such as *nix systems having case-sensitive file systems, whereas Windows file systems are typically case insensitive.
Perhaps ironically, I think, is that part of the reason Java was so moddable is partly because of that "write once, run anywhere" mantra. One of the advantages is very much in it's intermediate bytecode, which keeps a lot of information about the structure of the program, through reflection; better still, this information can be accessed at run-time and bytecode can be loaded dynamically. Most modloading frameworks (Forge, ModLoader, etc) take advantage of this quite thoroughly, to the point of directly modifying the java bytecode to inject method calls. There is no doubt in my mind that if Minecraft was written in C++ the modding community would be far more specialized because it would be a case of directly editing executable machine code for specific platforms.
This is a very common misunderstanding of software development teams and methodology.
Bringing new talent on board requires an investment from existing staff, which will cause them to lose productivity. It also requires that the new employees be brought up to speed with how they do things. These are non-zero costs to development time, and add in personal disagreements with how things are done and things can be very troublesome. The idea that a company can just hire more developers to become more productive is about as valid as suggesting that 9 women should be able to deliver a baby in one month.
For example, "hammering out bugs and inefficiencies" ignoring the fact that the existing staff are doing that pretty much full time (the move to the new version of OpenGL more or less spear-headed by TheMogMiner is essentially the biggest single speed improvement that can be made, and it's not even really the software's fault but the fact that hardware is not really designed to be performant with the old versions and interfaces. Ignoring that, 'hammering out bugs' is not something that anybody can do.
As an example, With my company there are some programs I wrote, some programs my co-workers wrote, and of course many that many of us have committed changes to. Some of us have better understandings of how those programs work than others. If there is a bug in our Update program, I usually have a good idea what might be causing it, because I wrote the bulk of the logic that it executes.
My co-workers are less likely to have a very good idea, at least, in the same way as myself, simply because they aren't as familiar with the layout. So if they were tasked with fixing a bug in it it would probably end up taking them longer than it would take me, and that isn't even to consider that there might be unforeseen regressions or side effects, for example "I fixed it by simply incrementing the flibble count" could cause a problem if that flibble count needs to be in sync with the number of flooblies that are in the list of flapples. So bringing on new developers to "fix bugs" is going to have a negative impact for a rather long time as they become familiar with it, and those new developers will, as a result, require the help of the existing developers to come up to speed, which negatively affects the development process of pretty much everybody.
As far as "inefficiencies" I've yet to hear a single, citable case based on say the MCP decompiled source code of non-trivial 'inefficiencies' so I find the claims specious at best; the only real case would be the OGL version and they are moving that forward as it is. The rest is just messy code. Messy code does not affect performance. the Java Virtual Machine doesn't care if code is messy or if it happens to use confusing structures. Programming source code is meant to be read by humans, and happens to incidentally also be executed by a computer. Their current refactorings are for "efficiency" but that efficiency is for the humans, not for the computer.
I don't think Starcraft was coded in Java, yet it has an good modding community. This is because the game features a built-in map editor that supports some amount of basic logic "programming" protocol. Kind of like a "peusdo-code" language. No need to modify binary executable files.
I'd think such a feature, providing a rather "large" way to mod the game directly from within the game, can work very well if added in right from the start, and will be a requisite for any game that hopes to compete in MC's '"backyard'" so to speak.
If for the end user player it is simply a matter of downloading a single file, putting it in a folder somewhere, and from within the game's launcher you just drag n drop the file or open - add - up / down, then yeah, mods would be way more popular. It is already much easier than a few versions ago, but still quite a ways to go. MultiMC is an example of an alternate launcher that does it relatively well, albeit could still be a tiny bit simpler, but I think such a capability should be built-in right in the vanilla launcher. Modders have the know-how and patience, but mere mod users are, more often than not, really not all that good at configuring game files, so yeah, the overall modding process itself would greatly benefit from being much more "moron proof". And for the modders, it would only mean much more players are trying their mods.
This is a legacy account, meaning it is no longer active
I've got one: TileEntities are stored in a ArrayList, not a hash table. That's why the game gets so slow with a lot of TileEntities about.
Messy code (which Minecraft has in spades) tends not to be *locally* inefficient, but it's often *globally* inefficient because it's hard to identify and change the chokepoints. These problems aren't things you can point to in the code, because the fact that the messiness hides them is the reason they're there. But with a very complex system messily coded by a small set of programmers, and constrained by the early decisions of *one* programmer, you can be certain the inefficiencies are there.
Geographicraft (formerly Climate Control) - Control climate, ocean, and land sizes; stop chunk walls; put modded biomes into Default worlds, and more!
RTG plus - All the beautiful terrain of RTG, plus varied and beautiful trees and forests.
And in one post you've proven that you don't know a damn thing about what all of these technical changes are actually for.
PS: I suggest you watch "The Story of Mojang". Its a long video but you'll learn a lot about them and you'll also see how they slowly but surely improve Minecraft even with not much members in the team.
Also, I think the quote "Quality over Quantity" makes alot of sense in developing games. Anyone agree?
Yet most of the fanbase has proven themselves more competent coders at times. It's java, not rocket science. People that know java code will be able to sift through inefficiencies in coding, fix bugs, and rework things without offsetting something else and causing more issues. If they cannot work with a slightly bigger team to cover more options at once then it doesn't say much for their ability for teamwork now does it?
Teamwork has little to do with it. Think of it like a car engine. No matter how well the mechanics get along, there can only be so many people working under the hood at a time before they start getting in each other's way.
The updates are getting better and better how, exactly? FPS-wise? I'd say no. Content-wise? Arguable, subjective. Code-wise? How?
The content people are hating on is not the optimization, it's the changes they can see. People will not be swayed by this to stop complaining about how enchanting, aesthetics, trading, commands, etcetera are breaking the game or useless. All you are doing is trying to distract them with something that's irrelevant to any of their arguments and that I'm fairly certain almost everyone already agrees on (yes, improving code is good).
And do you really need "Moosey Talks" in large, fancy letters? It's overly grand for an argument that fails to address the true reasons of the subject of its own first sentence and is stating what is completely obvious.
If you are planning to make a suggestion, please read this.
If you want to know more, you can read this.
For those who complain about post-Beta generation, you might want to see this.
How did it decrease your already low FPS? 1.7 FPS put my usual ~60 fps to ~560 fps ......... Don't blame a company about a game that you can't run. Even minecraft runs on 400$ laptops like cake. IDK what dinosaur your running it on, but I would suggest upgrading if you think their coding is at blame.
My post is a simple blog post about what I believe the updates are headed for. Ofcourse after several hours of research on their recent postings and tweets. If you don't like my formatting, don't read it. It's that simple.
Lots of tile entities are a well-known speed problem. Speed when there's just a few doesn't matter because - there's just a few.
Geographicraft (formerly Climate Control) - Control climate, ocean, and land sizes; stop chunk walls; put modded biomes into Default worlds, and more!
RTG plus - All the beautiful terrain of RTG, plus varied and beautiful trees and forests.
Allow me to play the conspiracy theorist for a moment. I think that the speed of updates is increasing in part because they (and by they I mean Jeb) deliberately want to make it impossible for modders to keep up so they can dictate exactly how we play. They can't stop everyone but they're doing a good job trying. Don't believe me? Go check how many mods are up-to-date. You can argue the reason but not the result.
Yeah, I don't really know about that whole "Easier cross-compatability" part of it, since I don't have much experience with Java. Honestly, I feel Minecraft is coded in Java because that is what Notch felt most comfortable working with, which is fine as well.
lol. so this is what happens if people don't agree with you? I thought your opinion was an opinion, not an monarchic law.
Miner's nightmare preset
Miner's nightmare preset (original terrain)
Killing the Ender Dragon, no damage (no armor/potions/enchantments/pumpkin)