Menu concerns for 1.08

[Springheel]

The menus have been in flux for a while, but since we're coming up on 1.08 I've noticed a couple issues that need to be dealt with.

 

There have been a lot of changes to the menus in order to make them suitable for translation; turning buttons into text, changes to the mouseover effects, font widths, etc. Let me make it clear up front that I'm content with the majority of those changes.

 

But there are a couple small things that I'm not entirely satisfied with.

 

One issue is that the artwork on the parchment has been modified. In some cases the size of the image has changed significantly. I assume that's a side-effect of separating the image and turning it into a decal rather than an intentional change, and that there would be no objections to my modifying the images to match the original 1.07 size.

 

The more difficult issue is the appearance of the menu titles.

 

We have 5 menus with menu titles (Main, Download, New Mission, Settings, Load/Save). Of the five, 2 have had the graphic title replaced with regular text. The other three have not. That alone is a bit of an issue...having them consistent for 1.08 is probably desirable.

 

I appreciate Tel's attempt to match the original look of the menu titles, and I know it's very difficult to do anything with the limited gui text effects. But at the moment I'm just not satisfied with the text version of the titles--they're a noticable step down in quality. Rather than a soft glow to blend the letters into the parchment, the replacement titles have a sharp dropshadow and really stand out. In addition, the font is not quite the same (you can see the different in the 'T's and the 'N'). There are three different versions of the Mason font, and the text titles are not the same version.

 

 

Original 1.07 title on top, new 1.08 title on bottom:

 

 

These are not major problems, and some people probably wouldn't even notice. But since I'm the one who made the menus in the first place, I can't help but see the difference.

 

I have a few ideas for possible solutions to this:

 

1. Stick with the original titles. Only two have been changed thus far, so this would be the quickest option. All of the menus can still be fully navigated by non-English speakers without being able to read the actual title (and in fact, anyone using the translated menus in the past seven months has already been doing this).

 

2. Create a glow font. Tels, you mentioned once about the option of creating a special font to simulate a background glow. That might help in this situation, though I'm not sure whether it would look good enough or not. Possibly a lot of work for an experiment that might not pan out.

 

3. Graphic Overlay. Leave the English titles the way they were in 1.07, but include a parchment background to the windowdef for translated titles. The parchment would go over top of and hide the English title, and a translated text title could appear over top of that. Not sure how hard that would be to make work though.

 

4. Subtitles. Leave the titles the way they were in 1.07, but add a translatable string above or underneath. The English translation would be blank, so that the English menus would stay the same. But other languages would have the translated menu title. This change is completely transparent to those not using alternate languages (good) but foreign-language speakers still get to read the title in their own language (good). See example below:

 

 

If other people have suggestions or thoughts on the matter, feel free to share.

[Tels]

Since I invested quit a lot of time into this issue, I am of course biased

 

Let me preface this with one thing: The translation work has been underway since last years summer, so its nearly one year. That the menu issues are now only mentioned 6 days before the freeze for v1.08 (and where I still have a lot of other outstanding issues) is very poor timing - it now creates pressure on me due to the "we must do something NOW or miss v1.08" situation, .

 

Anyway, here is my take:

 

For the options:

 

1 is not an option at all IMO. You lose all the work, just to satisfy your desire to keep things as they are. As you said, most people don't notice the difference - but anyone not in English will notice the difference.

 

2 Yes, creating the glow font is a few hours worth of work, and it might look slightly better. But frankly, too much work for such small difference. My idea was to add "glow font rendering" to the renderer, then we can also replace the "font + glow font" hacks the rest of the GUI uses for the glowing fonts. However, we have nobody working on this, and my brief look into this shows me I need a lot of coding work for this. This is something for v1.09 and something we really should do, but as I said, the current "glow hack" just works, so spending a lot of time to replace it is "nice to have".

 

3 That might work, if we define some sort of "string" that is "1" for english and "0" for all other languages. Then the title hides the text in english only. But it also means bringing back the graphics (more memory to waste), a lot more complicated GUI, and also different looks for different languages. Plus, in some languages the title can have completely different lenghts/widths. Not to mention that the original grpahical title was "fused" into the parchment, so I'd need to sep. it somehow and that would not work with the new parchment backgrounds.

 

4 Ug, now. The English versions do not look that good that you need to burden all international users with them - plus it would use even more space and it would make the difference between the title and the text even more apparant. And it also has the same issue with "bring back the graphics" as 3.

 

 

My opinion is:

 

* Converting the other two menus (downloads and load/save) is something that should be done for v1.08 - having the titles be consistent goes a long way to make it better. Since its on my TODO anyway, I will do it in the next few hours so we can leave that behind. (I need to commit the modified stone font first, tho). Edit: The Mason font is also used in other places, so that there are only "2 menus done" is not accurate.

 

* I can also modify our Mason font to match the original more closely. This was not done because A: it is additional work and B: nobody offered any opinion so far so I deemed it not important. If you think this is important and helps, just say so and the N and T will get to look more like the original. In this case also please say what other characters you want to modified

 

* If it helps, I can experiment with a glow font. But I'd rather not waste time on this when we are gonna fix the font renderer, anyway.

 

Otherwise, leave the new titles and see if anyone even notices the difference when v1.08 rolls out. My bet is not, because we got zero complains about it in v1.07 (but a lot of international users complimenting us forthe translation, and noticing when something was not translated, which means they actually used it to play).

 

 

One issue is that the artwork on the parchment has been modified. In some cases the size of the image has changed significantly. I assume that's a side-effect of separating the image and turning it into a decal rather than an intentional change, and that there would be no objections to my modifying the images to match the original 1.07 size.

 

Yes, if you think this is important, feel free to change it. Usually it would be enough to change the GUI rect size. Although I really wonder if we should spend time on such minor issues - see above

[Tels]

I already had modified the t and T but due to an mistake in the patch file, the t got cut off at the top. Here is how it looks now:

 

 

As I said, I can easily modify N and n, too.

[Tels]

I have moved the characters around to make a glow variant possible (the automatic conversion places some characters very close to the border, so the glow would be cut-off). While doing so, I noticed "ú" is invisible, so I fixed that.

 

Also, there we only a handful characters onthe 6th image, so I moved them around, so we only have 5 DDS images now. And then I removed the 12 and 24 pixel variants, so we always use the 48 pixel variant (which the menu headlines use, anyway).

 

And then finally I made a glow variant. (The russian version does not have a glow variant, it renders the same text twice. Not ideal:(

 

The amount and color of the glow can be tweaked by the line

 

#define HEADLINE_GLOW	   textscale 0.81  visible 1  textalign 1  forecolor 1,1,0.85,0.8  font "fonts/mason_glow"

 

in guis/mainmenu_defs.gui, line 403. The example here show the unmodified white, and a yellow variant (3rd and 4th row). The one the menu uses now is between these two and comes more close to the original:

 

 

I have not yet done the "nN" as it involves a bit more work, because of the ñ and so on variants.

 

Now to modify the Load/Save menu and the Download Menu screens...

[Springheel]

1 is not an option at all IMO. You lose all the work, just to satisfy your desire to keep things as they are. As you said, most people don't notice the difference - but anyone not in English will notice the difference.

 

I haven't read the rest of this yet, but just to head off any misunderstanding, I'm not talking about changing things that were already released in 1.07. I'm only talking about the two menu titles that were changed since the last release. There wouldn't be any difference for the end user to notice.

[Tels]

I haven't read the rest of this yet, but just to head off any misunderstanding, I'm not talking about changing things that were already released in 1.07. I'm only talking about the two menu titles that were changed since the last release. There wouldn't be any difference for the end user to notice.

 

I know, but I still resent this.

 

The changes have been in SVN since many months, and it is not my fault that they haven't been looked at for this long, until 7 days before freeze. And I absolutely loathe to lose (or postpone it 6 months) my work just because this issue was ignored until now.

 

It's already bad enough that the international users have to wait for such fixes for several months (7 since v1.07, probably 9 until the release of v1.08). It was so bad that I already created an intermediate update for them. And now they have to wait another X months just because the new headlines are "not pixel-perfect"?

 

Put yourself into the other role for a moment. The game is only available in Polish or German. After many years, someone translates at least the menus into English. It's not perfect and only 95% complete, but heh, it's a start. Then the other 5% are done, so instead of "Einstellungen", you can now read "Settings". And then the Art lead comes along, declares that "The new Settings for the English users looks a bit different so we need to rever that. That the International users now have to read "Settings" instead of "Einstellungen" for a couple of months more, to bad for them". How would you feel?

 

Edit:

 

In my opinion both the new and the old Settings look so alike, that it is not really possible to say which one is better. But one means "no translation" for anyone not speaking English, the other means international users are happy. The decision should be easy, me thinks.

 

Apart from the size differences (some of these are nec. because otherwise some international texts don't fit), the glow (now fixed), the "t" (now fixed) we only have the "n" as difference. Frankly, if the TTF font you choose back then for the headline would have the "n" that the font I had to use, you'd probably still argue that it needs to be "the other".

 

For me this sounds like you are arguing that the headline should still look like the version you did - not because this is better, but just because it should not be changed. While understandable, this is simply impossible without investing a ton of work into the GUI rendering engine and even then it would still be nec.to create exceptions for the English language. I think this are unreasonable demands.

 

 

So my opinion is that we should fix what we can (to bring the new closer to the old), and postpone any other fixes in that regard to v1.09. In the meantime, the international users enjoy a polished menu, while the English users have to live with some slight imperfections that most won't even notice.

[Springheel]

The changes have been in SVN since many months, and it is not my fault that they haven't been looked at for this long, until 7 days before freeze. And I absolutely loathe to lose (or postpone it 6 months) my work just because this issue was ignored until now.

 

I can understand that. I could have said something sooner, but since only two of the titles were changed at the time I didn't assume that was the final version. You seemed to imply on a few occasions that there were more changes to come.

 

 

We did have a conversation at one point where we agreed that the menu changes needed to be transparent enough that I couldn't really tell there had been a change. It's easy to say that subtle changes don't matter, but from an artistic standpoint all good menu design is a collection of subtle elements working together. Change the size of something and it throws off established sightlines; change the opacity of an element and it can affect the visual weight and balance between it and everything else. People without any art training might not notice which elements were changed, but everyone can feel the difference between a design that follows good artistic practices and one that doesn't.

 

Now, having said that, if you want to explore option #2, I'm fine with that. See below.

 

in guis/mainmenu_defs.gui, line 403. The example here show the unmodified white, and a yellow variant (3rd and 4th row). The one the menu uses now is between these two and comes more close to the original:

 

This looks promising. IIRC, there's a way to scale text in either the x or y direction, is there not? Scaling the text so that it is a bit higher would get it pretty close to the original, even though the horizontal size is smaller.

[Tels]

I can understand that. I could have said something sooner, but since only two of the titles were changed at the time I didn't assume that was the final version. You seemed to imply on a few occasions that there were more changes to come.

 

Hm, this is a misunderstanding. More changes to come was meant "I want to change the other menus, too" and "the renderer might get fixed more". It wasn't means that the appearance would change for instance for the settings menu headline - this was already "waiting for feedback". Since there came none I assumed it is "ok".

 

And since there is always way too much to day, the font renderer changes where pushed back as they are not critical (as some of the other fixes like the font loading etc).

 

We did have a conversation at one point where we agreed that the menu changes needed to be transparent enough that I couldn't really tell there had been a change. It's easy to say that subtle changes don't matter, but from an artistic standpoint all good menu design is a collection of subtle elements working together. Change the size of something and it throws off established sightlines; change the opacity of an element and it can affect the visual weight and balance between it and everything else. People without any art training might not notice which elements were changed, but everyone can feel the difference between a design that follows good artistic practices and one that doesn't.

 

While I basically agree, there is only so much one can do to cater for everyone, esp. with the limitations of the GUI. I have always made it clear that I do as much as I can, but there are simple things that are out of reach (it has gotten a lot more promising with the source code, of course!)

 

Now, having said that, if you want to explore option #2, I'm fine with that. See below.

 

This looks promising. IIRC, there's a way to scale text in either the x or y direction, is there not? Scaling the text so that it is a bit higher would get it pretty close to the original, even though the horizontal size is smaller.

 

Hm, no I think this only works for graphics. However, given that the renderer just applies "textscale, textscale" when rendering the font, it might be easy enough to add "textscalex, textscaley" and make both textscalex and textscaley default to textscale.

 

The other would be to use http://www.modwiki.net/wiki/Forceaspectheight_%28GUI_item_property%29 - if that works it might be a bit faster (no code change nec.) but is surely an ugly solution.

[Tels]

I toyed around with the forceaspectheight and thanx to the menue #defines it was actually easier to add than I thought. A ratio of 350:480 matches the text now more closely in height:

 

 

However, as you can see, the G is not as wide, and the S does not reach as much down. While the G can be easily fixed, the S is more problematic, because it means I would need to fix all 26 uppercase letters (plus the special variants). That's surely a few hours with Gimp and the font patcher.

 

Edit: Ok, changing the "g" gets us closer:

 

 

Now I have spent all the afternoon on this, and none of the other outstanding issues for v1.08 have been done

 

What next? Should I match the "nNñÑ" etc more closely to the orginal? Should I match the Uppercase characters more closely to the original font?

 

Or continue to work on the other menu issues (converting the Load/Save menu, the Download menu)?

 

Or continue to work on the outstanding bugs (finishing SL? ragdoll sounds?)

[Springheel]

This and the glow are already a huge improvement. I wouldn't worry at all about the width of the lowercase G & S. It would be nice if the uppercase was slightly larger but I wouldn't spend hours on it. Is there maybe a cheap and easy way to just increase the scale of the uppercase letters in relation to the lowercase or is that set in the actual image file?

[Tels]

Whops, already done the g and edited my post before I saw your replay.

 

The Uppercase letters' positions are shifted in the font file, so you can write "Settings" and it will look like the above. Before I discovered that this is actually possible, I toyed around with sep. "S" and "ettings". But this is quite complicated, you need always two strings (the translators will hate you and it is impossible to define where to place the S - because the text is centered, and it is impossible to foresee where the "S" need to land. This would mean you'd need for every language something like:

 

"#str_1000" "S"
"#str_1001" "ettings"
"#str_1002" "32"	   // x position of S

 

Instead of just

 

"#str_1000" "Settings"

 

A nightmare to create (manually aligning positions) and a nightmare to maintain.

[Tels]

Hm, ok, I thought that maybe it can be done. The font patcher is able to "scale" characters. That means the same texture is used, but is drawn just differently. I *think* if we scale the S 10% larger and maybe 8% wider (or something like that) it might actually look quite close.

 

And wow, that actually works (20% wider and 10% higher):

 

 

(Yes, that is a really 60% transparent overlay of a screenshot of the new text over the old

 

Sometimes I think I am a genius - quick, somebody wake me up!

[Tels]

While looking at the uppercase characters, it occured to me that I only done the normal upper case letter A - Z, but not any of the specials like Ö,Ä etc. So I now added these into the patch file:

 

 

We don't have such a string yet, but it is not unlikely to happen with these pesky foreign strings

 

I also fixed the patching of the glow font, this font now properly enhances the character sizes so the glow isn't cut off. As a side effect the glow got a bit stronger now, I'll adjust this in the GUI. But now I need to go and see the new MIB 3 movie

[Springheel]

And wow, that actually works (20% wider and 10% higher):

 

Wow, I didn't expect a solution quite this fast. Great job!

[Tels]

Spring, I just noticed that in your comparisation shot, the lower-case letters looked already the same size. Measuring it in Gimp confirms this.

 

Could you please take a screenshot on your system between v1.07 and the new 1.08 menu and post it here? I think the "forceAspectHeight" thing was unnec. and needs to be reverted. The uppercase letters still need to be scaled by 20% (but in both directions instead of 20% higher and 10% more wide).

 

Comparing my screenshot to you screenshot seems to be a problem, as the aspect ration (16:10 vs 16:9 might be different - that would make the letters have less pixels but on the screen they would still appear the same hight. Or in other words, the lower case letters will now be too high.

 

Edit: Checked again your screenshot, and remembering that I matched the text scale to the old size,so I just reverted the ForceAspectHeight change. The headline should now have the correct height again.

[Springheel]

It looks like some of the letters are the same height, but others (the s and o) are somewhat smaller:

 

(click to animate gif)

[Tels]

I was more concerned with the general height. Seems this is now right at least. That "s" is slightly smaller might be based on the TTF I used,and is probably not worth fixing.

 

However, what seems to be missing is that "N" and "M" are not as wide. The font file still scales themonly 10% in the width, not 20%. I adjusted this now and checked it in, could you please make a new comparisatin?

[Tels]

I promised to patch the Stone 24 font, and this is partly done now. Sorry that it took that long here is why:

 

For Stone 48, I patched in the top 20 most-used characters, but for Stone 24 I have now added over 40. Since we have 116 special characters now in our set, thats roughly one third. In addition I also fixed an error in Carleton (ý was actually drawn as ỳ a subtle but important difference and also extended our character set by about 20 new characters. These were also added to the font patcher files, so any font patched by it now automatically displays f.i. Ż as Z, Ŝ as S etc.

 

http://wiki.thedarkm...=I18N_-_Charset

 

And here is a screenshot showing Stone 24 in action (the line beginning with "Straße")

 

[Springheel]

The menu titles now look great. But there seems to be an issue with the recent Stone changes:

[Tels]

My bad, a typo. Should be fixed now.

[grayman]

This has nothing to do with menus, but it does have to do with the Stone font.

 

I was trying to use the DR readables editor on a readable in my WIP that uses a custom gui, and DR crashed. This had been working just fine for the last few months, ever since I created the readable.

 

I built my own copy of DR and debugged the problem, which occurs when the editor tries to deal with the font to display the text. Clues from the debugger make me think the problem occurs when trying to read the 24pt Stone font.

 

Here's a section from my gui:

 

windowDef title
{
	WORLD_SCALE
	rect 37, 35, 230, 390
	forecolor 0, 0, 0, 0 //1st show before fadein. keep at 0,0,0,0
	font "fonts/stone"
	text "<title>"
	textscale 0.24
}

 

Does that translate into "use the 24pt Stone font"?

 

I was working with TDM 1.08 when I experienced the crash.

 

If I go back and work with 1.07, there's no crash and the editor displays my readable's text just fine.

 

Which makes me think DR isn't going to be happy with the Stone changes.

 

Now, I can change the font I'm using to something that doesn't crash, but I'm wondering if Stone 24's changes in 1.08 (and I assume there were some from reading other threads) are going to affect existing maps or current WIPs.

 

EDIT: I forgot to mention that even though DR crashes, TDM is able to bring up the readable just fine in-game.

 

EDIT 2: I changed "0.24" to "0.5" in the text definitions in my guis and the Readable Editor brought up the page just fine, so there's definitely something wonky about the '0.24".

 

EDIT 3: I created a new readable and tried to change the gui (using the Readable Editor) to "parchment_stone_print", and DR crashed. That gui uses a textscale of 0.25 for the body text.

[Tels]

This has nothing to do with menus, but it does have to do with the Stone font.

 

I was trying to use the DR readables editor on a readable in my WIP that uses a custom gui, and DR crashed. This had been working just fine for the last few months, ever since I created the readable.

 

I built my own copy of DR and debugged the problem, which occurs when the editor tries to deal with the font to display the text. Clues from the debugger make me think the problem occurs when trying to read the 24pt Stone font.

 

Here's a section from my gui:

 

windowDef title
{
	WORLD_SCALE
	rect 37, 35, 230, 390
	forecolor 0, 0, 0, 0 //1st show before fadein. keep at 0,0,0,0
	font "fonts/stone"
	text "<title>"
	textscale 0.24
}

 

Does that translate into "use the 24pt Stone font"?

 

I was working with TDM 1.08 when I experienced the crash.

 

If I go back and work with 1.07, there's no crash and the editor displays my readable's text just fine.

 

Which makes me think DR isn't going to be happy with the Stone changes.

 

Now, I can change the font I'm using to something that doesn't crash, but I'm wondering if Stone 24's changes in 1.08 (and I assume there were some from reading other threads) are going to affect existing maps or current WIPs.

 

EDIT: I forgot to mention that even though DR crashes, TDM is able to bring up the readable just fine in-game.

 

Hm, there are two things here:

 

* the textscale is independent from the font scale. If you use a scale of 0.x (in this case 0.24) it is compared to some threshold values, and the right font size is choose. D3 (and hence TDM for now) uses three sizes, 12 pt, 24 pt and 48 pt. The threshold for the 12 => 24 is 0.15 (it was 0.3 with D3 but we changed it) and the second threshold is 0.30 (was 0.6).

 

So if your textscale is 0.149, it uses 12 pt, if you use 0.24 it uses 24pt, and if you are using 0.3001, it will use 48 point.

 

However, I have no idea what DR does in which case.

 

* I don't know what code DR does use to parse fonts. The font code in TDM was updated quite a bit, f.i. it can deal with missing font files now. The issue may be simple here that DR still expects all three fonts sizes to be present, and errors out when there is only the 24 and the 48 version present.

 

This would be an (easily-fixable) bug in DR. TDM now substitutes another existing size if the one it tries to load does not exist. That has the advantage that you don't need to have 3 sizes of all fonts (and hence don't need to patch 3 different sizes).

 

Edit: If you change the textscale and it works, maybe DR only loads the nec. fontsize - so with 0.24 it uses the 12pt version, doesn't find it, crashes, with 0.5 it uses the 24pt version, finds it and is happy. This would indicate also that DR still uses the old threshold values.

[grayman]

Ok. I'll file an issue against DR and OrbWeaver can look into it. Biker and I were betatesting 1.7.1 for him when I found this crash. I'll point him back to this part of this thread for background.

[Tels]

It should be easy testing wether it is the missing "fontimage_12.dat" file (just restore it from SVN), or the patched "fontImage_24.dat" file (just restore an older version). My money is on the missing file, but who knows, maybe DR doesn't like my patched file? (Can't imagine it and it would be quite a nightmare)

[grayman]

I filed this issue and called OrbWeaver's attention to it.