GZDoom localization development thread [Split]

Discuss anything ZDoom-related that doesn't fall into one of the other categories.
User avatar
Kostov
 
 
Posts: 2020
Joined: Thu Dec 26, 2013 3:26 pm
Location: Sweden
Contact:

Re: GZDoom localization development thread [Split]

Post by Kostov »

Graf Zahl wrote:The BigFont as single characters looks like it's working now. So if you want to add something there, now is the time.
Sweet! I’ll assemble everything necessary from Jimmy’s second image above and make a pull request.
User avatar
Kostov
 
 
Posts: 2020
Joined: Thu Dec 26, 2013 3:26 pm
Location: Sweden
Contact:

Re: GZDoom localization development thread [Split]

Post by Kostov »

Here’s the pull request! And here’s a preview!

Image
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom localization development thread [Split]

Post by Graf Zahl »

I'll have to do some thorough checks if those uppercase letters don't cause any problems elsewhere.
User avatar
Enjay
 
 
Posts: 26517
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland
Contact:

Re: GZDoom localization development thread [Split]

Post by Enjay »

Will this affect all areas - e.g. printed messages in ACS? I don't know how much this will be cared about but I guarantee that there will be loads of mods out there with HUDMessages and Print messages where people didn't pay much mind to capitalisation of their text simply because upper case and lower case ended up with the same result on screen.
User avatar
Kinsie
Posts: 7399
Joined: Fri Oct 22, 2004 9:22 am
Graphics Processor: nVidia with Vulkan support
Location: MAP33
Contact:

Re: GZDoom localization development thread [Split]

Post by Kinsie »

Enjay wrote:Will this affect all areas - e.g. printed messages in ACS? I don't know how much this will be cared about but I guarantee that there will be loads of mods out there with HUDMessages and Print messages where people didn't pay much mind to capitalisation of their text simply because upper case and lower case ended up with the same result on screen.
I'm pretty sure that's what Graf's worried about.

Personally, I'd stick to the lower-case characters for the official GZDoom distro and leave upper-case to modders to avoid any issues caused by decade(s) of precedent.
User avatar
Jimmy
 
 
Posts: 4720
Joined: Mon Apr 10, 2006 1:49 pm
Preferred Pronouns: He/Him
Contact:

Re: GZDoom localization development thread [Split]

Post by Jimmy »

1px kerning still needs to be added to that font, judging by the preview.
User avatar
Jimmy
 
 
Posts: 4720
Joined: Mon Apr 10, 2006 1:49 pm
Preferred Pronouns: He/Him
Contact:

Re: GZDoom localization development thread [Split]

Post by Jimmy »

A couple of flash thoughts:

(1) I don't think anything necessarily precludes inclusion of two versions of the Doom BIGFONT, one with uppercases and one without. Keep in mind that there have always technically been two versions since Vanilla - one for the menu, and one for the intermission screen that omits uppercases! The majority of use cases of DBIGFONT have been based on this latter version of the font. In the event that this new font is indeed problematic, for legacy purposes I imagine one should still be able to set the no-uppercases font with SetFont("BigFont"), and we could designate the uppercase font as "BigUpper", or whatever. Perhaps "BigLower" would be the same as "BigFont", in order to keep a non-ambiguous moniker for the legacy font.

(1.5) (Then again, calling the "lowercase" characters as such is a misnomer - they're technically SMALLCAPS. Not that this matters much, I suppose.)

(2) If the new BIGFONT turns out to cause more visual problems than it solves, then - big ask, I know, but - why not give HudMessage a long overdue overhaul? Perhaps if a new, more efficient HudMessage function was created (perhaps with font choice built-in?), the default font used could be the new BIGFONT with uppercases, and this would theoretically leave all the legacy instances of HudMessage tied with SetFont("BigFont") alone and not cause problems.
User avatar
Nash
 
 
Posts: 17434
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia
Contact:

Re: GZDoom localization development thread [Split]

Post by Nash »

Yeah I agree that an "all or nothing" replacement of the stock Bigfont is a bad idea. The mixed case one should be opt-in.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom localization development thread [Split]

Post by Graf Zahl »

The new font will be a great asset for allowing better menu localization in Doom, because now it is possible to define text based replacements for the graphics without visual degradation.

But beyond that I'm not convinced. It will create some jarring inconsistencies on the level summary with the WILV* lumps and many mods out there do not have proper capitalization of their map names for display here anyway. For this case my suggestion would be to leave it as it was, there already is an option to set this font in MAPINFO's Gameinfo section.

For everything else: no. "BigFont" needs to remain the one without capital letters or several mods doing HUD message output with it will be negatively affected. If that new font is given a different name it should be fine. Then the mapper will have the choice.
User avatar
Kostov
 
 
Posts: 2020
Joined: Thu Dec 26, 2013 3:26 pm
Location: Sweden
Contact:

Re: GZDoom localization development thread [Split]

Post by Kostov »

So what will we do about this? Do you want me to make a version without uppercase letters at all?
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom localization development thread [Split]

Post by Graf Zahl »

The end result will be that this full font will probably be named BigUpper, and BigFont will be changed to only contain the regular, now lowercase characters. If you can do that, it'd be great.

I'll be a bit busy with under-the-hood work. After transitioning the Windows backend to Unicode and allowing the Posix backend to pass full Unicode characters to EV_GUI_Char, the next big step will be to convert all text input from game data upon load and make sure that all internal text representations for everything are consistently UTF-8.

For that I need to make sure that I don't miss anything. Text lumps run through FScanner are easy: Convert them after loading, before parsing and they should be fine. For other text lumps I have to check the parsers, but I believe that the only one that may transfer text to other places is Dehacked. For binary lumps containing text there's ACS's string tables, Strife's dialogues and the file names in the resource management. Zips are gping to be tricky because I found out this morning that SLADE screws up badly when getting fed with non-ASCII file names and creating non-standard Zips that look quite a bit broken on all platforms I tested them on. The good thing about this is that it was basically impossible to load any Zips with non-ASCII file names in the first place, so there's no backwards compatiblity concerns when I declare this part UTF8-only with no handling for broken old stuff.
User avatar
Kostov
 
 
Posts: 2020
Joined: Thu Dec 26, 2013 3:26 pm
Location: Sweden
Contact:

Re: GZDoom localization development thread [Split]

Post by Kostov »

Gotcha. The pull request has been updated, with all the uppercase characters for Doom put into “bigupper” folders.

I take it that uppercase and lowercase won’t be possible to combine in the same string if they’re going to be put in separate folders? If they can, there’s another change I need to make.
Last edited by Kostov on Fri Feb 15, 2019 9:55 am, edited 1 time in total.
User avatar
theleo_ua
Posts: 162
Joined: Sun Feb 07, 2016 11:38 am
Operating System Version (Optional): Windows 10
Graphics Processor: ATI/AMD with Vulkan/Metal Support
Location: Ukraine
Contact:

Re: GZDoom localization development thread [Split]

Post by theleo_ua »

Graf Zahl wrote:I found out this morning that SLADE screws up badly when getting fed with non-ASCII file names and creating non-standard Zips that look quite a bit broken on all platforms I tested them on. The good thing about this is that it was basically impossible to load any Zips with non-ASCII file names in the first place, so there's no backwards compatiblity concerns when I declare this part UTF8-only with no handling for broken old stuff.
Maybe this should be discussed with slade's dev team and they can fix this in future version?
User avatar
Kostov
 
 
Posts: 2020
Joined: Thu Dec 26, 2013 3:26 pm
Location: Sweden
Contact:

Re: GZDoom localization development thread [Split]

Post by Kostov »

theleo_ua wrote:
Graf Zahl wrote:I found out this morning that SLADE screws up badly when getting fed with non-ASCII file names and creating non-standard Zips that look quite a bit broken on all platforms I tested them on. The good thing about this is that it was basically impossible to load any Zips with non-ASCII file names in the first place, so there's no backwards compatiblity concerns when I declare this part UTF8-only with no handling for broken old stuff.
Maybe this should be discussed with slade's dev team and they can fix this in future version?
I’ve made an issue on their GitHub regarding the lack of encoding support. It could be expanded so that it applies to Strife dialogs as well.
User avatar
Rachael
Posts: 13531
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: GZDoom localization development thread [Split]

Post by Rachael »

Plus, Graf has already posted a reply in their topic bringing attention to that very issue.
Post Reply

Return to “General”