Greetings and salutations!
This week's screenshot shows a familiar window, now offset from its previous position:
The week just past was perhaps a bit of a slow one--but nevertheless, some things did get done, include one possibly-important improvement to keyboard support:
As in previous weeks, work continued in the week just past on polishing and finishing the mist-related feature in level six. This is proving rather fiddly, I'm afraid--but I do think that I'm making progress!
And it was for this feature that I ended up moving the window shown above.
You see, one instance of that feature was located quite near to said window. So close, unfortunately, that careful manoeuvring into the window could reveal part of the trick of it--and look iffy in doing so.
So, I set about moving the window.
As you may recall from previous blog-posts, the stonework of the walls makes the process of setting a window-frame into them a slightly lengthy one--and so it was here.
Furthermore, the lack of certain modifiers previously present resulted in my working on a patch of wall taken from a stored copy, and then "welding" that into the main wall.
But it did all get done, I believe, and, as shown above, the window is now moved!
You may be aware that A Door to the Mists employs a custom key-mapping module, which I call simply "KeyMapper".
As it happens, KeyMapper is also available for others to use via GitHub, and in the week just past, such a user pointed out a few problems with it.
First, there were some problems with certain files, perhaps most saliently that the assets for the example game were missing. These I corrected, I believe, as well as adding in a license for said assets.
Second, there was a bit of code-cleanup to do, I believe.
But perhaps more importantly, it was pointed out to me that KeyMapper didn't support certain non-English keys.
As it turns out, this is because Panda's default key-event system doesn't support those keys. Instead, it handles such things by offering another set of events, called "raw" key events, along with a keyboard-mapping system.
In short, these events bind not to a key-character, but to a location on the keyboard. Together with a map of the keyboard layout, this allows the system to represent a variety of keys that might be present.
(Presuming that the used font contains the relevant glyphs--which may in fact prove to be a problem for A Door to the Mists...)
Furthermore, the fact that the "raw"-events bind to key-locations rather than key-characters means that mappings remain consistently-placed regardless of layout.
For example, if stored by key-character, the traditional WASD becomes rather awkward on, say, an AZERTY keyboard. However, if stored by key-location, WASD simply becomes ZQSD (I believe)--the keys found in the same locations as W, A, S, and D on a QWERTY keyboard. This means that an AZERTY-user can just pick up and use the mapping, without awkward hand-positions or re-binding.
This should, I hope, make for a more convenient experience for users. ^_^
Here is a quick excerpt of a screenshot of the KeyMapper example-game, showing some Czech characters, I believe:
(Alas, the font currently used in A Door to the Mists lacks the relevant glyphs. :/)
Concomitantly, I also updated the default key-mapping profiles to use left-control and left-shift in place of their generic versions: Since the "raw"-events bind to key-locations, they naturally differentiate between the left- and right- versions of the "shift" and "control" keys. As a result, a binding of just "shift" or just "control" doesn't work. Thus a quick change from "shift" and "control" to "lshift" and "lcontrol" was made!
Similarly, I updated the relevant language-file to have side-specific labels for shift (so that it displays something more intuitive than "lshift"); it seems that I already had such for "control".
And along the way a few more things were done that don't seem worth detailing here!
That then is all for this week--stay well, and thank you for reading! ^_^
