This week, we see some work that is being done on the UI. We hear from @imbris about their work on winit, as well as server events. @Timo has been working on quite a few smaller issues.

- AngelOnFira, TWiV Editor

Contributor Work

Thanks to this week's contributors, @xMAC94x, @Songtronix, @Acrimon, @Imbris, and @Shandley!

@Timo has been working on quite a lot. He added a loadout struct to store weapons and their selected abilities. In combat, @Timo added a slight bouncing animation in first-person mode, added a shield item, and added a sword dash attack ability. He also fixed bugs for most weapon types, such as bows and boost. Finally, he improved character creation so the chest armor slider adjusts to available assets dynamically.

@Songtronix has ongoing work to improve the book. @Cedric is working on an external programming language called WLambda. @Octo, @Pfau, and @Slipped have been working on some upcoming UI changes.

Work of @imbris

Previously, the issue blocking updating to the latest winit branch was mouse movement input lag occuring on macOS. To dig deeper into what was going on I created an example program to print out when events were being received from winit (see this). With testing by @Shandley we saw an output that looked like this:

Generating mouse event: (8.000, 0.000) Generating mouse event: (19.000, -5.000) [DeviceEvent::MouseMotion(8.000, 0.000)] @ 0.193 us, 342.641 us after winit created [DeviceEvent::MouseMotion(19.000, -5.000)] @ 41.391 us, 178.440 us after winit created [MainEventCleared] @ 50.862 us [MainEventCleared] @ 34315.527 us Generating mouse event: (42.000, -8.000) Generating mouse event: (83.000, -16.000) [DeviceEvent::MouseMotion(42.000, -8.000)] @ 70504.492 us, 319.739 us after winit created [DeviceEvent::MouseMotion(83.000, -16.000)] @ 70528.703 us, 153.272 us after winit created [MainEventCleared] @ 70541.742 us [MainEventCleared] @ 106441.617 us Generating mouse event: (80.000, -11.000) Generating mouse event: (133.000, -14.000) [DeviceEvent::MouseMotion(80.000, -11.000)] @ 141973.828 us, 366.537 us after winit created [DeviceEvent::MouseMotion(133.000, -14.000)] @ 141990.969 us, 123.327 us after winit created [MainEventCleared] @ 141999.312 us [MainEventCleared] @ 177216.766 us

(Note: the "Generating mouse event" lines come from a println! I inserted into the winit codebase). As you can see, there seems to be a bug in the macOS event loop such that mouse events are only generated every other MainEventsCleared . This was an issue because I am using MainEventsCleared as the point where we run update code, render, and sleep to regulate the framerate (this is using ControlFlow::Poll ).

So mouse movement events were only received every other frame. Alas, digging around in winit 's macOS code and staring at this code, I could not suss out what was causing the issue (I learned to call a method in Objective C is also referred to as "sending a message"). Nevertheless, I then realized we can just respond to every other MainEventsCleared which seems to mostly work just fine :D (to follow this issue see here).

Now, we need to figure out why arrow keys are producing RecievedCharacter events on macOS and what those characters are so that they can be filtered out. Also, there may be some sort of fps degradation over time on macOS that needs to be investigated.

Latency improvements for ServerEvent mediated effects

I made some improvements to the latency of ServerEvent mediated effects last week. Notable examples of such effects include inventory manipulations, terrain manipulation, and projectile generation.

Essentially, what used to occur is that the ServerEvent handling would be performed after all ECS systems were run each tick on the server. This included server-specific systems that sent sync data to clients.

Since syncing was performed before server event handling, clients would not see the effects of that handling until the next server tick. To remedy this I rearranged when sync systems were being run so that they would run at the end of the server's tick. You might notice that shooting a bow is slightly more responsive now.

UI Improvements by @Pfau and Co.

Recently, a small group has been working on some UI changes. This is being done by myself, @Slipped, and @Octo. The aim was to reduce the number of windows in the UI and start introducing a more artistic theme for it. So we decided to merge 4 windows:

The character menu and the bag

The map and the quest log

In the last two weeks, we worked on the first item. I started by making a concept with our old assets.

This is just the character menu above a slightly stretched bag. So far so good. Then we started cutting bits and pieces off and tried to condense the information.

This... slightly crowded window was the result. We decided to give the stats a whole tab of the menu you can switch to. Some minor changes followed, with the decision to move the gem item into slots inside the armour later.

Next, we added a scrollbar, a currency counter, and an indicator to show how much inventory space is left. We also added tabs you can open to only show certain types of items.

Then, we started to think about a general colour and design theme. We decided on "Runic Blue"

These changes are making use of the function to be able to colour within the code itself. We created a bunch of greyscale .png files for this and then coloured them with a palette from the code. We could even let the player choose from some colour themes, or modders can come up with their own palette as well.

This is what we already have running in Veloren. Nothing is final yet, and more work will be done on this front in the near future.