Legacy syntax option?

[glowiak]

I am very excited about this project, finally not having to fear of making too many native calls. I also see some nice additions like Vector3 accepting constructor parameters.

But I noticed that the syntax is quite different from that of the regular Jaylib, and as my Jaylib game has over 5k lines of code with calls to Jaylib scattered all around rewriting it to match with the new syntax would be painful.

Would there be an option to umm create a "legacy syntax" class with wrapper functions to make them work like the old ones?

If not, I'll write something like that myself.

[glowiak]

Hmm. Just wrote a quick bunnymark, and the performance is slightly worse than on regular Jaylib (79fps vs 82fps).

[electronstudio]

Differences I am aware of:

• Constructors take parameters.
• I took the opportunity to change the method names to lowercase, since that is the Java standard.
• The field accessors are now getX() and setX() rather than x() again since that is Java standard.

I'm not sure how to handle people wanting to migrate. I could generate classes with the old names and accessors but you would probably be the only one who ever used them. Maybe I could have a flag when the library is built, then you could build a version with the flag set.

My tests show FFM is faster, but there's not a huge difference, so I wouldn't say you have to migrate.

[electronstudio]

I added the option, here is a build I did you can try that has the old names: jaylib-ffm-0.0.2-SNAPSHOT.zip

It might be slightly more optimized than 0.0.1 also. If you send me your bunnymark I will try that.

[electronstudio]

Here's my benchmarks https://github.com/electronstudio/megabunny . (It draws one million bunnies but it doesn't move them so you will only see a black screen.)

[electronstudio]

There seems to be some debate over what is the preferred name for getters/setters. https://stackoverflow.com/questions/59981081/post-java-14-getter-setter-naming-convention I could maybe include both versions.

[glowiak]

@electronstudio I mean, I know Java's naming conventions and I use them, but this is a binding to a library that follows its very own naming scheme.

Plus, like I wrote almost 10 thousand lines of code using the old naming conventions, I am quite used to them.

[glowiak]

Tried the 0.2-SNAPSHOT build.

This one has the same performance as the JavaCPP version.

Thanks.

[electronstudio]

My goal with the naming has always been to be as Java-like as possible. The only reason Jaylib uses the C naming is because that's how JavaCPP generates it.

You might find performance increases if you do your own memory management by creating an Arena and then passing it to any functions that will take it, like this https://github.com/electronstudio/jaylib-ffm/blob/e8b4b3f6c0b91da22d93a97e763bf7370609ff88/src/main/java/uk/co/electronstudio/tests/Bunnymark.java#L31

[glowiak]

Right

Thank you!

[electronstudio]

btw I was thinking of doing a Java FFM binding for SDL, I only did the Raylib one because I thought it would be an easy way to get some experience with FFM before trying that. (the only current full Java binding for SDL I can find is JNA, which is much slower than Java JNI or FFM. I did a JNI one long ago but it was done by hand, not autogenerated, and so only covered a small part of SDL API.)

[electronstudio]

I've included both types of getters/setters as standard. You'll still need to build with LEGACY_NAMES if you want the uppercase function names.