for that, kotlin native would have to mature quite...

# kotlin-native

[badlogic]

for that, kotlin native would have to mature quite a bit, e.g. threading support etc.

[olonho]

badlogic: but how would you suggest us calling libgdx? Via native->Java interop, or you’re planning native port?

[badlogic]

port to kotlin is the only way

[badlogic]

at which point i'd a full rewrite anyways :)

[olonho]

Port to Kotlin would be amazing!

[Ruckus]

@badlogic Would that mean MOE/RVM-fork would no longer be needed? What kind of changes would you make to the engine? (Maybe this thread isn't the best place for these questions.)

[badlogic]

I failed at Slack's threaded convos. Libgdx plus Kotlin Native will never ever be a thing. Would require a full rewrite of libgdx in Kotlin.

[Ruckus]

Oh, dang. I had my hopes up for a minute there 🙂

[badlogic]

As for changes in a rewrite, dunno, lots of funky APIs that need to go/be remodeled

[badlogic]

biggest change would be removing OpenGL access replacing it with a wrapper around whatever the platform supports

[badlogic]

which is its own can of worms and could be outsourced to people who know what they are doing, e.g. oreyol, bgfx

[badlogic]

but neither of these do consoles, cause consoles are all kinds of weird

[Ruckus]

Fair points. So basically it would just be a whole new engine. Would it even be possible to have existing plugins work? They all basically assume they have a JVM equivalent.