Controls Menu
I decided to finish off one of the more complicated submenus first - the controls definition menu. Although Ice Slider is simple enough to get away without one of these, I really want one that I can copy across to future games. Plus it's always good manners to allow your players to define their own controls, of course. Although my control system only allows keyboard input at the moment, it does allow up to three key definitions for every game action - more than enough for something like Ice Slider.

I mentioned in the last post that I thought there might be a few snags implementing this menu, and that certainly was an understatement. Some of the highlight problems:

• SDL has a nice function called SDL_GetKeyName that returns SDL's name for each of the keys. Unfortunately these strings make use of the full ASCII set, whereas my Aenigma font "Stranded" that I'm using only has the alphanumeric glyphs defined. Thus I had to define my own array of strings to name each of the two hundred odd keys defined by SDL. And of course, as is required when hand writing such a long array, there was an obscure off-by-one error that put all the strings out of alignment (turned out to be a missing comma). I'm also unsure whether all the names are correct - I still have to test all the keys and peform some fine tuning there.
  
• I'd already written an input control listener wrapper thingummy-jig that translates raw input data into event signals corresponding to game actions. However this control menu is a special case that needs to break that layer and get some raw data whenever a new key is being entered. This lead to all sorts of interesting problems as you need to press a key to tell the program that you are entering a new key. My menu structure as it is is basically a huge state machine made of nested switches, but I had to had another layer just to deal with that problem.
  
• Continuing from the enter a key problem, I've found out that SDL considers NumLock and CapsLock to be pressed down whenever they are active. I still haven't fixed that problem yet - I'm going to see if SDL has a setting to deactivate that behaviour. If not I'll either put in some special code for those keys or just disable them completely.
  
• I found it's not a good idea to immediately change the keys once they are modified in the menu, especially if you use the defined arrow keys to navigate around the menu. Even worse is when this applies to deleting keys and you allow the player to clear all the definitions [smile] (fixed that one: you have to have at least one key definition, and now you must choose "save" to apply your key bindings)
  
• When I had almost finished the menu, I realised that I really needed those "save" and "reset" options, and they would have really mucked up the hacked together menu system I'd already written. So I had to rewrite most of the control menu code again. It's still a deep structure of switch statements, but at least now it's more understandable and allows those extra commands.

I still haven't finished with this menu - I'm unsure about whether I should allow the player to bind two actions to the same key or put in a logic test to stop that, and there's some cosmetic changes I'll need to make to the looks and the names of things - but it's there, workable and "good enough" for the alpha.

Next up is the graphics submenu, which will probably only have a handful of features to begin with as there's little already defined. Once that's done, I'll leave the other menus until later and I can start on the game code proper.