question minecraft c++
closed account (DEb4GNh0)
if minecraft was made in c++,everyone could play ftb?
sorry for bad English.
sorry for bad English.
If Minecraft was made in C++, the degree to which it could be modded would very much depend on how the game's code is structured. Decompiling, editing, and recompiling obfuscated C++ executables is very awkward, unlike Java's executable jar archives. For modding to be a realistic possibility, Mojang would have to set up some sort of scripting and resource system, or perhaps a dynamic library loader (a generally bad idea, but still an option).
I do not have faith, however, that this would have been done. Mojang has only just recently started using a more customizable resource system, and frankly that system is actually quite poorly designed from a modder's perspective.
In short, were Minecraft in C++, it's likely that FTB would never have been created.
-Albatross
I do not have faith, however, that this would have been done. Mojang has only just recently started using a more customizable resource system, and frankly that system is actually quite poorly designed from a modder's perspective.
In short, were Minecraft in C++, it's likely that FTB would never have been created.
-Albatross
I've actually thought about translating minecraft into C++ myself just to see how it'd run in comparison to java and GC.
Also their seems to be some rediculous programing choices in minecraft that I simply don't understand... I may be making it up but I'm pretty sure that checking if a wolf could eat food was done in the wolf's onClick event (or whatever event it is) and was a number of special cases to check if the item being held was meat.
The last time I checked the code this had been replaced with a boolean value in the item class. So those 256-ish items registered each hold a boolean value, most likely taking either a whole byte or 4 bytes of ram each? (Not certain on how ram works with 32b processors). That is unless java can rearrange the data quite statically and use 1b for each bool, probably giving you 256b of boolean vales... which is still 32 bytes of memory...
and the processor still has to run a small check, surely the ever so slightly more cpu for special case checking on something that happens so rarely would be better wouldn't it?
Also their seems to be some rediculous programing choices in minecraft that I simply don't understand... I may be making it up but I'm pretty sure that checking if a wolf could eat food was done in the wolf's onClick event (or whatever event it is) and was a number of special cases to check if the item being held was meat.
The last time I checked the code this had been replaced with a boolean value in the item class. So those 256-ish items registered each hold a boolean value, most likely taking either a whole byte or 4 bytes of ram each? (Not certain on how ram works with 32b processors). That is unless java can rearrange the data quite statically and use 1b for each bool, probably giving you 256b of boolean vales... which is still 32 bytes of memory...
and the processor still has to run a small check, surely the ever so slightly more cpu for special case checking on something that happens so rarely would be better wouldn't it?
The item registry holds either 215 or 216 items. The test whether a wolf can eat a piece of food is done (IIRC) by calling a member function in the Item base class (that's one thing Minecraft suffers from bigtime: the Item and Block base classes both suffer from huge bloating). ItemFood, however, does contain an extra boolean value (cannot remember if it was const or not) that is returned by the member function. The memory consumed here isn't a huge issue, really.
But Minecraft's codebase is indeed a mess, even more so with the 1.8 update. Misuse of UUIDs and the entire block properties system comes to mind.
-Albatross
But Minecraft's codebase is indeed a mess, even more so with the 1.8 update. Misuse of UUIDs and the entire block properties system comes to mind.
-Albatross
Last edited on
There's minetest which has gotten a lot better over the years: http://www.minetest.net/
There are *tons* of issues with Minecraft... that Mojang has no intention of fixing. Here's some obvious ones...
1) Use of TCP. Might not be bad with a few clients. But on a server with hundreds of players, TCP sockets are incredibly inefficient on both bandwidth and system resources. I won't get into why that is... but generally any real-time packet that doesn't need to be reliable should be done using UDP packets.
2) Bad protocol. Packets should be serialized. Because they're are serialized, we know they're always in a specific format. We can predetermine things like strings inside of a packet by parsing the header of a packet, then parsing another integer (usually 2 or 4 bytes) that determines the size of the string, then parsing the string. If there are multiple strings, you have multiple integers that sit next to each other so we can parse the serialized sizes at once. In the case of Minecraft, we parse the header... then we have this weird variable sized integer that we have to take resources to compute the size of. Then we parse the string. If there are multiple strings... we have to parse each string one at a time since the integer is at the beginning of each string rather than at the beginning of the packet. I can go on and on about how bad this is in real-time networking but I'm just going to move on...
3) Liberal usage of Memory. It's not always so true what people say about Java. It can be a memory hog... but it's generally the user that causes the problems. "I can allocate whatever I want and Java will clean up after me". This is not a good mindset and leads to problems like a 2 man Minecraft server crashing with out of memory exceptions on a 1GB VPS dedicated to that Minecraft server.
4) Retarded Code Obfuscation. Mojang went well out of their way to obfuscate their code. They still do to this day. Yet, if it weren't for the community reverse engineering their code, Minecraft would probably not be much of a thing today.
And these are issues that can be addressed without even moving to C++. A new language doesn't fix the programmer.
There are *tons* of issues with Minecraft... that Mojang has no intention of fixing. Here's some obvious ones...
1) Use of TCP. Might not be bad with a few clients. But on a server with hundreds of players, TCP sockets are incredibly inefficient on both bandwidth and system resources. I won't get into why that is... but generally any real-time packet that doesn't need to be reliable should be done using UDP packets.
2) Bad protocol. Packets should be serialized. Because they're are serialized, we know they're always in a specific format. We can predetermine things like strings inside of a packet by parsing the header of a packet, then parsing another integer (usually 2 or 4 bytes) that determines the size of the string, then parsing the string. If there are multiple strings, you have multiple integers that sit next to each other so we can parse the serialized sizes at once. In the case of Minecraft, we parse the header... then we have this weird variable sized integer that we have to take resources to compute the size of. Then we parse the string. If there are multiple strings... we have to parse each string one at a time since the integer is at the beginning of each string rather than at the beginning of the packet. I can go on and on about how bad this is in real-time networking but I'm just going to move on...
3) Liberal usage of Memory. It's not always so true what people say about Java. It can be a memory hog... but it's generally the user that causes the problems. "I can allocate whatever I want and Java will clean up after me". This is not a good mindset and leads to problems like a 2 man Minecraft server crashing with out of memory exceptions on a 1GB VPS dedicated to that Minecraft server.
4) Retarded Code Obfuscation. Mojang went well out of their way to obfuscate their code. They still do to this day. Yet, if it weren't for the community reverse engineering their code, Minecraft would probably not be much of a thing today.
And these are issues that can be addressed without even moving to C++. A new language doesn't fix the programmer.
I agree completely with the above post...
The only thing that chained to C++ would really do would improve booting time wouldn't it? (As you won't be JIT compiling when you start... Or have I not read into JIT enough and got that wrong too :D ).
@Albatross was it just ItemFood? It was a long time ago I noticed this and clearly I forgot which class and thought it was just the generic item class. This isn't as bad but still pretty awful in comparison to the one wolf class receiving the OnClick and checking.
And with the obfuscation.... -_-
What even happened to the modding API? XD
But anyways, a performance patch is just one of those things that isn't likely to ever happen (*cough HiRez too cough*)
The only thing that chained to C++ would really do would improve booting time wouldn't it? (As you won't be JIT compiling when you start... Or have I not read into JIT enough and got that wrong too :D ).
@Albatross was it just ItemFood? It was a long time ago I noticed this and clearly I forgot which class and thought it was just the generic item class. This isn't as bad but still pretty awful in comparison to the one wolf class receiving the OnClick and checking.
And with the obfuscation.... -_-
What even happened to the modding API? XD
But anyways, a performance patch is just one of those things that isn't likely to ever happen (*cough HiRez too cough*)
Side note about java (not minecraft)
I will about that I'm guilty for throwing a lot of abuse at java for many reasons, but as I venture into more languages and further into computer science generally I realise java (portability) is a very good concept, and it's really well implemented for consistency and performance across many platforms.
There are still lots of things I don't like about it like forced OOP, lack of default arguments, GC, etc... but hey, you can't be perfect right?
I certainly don't think C++ is perfect either
I will about that I'm guilty for throwing a lot of abuse at java for many reasons, but as I venture into more languages and further into computer science generally I realise java (portability) is a very good concept, and it's really well implemented for consistency and performance across many platforms.
There are still lots of things I don't like about it like forced OOP, lack of default arguments, GC, etc... but hey, you can't be perfect right?
I certainly don't think C++ is perfect either
| TheRabbitologist wrote: |
|---|
| But Minecraft's codebase is indeed a mess, even more so with the 1.8 update. Misuse of UUIDs and the entire block properties system comes to mind. |
Well whatever they did 1.8 has had a huge performance boost for me. I know they started transitioning to this block properties system. Can you(or anyone) elaborate on what's wrong with it? It must be a more sensible system than whatever they were using before, or else why would they go through the trouble?
Last edited on
It's mainly due to them starting to use [semi] modern graphics programming techniques (things that have been available since 2004).
I mean really we should be a little bit more fair. The game was created by one person until beta, at which point everyone at mojang probably had to work around whatever was already there for the most part.
Eventually it just ends up a mess as people come into a project instead of having common goals, styles, plans etc before a project.
Eventually it just ends up a mess as people come into a project instead of having common goals, styles, plans etc before a project.
Minecraft's old codebase (pre 1.0) was excusable for that reason. It was generally quite C-ish with a lot of stuff hard coded. That's okay. What's not excusable is how many of its longstanding problems haven't been fixed, and how much worse its code's design has gotten from 1.5 to 1.8.
-Albatross
-Albatross
Topic archived. No new replies allowed.