Allow fonts of different weights to be displayed at the same time

[Ranran(retired)]

The new anti-aliased fonts look great.
As I tested it, I started to think there was still room for improvement.
Thin fonts look especially good on dialogs. Thin fonts are especially preferred in Japanese, which has complex shapes derived from China.
On the other hand, such thin fonts have poor visibility on the "main screen"(map view) of the game.

Particularly in the extended case, the station label's floating text defaults to a shadowed style with no background.
In my opinion, the readability is not very good.

I notice that Hajo has been changing their label design last year.

- Both can be drawn in bold style.

Hajo is growing flowers and James is renovating the shed but I would like to incorporate it.
Font innovation is a big effort, but I think the ability to use bold type can be achieved with a little more effort on top of that.
However, implementing this into individual UIs will require another discussion and effort but there is no doubt that this will lead to improvements to the UI in the future.


I took Hajo's code as a reference and tested it with extended.


Hajo used bold only in the title bar of the dialog.
I found the station label difficult to read so I changed it to bold. (This change is not included in the patch)

some notes:
Hajo was changing the file structure (display.h/display.cc), but I didn't do that to avoid confusing the changes. It was predicted that it would be easier to merge into extended.
Certainly simgraph is so bloated that it might make sense to separate it. If separation is required, it can be done later.
Some conflicts have arisen in the process of implementing aliasing fonts in Standard.
https://github.com/Varkalandar/simutrans_ts/commit/1fe397ed7173aacd6376468b2b50ef55e99b69b9

Code Select Expand

if(c == '\e') {
if(decoder.has_next()) {
utf32 c2 = decoder.next();
color = handle_color_sequences(c2, default_color);
}
continue; // nothing to see
}
This code in hajo's branch was removing the letter "e" from all text in my environment.




I submit a patch that I created for extended and modified for standard. I would appreciate it if you would consider implementing a bold font.
(Not tested with standard. It seems that the required libraries are different from extended in order to build. It was possible to build with git actions.)
This is like the first step; for example, in order to make bold text available in the UI, we need to prepare something like a bold option for gu_label_t.
Hajo also did something to make different font sizes available, but that's not included. (I hope to eventually implement it.)
First of all, we need to check whether bold fonts can be used correctly.

I can't attach the patch file, so I post the github link.
https://github.com/Ranran-the-JuicyPork/simutrans/commit/c8b3d1ac87800e1e5f00a59c5c481e03dcb31acf.patch

[prissi]

I think the better way would be to use the bold font of the used TTF font, especially for CJK bold. Simutrans had in ancient times two fonts already. Hence, having a second bold font should be easy, one would just need a second fonts structure and loading it of course.

[Ranran(retired)]

As a result of STFW, I learned that the font can be made thicker with FT_GlyphSlot_Embolden.
I couldn't figure out how to select a different bold font or specify the font weight to generate bold.
What I could have done could have been a different method than either Hajo or Prissi's suggestion.
However, I think it is able to draw bold fonts that are easier to read than Hajo's implementation.




Floating text without a background is easier to see in bold.

The code is for extended. I don't know if this implementation method is correct...
https://github.com/Ranran-the-JuicyPork/simutrans-ex-fix/commit/3189d640f70fb47fe8fddeb955ee950ce1babca2.patch

EDIT:
Also, I noticed while testing that Simutrans has a very poor response to Japanese input.
I don't know when this started. At least the current night reversion is not good.

[prissi]

What is the problem? I could enter Japanese normally in both GDI and SDL2. I noted though that the cursor stayed at the beginning of the conversion string, but I though that is needed due how the conversion is handled.

[Ranran(retired)]

When inputting Japanese with simutrans, that is, unlike the method of directly inputting half-width English characters, in the Japanese input mode, the response is clearly slower than with normal applications.
The difference is obvious when you compare it to typing text into a notepad or browser.
For example, if you quickly input about 10 Japanese characters, the characters will appear with a slight delay. The more quickly you type, the longer the lag will be before the last character entered appears.


EDIT:

This doesn't seem to be limited to Japanese. For example, enter ijijiji 50 times.
I'm stopping input halfway through. Then I move the mouse. However, you can confirm that the ij input is still continuing.
I'm typing "ij" much faster than it appears. But on the other hand, simutrans seems to process input at regular intervals.
This kind of lag can be extremely frustrating in Japanese, where it is necessary to confirm that the characters have been entered before "converting" them into kanji.

[prissi]

Thanks. This may be a side effect of the changes to make touch usable. Whoever had implemented touch decided to use floats and hence any quantum osicllations of a finger spams an event, usually 1000 or more per second. Since Simutrans tried to handle them all, it was not working with touch or tablets. The only way out was to to swallow all events until the movement stopped. The next event is then handled upon the next event loop, usually a frame later.

In my tests, this only occurred with the GDI version, SDL2 run smoothly. Which did you test it on?

I see what can be done about, maybe another hack to prioritize key events.

[Ranran(retired)]

In my tests, this only occurred with the GDI version, SDL2 run smoothly. Which did you test it on?

https://nightly.simutrans.com/en/
I'm testing what I downloaded from here, as well as the self-build version of extended and the GDI version of git actions.