A fully implemented current objectives window — but also Vorple optimization woes.
So the good news is that the current objectives window has been fully implemented. It not only lists the current objectives at all times, but smartly breaks objective subheaders into a dropdown box that players can toggle between. This was the best solution I could find in terms of usability and compatibility with low-resolution displays.
Unfortunately, programming this has led to a much more significant and noticeable issue with the Vorple interpreter: slowdown. After implementing the current objectives window, I started to see significant input delay after every command. Quixe reported taking up to an entire second to process a turn. This game shouldn’t require such a huge amount of processor cycles that it takes a gaming PC a noticeable amount of time to process a turn, and yet it does:
I’ve spent quite a lot of time trying to optimize the code, and I managed to shave about 200 ms off the delay by bundling as many instructions as possible into single commands. But I suspect that I’ll have to dig into Vorple’s innards and refactor my GUI code to optimize it further.
Right now I’m concerned with my final year project showcase, which will be on the first week of May. Unfortunately I think other features will have to be prioritized for it, like making portraits and banner artwork for the slice of the game I plan to show in my demo. I’ll come back to optimization later once the pressure of having something to impress the general public isn’t as high. It’s a really annoying problem and and I’m hoping to figure out a more performant way to pass GUI updates in the future.