Let's say I wanted to create a 3D game which requi...

# announcements

[CLOVIS]

Let's say I wanted to create a 3D game which requires access to some low level functions (for example Vulkan APIs), and I didn't like the C or C++ syntax. What are the options for Kotlin?

• Fully using the JVM, with LibGDX or jMonkeyEngine. However, it's impossible to access low level functions directly.

• Using an hybrid of JVM and C via JNI. However many benchmarks seem to suggest the speed aspects are not that great, because anything other than primitives must be copied back and forth to ensure thread safety. One solution could be to avoid arrays as much as possible and try to have as few native calls as possible, but it might not be doable as many calls might be required per frame

• Fully native, however to my understanding Kotlin/Native is built for low RAM usage and not for fast speeds. The inability to ‘unfreeze' objects might be very good for IoT, but it doesn't sound that good for 3d game—please enlighten me if you have more insights for this.

None of these solutions sound good, is there any I missed, or is it just not possible (at least currently)? I'm aware video games is probably not very high in Kotlin's roadmap, but I'm curious as to how it could compare to C# and other high level languages that are used.

[ephemient]

if you stick with JVM, NIO buffers can share memory across the JNI boundary cheaply

[Dominaezzz]

Have you checked out Rust? It's pretty modern and is an ideal "replacement" for C/C++.

[Dominaezzz]

Also, while you're looking for potential libraries/engines. https://github.com/Dominaezzz/kgl exists. 😁

[nfrankel]

😱
mentioning rust on a kotlin slack!
😂

[ephemient]

heck, if your only problem with C/C++ is the syntax, try http://users.monash.edu/~damian/papers/HTML/ModestProposal.html 😉

[Hanno]

Make your world simple and use jvm with bindings someone else maintains perfectly :) in your example you can use lwjgl for vulkan or opengl calls. Their bindings are very very good and optimized. I use that for years. I doubt that the jni overhead is really relevant.. i am coding some super high performance things with that.

But. You know. There are better runtimes for games and 3d stuff...you will constantly fight memory layout and missing value types

[ephemient]

you can implement your own "value" types as wrappers around Buffer, although it's tedious. doable if code-generated, otherwise it's like reading/writing C structs by hand

[Hanno]

Yea, i have sth in place for that xD https://github.com/hannespernpeintner/kotlin-structs this is "fighting object layout" i mentioned earlier, but it works okayish :)

[Youssef Shoaib [MOD]]

@Hanno I took a quick peek and I think there could possibly be an improvement that might improve performance a bit. Even though you are using inline classes for your properties, the usage of the memberStructs list causes the compiler to automatically box all of your properties, which probably adds a memory overhead. You could conceivably remove the memberStructs and remove the lazy sumBy and then on delegate creation you could just increase the sizeInBytes eagerly and finally your delegates would be nothing more than just the memory offsets that you need to access that specific piece of data and that's it!

[Youssef Shoaib [MOD]]

I can make a PR implementing those changes if you are interested btw

[Hanno]

Thanks for your feedback! I tried that some time ago and got some weird compiler bugs, but i will definitly try again.

[Hanno]

Oh yes, appreciated, thx!

[Hanno]

Ah, Not sure if i tried exactly this. Would be nice if you help me :)

[Youssef Shoaib [MOD]]

@Hanno Well you're in luck because I just had a burst of motivation and submitted a pull request lol. I also figured out a way to get delegation using an enum value working so expect a pull request of that soon (and I think I even found a strategy that could make EnumProperty inline by making the compiler carry the type information in a reified manner instead of storing it as a Class object and so then the EnumProperty class would only need to store its offset and that's it. It's less complicated in practice than I make it sound like lol). I've also thought about the possibility of making Array implement Java's Collection interface so I might make a pull request of that too soon.