If we move to the left and then want to move up, we might still be holding the Left key while pressing the Up arrow.
If we were still holding another key (like Left) while pressing the key for the new desired direction (like Up), then the Up arrow key press event is ignored until we release the other key we were holding.
Actual behavior:
If we hold both Right and any other arrow key, we always move Right, regardless of whether the last key we pressed was Right, Down, Left, or Up.
In other words, the Right key can't be overridden by holding another arrow key at the same time.
The other arrow keys can be overridden. Like, if we hold Left and then press Down, we will move Down. But not the other way around: If we hold Down and then press Left, we still keep moving Down.
The order in which this happens seems to be: Right -> Down -> Left -> Up, listed in order of priority. In other words, moving Right is always preferred over moving Down if both the Right and Down keys are held.
Important: For a game that uses 'key states' to determine direction, that's to be expected. Nothing wrong there. This is simply due to the order in which the key states are evaluated by OpenSupaplex, similar to this:
if (right) {
move_right();
} else if (down) {
move_down();
} else if (left) {
move_left();
} else if (up) {
move_up();
}This is actually the same as in the original game. Somehow the original game feels a bit different, but maybe that's because I've played on DOSBox instead of real hardware. Anyway, that's the reason I looked into this.
Desired behavior:
The desired behavior is to always move in the direction of the last key press, regardless of whether another key was held.
It might be desirable to add an 'Honor last arrow key press' option, where the movement direction always changes to the last key that was pressed, regardless of whether you were holding another key.
Why: This may make movement feel smoother, more responsive (snappier) while you're changing directions.
Then again, I recognize this is subjective because you're implementing a faithful replication of the original game. And the original game behaves the same as OpenSupaplex. Consider this report to be an enhancement request instead. It would be totally understandable if you do not wish to implement enhancements at all. If you do, you may want to add an option to simply toggle on/off all enhancements (if any others are implemented).
Possible solution:
It seems that OpenSupaplex looks at 'key states' to determine the direction, instead of processing key press events. This problem can be avoided by implementing an event-based handler instead of a 'key state' handler, by avoiding SDL_GetKeyState() and using SDL_PollEvent() instead.
I tested the above with OpenSupaplex v7.1.2.
Thanks for keeping this classic game alive. It is highly appreciated. 🙂
If we move to the left and then want to move up, we might still be holding the Left key while pressing the Up arrow.
If we were still holding another key (like Left) while pressing the key for the new desired direction (like Up), then the Up arrow key press event is ignored until we release the other key we were holding.
Actual behavior:
If we hold both Right and any other arrow key, we always move Right, regardless of whether the last key we pressed was Right, Down, Left, or Up.
In other words, the Right key can't be overridden by holding another arrow key at the same time.
The other arrow keys can be overridden. Like, if we hold Left and then press Down, we will move Down. But not the other way around: If we hold Down and then press Left, we still keep moving Down.
The order in which this happens seems to be: Right -> Down -> Left -> Up, listed in order of priority. In other words, moving Right is always preferred over moving Down if both the Right and Down keys are held.
Important: For a game that uses 'key states' to determine direction, that's to be expected. Nothing wrong there. This is simply due to the order in which the key states are evaluated by OpenSupaplex, similar to this:
This is actually the same as in the original game. Somehow the original game feels a bit different, but maybe that's because I've played on DOSBox instead of real hardware. Anyway, that's the reason I looked into this.
Desired behavior:
The desired behavior is to always move in the direction of the last key press, regardless of whether another key was held.
It might be desirable to add an 'Honor last arrow key press' option, where the movement direction always changes to the last key that was pressed, regardless of whether you were holding another key.
Why: This may make movement feel smoother, more responsive (snappier) while you're changing directions.
Then again, I recognize this is subjective because you're implementing a faithful replication of the original game. And the original game behaves the same as OpenSupaplex. Consider this report to be an enhancement request instead. It would be totally understandable if you do not wish to implement enhancements at all. If you do, you may want to add an option to simply toggle on/off all enhancements (if any others are implemented).
Possible solution:
It seems that OpenSupaplex looks at 'key states' to determine the direction, instead of processing key press events. This problem can be avoided by implementing an event-based handler instead of a 'key state' handler, by avoiding
SDL_GetKeyState()and usingSDL_PollEvent()instead.I tested the above with OpenSupaplex v7.1.2.
Thanks for keeping this classic game alive. It is highly appreciated. 🙂