Tilengine on Java - Printable Version +- Tilengine - The 2D retro graphics engine forum (http://tilengine.org/forum) +-- Forum: English forums (http://tilengine.org/forum/forumdisplay.php?fid=3) +--- Forum: Support (http://tilengine.org/forum/forumdisplay.php?fid=7) +--- Thread: Tilengine on Java (/showthread.php?tid=952) |
Tilengine on Java - System64 - 12-01-2020 Hello! Is the latest version of Tilengine compatible with Java? Can I use the newer functions if I use the bindings? Thanks for the answer. RE: Tilengine on Java - megamarc - 12-02-2020 Hi! As any native system C library, you can use Tilengine from any language that suports interfacing with system libraries. Java requires a JNI binding to do this. I developed one at the beginning, to demonstrate Tilengine inside a Java Applet, but it's largely outdated and unmaintained nowadays. However, should the JNI plugin be updated, you could use Tilengine without issue. Here's the binding: https://github.com/megamarc/JTilengine RE: Tilengine on Java - System64 - 12-02-2020 Thanks! So if I put the latest Tilengine DLL library, I can use the newer features of the library? Shouldn't I add the new functions to this file? https://github.com/megamarc/JTilengine/blob/master/jni/TilengineJNI.c ? RE: Tilengine on Java - megamarc - 12-03-2020 Hi! Provided samples should work with old JNI, as they don't use newer features of the engine. However, to access these newer features, yes, TilengineJNI.c AND Tilengine.java should be updated with required functions, currently not present. RE: Tilengine on Java - System64 - 12-03-2020 (12-03-2020, 01:27 AM)megamarc Wrote: Hi! I don't know C very well ans I have basic knowledge to Java (but I know OOP). Can I update it easily ? RE: Tilengine on Java - megamarc - 12-03-2020 Hi, Doing a binding is more a tedious work than a challenging one. It requires repetitive work done by hand that is error-prone, because you have to map every function and data structure, keeping names, parameter ordering and type. However you need a moderate experience in both languages, as you're interfacing between them. Definitely not a beginner task. You can figure out the mechanism by examining a working example -in this case TilengineJNI.c and Tilengine.java- and learning about JNI, for example here (but there are many tutorials out there): https://www.baeldung.com/jni RE: Tilengine on Java - System64 - 12-03-2020 I'll take a look to theses exemples and give it a try. By the way, are the bindings stuck to an old version or will they updated some day? Because they can be useful for people that use others languages than C / C++. RE: Tilengine on Java - megamarc - 12-04-2020 Hi, The bindings that are updated more are C# (for compiled, managed language) and Python (for interpreted, scripted language). Other bindings are contributed by other people, or are a proof of concept demonstrating the integration of Tilengine. Unitil now nobody has shown interest on the Java binding, so I'm afraid that keeping it alive is not a priority at this moment. Most people is using the library directly in C. RE: Tilengine on Java - System64 - 12-04-2020 (12-04-2020, 04:15 PM)megamarc Wrote: Hi, Thanks anyway! I'll try to learn C and use it in pure C or updating the Java binding. I took a look to this binding too. The most of the binding is pretty repeatitive and easy to understand. But there is some parts I don't understand well. For exemple why this part only has 2 lines of code Code: JNIEXPORT jboolean JNICALL Java_Tilengine_SetBGPalette (JNIEnv* env, jobject thisobj, jint palette) and this part has more code? Code: JNIEXPORT void JNICALL Java_Tilengine_SetRasterCallback (JNIEnv* env, jobject thisobj, jobject obj, jstring methodname) RE: Tilengine on Java - megamarc - 12-05-2020 You picked two extreme cases In order to communicate, sometimes the binding must do data conversion before passing the arguments. In other cases, it must create and destroy elements that are needed on the Java side. The first example is the simplest one: no conversion of any data is needed, just call the function. Done! The second one manages the callback, the Java function that needs to be called from the native library. Callbacks are always the trickiest part of a binding. In thsi case, it requires destroying a previously allocated Java object, and creating a new one. In addition, it gets a text string, that needs explicit conversion because C and Java don't represent strings internally in the same way. That's why this function is the most complex of all. |