Different Screen Resolution When Running From IDE vs Executable

Hello Guys,
I’m not totally sure it is related to JME but maybe someone encountered this issue.
I’m getting different resolutions when running my JME scenes from IDE vs Outside the IDE (I’m using InteliJ).
The problem is that I get different screen size when using a given resolution (e.g. 1400x800). It looks correct when running from the IDE but bigger than it should be when running outside of the IDE…

Here is a sample video demonstrating the problem:


It’s the same code , same flow , same settings. Here is the setup code:
        sceneMaxApp = new SceneMaxApp(appType);
        AppSettings settings = new AppSettings(true);
        settings.setGammaCorrection(false);
        settings.setSamples(4); // anti-aliasing
        settings.setVSync(true);
        prg=setCanvasSize(settings,prg);
        prg=setWindowMode(settings,prg);
        settings.setTitle("");

        sceneMaxApp.setSettings(settings);
        sceneMaxApp.createCanvas(); // create canvas!

        Dimension dim = Toolkit.getDefaultToolkit().getScreenSize();
        JmeCanvasContext ctx = (JmeCanvasContext) sceneMaxApp.getContext();
        ctx.setSystemListener(sceneMaxApp);
        ctx.getCanvas().setLocation(dim.width/2-this.customWidth/2, dim.height/2-this.customHeight/2);

And here is the function which sets the AppSettings width & height:

   private String setCanvasSize(AppSettings settings, String prg) {

        String pat="^canvas\\.size\\s+((?<val1>\\d+),(?<val2>\\d+))";
        Pattern p = Pattern.compile(pat,Pattern.CASE_INSENSITIVE | Pattern.MULTILINE);
        Matcher m = p.matcher(prg);
        int width = 1024;
        int height = 768;
        if(m.find()) {

            String w = m.group("val1");
            String h = m.group("val2");
            width=Integer.parseInt(w);
            height=Integer.parseInt(h);

            prg = m.replaceFirst("");
        }

        settings.setWidth(width);
        settings.setHeight(height);
        this.customWidth = width;
        this.customHeight = height;

        return prg;
    }

Maybe its a Swing issue… What do you think?

1 Like

What is your desktop resolution? 1400x800? Because that’s what the second launch looks like.

Try to run it without the IDE by using gradlew.bat run (if you have a gradle wrapper laying around).
The difference here is the JVM: You compiled it somehow so it uses another JVM than gradle.
In case you did some native compilation, then this is probably doing something.

Are you also certain that setCanvasSize works, e.g. by printing it out?
The centering could also be key here, because I guess that is what your last line in the upper code block is supposed to do? If so, print our all the values there and see how they differ. If they don’t, then the native compilation somehow messes with the canvas.

1 Like

I’m not doing any native compilation, just wrapping it as executable using launch4j.
I did printed the canvas size in run-time in both cases and in both it was the same 1400x800 , which is BTW smaller than my desktop resolution.
It’s like that the Swing window of the SimpleApplication (JME uses Swing window right?) is somehow created in bigger size and JME’s drawing canvas is stretched to fit that size.
I will do some more tests… maybe it’s something with the launch4j that messes things here.

Also, this behavior is not consistent on all computers I tested my app. On some of them it runs just fine

1 Like

Jme uses AWT(ABstract window toolkit) as a frame to render in(correct me if i am wrong),but you can use a Canvas inside a JFrame then do

EDIT: jme uses AWT Canvas to have its render in & you can attach that canvas to a JFrame as shown in the example.

    frame.getContentPane().add(canvas);
    frame.pack();
    frame.setLocationRelativeTo(null);
    frame.setVisible(true);

to centerize it

there’s also an example for that , here take a look ,but remember the code order is a very essential & there’s no need for Thread.sleep() you can remove it , its just for demostration :slight_smile:

2 Likes

So after several more tests I found that I have 2 versions of Java on my computer:

  1. C:\Program Files\Java\jdk1.8.0_45\bin\java.exe
  2. C:\Program Files\Java\jre1.8.0_251\bin\java.exe

it appears that when using the 1.8.0_251 version the screen looks bigger and not centered as shown in the movie above.

3 Likes

curious, probably its java AWT had some differences between java versions (or JRE vs JDK?)

1 Like

You might be running into different defaults for screen scaling. (Mostly used on UHD/retina-ish displays)

1 Like

Copy the proper jre into a bin folder with the game & force launch4j to use it :slightly_smiling_face:, it will increase the game size a little bit by 250-300mbs & encourage to copy only jre which you can found inside jdk in some cases if you donot have jre

**The Bundled jre path : **
image

Seems high? This is one of the reasons that I’m not too fond of including a JRE with every application.

I don’t think you want to encourage that. What happens when they try to upgrade the version of java they build with? Probably back to the same issue.

1 Like

Couple questions for the OP:

Find the java.exe files, and right-click. (Windows only!) In the context menu, go Properties->compatibility There should be a checkbox for Override High DPI Scaling behavior, as well as an option field for Scaling performed by:

  • Do these settings match from one to the other?
  • Does changing them change the launch behavior?

The centering thing may just be Windows being weird with where it puts new windows. However, If the scaling settings are involved, it may be that the Offset that would center the normal size window is also getting scaled. From the video, it appears that the scaled window would be centered if the entire display had been scaled by the same amount.

1 Like

This is interesting. I already deleted the 251 version so now the problem is gone but I will try to re-install and see if it changes the launch behavior.

regarding centering - I don’t think it a real problem because I’m trying to center according to the AppSettings but the window was actually scaled so it makes sense that the calculation were not correct in that case.