I want to know how to export/distribute my LWJGL game by hand, without a tool (apart from Eclipse :P),
so that i dont rely on the ‘magic’ of JarSplice. I want to be able to structure my games/LWJGL application the way i want, with a proper ‘folder hierarchy’, and make sure it runs properly on every Platform compatible, in a controlled manner. (Folder structure; versioning; resources etc.)
I need control over this process :>
I can’t figure out where to start this kind of stuff.
I’m not really sure what you’re asking. What specific problem are you having? But I’ll try to give you more details:
The most difficult part about LWJGL deployment is that it requires native libraries. These native libraries give LWJGL access to your hardware, such as your graphics card, for OpenGL. That’s what makes it so awesome.
The problem is that you have to tell Java where those native libraries are located. You can do this as a command line argument, but no users want to run games via the command line.
Tools like JarSplice do that for you: they wrap your LWJGL program in another program that tells Java where the native libraries are located, then runs your LWJGL program. There really isn’t a lot of “magic” involved.
But i though that the application only has to know about the natives delivered with LWJGL in the natives folder?
To reformulate my ‘question’, what do i have to learn, to understand the process of exporting and ‘hook up’ the needed references (LWJGL jars/) and natives,
in order to have the game running on a certain OS. (Either in EXE/DMG etc.)
Furthermore, do you see any advantage of putting the natives (Windows/Linux/OSX) together in one app? I though i was better of including the right natives for a certain ‘port’.
To put it this way, i guess i ‘want’ to know how your program(and JarSplice) put these projects together.
Also with JarSplice etc. i dont know how to order folders in any way… which is a real problem for me!
I do NOT, like the fact that a little program puts my project together, and if it works, it just works…, i prefer knowing whats up
Edit: Nice website, a lot of info on there
I hope i explained it a tad better this time.
Thank you very much for answering so quick!
I’m still not totally sure what that means. If your application uses native libraries, you have to tell Java about the natives for your system- how are you running your program on your machine? If you’re running it from eclipse, you have to tell it about the natives by attaching the native library to the jar. If you’re running from the command line, you have to set -Djava.library.path command line option.
The user of your game has to do the same thing- but that can be pretty annoying for an end-user. That’s why we use a wrapper like JarSplice or JarMatey to do it for them.
First: understand the above, the java.library.path stuff. Try running a LWJGL application via the command line.
Second: Putting together a platform-specific executable can be pretty annoying. If that’s really the route you want to go, you’d have to google “how to create a Windows executable”, “how to create a mac app”, “how to create a runnable file on linux”, etc. I don’t think it’s very complicated, it’s just annoying to have to handle yourself.
I’d personally put them all in one self-extracting jar using JarMatey. The benefit to this is that I only need to worry about sending people one file- no worrying about making sure I give them the right version. The only downside is that the download size might be a little bigger, but that’s really not a concern to most people.
But basically, all I’m really doing is detecting what type of system we’re running on, extracting the correct natives, then running the application with the -Djava.library.path set using a ProcessBuilder.
I’m not really sure what that means either. Why do you need to order the folders?
That’s the “launcher” class that runs when the exported jar is run on the user’s computer. It extracts the correct natives and then runs the real program after setting the native library path. That’s what JarSplice is doing too.
Also, it’s worth noting that JOGL and libGDX both have these kinds of “self-extracting” mechanisms in place.
If you don’t want to use a third party application.
System.setProperty("org.lwjgl.librarypath", new File("natives").getAbsolutePath());
And have all the library files in a folder called natives
When you export to a jar, the folder should be in the jar’s directory. If you run in eclipse, the folder should be outside of the SRC folder, but still in the project folder.
I’m not trying to argue, but I’ve never seen that. Then again, most “real” games are bundled up as a platform-specific executable, not as a jar.
Your approach will certainly work. It just depends on how simple you want to make it for the users. Easier for you = harder for the users. Easier for the users = harder for you. It’s a trade-off. I generally go the “hard for me, easy for users” approach, but your way certainly works too.
I can see that my urge to ‘do it all by myself’, will turn into something i’ll most probably break first, before actually beeing able to use it properly, especially now where i want to finish my game.
I guess, for now i start to learn the java path stuff when i’ve got time, and eventually when i have time do some work on the rest, try out your suggestions
It seems to be nothing complicated, but having to delve into a new topic again, is not acceptable i think, after all. (Atm, i have to learn all sorts of stuff to finally get some stuff going like savegames etc. which turns out to be a huge pain to get going with a large, complex amount of data).
Quote from KevinWorkman:
[quote]I’m not really sure what that means either. Why do you need to order the folders?
[/quote]
Well i wanted to structure my final game the way i wanted because:
‘more’ beautiful ;D (programmer urge i guess)
i’d like to have an idea how things change over time, and i dont know how the program is putting it together
Just having an executable and a resource folder doesn’t quite cut it for me, i guess you can understand that i want a little more control of that:
I dont just dump all of my classes in my ‘src’ package either …
I too had faced this problem once, but I went on and implemented a [icode]NativesLoader[/icode] class. This class will extract the native libraries packaged inside the JAR to a temporary directory, sets the [icode]java.library.path[/icode] property to the temporary directory where I extracted the natives. Finally in the end, I delete the natives and the temporary directory that I created before quitting the game.
Again, I really don’t want to bicker- but the examples you’ve shown are of installation directories, which is an option I already brought up, using JWrapper.
What I don’t see is a game that consists of a single executable (not installable) file that requires a data directory next to that executable. That’s too easy for users to mess up, so even though it would be easy for a developer to implement, it’s not something that many “real” games do.
The examples you’ve shown of an installation directory aren’t really what I’m talking about. That’s certainly another option, but it involves using something like JWrapper to create an installer.
Sorry if I should have been more clear, but I think we’re talking about two different things at this point.
Yeah, exactly. Step on is understanding what the java.library.path argument is doing. Any other solutions are going to set this argument somehow, so it’s the most basic building block of any more complicated solution, even one you write yourself.
That’s understandable. I don’t really remember how JarSplice organizes its natives, but I can tell you how JarMatey organizes its natives:
First, the output jar contains a directory called JarMateyNatives.
Inside that directory, you can put directories for any OS you want to include natives for: Windows, Mac, Linux, for example.
Then inside those directories, you can put native files for those specific operating systems. You’d put dll files in your Windows directory, etc.
You can also put subdirectories for specific architectures inside the OS directories: Windows/amd64, for example.
Then inside those subdirectories, you can put native files for those specific OS/architecture combos.
When JarMatey runs, it detects what kind of system it’s on, then extracts the native files from the corresponding directories. They are extracted to a temporary directory, and the java.library.path is set to that temp directory. Then when the program closes, that temporary directory is deleted.
You can also include external resource files in JarMatey if you want, and the process is pretty much the same: JarMatey extracts these files to a temporary directory, then sets the “current directory” to that directory, so any code you write can assume those files or folders are next to the jar.
You can use whatever organization you want for the external files.
Anyway, I’m not trying to “sell you” on JarMatey, just using it as an example for how things might work.
Thank you very much again, i’ll look into all the java stuff, and then i’ll get working on my own solution.
Game programing is a never ending hole it seems
[quote]Quote by KevinWorkman:
Anyway, I’m not trying to “sell you” on JarMatey, just using it as an example for how things might work.
[/quote]
You made me understand, how these tools work, and that’s something i really appreciate, since for me it really was ‘magic’
Your tool is definitely a source to learn from, so thank you very much for posting it
