[QOL] Borderless Minimap and Automap type save

[Rasti-i]

Adds a new automap type similar to the existing minimap, but less intrusive on the screen.
Also fixes the issue of not having the current automap type being saved and the game defaulting to the regular fullscreen automap on load. It does so by appending 1 byte of extra data to store the current automap type in the savefile, if that extra byte isn't found on load or is invalid, it falls back to the regular map ensuring backwards compatibility.

Preview of the new automap type and behavior:

[StephenCWills]

Also fixes the issue of not having the current automap type being saved and the game defaulting to the regular fullscreen automap on load. It does so by appending 1 byte of extra data to store the current automap type in the savefile, if that extra byte isn't found on load or is invalid, it falls back to the regular map ensuring backwards compatibility.

By placing the data in the game file, the persistence only applies to Single Player and only to the current game session. It will still reset when you select New Game, or whenever you create/join a Multiplayer game session, or when you create a new character. Is there some reason that this should be preferred over saving the user's selection in the INI file?

[Rasti-i]

By placing the data in the game file, the persistence only applies to Single Player and only to the current game session. It will still reset when you select New Game, or whenever you create/join a Multiplayer game session, or when you create a new character. Is there some reason that this should be preferred over saving the user's selection in the INI file?

Hi, multiplayer currently doesn't remember the map's state at all (whether it's open or not) anyway, but singleplayer does so that's what I wanted to improve on. The goal for it isn't to persist across different characters and sessions, I believe it's convenient to have the currently used type be stored and loaded per-save, especially since some users may prefer a different automap type depending on the current in-game environment, character or activity, so using the INI file to dictate the map type on game load would come back to the same inconvenience when circumstances change, having it saved in the game save makes it something the end-user doesn't have to worry about at all, a "pick up the way you left" solution.

[Trihedraf]

I would way rather it be saved in the ini. That would also be helpful on mobile where there is no way to change map types currently.

[StephenCWills]

some users may prefer a different automap type depending on the current in-game environment, character or activity, so using the INI file to dictate the map type on game load would come back to the same inconvenience when circumstances change

I don't agree. If a player were changing their map type based on circumstance, then they are no better off one way or the other. They'd need to have the keybinding to change the map type to whatever they need based on circumstance. One could even go so far as to argue that the INI file is a better option in that case, because the player can keep track of the current map type based on what they most recently changed it to. Otherwise, changing save files could change the map type in unexpected ways simply because you don't remember what the map type was when you last played that character.

Having it in the game file only definitively improves things if the player is frequently switching between SP characters that are consistently using different fixed map types. Like, for example, if there were a good reason to prefer the minimap for Rogue vs the fullscreen map for Warrior. Since you didn't offer a concrete argument to explain why different map types for different characters might be preferred--and because I, myself, can't think of one--I'm inclined to believe there isn't one.

I understand designing the feature based on what is consistent with the game's current mechanics, but the possibility of a player that prefers it this way isn't enough for me to approve of a change that affects the save file. To me it seems far better in terms of usability to put the option in the INI file, and if the persistence is eventually going to end up in the INI file anyway, then this change to put it in the save file isn't even a step in the right direction. So for this PR, I'd rather see it go straight into the INI file or nowhere at all.

[Rasti-i]

Since you didn't offer a concrete argument to explain why different map types for different characters might be preferred--and because I, myself, can't think of one--I'm inclined to believe there isn't one.

I understand designing the feature based on what is consistent with the game's current mechanics, but the possibility of a player that prefers it this way isn't enough for me to approve of a change that affects the save file. To me it seems far better in terms of usability to put the option in the INI file, and if the persistence is eventually going to end up in the INI file anyway, then this change to put it in the save file isn't even a step in the right direction. So for this PR, I'd rather see it go straight into the INI file or nowhere at all.

A melee character might prefer minimap over a fullscreen map for more combat clearance for example. Also different characters in singleplayer tend to be saved in different locations, which then again the user might prefer a different map type for, some dungeon level layouts/colors make the fullscreen map more or less visible.

But that aside, I changed the implementation into a gameplay option, that option gets read when the game is loaded to set the automap type, and it also gets written to when the game is saved, preserving my intended behavior minus the game character distinction. The option can be changed via the in-game menu, or the INI file. I believe that's the best compromise.

In-Game Menu:

INI file:
Automap Type=2
// 0=Opaque 1=Transparent 2=Minimap 3=Borderless Minimap

[StephenCWills]

Thanks. I've noticed a couple inconsistencies regarding the pattern we use for INI file options. I've referenced the item highlight as a good example. If you need more, the zoom flag is another good example.

[StephenCWills]

Sorry to keep picking on things in this PR, but I do think it's almost ready.

[StephenCWills]

Looks like you need to run clang-format on options.cpp and options.h. You can ignore the macOS error.