I've completed binding essentially all of Allegro and its addons in my jalleg Java language binding for Allegro and deployed a snapshot to the OSSRH (snapshots for Maven Central). That means you can have your Java build with Maven or Gradle automatically download everything you need for Allegro development. Only a few methods are missing that were hard to map, and it might be possible some of the bindings may need tweaking.

I currently only have included pre-built Allegro Windows 64 bit DLL but if anyone can provide and/or test in Linux I'd appreciate it. Theoretically this should work in Android as well.

To build and run you need JDK 7 or later. If you just want to run the current example you only need JDK 7 64 bit for Windows or later version, you can download a pre-compiled zip, unpack and run the bat file.

There are a few examples but the default one that runs is a ball and paddle game using a handful of Allegro features:

• Display and primitives addon

• Font addon for scores

• Keyboard: A/Z left player, up/down right player

• Mouse: click where you want the paddle to be

• Joystick: controls the right player

• Haptics addon: if you have for example XBox controller as your joystick, you get rumble effect when ball hits

• Audio addon: sound effects generated by square waves

{"name":"BallAndPaddleExample.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/7\/9\/79dbc6949eb903b87993b07f0647614b.png","w":642,"h":528,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/7\/9\/79dbc6949eb903b87993b07f0647614b"}

Soon I will try a pull request to add jalleg as an Allegro 5 binding on liballeg.org.

Please do, no one else but myself have tried it yet, although I've run it on multiple machines. I'm especially interested if anyone who works with Allegro on Linux can try it, part of the point of this is to be cross-platform and I'm not sure how Allegro is loaded there. I also don't understand about al_run_main and how it's required on OSX and if it still applies in Java.

I'm willing to help where I can. One of my aspirations for this project is to make a tutorial eventually of "how to get into programming via Allegro and game dev" that would kind of build off of assumed basic programming knowledge (like what is a variable, loop, function, etc.) but start with install of Java and IDE tools and build something simple.

EDIT: I started the tutorial, it is here: https://github.com/gillius/jalleg/wiki/Allegro-for-new-Java-developers.

I know Allegro isn't going to take the world by storm for real dev, and certainly neither jalleg. But, Allegro and game dev was instrumental in inspiring me to learn how to program and really get into this career and so I feel that Java and other JVM languages like JavaScript perhaps are an easier entry point than C. Allegro ties into that because it is so crazy simple to build a simple retro-style game, which is more than enough to get into the basics of programming and game design. Allegro is the easiest game dev environment I've seen outside of the "point and click" game assembly things out there which really I consider some of those more like level editors than dev environments.

My other goal for this is totally self-serving and that is just for fun. I program typical line-of-business software for a job now and miss those days I could just hack on a game on a weekend.

What I need to know to make the Linux thing work is where I get the .so. Right now I just assume that the so is called liballegro_monolith-5.2.so and is located in the standard ldconfig path. If that assumption is correct then jalleg theoretically should just work. The alternative is for there to exist a mostly static-linked so (dynamic to libc/ldlinux/etc. of course as required) that I can put into my JAR file, then jalleg will unpack and load it as it does DLL on Windows.

OK, unfortunately, the binding would be different without the monolith library -- the way JNA works there would be a separate class for each component. However, it might not be that hard to refactor as I would just need to copy/paste the relevant functions into different classes and in the source I have them mostly sorted by the same pages as in the liballeg.org documentation (so each addon is in its own section).

It would be a little more work on the dynamic DLL/so loader as there would be a lot more files to unpack, and a little more work on the user of the library as there would be a separate import for each library instead of one import of AllegroLibrary, but it would allow the user to conditionally exclude DLLs/sos in their custom distribution to reduce the size. This was on my list of things I thought I'd have to do at some point but my first goal was just to simply get it working first.

Thanks for trying this out!

The start of the AllegroLibrary class had a hardcoded name of the library, but I just pushed a commit to make it configurable (the hardcoded value, and the new default is "allegro_monolith-5.2").

You can try it this way: gradlew -PAL_NAME=alleg run will try to load alleg.dll or liballeg.so. Or you can put an absolute path like gradlew -PAL_NAME=/home/bambams/allegro.so run

My understanding of JNA is that it first tries to load the so the normal way (i.e. from /lib and /usr/lib). Then it looks in your classpath for /os-arch/libx.so, as you see linux-x86-64/liballegro_monolith-5.2.so in your case. Since I don't have a JAR with static Linux Allegro in it, if you don't have Allegro installed in global ld paths, use the method above to specify the absolute path.

Documentation for NativeLibrary.getInstance parameter says the first parameter is "the library name to load. This can be short form (e.g. "c"), an explicit version (e.g. "libc.so.6"), or the full path to the library (e.g. "/lib/libc.so.6")."

Another thing I note about the doc is that it allows multiple classes binding to the same library, that's good it means I can break out AllegroLibrary per the way Allegro is normally built and put some logic to load the small file first, then try monolith.

Of course, Java has System.getenv("AL_NAME") to do that, so I just pushed a change to do exactly that. The "property business" is just a more common way in the Java world, because people are used to using java -DAL_NAME=blah to launch.

I just pushed a change:

1. If Java system propery AL_NAME is set, use it

2. else if environment variable AL_NAME is set, use it

3. else use "allegro_monolith-5.2"

So questions for Linux Allegro users... If you install Allegro (for example as from the Ubuntu PPA), what files do you get, where, and their names? I could search for them.

Also, if there is a common environment variable set for Allegro users (like ALLEGRO_PATH) that can be used to find the so, I can use that as well for those that build themselves.

EDIT: jalleg now automatically falls back to trying to load the Allegro components such as liballegro.so, liballegro_audio.so, etc. Therefore, you can follow https://wiki.allegro.cc/index.php?title=Install_Allegro_from_Ubuntu_PPAs or build and install Allegro "globally" (i.e. into /usr/lib or another ld path), and it will work with Linux out of the box. The AL_NAME method to point to monolith Allegro still works.

EDIT2: Full Linux getting started instructions available at https://github.com/gillius/jalleg/wiki/Allegro-for-new-Java-developers

Thanks for trying out the lib, Amarillion!

That error is when the JNA classes are loading. JNA tries to load native code installed in the system before it unpacks libraries bundled within the JAR itself. Based on https://github.com/java-native-access/jna/issues/281, that seems to be what might be happening to you, if you have libjnispatch.so on your ld path (i.e. in /usr/lib) for an older JNA, this will happen. The JNA author's suggestion from the GH issue is to use "-Djna.nosys=true" to force JNA to use the bundled native lib over the pre-installed one. It seems odd to me that a Linux would include a libjnidispatch.so, but it's also bad on their part that they didn't add (or use) numbers onto their so like libjnidispatch.so.0 that's supposed to handle this... This is a shortcoming of JNA I did not know about.

Other than that, what you did should work. You can also try to run my example program from the jalleg source by:

git clone https://github.com/gillius/jalleg.git
cd jalleg
./gradlew run

However, if your issue is libjnidispatch.so already on your ld path, the same problem will occur. I'm not sure -Djna.nosys=true will work on gradlew because it would apply to gradle and not the executing process. If this situation is more common I can observe also an environment variable like I did with AL_NAME.

I've programmed Java before, and used Allegro as well. Could you give me an example of what it takes to use jalleg? A small tutorial perhaps? Are the functions all named the same? How do you access them?

Oh, okay, I saw your tutorial. It doesn't included how to actually use jalleg yet, only to set it up. Are there any docs for jalleg included?

I would love to be able to use allegro with java. It could make some things so much easier than it is with swing.

Edit
I like how it (your example program and the ball) speeds up. Does the original pong do that?