Posts: 187
Threads: 22
Joined: Dec 2020
Reputation:
1
For the SetLayerTilemap method, you can just remove the duplicate one I will fix it in the next commit.
for the sample, I still worked with it so the archive I sent you is outdated.
what I did is a System.out.println(Global.tln.GetLayerHeight(0)); to display the height, and it crashes when the program executes this instruction. Same when I store it in a int variable and print it : It crashes at the variable asignation. GetLayerWidth crashes too, same for SetLayerMosaic : when I use it, it crashes the program.
Posts: 673
Threads: 33
Joined: Jan 1970
Reputation:
13
I think we're experiencing portability problems here. I cannot run my own TestWindow/TestPanel samples either, java gets complaining about crashes inside lots of innocent functions that otherwise work perfectly outside the binding. Nothing of this happened with the original 32-bit build. I'll investigate...
Can you publish the sources of your test, please?
Posts: 673
Threads: 33
Joined: Jan 1970
Reputation:
13
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.
Posts: 187
Threads: 22
Joined: Dec 2020
Reputation:
1
12-11-2020, 03:34 AM
(This post was last modified: 12-11-2020, 05:35 AM by System64.)
I'll try that
It's a shame a 64-bits Java installation isn't compatible with 32 bits libs too!
So if I understand well, jint becomes jlong and jshort becomes jint?
What should I do to fix that?
Update : One of the solutions is providing the 32-bits game version with an embedded 32-bits JRE
Posts: 673
Threads: 33
Joined: Jan 1970
Reputation:
13
The solution should be to convert jint to jlong, but only those that are being used to hold pointers. You can't do "replace all" because jint are used in many places for legitimate 32-bit integers. So it must be done by hand.
Maybe it is better to stick to full 32-bit versions (Tilengine.dll, TilengineJNI.dll an JRE) and forget about a native 64-bit binding...
Posts: 187
Threads: 22
Joined: Dec 2020
Reputation:
1
Yeah I think sticking to 32-bits will be easier, I also don't need so high values that 64-bits supports. But I'm on a 64-bits processor, how can I compile for 32-bits?
Posts: 673
Threads: 33
Joined: Jan 1970
Reputation:
13
You can use -m32 command line switch on C compilers that support both archtectures (tcc does)
Posts: 187
Threads: 22
Joined: Dec 2020
Reputation:
1
I compiled to 32-bits but this time, it crashes directly likes I have a white window with nothing and after, the app closes itself
Posts: 673
Threads: 33
Joined: Jan 1970
Reputation:
13
I'm trying to download the 32-bit JRE from Oracle, but their site is having difficulties and downloads don't work.
We have to forget about having native 64-bit version and stick to the working 32-bit. I have seen people complaining in forums about the same question: they need 32-bit JRE because their system relies on 32-bit JNI libraries than cannot be ported. That is, until Java implements a native pointer type for external libraries just like C# or Python have.
I'll update here when I have 32-bit JRE working again.
