Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
STARK: Implement keyboard bindings #1474
The commit 3e38b1c is used to propose a solution for a case like this, assuming that an option may wrap up more than one line.
In the original implementation (I mean the one before 2453408), when calculating how many options are displayed on the screen, an option will be added as long as there is remaining space, even though it will exceed it (for 9 pixels, to be specific).
However, for a case shown with the pic above, it will cause problems. If in that case, the
In the original implementation, that larger option will be included, which will cause a corner case that the last option will never show up. The game should first check whether the next option may completely fit into the remaining space, then add it to the list. To do so, the original height used to bound the options needs to be enlarged to ensure that all four lines of options can be included.
Actually, I am not sure whether this is how the original game handles this. So many things could happen in scrolling if it is possible to have options wrap up multiple lines. Is it really possible? Is there a location I can check on it in the game?
My understanding of the (mostly reverse engineered) initial code is that the game accommodates with options spanning two lines by scrolling options by increments of 3 even if 4 lines can be drawn. That way there can be one option spanning two lines without (too much) trouble.
I don't think it's necessary to implement something too complicated that handles all the cases. Keeping the status-quo is fine with me.
This sounds like what the old implementation does, yet that implementation behaves differently with my Steam version. In the old implementation, if you scroll down to the bottom you'll have only 3 options displayed:
But in the Steam version, you should have a full four of them:
What did you mean by "status-quo"? The original "scrolling by 3" or the new one I proposed? The one I wrote is not very complicated, just some very basic checking, and it doesn't seem to decrease the performance. If there is no bug there I prefer to use the one I propose.
Indeed, something I don't understand is happening. I was able to reproduce the silent dialogs twice tonight, but not anymore after that. There's no memory problems detected by Valgrind / ASan so I'll say it was a mistake on my end for now.
Thanks for your work; merging.