Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (497)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  Exporting Java game using Jogl into ONLY one Jar in Eclipse  (Read 5477 times)
0 Members and 1 Guest are viewing this topic.
Offline M2009

Junior Member





« Posted 2009-05-25 23:28:37 »

Hello.

I'm making a simple little test game with Jogl. I have set up the "Java Build Path" so that these two jar files are "Referenced Libraries":

gluegen-rt.jar
jogl.jar

Then I have downloaded two DLL files and placed them in the project "root" folder (the folder that has the "src" and "bin" folders):

jogl.dll
jogl_awt.dll

With these two DLL files in that folder I am able to "Run" the game from Eclipse. However when I export the game as a "Runnable JAR file" the game will not start when I execute the jar file. If I place the two DLL files in the same folder as the jar file I can however run the game.

My operating system is Vista 64. I have realized those two DLL files are just for my OS. However I want my game to work on Linux also (and any other system that supports OpenGL for that matter, as Java was intended).

I guess it's possible to put all OpenGL binaries for every system on Earth in a RAR archive, and then include it with my game distribution. However this requires the user to find the correct binaries and place them in the same directory as the jar file. And what if the binaries get old or does not exist?

I have played a few Jogl games from my browser, using Java Web Start (jnlp file). I realized that these games do not require any DLL files to be placed outside of the jar file, and when I downloaded and inspected the jar file the DLL files was not inside it. This is also true for the official Jogl demos at: https://jogl-demos.dev.java.net/

Why can these Java Applications run Jogl??

I want to distribute my game as a single jar file too, I don't want to have to bundle the neccessary binaries for Jogl.

What's the secret?

Offline lhkbob

JGO Knight


Medals: 32



« Reply #1 - Posted 2009-05-26 05:05:41 »

The jnlp files for those applications are setup so that the proper native libraries are downloaded, too.  They are not embedded within the jar.

Offline M2009

Junior Member





« Reply #2 - Posted 2009-05-26 10:46:13 »

So I have to include the binaries when I release my game?

Can you tell me how I can make a jnlp file that loads the correct binaries depending on if you start the game on linux/windows/other?

I would like to be able to distribute this game folder:

GameName/start.jnlp
GameName/v1.0.jar
GameName/data/linux/<open gl binaries>
GameName/data/windows/<open gl binaries>

Then the person that want to play the game just have to double click on "start.jnlp", then "v1.0.jar" will launch with the correct binaries depending on which operating system he is on.

I'm assuming that I can use a jnlp file even though nothing is supposed to be downloaded (for offline usage).

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline lhkbob

JGO Knight


Medals: 32



« Reply #3 - Posted 2009-05-26 17:14:08 »

A jnlp can be run in offline mode, but it must download everything first, so I don't think this is the route you want.  The benefit of using the jnlp would be that only the correct OS natives would be downloaded.

If you're giving them all of the natives anyway in your folder structure, why not just place all native libraries in the same directory?  The JVM is smart enough to only load the ones for its operating system.

Offline cylab

JGO Ninja


Medals: 49



« Reply #4 - Posted 2009-05-26 17:20:37 »

The JVM is smart enough to only load the ones for its operating system.
Correct me, if I am wrong, but unfortunately that won't work for all platforms. For example the dlls for win32 and amd64 are named the same and thus cannot be placed in the same directory. Easiest way is to include all native libraries in your distribution and provide different start-scripts for the different platforms.

Mathias - I Know What [you] Did Last Summer!
Offline M2009

Junior Member





« Reply #5 - Posted 2009-05-26 21:53:44 »

cylab: Yes I have noticed that problem.

So i guess I'm stuck with having different start scripts for each platform? Sad

Or maybe not... it would be great if I can somehow check in the main class which operating system is being run, and then I just set which binaries to use inside the class. Then I will get this distribution:

GameName/GameName_v1.0.jar
GameName/data/linux/<open gl binaries>
GameName/data/windows/<open gl binaries>

Which is even better than before because regardless of which operating system is being used only "GameName_v1.0.jar" needs to be run.

So new question, is it possible to tell the Java Virtual Machine which binaries to load inside the main class?

Looking for something like this:

if (windows64bit){
loadThisBinary("windows/64/blabla.dll")
} else if (windows32bit) {
loadThisBinary("windows/32/blabla.dll")
} else if (linux) {
loadThisBinary("linux/blabla.dll")
} else {
//show dialog that the user needs to fix the correct Jogl binaries himself and that without them a exception will be thrown
}

This way the same jar file can be opened on all operating systems and the correct binaries will be loaded automatically without the user being bothered at all. Smiley

Offline lhkbob

JGO Knight


Medals: 32



« Reply #6 - Posted 2009-05-26 22:12:35 »

Correct me, if I am wrong, but unfortunately that won't work for all platforms. For example the dlls for win32 and amd64 are named the same and thus cannot be placed in the same directory. Easiest way is to include all native libraries in your distribution and provide different start-scripts for the different platforms.

Oooh ... good point, I didn't think of that.

Offline bienator

Senior Member




OutOfCoffeeException


« Reply #7 - Posted 2009-05-27 16:27:47 »

This is a pretty annoying issue and should have been solved long time ago from JOGL's point of view.

So new question, is it possible to tell the Java Virtual Machine which binaries to load inside the main class?
In theory yes (System.loadLibrary()) but i fear this won't work since jogl will try to load the libs again (not sure). Secondly i think the JVM can't load natives directly from jars, AFAIK library path has to consist of plain folders.

But you could do it the same way like webstart does it. Use one lib folder and copy at first start the platform dependent libs into the path. In fact that what we've done in the NetBeans OpenGL Pack on module install (in a jogl independent manner) too.
https://netbeans-opengl-pack.dev.java.net/source/browse/netbeans-opengl-pack/trunk/native-lib-support/src/net/java/nativelibsupport/

Offline M2009

Junior Member





« Reply #8 - Posted 2009-05-27 20:12:01 »

Ok, what I tried was moving the DLL files into a folder "test" I placed in the root directory. Then I put these two lines at the top of main:

System.loadLibrary("test/jogl.dll");
System.loadLibrary("test/jogl_awt.dll");

When I ran the application I got this error:

Exception in thread "main" java.lang.UnsatisfiedLinkError: no test/jogl.dll in java.library.path
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.loadLibrary0(Unknown Source)
at java.lang.System.loadLibrary(Unknown Source)
at mainpack.GameName.main(GameName.java:6)

How can this be fixed? Notice that I don't want the user to have to pass any application arguments to the jar file, I want him to be able to run it just from double clicking the jar file.

In case this is a dead end, can somebody please post a sample .jnlp file that launches the jar with the correct binaries?

Offline cylab

JGO Ninja


Medals: 49



« Reply #9 - Posted 2009-05-27 22:15:47 »

You could write yourself a laucher-app, that extracts the platform specific files and calls java again with the appropriate commandline arguments.

Mathias - I Know What [you] Did Last Summer!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline lhkbob

JGO Knight


Medals: 32



« Reply #10 - Posted 2009-05-27 23:54:20 »

Ok, what I tried was moving the DLL files into a folder "test" I placed in the root directory. Then I put these two lines at the top of main:

System.loadLibrary("test/jogl.dll");
System.loadLibrary("test/jogl_awt.dll");

loadLibrary doesn't take a path, it takes the library name.  The library name is translated into a file name differently, for example on windows jogl becomes jogl.dll, but on mac it's libjogl.jnilib.  All of this conversion is automatic.  I'm pretty sure that a folder can't be part of the library name.

There are two options to solve this:
1. use loadLibrary and add /test/ to your java.library.path (which should be configurable in the MANIFEST file of your jar).
2. use System.load() and System.mapLibraryName():
1  
2  
3  
String libName = "jogl";
String libFile = System.mapLibraryName(libName);
System.load("test/" + libFile);


These options are based on the assumption that it's not a problem loading the native libraries behind JOGL's back.

Offline CyanPrime
« Reply #11 - Posted 2009-05-28 02:29:53 »

Quote
1. use loadLibrary and add /test/ to your java.library.path (which should be configurable in the MANIFEST file of your jar).
http://forums.sun.com/thread.jspa?threadID=5370285

How do you set the manifest's library path? cause they said you can't.
Offline lhkbob

JGO Knight


Medals: 32



« Reply #12 - Posted 2009-05-28 04:52:27 »

http://forums.sun.com/thread.jspa?threadID=5370285

How do you set the manifest's library path? cause they said you can't.
That's a good point, I should stop giving advice without trying it first.

Anyway, here's blog that should help solve your problem.  Read down to the last comment with the large code post.
http://www.javalobby.org/forums/thread.jspa?threadID=15512&tstart=0

Offline cylab

JGO Ninja


Medals: 49



« Reply #13 - Posted 2009-05-28 20:21:30 »

That's a good point, I should stop giving advice without trying it first.

Anyway, here's blog that should help solve your problem.  Read down to the last comment with the large code post.
http://www.javalobby.org/forums/thread.jspa?threadID=15512&tstart=0

There might be a simpler way to do it by invoking the main-method via reflection:
http://www.java-gaming.org/topics/do-i-have-to-put-the-libs-in-the-system-folder/20162/view.html
(This is for JInput, but might apply to JOGL as well)

Mathias - I Know What [you] Did Last Summer!
Offline M2009

Junior Member





« Reply #14 - Posted 2009-05-29 00:04:00 »

I thought of a solution myself that works rather well. Don't know why I didn't think of it sooner; I just check which binaries are needed, then I copy them into the root directory (where the jar is). "." seems to always be part of the "java.library.path".

Here's my solution:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
/* Imports used for this. */
import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.nio.channels.FileChannel;

/* Code to be placed in the application's main method. */
try {
    String[] binaries = {"win/64/jogl.dll", "win/64/jogl_awt.dll"};
    for (int i=0; i<binaries.length; i++) {
        File srcFile = new File("./binaries/" + binaries[i]);
        File dstFile = new File("./" + binaries[i]
                .substring(binaries[i].lastIndexOf('/')));
        if (!dstFile.exists()) {  //safety - keep existing files
           dstFile.createNewFile();
            FileChannel source = null;
            FileChannel destination = null;
            source = new FileInputStream(srcFile).getChannel();
            destination = new FileOutputStream(dstFile).getChannel();
            destination.transferFrom(source, 0, source.size());
            source.close();
            destination.close();
        }
    }
} catch (Exception e) {
    System.err.println("Error (insert explanation of what has gone " +
            "wrong here and show instructions to the user so that he " +
            "can do the job manually).");
    System.exit(1);
}


The code will be placed at the top of main() and what it does is copying two DLL files to the same folder as the jar (from inside a "binaries" folder that rests in the same path as the jar).

I've tried making the code clean so that it will be easy to read, use and understand, that way other people who find this topic can just copy it and be good to go. I've read by the way that the way I'm copying files should be really effective.)

What would be great now is a way to compress the binaries. Maybe hide them inside the jar file and then extract them? Is there a way of doing that without making it fail on a lot of computers due to security issues (for example in schools)? Otherwise is it any way of compressing them into their own archives somehow and then extract them?

"jogl.dll" and "jogl_awt.dll" takes 328 KiB uncompressed, and if that is how it is for many other system binaries as well the inclusion of all libraries will easily add over 1 MiB of unnecessary space. By using WinRAR's best compression method I'm able to reduce the two DLL files from 328 KiB to only 26.7 KiB.

An additional thought, can the running application launch other jars with arguments? Maybe even arguments to the Java Virtual Machine? If so, I can just have main() check which OS it is running on and then start the same jar file again with the "-Djava.library.path=..." argument, adding the correct binaries folder that way. Right? (An additional argument would be passed on to the jar so that main skips the OS check and proceeds to launch the game.)

Please try to answer all questions in this post if you can, they are all important. Smiley

(Note that this topic is NOT to be considered over yet just because I said "here's my solution" at the beginnig of the post, hehe.)

Edit: Clarified some things.

Offline cylab

JGO Ninja


Medals: 49



« Reply #15 - Posted 2009-05-29 10:20:47 »

I copy them into the root directory (where the jar is). "." seems to always be part of the "java.library.path".

Nope. This is only true for windows, because windows adds the current working directory implicitely to the PATH and under windows the default java.library.path contains the PATH environment.
Also this might fail (just speculating) if you have static references to JOGL code in your main class.

Best solution currently seems to be to create an extra laucher class without references to any class, and have a main like this:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
public static void main(String[] args)
{
    try
    {
        // implementation of the evalPlatform() method left to the student for exercise ;)
       String platform = evalPlatform();

        // Set the java.library.path first
       System.setProperty("java.library.path", System.getProperty("user.dir") + System.getProperty("file.separator") + platform);

        // Get the reference to the actual app class after setting java.library.path to make sure, no subsystem calls loadLibrary too soon
       final Method appmain = Class.forName("your.MainClass").getMethod("main", new Class[]{String[].class});

        // Don't know why the original author of this snippet copies the arguments to a new array, but hey - let's do it anyway...
       final String[] argz = new String[args.length];
        System.arraycopy(args, 0, argz, 0, argz.length);

        // Now start your app
       appmain.invoke(null, new Object[]{argz});
    }
    catch (Exception e)
    {
        System.err.println("Error (insert explanation of what has gone " +
            "wrong here and show instructions to the user so that he " +
            "can do the job manually).");
         System.exit(1);
    }
}




Mathias - I Know What [you] Did Last Summer!
Offline M2009

Junior Member





« Reply #16 - Posted 2009-05-29 19:46:28 »

Oh, that's too bad. I'll try your suggestion soon.

In the mean time, anybody know if a jar file can be launched from inside the main method with program arguments and/or VM arguments?

Also, is it possible to extract files from a jar? So that the binaries can be compressed.

Offline cylab

JGO Ninja


Medals: 49



« Reply #17 - Posted 2009-05-29 20:21:28 »

In the mean time, anybody know if a jar file can be launched from inside the main method with program arguments and/or VM arguments?

You can simply call the main()-Method of a class with the arguments.

If the jar is not part of your classpath, you could use an URLClassloader with the jar as resource and use classLoaderInstance.loadClass("your.MainCLass").invoke(null, new String[]{"arg1","arg2"}). You can even read out the jars manifest and get the Main-Class attribute to get the name of the class. You can't pass system properties in the call - you would have to use System.setProperty() before the invoke call.

Also, is it possible to extract files from a jar? So that the binaries can be compressed.

Yes it is Smiley see the javadoc for the JarFile class.

The most problematic part might be to reliable get hold of the location of the jar file, since you have no way of getting the location of your own jar and the user.dir system property and relative paths only work, if your jar is started from within the directory where it is located. So with a "java -jar /absulute/path/to/jar" you are screwed.

Mathias - I Know What [you] Did Last Summer!
Offline M2009

Junior Member





« Reply #18 - Posted 2009-05-29 21:32:44 »

Tested your suggestion now, it did not work.

I have experienced with Runtime.getRuntime().exec() and found out something that works, but not unless I start the jar file from Window's cmd terminal. Very strange.

@Your first answer, that does not work. You can't for example send "-Djava.class.path=binaries" to the virtual machine that way. With the exec() method however I have found out that you can, but it only works from the cmd for some reason.

@Your second answer, I rather have someone that knows to tell me. It's much better since you only get the information relevant and saves me the trouble of reading page after page after page.

I have a way of getting the jar file that is being executed:

File jarFile = new File(Global.class.getProtectionDomain().getCodeSource().getLocation().toURI());

So if you wish to for example get the file size of the current jar that is being executed:

if (jarFile.isFile()) {long jarFileSize = jarFile.length();}

Sorry for the hasty reply, I have to travel and I'm a bit stressed at the moment.

Offline cylab

JGO Ninja


Medals: 49



« Reply #19 - Posted 2009-05-29 23:35:49 »

Tested your suggestion now, it did not work.

What was the problem? Are you sure, the path you set with System.setProperty() was correct?

I have experienced with Runtime.getRuntime().exec() and found out something that works, but not unless I start the jar file from Window's cmd terminal. Very strange.

You probably have to pass the absulute path ti the java.exe for exec to make it work correctly. Problem is how to find this.

@Your first answer, that does not work. You can't for example send "-Djava.class.path=binaries" to the virtual machine that way.

Right, you can only pass the normal application arguments, not the jvm ones.

@Your second answer, I rather have someone that knows to tell me. It's much better since you only get the information relevant and saves me the trouble of reading page after page after page.

This wasn't meant as a rtfm rant. I just thought you would have missed this class.

Also it's sometimes hard (or cumbersome) to explain details in a forum from the head. Even if I would have provided you with some pseudo code, you would probably have needed to read the doc to get it to work. And reading the javadoc of the classes you will use doesn't hurt Wink

I have a way of getting the jar file that is being executed:

File jarFile = new File(Global.class.getProtectionDomain().getCodeSource().getLocation().toURI());

Never thought of that. Thanks for the hint!

Mathias - I Know What [you] Did Last Summer!
Offline cylab

JGO Ninja


Medals: 49



« Reply #20 - Posted 2009-05-30 00:07:29 »

I tested my own suggestion and unforunately - as stated - it doesn't work. After that I tried the method from the javalobby forum, that lhkbob posted and this does indeed work Smiley It might be vendor-specific (sun vm only!?) and not future proof, but it should suffice for now.

Here is my working Launcher class (the Launcher might not be needed, but this way it is nicely separated and maybe I extend this to a generic wrapper):

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
import java.lang.reflect.Field;

/**
 *
 * @author cylab
 */

public class Launcher
{
    public static void main(String[] args)
    {
        try
        {
            // Get the system paths field, make it accessible and to null
           // so that whenever "System.loadLibrary" is called,
           // it will be reconstructed with the changed value.
           Field sys_paths = ClassLoader.class.getDeclaredField("sys_paths");
            sys_paths.setAccessible(true);
            sys_paths.set(ClassLoader.class, null);
            // Now change the System property
           System.setProperty("java.library.path",
                "/home/cylab/.netbeans/6.5/jogl-runtime/jogl.jar-natives-linux-i586:/home/cylab/.netbeans/6.5/gluegen-runtime/gluegen-rt.jar-natives-linux-i586");

            // Get the reference to the actual app class after setting java.library.path and start your app
           Class.forName("org.yourorghere.SimpleJOGL")
                .getMethod("main", new Class[]{String[].class}).invoke(null, new Object[]{args});

        }
        catch (Exception e)
        {
            e.printStackTrace();
            System.exit(1);
        }
    }
}


You will still need some code to get the right platform library path.

Mathias - I Know What [you] Did Last Summer!
Offline M2009

Junior Member





« Reply #21 - Posted 2009-05-30 12:23:57 »

Looks interesting, I'll try it now.

Offline M2009

Junior Member





« Reply #22 - Posted 2009-05-30 14:27:18 »

Good news everyone, it worked! Now we have a way of changing the java.library.path programatically from inside main(). Setting ClassLoader.class to null really did the trick. Thank you cylab!

Here's my version of your code.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
public class TheMainClass {
   
    public static void main(String[] args) {
        if (args.length==0) {
            try {
                Field sys_paths = ClassLoader.class
                        .getDeclaredField("sys_paths");
                sys_paths.setAccessible(true);
                sys_paths.set(ClassLoader.class, null);
                System.setProperty("java.library.path", "binaries/win32");
                String[] arguments = {"start"};
                TheMainClass.class.getMethod("main", String[].class)
                        .invoke(null, new Object[] {arguments});
            } catch (Exception e) {
                e.printStackTrace();
                System.exit(1);
            }
        } else {
            //do whatever main should really do here
       }
    }
}


If an exception occurs one can explain to the user that he can bypass this if he starts the game with the an argument (should he want to aquire the jogl binaries manually and place them in the java.library.path on his system).

As you can see this code makes it impossible to send arguments to the application, if that is needed the code needs to be rewritten a little. It's easily done but I wanted to keep the code simple and clean for now, this way only one main() method is needed in the application.

What the code does is that it sets the java.library.path to "binaries\win32" - the "binaries" folder is in the same folder as the jar file and the "win32" folder is inside the "binaries" folder (duh).

Remember: If you change the class name from "TheMainClass" to something else you also have to change "TheMainClass" to the same thing a few rows down into the code.

This code was tested on Windows Vista 64, anyone else care to test on other systems? Some of you may notice that I'm loading the win32 binaries on a 64 bit operating system, I guess its the type of Java Virtual Machine that counts and not the OS, I have the 32bit VM installed.

By the way, "/" should be pretty universal right? Would be nice not having to use System.getProperty("file.separator") all the time.

Alright, great job everyone. Smiley Now it's just a matter of figuring out which binaries to use (and compress them if possible). Any suggestions?

Offline cylab

JGO Ninja


Medals: 49



« Reply #23 - Posted 2009-05-30 15:05:38 »

You won't need to call the main method again via reflection with the javalobby version. I just combined both approaches to get a separation of the launcher and the normal main class. If you don't want that, you can simply use:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
public class TheMainClass {
   
    public static void main(String[] args) {
        if (System.getProperty("suppress-natives-injection",null)==null) {
            try {
                Field sys_paths = ClassLoader.class
                        .getDeclaredField("sys_paths");
                sys_paths.setAccessible(true);
                sys_paths.set(ClassLoader.class, null);
                System.setProperty("java.library.path", "binaries/win32");
            } catch (Exception e) {
                e.printStackTrace();
                System.exit(1);
            }
        }
         //do whatever main should really do here
   }
}


This way you can still have normal arguments. On an exception you could advice the user to call the app with
1  
java -Dsuppress-natives-injection -Djava.library.path=/users/own/natives/path YourMainClass

Mathias - I Know What [you] Did Last Summer!
Offline M2009

Junior Member





« Reply #24 - Posted 2009-05-30 15:29:39 »

Why that's just splendid! Nice to see that you don't have to trick Java by calling main a second time in order to change "java.library.path".

Now I'm (again) wondering if it's possible to launch a java application from inside another java application (a solution that always works). Here's why:

I was thinking about having one java application that asks the user what operating system he is on. Then he presses "start server" or "start client", then another java application will be launched with arguments descibing which binaries to use. The point of having one java application launching another would be that if the game crashes the launcher application would still be running and can display messages etc about it.

The problem with using exec() would be, I guess, that some systems won't have just "java" bound to the whole path to java.exe. I've seen that once on the University. There's also something about allowing a java application to launch other java applications that screams security warning to me, making me guess that some places will not allow this thus making the game unable to start.

Thanks for all the help, I hope there's a solution to this also.

Offline M2009

Junior Member





« Reply #25 - Posted 2009-05-30 23:52:52 »

I've been wondering by the way... do Jogl draw things outside the area defined by glOrtho? If I draw a circle, but half of it is outside the ortho area, is only the half showing drawn or is the rest also drawn? How about if the whole circle is outside the ortho area, is it not drawn automatically (the commands drawing the circle are ignored) or do I have to implement some kind of bounding box check myself to decide if the commands should be executed or not?

Not drawing stuff outside of view auomatically sounds too good to be true, but I might as well ask anyway. Wink

Offline lhkbob

JGO Knight


Medals: 32



« Reply #26 - Posted 2009-05-31 04:10:29 »

The drawing command is not ignored, but nothing would be drawn onscreen (or half-circle etc.).  When processing the drawing command, the opengl drivers will clip away things outside of the window.  Even though it clips it, it's better to cull it with the CPU since then the GL commands are never invoked.

Offline M2009

Junior Member





« Reply #27 - Posted 2009-05-31 14:26:58 »

Ok, that's nice. Then I'll have to somehow find out if the CPU saves processing power if I calculate if a object is worth drawing or not. I guess it'll only be worth the calculations if very complex things are to be drawn.

Anybody have any thought about the other thing I was wondering about?

Offline cylab

JGO Ninja


Medals: 49



« Reply #28 - Posted 2009-05-31 14:48:32 »

Quote
There's also something about allowing a java application to launch other java applications that screams security warning to me, making me guess that some places will not allow this thus making the game unable to start.

All these mechanisms apply only for content downloaded and then run with full privileges anyway, so no - starting a java app vie exec() won't have security problems. To get the java[.exe] you can make yourself a search-list of known directories for the jvm installation, if the vm is not installed "correctly".

Quote
I was thinking about having one java application that asks the user what operating system he is on. Then he presses "start server" or "start client", then another java application will be launched with arguments descibing which binaries to use. The point of having one java application launching another would be that if the game crashes the launcher application would still be running and can display messages etc about it.

While having a launcher app may be useful, I think you should try to find out operation system automatically. There are some System properties, that contain info about the OS and CPU platform. Don't know them from the head now, just print them all out and look for something ending in .os, .arch and/or .platform...

Mathias - I Know What [you] Did Last Summer!
Offline M2009

Junior Member





« Reply #29 - Posted 2009-05-31 17:45:33 »

Alright, very interesting. Good to know there won't be any security problems; I'd hate to learn that my game is unplayable in some school somewhere just because the admins over there had disallowed java applications from launching other java applications, but if that's not possible I don't have to worry. Smiley

I think I'll go with a launcher application because then I could have it restart the server if it crashes or something. Wonder if it's possible to close a started application (if Java was the one that started it)... I bet it is.

I'll probably have automatic OS detection, however if the app is unable to determine correctly the user will be able to manually set his OS. Thanks for the input.

Now gentlemen it's just a matter of being able to extract the DLL files from the jar archive. Anyone knows a good way?

Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

BurntPizza (22 views)
2014-09-19 03:14:18

Dwinin (35 views)
2014-09-12 09:08:26

Norakomi (62 views)
2014-09-10 13:57:51

TehJavaDev (90 views)
2014-09-10 06:39:09

Tekkerue (44 views)
2014-09-09 02:24:56

mitcheeb (65 views)
2014-09-08 06:06:29

BurntPizza (48 views)
2014-09-07 01:13:42

Longarmx (35 views)
2014-09-07 01:12:14

Longarmx (40 views)
2014-09-07 01:11:22

Longarmx (37 views)
2014-09-07 01:10:19
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!