Version 0.7: Precompiled binaries

Version 0.7: Precompiled binaries

The new things in Magnetic Transports version 0.7:

• Native precompiled binaries released.
• Games can now be saved (and loaded).
• Gliders can now be launched in eight directions from the landing pads instead of just one.
• The Configuration class has taken over the responsibility for a lot of fields that were previously hard coded static final.
• User can now define all configurable values held by Configuration.

The native precompiled binaries are available in the download section, just keep in mind that the project is still very much in the development stage. The different versions basically consist of the same jar files but with different native JOGL bindings. The reason that I split them up is that each of the bindings take up about one MB and I opted for making three native 1.5 MB packages instead of one universal 3.5 MB release. As a result one would think that if one package worked then all would work (as one can assume JOGL is fairly well tested), but surprisingly that is not the case. The Linux version should work well as it is the one that has been tested during development. I have no possibility to test the MacOSX package as I don't have access to such a platform. The surprising thing (or maybe not) is that the win32 package does some very strange things when I tested it, the game window opens up and all but no listeners are ever notified of anything (hence nothing happens). This would suggest that there is some thread issue or something even stranger going on in the win32 version, I will look into it when I get the time. However making a precompiled version that works on windows is not a huge priority for me until the game is fully developed.

One thing that I found annoyingly hard though was to set things up so that users would just have to run the jar file to run the game. Therefor I'm going to share how I did it in case someone wants to know:

How to package JOGL so it doesn't have to be installed by the user.

This is how I set up the releases: I have the game's jar file (only containing the game) in the main dir, then I have a dir named lib in which I put the jogl.jar and the native bindings (libjogl.so, libjogl_cg.so in linux). There are two problems that have to be dealt with in order to get the game to launch (assuming that the user does not have JOGL installed in the JRE), a simple one: put jogl.jar in the classpath, and a harder one: put the lib dir in the library path (and then load the libraries).

The solution to the first one should be well known, just put "Class-Path: lib/jogl.jar" in the manifest. As far as I know there is no simple manifest solution to the second problem, so one has to modify the library path via System's java.library.path. But the value is basically read only while running a program so one has to use a trick.

private static final String LIB_DIR_NAME = "lib";
[...]
//Set the library path and load the jogl library.
try {
	//Reset the "sys_paths" field of the ClassLoader to null.
	Class clazz = ClassLoader.class;
	Field field = clazz.getDeclaredField("sys_paths");
	boolean accessable = field.isAccessible();
	if(!accessable) {
		field.setAccessible(true);
	}
	Object original = field.get(clazz);
	try {
		//Reset it to null so that whenever "System.loadLibrary" is 
		//called, it will be reconstructed with the changed value.
		field.set(clazz, null);
		
		//Get the base dir of the program.
		String basePath = System.getProperty("user.dir");
		//get the system dependent file separator.
		String fileSeparator = System.getProperty("file.separator");
		//Get the system dependant path separator.
		String pathSeperator = System.getProperty("path.separator");
		//Get the current library paths.
		String libPaths = System.getProperty("java.library.path");
		//Create the path to our library dir.
		String libDir = basePath + fileSeparator + LIB_DIR_NAME;

		//Append our library dir to the existing library path.
		System.setProperty("java.library.path", libPaths + pathSeperator + libDir);
		//Load the libraries.
		System.loadLibrary("jawt");
		System.loadLibrary("jogl");
	} finally {
		//Revert back to the original.
		field.set(clazz, original);
		field.setAccessible(accessable);
	}
} catch(Exception e) {
	e.printStackTrace();
}

Yes, it is dirty and probably shouldn't be used it if there was another way. However I'm yet to find a better way to do it. I might replace it with something other in the future, but it's not on the top of my priority list as the project is still in development.

The side effect of this is that the jar has to be launched from the directory it resides in. I.e. the libraries will not be loaded if the user does something like "java -jar magnetic-gliders/magnetic.gliders.jar", double clicking and so on does execute from the correct directory.

So that is it, those two things should enable users to run the jar file directly without any webstart or installation of native bindings.

Back to the new features:

This is the new launch dialog. North is up on the screen and so on, so the transports launch in the physical direction of the button. This should remove the luck that was involved in map generation, the game used to become a whole lot harder if all transports were stuck on the east side of the map.

All static final fields that should be user configurable were moved to a new enumeration in the Configuration class. Then all those enumerations were projected onto the configuration dialog. This of course enables the user to make the game trivial, or excruciatingly hard, the choice is meant to be free.

The class diagram has also been updated, there were hardly any structural changes in the code to talk about (which is to be expected at this stage). The new changes are mostly reflected in the javadoc, which is quite large too.

I'm almost out of new things to do now *cough* event animation *cough*. So I will mostly focus on improving things from here on.