GZDoom localization development thread [Split]

Discuss anything ZDoom-related that doesn't fall into one of the other categories.

Re: GZDoom localization development thread [Split]

Postby Undead » Wed Feb 13, 2019 10:43 am

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
Undead
 
 
 
Joined: 26 Dec 2013
Location: Sweden

Re: GZDoom localization development thread [Split]

Postby Undead » Thu Feb 14, 2019 2:17 pm

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

Image
User avatar
Undead
 
 
 
Joined: 26 Dec 2013
Location: Sweden

Re: GZDoom localization development thread [Split]

Postby Graf Zahl » Thu Feb 14, 2019 3:03 pm

I'll have to do some thorough checks if those uppercase letters don't cause any problems elsewhere.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: GZDoom localization development thread [Split]

Postby Enjay » Thu Feb 14, 2019 6:15 pm

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
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Re: GZDoom localization development thread [Split]

Postby Kinsie » Thu Feb 14, 2019 9:43 pm

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
Kinsie
A Concept Utterly Obsolete
 
Joined: 22 Oct 2004
Location: MAP33
Discord: Find Me...
Twitch ID: thekinsie

Re: GZDoom localization development thread [Split]

Postby Jimmy » Fri Feb 15, 2019 12:05 am

1px kerning still needs to be added to that font, judging by the preview.
Jimmy
I picked a fine day to be lactose intolerant
 
 
 
Joined: 10 Apr 2006
Location: Perth, WA
Discord: Jimmy#4100
Twitch ID: JimmySquared

Re: GZDoom localization development thread [Split]

Postby Jimmy » Fri Feb 15, 2019 12:26 am

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.
Jimmy
I picked a fine day to be lactose intolerant
 
 
 
Joined: 10 Apr 2006
Location: Perth, WA
Discord: Jimmy#4100
Twitch ID: JimmySquared

Re: GZDoom localization development thread [Split]

Postby Nash » Fri Feb 15, 2019 1:18 am

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
Nash
Nash Muhandes
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia

Re: GZDoom localization development thread [Split]

Postby Graf Zahl » Fri Feb 15, 2019 3:49 am

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
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: GZDoom localization development thread [Split]

Postby Undead » Fri Feb 15, 2019 5:04 am

So what will we do about this? Do you want me to make a version without uppercase letters at all?
User avatar
Undead
 
 
 
Joined: 26 Dec 2013
Location: Sweden

Re: GZDoom localization development thread [Split]

Postby Graf Zahl » Fri Feb 15, 2019 6:53 am

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
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: GZDoom localization development thread [Split]

Postby Undead » Fri Feb 15, 2019 9:48 am

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 Undead on Fri Feb 15, 2019 10:55 am, edited 1 time in total.
User avatar
Undead
 
 
 
Joined: 26 Dec 2013
Location: Sweden

Re: GZDoom localization development thread [Split]

Postby theleo_ua » Fri Feb 15, 2019 10:41 am

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
theleo_ua
 
Joined: 07 Feb 2016

Re: GZDoom localization development thread [Split]

Postby Undead » Fri Feb 15, 2019 10:43 am

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
Undead
 
 
 
Joined: 26 Dec 2013
Location: Sweden

Re: GZDoom localization development thread [Split]

Postby Rachael » Fri Feb 15, 2019 10:46 am

Plus, Graf has already posted a reply in their topic bringing attention to that very issue.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle

PreviousNext

Return to General

Who is online

Users browsing this forum: Ahrefs [Bot], Semrush [Bot] and 1 guest