Continuation of Java Version?

Quote from yahwho

https://en.wikipedia.org/wiki/Enumerated_type - I just quickly edited Wikepedia to backup my argument

lmao!

Quote from paulevs

Addition: Red's post about languages and what parts of RW uses C++

Thanks for this link!

Quote from yahwho

It's not using the built in enum class, but it works the same, and it's written in Java

Technically you still can apply it even on Java enums, with using .ordinal() which will return enum index:

public enum EnumFruits {
    APPLE, BANANA;
}

int weirdData = APPLE.ordinal() + BANANA.ordinal();

But it will require more additional function callsm while in C languages you can use numbers directly, and cast them to enums too:

Direction direction = APPLE + BANANA; // Direction is another enum

Like I said, rewrite.

I think I'm done here bud.

Peace on earth.

The Java version will definitely remain playable We may release a bugfix update in the future if there are still some people playing the Java version (although it's unclear whether or when this may happen), but there are no more content or feature updates planned unfortunately...

About the language used by the new version (even though that's a bit OT ), large parts are indeed written in C#, but most performance-critical things (e.g. chunk generation) are implemented in plain C++. The game is also mostly working with native memory (i.e. raw pointers instead of arrays), which isn't managed by Unitys ancient garbage collector (therefore it causes less frame drops during garbage collection).

When compiling the game, however, all C# code is turned into C++ via Unitys IL2CPP. It's by far not as efficient as plain C++, but still faster than C# - although that's not the fault of C# (I don't think that C# is considerably slower than Java), actually it's Unitys old Mono implementation that is so slow.

Quote from red51

When compiling the game, however, all C# code is turned into C++ via Unitys IL2CPP. It's by far not as efficient as plain C++, but still faster than C# - although that's not the fault of C# (I don't think that C# is considerably slower than Java), actually it's Unitys old Mono implementation that is so slow.

Thanks for clarification
Do you have plans to turn more parts into C++ code or it will remain C#?

Quote from paulevs

Do you have plans to turn more parts into C++ code or it will remain C#?

This would be only beneficial for performance-critical things, and it only works for things which don't have much dependencies to other objects and classes Communication between C# and C++ is a bit tricky, because we can't access managed objects from C++ easily. And on the other hand, we can't turn everything into unmanaged pointers or structs on C#... in general, Unity isn't really made for C++ programming unfortunately, so you can't access the Unity API from C++ directly unless you write a wrapper for it - but this introduces other problems and limitations, and also adds another layer of complexity due to not being able to communicate with Unity directly

It wouldn't really help if we move causal stuff (e.g. UI handling, inventory handling etc) to C++, for example (in fact that would do more harm than good)...

But there are still a few performance-critical things which are still written in C# (e.g. chunk modifications). This is something we definitely want to port to C++, but this is a bit tricky (because it still requires access to managed data and also requires proper synchronization of managed [C#] threads), so unfortunately I have no ETA for that yet