The current menu system simply does not work that well with 320x200, rendering the game hard to use at that tiny screen size. This is a clear case where the work required to keep it operational stands in no relation to the benefit.
There are two options here - one only disables the vertical thrust and the other goes back fully to the original non-z-aware code.
Both options are settable through MAPINFO.
For the compatibility presets, the normal ones only disable the vertical thrust, the strict ones force use of the old code entirely.
This was yet another piece of code that essentially was unworkable thanks to the limited screen space with the old bitmap fonts.
With the new font there is enough screen space to do this properly.
This has to be set in the console, the default is still the regular small font. Mainly added because some mods have really hard to read fonts where it is not easy to decipher the numbers.
1. Top-level menu names are now properly handled.
2. Changing "Any or All terms" option now immediately updates the results.
3. Reformatted menu.zs to have tabs instead of spaces.
The default was changed to replace graphics if only known content is affected.
This also required blocking the feature for Hacx, Harmony and Action Doom 2 which have no localization yet and would fall back on Doom's texts if not blocked.
- clamp scissors fully to avoid NVidia's awful drivers locking up the entire system if they end up out of bounds
- perform buffer clears as part of the render pass. this puts some restrictions on how FRenderState.Clear can be used
- add an offset uniform to the present shaders so the vulkan target can flip the image during presentation
The most important one is the autosave tagging. This was done because the old printout was missing the year and printed the month as a 3 character English string, sabotaging any attempt to sort the autosaves by anything meaningful.
Parts of this menu suffered badly from lack of screen space to convey the intended information due to the oversized fonts. With the new font this is a lot less problematic (unless using 320x200, of course)
Unlike uObjectColor2, this is more global state. uObjectColor2 is part of gradient calculation which may later be offloaded to a secondary buffer which already resulted in only conditionally setting it, resulting in broken special colormap application for the software renderer.
This option value is used for 4 different options, and splitting it up into three will allow for languages based on grammatical gender systems to have different endings. Necessary for e.g. Russian in order to sound correctly.
The corresponding strings are already in the language spreadsheet.
The recent localization work has made it apparent that on many images the menu was extremely hard to read because its colors often clash with the background.
The choice of a bright overlay color with extremely low opacity is simply not enough to make the menus comfortable to navigate. Chex Quest was particularly bad but the problem existed in many Doom mods as well.
This also changes the CQ dim color to something a bit more green to better fit with the theme.
- moved language entry up a bit in the menu
- converted the language entry into a proper CVAR string list selection, instead of a separate menu with said list.
Now a localization mod can disable the graphics patches containing text entirely so that it can properly localize the text based menu variant.
If this flag gets set in MAPINFO, it will override all user settings.
In this menu, all languages supported by GZDoom are selectable with one simple click! Credits to @PROPHESSOR for making it!
(This only edits the English and French languages because they are the only languages currently up to date with GZDoom’s development. A Russian translation will follow suit at a later date.)
* added a CVAR that sets how localizable graphics need to be dealt with.
* pass the substitution string to OkForLocalization so that proper checks can be performed.
* increased item spacing on Doom's list menus to 18 from 16 pixels, because otherwise the diacritic letters would not fit. 20 would have been more ideal but 18 was the limit without compromising its visual style
* added a second text-only main menu because here the spacing cannot be changed. Doing so would render any single-patch main menu non-functional. So here the rules are that if substitution takes place, it will swap out the entire menu class.
* fixed some issues with the summary screen's "entering" and "finished" graphics.
Passing something non-constant at compile time here is extremely dangerous, especially when users can replace those strings if they like.
It now uses FString::Substitute in all cases where something needs to be inserted into a template string.
* entering a savegame description did not work anymore
* the length check was too restrictive and always underestimated the available space
* use the console font for entering a savegame description. This has more characters and better contrast for this content.
* the interface to the text enterer used bad measurements.
What is done:
D1. Controls are separated by existing sections, each section is now a submenu;
D2. The original sections are preserved;
D3. The original controls order is preserved;
D4. "Controls" section is renamed to "Game", because "Controls" submenu of "Customize Controls" would be too confusing;
D5. Map (automap) controls are added as a section, map controls submenu is unchanged;
D6. Missing controls are added to "Other" section;
D7. Sections are given a title following the scheme "Customize <section> Controls", except N4 (see below).
D8. Inside the sections, spaces are added to group the related controls.
Things that I'm not sure about:
N1. "Game" controls section name is too generic - I'll gladly change it to something more suitable;
N2. "Other" controls section name is too generic - I'll gladly change it to something more suitable;
N3. Map controls submenu could use some spacing, and internal title ("Map Controls") is redundant;
N4. "Strife Popup Screens" section name is too long to fit in scheme described in D7, therefore the title is "Strife Popup Screens Controls";
N5. "Game" section could be divided further, but this will break the original menu structure.
For the Doom IWADs the provided font looks almost identical to the characters used on the title patches. So, for any level name that got replaced in some language, it will now check if the retrieved name comes from the default table, and if not, ignore the title patch and print the name with the specified font.
This also required removing the 'en' label from the default table, because with this present, the text would always be picked from 'en' instead of 'default'. Since 'en' and 'default' had the same contents, in any English locale the 'default' table was never hit, so this won't make any difference for the texts being chosen.
Last but not least, wminfo has been made a local variable in G_DoCompleted. There were two places where this was accessed from outside the summary screen or its setup code, and both were incorrect.
This was broken by several small unicode-incompatible code fragments.
This commit also removes the input limit for the player name and the savegame description. With multibyte encoding, limiting them to a fixed length did not work right.
Currently these will just overflow the fields if the text becomes too long, this needs some additional work.
Now that GZDoom supports uppercase and lowercase characters in the BIGFONT format, this commit actually adds those characters. It contains full support for both the English and Russian (minus the letter Ё) alphabets for both Doom and Strife. As for the existing punctuation graphic lumps in Strife, all extra space is removed, and the sprite offsets are adjusted instead.
This also adjusts the English language file so that all menu header texts utilize these new characters. As a tiny extra, it also adds the letter Ё to the Strife smallfont.
(Credits to Skulltag for the uppercase B, Amuscaria for the uppercase X and Z, and @jnechaevsky for all Russian characters, taken from Russian Doom!)
With localization for non-Latin languages on the support list the multibyte API doesn't cut it anymore. It neither can handle system text output outside the local code page nor can an ANSI window receive text input outside its own code page.
Similar problems exist for file names. With the multibyte API it is impossible to handle any file containing characters outside the active local code page.
So as of now, everything that may pass along some Unicode text will use the Unicode API with some text conversion functions. The only places where calls to the multibyte API were left are those where known string literals are passed or where the information is not used for anything but comparing it to other return values from the same API.
