V3.5.0 beta testing

Development
21

Yeah, exactly!

I have some code that’s something like this:

  class NonLoopingAction extends BaseAction {
     ...
     public boolean interpolate(double t) {
      var result = delegate.interpolate(t);
      if (!result) {
        composer.removeCurrentAction(AnimComposer.DEFAULT_LAYER);
      }
      return result;
    }
  }

So I thought it might be wrong to have this side effect inside interpolate and I wouldn’t mind changing it, but I think keeping it backward compatible and foolproof as before would be nice.

1 Like
22

@capdevon please create a pull request with the proposed fix

1 Like
23

Done

5 Likes
24

Thanks!

2 Likes
25

I just published a new pre-release for beta testing:

Testers, please upgrade to v3.5.0-beta6 ASAP.

If we’re lucky, this might be the last beta release before v3.5.0-stable!

4 Likes
26

I no longer get the animation error. Thank you @capdevon and @sgold !

3 Likes
27

I had a report of a new user-interface issue in jme-vehicles MavDemo1 on a dual-screen Windows system, when build using JME v.3.5.0-beta5:

MavDemo1 has a Lemur user interface. I’m guessing this issue is related to LWJGL 3.3.0 and a dual screen.

I can’t reproduce the issue because I don’t have a dual-monitor setup. Does anyone have time to debug this?

28

Is the primary screen one of the hires pixel things (forget what it’s called) that cause mouse pointer issues?

…in that case it wouldn’t be a dual monitor problem but a “when on the over-resolutioned monitor” problem.

1 Like
29

Is the primary screen one of the hires pixel things (forget what it’s called) that cause mouse pointer issues?

I don’t know how to find an answer to that question.

If the word you’re looking for is “Retina” then I assume the answer is “no”, since “Retina” is an Apple trademark and the OP was using Windows.

30

But there is a windows version of the same thing I thought. We’ve had issues reported about this.

My guess is that the primary display is reporting a resolution that’s different than what the OS mouse position thinks resolution is… like with a retina display.

1 Like
31

I think that’s a good guess.

I got troubling news this morning: this particular issue doesn’t occur with JME 3.4.0-stable, so it’s a regression.

1 Like
32

I vaguely remember discussion around a retina-related fix for mouse coordinates… did that go into 3.5? Maybe it’s the cause of the regression.

1 Like
33

PR 1607 was integrated into “master” branch on 11 November 2021. Since the master-v3.5 split didn’t take place until 15 December, the PR 1607 fix is included in “v3.5” as well.

If you’re thinking of a different fix, I’ll need more hints.

34

That’s the one. Also mentions “hidpi” on Windows.

So if I read your message right then this could be the cause of the regression. A “mouse position” related fix that is in 3.5 but not in 3.4. Yes?

1 Like
35

Okay, so now I have 2 candidates for the cause of the regression: PR 1607 and PR 1659.

Edit: I can’t reproduce this issue, since I have neither a HiDPI monitor nor a dual-display system. Help me, please!

36

I just tried to reproduce it with linux, my monitor isn’t special but I tried scaling (which I assume is what hi dpi monitors do?).
Using xrandr I tried this and several combinations:
xrandr --output HDMI-2 --mode 2560x1440 --scale 0.5x0.5 --output eDP-1 --mode 1920x1080 --scale 1x1 --pos -400x-400

but everything worked fine when I tried with my project that uses lemur.
I wanted to run the vehicles project but I couldn’t build it (jcenter bad gateway).

Maybe you can try playing with xrandr?
I’m thinking maybe windows/macos scale individual windows and not the whole screen so this is not the same.

1 Like
37

Just published JME v3.5.0-beta7 to Maven Central. This includes changing the default setting for “UseRetinaFrameBuffer” from true to false, which I’m hoping will solve the recently reported mouse-position bugs. Please test beta7:

3 Likes
38

This morning I figured out how to enable scaling on my Windows 11 laptop (settings → system → display → scale & layout → scale). I tested MavDemo1 with JME 3.5.0-beta7 and saw that it wasn’t working, so I hacked into GlfwMouseInput until I fixed the issue, at least for MavDemo1 on my laptop.

I’d appreciate it if someone would review the resulting PR 1746 ASAP. Help, please!

4 Likes
39

Now there’s a “beta9” release with the fix (hopefully) for issue 1745:

Testers, please switch to beta9 ASAP.

8 Likes
40

With the arrival of “code freeze”, beta testing can wind down now. I send heartfelt thanks to everyone who participated in finding, documenting, and fixing bugs and verifying the fixes.

I imagine many are eager (as I am) to see the fruits of our labor … 3.5.0-stable, here we come!

8 Likes