Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Tilengine on Java
yeah it complains because gcc compiled a buggy dll, but it works fine now.

I'll change the to indicate people to use tcc on Windows, update the dates on the licenses, commit and do a first pull request.
I've accepted your pull request as a "draft", that I must review. Thanks! I guess you'll recieve a notification when the merge is done
You're welcome! If there are issues, don't hesitate to tell which ones you have encountered!
Thank you for accepting my pull request

There are still things I need to update, so I'll do another one soon
Great :-)

I've done another push with some more modifications after yours, if you want to continue from there, then you should sync again
It's not related directly with Java, but I want to avoid hardcoding certain things, especially raster effects

Can I use a scripting language likes LUA for that kind of tasks and keeps the main program in Java (or another language)?
Last year I released a modified tilengine version with Lua support. It's quite different than the other bindings, because this version is designed to act as a retroarch emulation core plugin, with the game itself written in Lua at the end. To have a rough idea:

Classic binding load chain:
Java game -> TilengineJNI.dll -> Tilengine.dll

Tilengine_libretro with Lua load chain:
RetroArch -> Tilengine_libretro.dll -> Game in Lua

Here's the project:

Basic example in Lua:

To use two different languages, you have to look for specific way (it may not be possible at all) for those languages. For Java + Lua you can check this forum thread:
Seems LUA is better with C language, someone recommends to use Groovy, jruby or jython
again, I don't know if I can interact with the game directly for graphics effects

Otherwise I have 2 more ideas :
- I can use game objects to define which effects is used : that still needs Hardcoding but still better than nothing
- I can use a classloader that loads a compiled class with a static method inside : More complex but more flexible
Whichever method you choose will be ok  Smile

However, a little advice for this early stage of evaluation and prototype testing. Don't over-engineer it. I mean, don't create a surrounding infrastructure that is more complex than the functionality you try to accomplish. Adhere to the KISS principle: Keep It Short and Simple.

Forum Jump:

Users browsing this thread: 1 Guest(s)