I'm not sure why keys doing multiple things at once is related; to me they are separate problems.
For example, if you're allowed to set the down arrow to "select" while the down arrow still moves the selection down, and you can't move the selection down any way, you're forced to select every menu entry.
If you disagree with this design decision, you can re-add the arrow keys or whatever to the lists assigned in set_gui_controls. But I've made this decision for very specific reasons, so I will not be regressing my release.
You should consider having multiple ways for driving the menus. For example, in C-Dogs SDL, you can drive the menus using: player 1 controls, arrow keys, mouse, or joystick 1.
You can use the keyboard or gamepad. In this context, I don't think mouse control is a good idea, since you don't normally use the mouse anywhere in the game. Even in games where you do use the mouse, I'd say navigating menus with it like in a GUI is questionable, because in some contexts, mouse support can make it unreasonably difficult to just use the keyboard (which is easier).
And yes, even if you set player 1 controls to the arrows for example, it still works, because the game just loops over all the possible menu controls to determine whether up was pressed or whatever.
That method of control puts the order of controls out of sync, and not to mention is inefficient. For example, if the game slows down and the player presses "down" twice and presses "enter" expecting to go into a certain menu, then presses down again because of impatience, this design decision would cause them to choose the wrong menu option. I think this is a bad design choice. If you disagree, feel free to publish a fork of xsge_gui (which handles the menu control) that works the way you describe.
I've never seen this with SDL2 + win/macOS, so either it's an X bug or SDL 1 bug.
It's a bug with the combination of SDL 1 and X, as far as I know.
If it's the former you should allow changing it for non-X ports.
I'm not going to design a game to behave in different ways on different window systems, even if I can figure out how to detect whether or not X is running and currently in use. Besides, I don't know the cause of the bug I am referring to. I'm not going to play a game of cat and mouse where I make special environments for every affected system.
If you disagree with my design decision to put the options menu only in the main menu, please feel free to publish your fork which also adds an options menu to the pause menu. All you should need to do is make a new class inheriting ModalMenu and OptionsMenu, then add an option that creates these to PauseMenu.
I assumed that game used WASD to control so I opened config menu and presses arrow keys. To my amazement, when I "rebound" down key, I couldn't use arrow keys at all. Since down is the last movement key, I've "rebound" all the movement keys before noticing this.
You can see all the controls after you change one, so all you have to do is look through the list and see which key is assigned to "down". In fact, although it is not documented, you can even use the "sneak" key to do the same thing. I think you're exaggerating a minor nuisance which is a result of a trade-off for stability and reliability. If you disagree with the design choices I made for controls config, feel free to publish your modified version. All of the code which handles it is in the event_choose method of KeyboardMenu.
In my own engine I decided the have a notion of field of view that is the lowest amount of game world that must be visible at any aspect ratio. So the game renders more horizontal stuff in widescreen and more vertical stuff in portrait.
This complicates game design tremendously, and it is pretty much guaranteed to allow breaking the game or making it look atrocious. I design my games in a simple manner unless there is a very good reason why they shouldn't be. If you disagree with my decision to design games like this, then please feel free to develop your fork, though I must warn you that this is not a simple task and the only assistance I will give is to add unavailable capabilities needed for the job to the SGE API.
This is just a bad design decision. You need to put level name somewhere at the start of the file and read only a few bytes.
I didn't design the level format. It's a standard TMX file. Also, you can't just look for the name; you also have to look through all the objects and see if any Tux dolls are available, because otherwise the indicator for that won't display correctly, and that entails looking for doors and warp pipes and recursively searching those files as well. If you can change it so that it only loads the TMX file softly (without creating a room, the part that takes up the most time), and if it is
always instantaneous (because I consider two load times for one level to be unacceptable), then I will happily merge that. However, I consider this to be an enhancement of very little importance that involves a lot of work, so I will not be devoting my own time to it.
Well it's not solely because of the difficulty but overall boringness. There is no multiplayer or sandbox mode to experiment in. Though SuperTux has the same problem.
Haven't we been through this before? If you don't like single-player games, that's fine, but many people do.
I am open to adding a 2-player option to ReTux (probably similar to NSMBWii), but I don't have graphics for that.