Greetings and salutations!
Much of the work of the week just past was one or more of technical, audio-related, or bug-fixing, so I don't have any particularly interesting new visuals to show. So instead, this week's screenshot comes from my side-project; more specifically, from a work-in-progress editor for it:
The week just past saw bug-fixes, sound-work, and work on one major technical matter...
That technical matter was threaded level-loading. In short, this would allow the game to perform the process of level-loading (or some part thereof) in the background, thus leaving it free to animate the loading screen. This animation in turn might reassure the player that the game hasn't stopped working.
I had previously done something similar for saving. That, as I recall, turned out to be fairly simple.
This did not.
For one thing, it seems that the process of loading a level has become a little convoluted. Not all of it necessarily happens within the bounds of a single update, and the process seems to vary a little bit depending on the source of the load (starting a new game, loading a save, etc.). And at this point, I honestly don't remember why it ended up this way.
I considered re-engineering the process of level-loading to be more friendly to threading. But what I have right now works, and I fear that re-engineering it seems all too likely to produce new bugs and issues, or to re-introduce ones that I'd already dealt with.
Now, on the Panda3D forum it was suggested to me that, instead of attempting to put the whole process into a thread, I might put only the loading of the level's 3D model into a thread--that being the part of the process that seems to take by far the longest.
This seemed more feasible. It involved interrupting the reconstruction of the level-object at a certain point, but that was soluble. And indeed, this approach seemed to work!
But between the convoluted level-loading process and my own lack of expertise with threading, I'm not convinced that it's wise for me to go with this. Without extensive testing, it's hard for me to be confident that everything is working as expected, and there remains the risk of issues arising due to some unanticipated set of actions occurring during threaded loading.
For now, I'm still considering whether or not to go with the threaded approach, or to stick with my current static-but-reliable approach.
I also attended to some sound-work in the week just past.
For one, I added support for attacks to optionally have individual sound-effects for their impacts. This is now used to give the mummy-enemies a separate sound to play on landing their "push" attacks.
For another, I had realised that my menus lacked rollover-sounds--that is, sounds that are played when the mouse passes over UI-controls.
Rectifying this was fairly simple and straightforward, I'm glad to say! ^_^
I was a little concerned that having these play too often might become annoying, but it doesn't seem to me to be so, and advice from the TIGSource forum supports this feeling.
One issue that does arise from this, however, is that moving the mouse rapidly across several UI-controls now produces an unpleasant electric "burr". I'm uncertain of the source of the problem, and am seeking help on the TIGSource forum at time of writing.
Over the course of the week just past I also fixed a variety of bugs. Most of these don't seem worth detailing here, but one was a little odd:
During gameplay, one can press the "o"-key to open the "options" menu. During the week just past, I discovered that it wasn't working.
Specifically, it didn't work at first, but would work as expected if I opened the key-mapper and re-bound it, even if I simply renewed its binding to "o".
This was a little disconcerting, I think. After all, not only was this a long-standing feature, but it prompted the worry that something was wrong in my key-mapping module.
I hunted for its cause. I traced through the steps of loading and binding keys. I even checked partway into Panda3D's source to see whether the relevant event was being properly added, as I recall. But I found no apparent cause for the problem.
Eventually--and I don't recall how I came upon this--I discovered the source of it:
As it turns out, in the main-menu class I had added some debugging key-events--one of which was bound to "o". In short, my key-mapping was (presumably) working as intended--but the main menu was then overriding its key-event with this debugging code!
Thankfully, once found this was easy enough to fix, I do believe; the debugging key-events were no longer called for, and so have simply been removed.
And finally, I've mentioned a side-project of mine, I believe, a "wandering visual novel". Progress has been made there, slow but continuing. Of late I've primarily been working on (or towards) a tile-editor for it. The screenshot at the start of this post shows a glimpse of its current (very work-in-progress) state.
That then is all for this week! Stay well, and thank you for reading! ^_^
