Lemur/SimTools Patch-stravaganza

User Code & Projects
21

So, I woke up today and though “Ok, I will test some of my old apps to see if they still work right…”

I have mixed feelings about how that went. On the one hand, it was a pain tracking down the bug I immediately found… (four hours of pain to find and fix)… on the other hand, it validates the process.

Story:
I ran the spacebugs game I’d worked on some months ago. Seemed to run ok but movement was really jittery. (Also, for some reason the space bug walking around wasn’t animating but I left that aside because the jitter was sickening.) Except… that non-animating bug was super diagnostically significant.

I first went down the trail to make sure the camera was synching on the same frame as the mob that it was tracking. It was.

Finally, I started thinking about that bug. In spacebugs, animation is based on the ‘animation state’ of the character and how far they’ve moved in any direction. So, if the object has moved forward X units in some span of time, the MobAnimationState calculates how much forward velocity that was and uses it to set the “walk” animation and speed. (If the bug had a “walk sideways” animation already then it would mix the two based on side-to-side velocity, etc…) This is nice because it frees up a lot of networking synching issues and makes the mobs very reactive… if you bump the bug, he won’t just slide but walk a little backwards.

Well, he wasn’t animating for the same reason there was jitter. Objects were only updating position every few frames.

I will spare you the rest of a long story on how I found this but it’s related to a change I recently made in SiO2’s SimTime. I got tired of giant time values and so I set it up to initialize the starting simulation time to 0. Thus if your game has been running for 5 seconds, SimTime.getTimeInSeconds() will show 5 seconds. Nice.

However, this poked at a bug in SimEthereal where the remote time source was being synched directly off of System.nanoTime() instead of the real simulation time. So the object visuals were trying to interpolate position at time 1837460837647375 seconds between start and end times of 5 and 5.033 seconds.

3 hours to find the issue, an hour to clean up and fix it. Now SimEthereal lets you specify a custom TimeSource on the server. And I even added a nice log.warn() in there for anyone else who may have this setup issue.

So, hurray for the process… boo for the time sync.

2 Likes
22

If it helps, my recollection is that the camera width/height should always represent the buffer. So for a camera on a screen viewport, it should be the display size. For a camera on an off screen buffer, it should be the buffer size.

Viewport edges are then fraction of those width/height values. The camera width/height doesn’t change, though. The viewport is always going to be viewing a portion of the camera’s total “frame”… else it wouldn’t be a viewport anymore.

23

And… a few hours later, many of which were monkeying around with gradle versions, java versions, etc… I finally got new releases uploaded for:
sim-math: v 1.2.0
Zay-ES/Zay-ES-Net: v 1.3.0
sio2: v 1.2.0
sim-ethereal: 1.3.0

Now… I will take a break before diving into Lemur related issues.

24

You can add the MigLayout and the JFX Panel that I built to Lemur if you want.

1 Like
25

Please do. Very nice work there.

26

I don’t know if I’m setup to properly support them but I would like to make them available more readily.

…just not sure how best to do that.

27

Please take a look at

It adds two callback, key callback and char callback.
If I remove char callback, and only keep key callback, this is the result I get when I’m pressing,holding and releasing a key

Key(CODE=31, PRESSED)
Key(CODE=31, REPEATING)
Key(CODE=31, REPEATING)
Key(CODE=31, REPEATING)
Key(CODE=31, REPEATING)
Key(CODE=31, REPEATING)
Key(CODE=31, REPEATING)
Key(CODE=31, REPEATING)
Key(CODE=31, REPEATING)
Key(CODE=31, REPEATING)
Key(CODE=31, REPEATING)
Key(CODE=31, REPEATING)
Key(CODE=31, REPEATING)
Key(CODE=31, REPEATING)
Key(CODE=31, REPEATING)
Key(CODE=31, REPEATING)
Key(CODE=31, RELEASED)

This seems to work as expected and adding || isRepeating() to if statement in KeyHandler will fix issue ?

and regarding the char callback, what is it for ? Should we remove it ?

28

There is the code and the character. Lemur’s text panel will surely need the character, right?

There is no other way for me to tell the difference between an ‘m’ and an ‘M’ or a ‘.’ and a ‘>’ because the key codes will be the same.

At least those are the things you will have to look at. I don’t run lwjgl3 and don’t intend to in the short term so I’m unable to debug this myself right now.

29

https://github.com/jMonkeyEngine-Contributions/Lemur/pull/65/commits/84c4a075bf12a99d09e0815a0ffc44d4b8612e0f

30

So, am I right that lwjgl3 is sending double events for key repeats? One with isPressed true and one with isRepeating true? (If so, that’s dumb but ok.)

I guess that this fix is ok because the improperly coded one will be skipped… and lwjgl2 doesn’t double send events. I will make sure it doesn’t break lwjgl2 after I apply the fix.

31

Not really relevant for Paul but lwjgl3 has another issue which might be a bit coupled to that:

I think I even had that issue on Windows then. Just in case anyone wants to dive deeper into lwjgl3

32

It sends three of them actually!
One for isPressed, one for isReleased and one for isRepeting at the same time.

in char callback, for each invoke, it creates two key input event, one for key pressed and one for key released. It seems like a mess!

glfwSetCharCallback(context.getWindowHandle(), charCallback = new GLFWCharCallback() {
            @Override
            public void invoke(final long window, final int codepoint) {

                final char keyChar = (char) codepoint;

                final KeyInputEvent pressed = new KeyInputEvent(KeyInput.KEY_UNKNOWN, keyChar, true, false);
                pressed.setTime(getInputTimeNanos());

                keyInputEvents.add(pressed);

                final KeyInputEvent released = new KeyInputEvent(KeyInput.KEY_UNKNOWN, keyChar, false, false);
                released.setTime(getInputTimeNanos());

                keyInputEvents.add(released);
            }
});

I made a quick test on lwjgl2, and it looks fine.

33

Maybe add them to the proto library and add a comment that points people to me for support? Each one is just a single .java file and both have been extensively tested since they are the core of my game UI

34

But proto is an incubator for eventual inclusion in core. I was thinking maybe a separate space for user supported add-ons or something.

Sure… but when folks submit patches I won’t know what to do with them. I don’t use these classes, don’t have any plans to use them, etc… I have no ability to test them myself without considerable work. I’d rather they stay maintained by the community.

…and if that’s not you then maybe it’s one of the other devs who use them.

Maybe an ideal situation is that someone else manages a repo for them and we link to them in the Lemur docs. (Plus, I definitely don’t want to fall into the JME trap where good things eventually die because they time themselves to JME’s long release cycles instead of remaining independent. Keeping these separate from Lemur means that they can at least iterate if necessary.)

zissis reminded me that I need to mention a breaking change when using SiO2 and SimEthereal together. I was going to mention it in the official release announcement but that may be a bit… so here is the code snippet your game server will need to fix the issue:

        ethereal.setTimeSource(new TimeSource() {
                @Override
                public long getTime() {
                    return systems.getStepTime().getUnlockedTime(System.nanoTime());
                }
            });

…and if you don’t add that and need it then you will get tons of warnings about your time sources being incompatible. So it will at least be obvious. :slight_smile:

1 Like
35

As to the other stuff in this thread, I’ve addressed many of the Lemur feature requests so far. It might be all that I can this weekend.

There are still a couple things I want to look into:

I’d like to play with the +/- thing, tooltips, etc… but:
a) I’m not sure I’ll have time
b) they shouldn’t require core changes (ie: 100% add-on-capable)
…so it’s possible others could take a crack at them also.

We’ll see.

As said, I’ve already applied a lot of PRs and implemented some of the feature requests. Here is Lemur’s latest pre-release changelog:

Good progress today.

3 Likes
36

I guess I will have to get off of my butt and start a git project for all my enhancements :slight_smile: . I could even through in my shaders.

3 Likes
37

Just pushed 1.3.1 of Zay-es-net up to bintray to fix an issue with the RemoteEntityData.completeEntity() patch that had a backwards if check. My fault for not being able to thoroughly test that PR. :confused:

Thanks to @zissis for tracking that one down for me.

1 Like
38

It would be nice if your “Stone” style can be included in default style set.

39

Oooh, that’s a good idea. Not sure I will have time to get it ready for this release or not.

40

Am I late to the party?

There’s Joystick input remapping - #7 by pspeed
and Joystick input remapping - #13 by Pesegato

In short: I already made input remapping myself (BigBanana), but InputMapper don’t integrate seamlessly with InputManager and, in the current state, I’m forced to fall back to InputManager to overcome the above issues.