3 ms·
C# is better for gamedev for quite a lot of reasons, but most importantly because it has value types (structs) that aren’t boxed. In gamedev you use a lot of sm
by lasagnaphil 6y ago
C# is better for gamedev for quite a lot of reasons, but most importantly because it has value types (structs) that aren’t boxed. In gamedev you use a lot of small-size types such as Vector3 or Vector4 for all sorts of math, but if you implement them naively in Java you have to always heap-allocate them, which brings severe penalties in terms of cache locality and GC. Modern Java gamedev libraries like JOML tries to avoid this by using NIO buffers (JVM provides some utilities to manually alloc/dealloc memory), but the API is quite finicky as a result. (Plus, there is no operator overloading in Java, which is another bummer.) Project Valhalla is trying to add proper value types to the JVM, but sadly as of today the project seems a bit abandoned... (See https://wiki.openjdk.java.net/display/valhalla/Main https://wiki.openjdk.java.net/display/valhalla/Main)
- djhworld 6y ago> Project Valhalla is trying to add proper value types to the JVM, but sadly as of today the project seems a bit abandoned... The repo seems to have very recent activity, has commits from today! https://github.com/openjdk/valhalla https://github.com/openjdk/valhalla
- didibus 6y agoAgree, and not just gamedev, I think for desktop apps this is an issue as well. The memory profile of a Java app suffer from lots of unnecessary boxing. Also, the GCs are not designed and tuned to desktop apps, but to backend services. So they'll exhibit behavior like never releasing memory back to the OS and hording 100% memory.