GZDoom localization development thread [Split]

[Rachael]

That all depends on whether you want to modify the original game’s contents, which, out of principle, is a red flag to me.

Even for modders?

[Kostov]

Good point. Still, I don’t think it would be a bad choice in the long run—non-accented letters are the norm in English, and accented ones are the exception. I personally wouldn’t mind seeing letters collide every once in a while as long as it’s consistent.

[Rachael]

Agree to disagree, and I think we should just leave it at that.

I know you're very passionate about this subproject, but ultimately you're not seeing the bigger picture here, and in the world of programming that can bite you in the ass in unpleasant ways.

Every time Graf complains about something Randi did, it usually originated from an idea like your's - a special case scenario one-liner that eventually gets buried in the code and causes a bug somewhere else, to be discovered years later or be revealed by a refactoring later on that triggers the bug. And with the case of language this is especially bad, because in the grand scheme of things the language code is only a minor subproject as far as the C++ side goes. That means the code is essentially going to be in an as-is state outside of bug fixes as the developers move on to other projects and a lot of the finer implementation details will be forgotten about.

To make matters worse, these one-liners aren't easy to find when you're looking for them 10+ years after they were put in.

It's a bad idea, it shouldn't be done, Graf seems to think so too, and it's really not hurting anything. I think it's best to just leave it alone.

[Graf Zahl]

The main problem here, of course, is, that users can replace the font - so any special tweak to make one particular font look better will have far wider repercussions.
And for what it's worth - I always found the spacing in the dialogues a bit too tight anyway.

Apropos one-liner hacks: Just last week we had one of these surfacing: When I changed the menu dim to better accomodate the menus' visibility, it just happened that Hexen's dim became opaque. Why? Because back in the day a special case was added to double the opacity of the dim when playing Hexen. Too bad that I decided to set the default to 0.5 which made it fully opaque.
I really hate this style of coding - hacking in a special case based on very specific circumstances that are taken for granted. I've never seen that it doesn't cause problems later.

ZDoom's original code was full of these things - often causing subtle bugs because those hacks were based on bogus assumptions. I have spent endless time fixing these over the years, they were basically everywhere, and many still are, just lurking for biting someone in the ass. A good example for this is that Randi once added some special coding to the Pain Elemental to move down when hitting a sloped ceiling. Just too bad that part of this code was a class member function of APainElemental and part of it was in A_PainAttack, making the entire thing broken from the start because even Dehacked can give this action to other actors.

Quoting an old movie: "Assumption is the mother of all fuckups." So what makes you assume that this time the hack will be benign?

[Enjay]

A good example for this is that Randi once added some special coding to the Pain Elemental to move down when hitting a sloped ceiling. Just too bad that part of this code was a class member function of APainElemental and part of it was in A_PainAttack, making the entire thing broken from the start because even Dehacked can give this action to other actors.

I remember when that code was added - and it was a very long time ago. I'm not defending the code, but I do remember that the pain elemental was definitely behaving badly with reference to sloped ceilings and it took a number of goes to get it "right". I also wonder if the "fix" was what was responsible for some problems that I had with exactly the situation that you mention: giving A_PainAttack to actors via DeHacked (though it was so long ago, I don't remember the details).

[Graf Zahl]

The problem with that code wasn't that it was a hack, but that it made a bogus assumption (i.e. the PE and nothing else can call A_PainAttack.)
The point being, you cannot ASSUME that you got all eventualities covered, you have to make sure. So, here someone suggested a) to add a hack under b) the assumption that he got everything relevant covered. But as things stand a) hacks are never good and b) if they are needed they shouldn't be based on faulty assumptions. There's more than one valid reason why there may be some non-standard characters in English text.

[Gez]

Yeah, I forgot about that completely. French names that land in English by any means always keep their accents. Which is hell to type on an American keyboard because you can't type accents on those without alt-codes or copy-pasting or just add one of the European layouts to your switchable keyboard layout selection.

Yeah, a few French words come with accents when you want to spell them correctly (e.g. "fiancé" and "fiancée"; also "voilà" which is quite popular on the Internet even if anglophones usually spell it as "viola") but that's not all. You can find things like "coöperate" (I think the New Yorker loves that) to mark that the second o is separate from the first and that they don't make an ou sound; and then there's "Pokémon" which isn't a French word at all.

[Rachael]

About the American keyboard: Silliness aside with many Americans thinking that they're the most important people in the universe, I think we would've had an international layout become standard here if the original IBM PC keyboard layouts (particularly Model M, which is the base for most of today's variants) were designed in Europe instead of here. It actually would be nice to type accents on my keyboard without being forced to swap layouts and use muscle memory from a Swedish keyboard.

And if you're going to suggest I use a Swedish layout full-time: forget it. I've been using the American layout for 23 years prior to my introduction of my first Swedish keyboard - you can't teach this old dog new tricks, she's too damn stubborn.

[Enjay]

I wonder how much of using the accents in English is an American English thing? The reason that I ask is that although it is probably strictly correct to use the accents in British English, in practice they seem to appear far more rarely (even when hand written, so it's not just a keyboard thing).

My guess is that most people simply don't know how to use the accents, especially if they have never learned a language other than English (not unusual in the UK). Again, I'm guessing, but I reckon a lot of people don't even realise that the accents are meant to be there, rather than simply leaving them off.

The reason that I wonder if it is slightly different in American English is, even though the UK has always been a country of immigration and has cultural influences from around the world dating back many centuries, the US has much more of a "melting pot" culture where the influences of the various ancestries that make up modern America are perhaps more overt.

And maybe not.

[Kostov]

One problem with the dynamic line height: it doesn’t account for offsets. Two characters, Ñ and Й, are 10 pixels tall instead of 9 but extend at the bottom instead of the top. This adds unnecessary line spacing. Any way to affect this?

[Rachael]

It might be possible to change the font reader to add an offset functionality. I am not 100% sure about that, though - in my experience, that's some code I've been afraid to dive into.

[theleo_ua]

Graf Zahl, Rachael, totally agree with you about hacks and assumptions, but I discussed this with Undead in our Russian discord server, and discovered that Undead proposed you incorrect solution

At fisrt, let me describe the problem with screenshots:

1) Here is how lines are rendered in GZDoom 3.7.2: https://cdn.discordapp.com/attachments/ ... nknown.png

Let's call this "Way 1"

2) Here is how lines are rendered in previous dev version of GZDoom: https://cdn.discordapp.com/attachments/ ... nknown.png

Let's call this "Way 2"

3) Here is how lines are rendered in current dev version of GZDoom: https://cdn.discordapp.com/attachments/ ... nknown.png

Let's call this "Way 3"


The problem is next: Undead don't like Way 3 (for English), so he proposed to use hack "to render English in Way 1 or Way 2, and render other languages in Way 3"

My suggestion is next: just add option "language render type" with next values:
Way 1
Way 2
Way 3 (default)

I mean, that changing value in this option will affect all languages (not only English)

This way, default users will have "Way 3", and Undead will set Way1/2 when he use English, and will change to Way 3 when he use Russian or French for example

Of course, those "Way 1/2/3" should be renamed to something understandable for users

[Graf Zahl]

TBH, this is the type of option many users would rightfully describe as "clutter".
The main problem seems to me that the last revision of the font did not factor in these things. You simply cannot increase the height for the accents without negatively affecting other things as well. I am tempted to just revert that commit so that "way2" gets reinstated.

[Nash]

I don't really know what's being discussed here but "Way 2" looks the best to my eyes, from a player perspective. Sorry I can't add much more to the discussion

[Graf Zahl]

This is caused by the font height being different because Undead was tinkering with the accents.