12-11-2020, 03:28 AM
Hi!
I think I know what happens.
In original 32-bit binding and library, returned pointers by the Tilengine native library are handled as jint (32-bit). However, 64-bit builds return 64-bit pointers that get truncated to 32-bit Java jint. They should be handled as jlong, that are 64-bit wide. That is. I haven't tested, but I'm pretty sure we're having address truncation. That's why as long as we try to feed the engine with any loaded asset, it crashes.
That's a shame that Java doesn't provide a portable way to handle native pointers, having to rely on fixed-width, machine dependant integers... It doesn't allow typedef either, so I don't know how to handle this in a portable and clean manner without having to maintain two separate bindings.
I think I know what happens.
In original 32-bit binding and library, returned pointers by the Tilengine native library are handled as jint (32-bit). However, 64-bit builds return 64-bit pointers that get truncated to 32-bit Java jint. They should be handled as jlong, that are 64-bit wide. That is. I haven't tested, but I'm pretty sure we're having address truncation. That's why as long as we try to feed the engine with any loaded asset, it crashes.
That's a shame that Java doesn't provide a portable way to handle native pointers, having to rely on fixed-width, machine dependant integers... It doesn't allow typedef either, so I don't know how to handle this in a portable and clean manner without having to maintain two separate bindings.