twpol
commented
11 years ago Imported from https://bugs.launchpad.net/or/+bug/1166405/comments/1
| Property | Value |
|---|---|
| Posted by | Edward Keenan (edwardk) |
| Date posted | Mon, 08 Apr 2013 19:06:48 GMT |
Closed twpol closed 11 years ago
twpol
commented
11 years ago | Property | Value |
|---|---|
| Posted by | Edward Keenan (edwardk) |
| Date posted | Mon, 08 Apr 2013 19:06:48 GMT |
twpol
commented
11 years ago | Property | Value |
|---|---|
| Posted by | James Ross (twpol) |
| Date posted | Mon, 08 Apr 2013 20:14:01 GMT |
Have you looked through many locomotives? While I know the font sizing is not perfectly following the MSTS data (for tricky reasons), it shouldn't be that much larger than the space unless the cab control is positioned badly, from what I've seen in testing.
twpol
commented
11 years ago | Property | Value |
|---|---|
| Posted by | Bill Currey (wjcurrey) |
| Date posted | Mon, 08 Apr 2013 21:18:46 GMT |
James, Edward this is screen shoot from 3DTS Tachappi route
[image: Inline image 1]
Below is screen shoot from CabEditor for the cab, notice green height/width box.
Properties: X: 106, Y:284 W:32 H:32 Text Justification: Center [image: Inline image 2]
Here is corrected screen shoot. [image: Inline image 3]
And the correponding CabEdit
Properties: X: 106, Y:292 W:32 H:16 Text Justification: Center
[image: Inline image 4]
By changing the box parameters the font can be adjusted properly. However MSTS seems to correct for this aromatically. I am guessing here but believe MSTS centers on the box height and width to render the text, and along with window size dimensions.
twpol
commented
11 years ago | Property | Value |
|---|---|
| Posted by | James Ross (twpol) |
| Date posted | Mon, 08 Apr 2013 21:39:13 GMT |
It would not surprise me if MSTS only had a fixed set of sizes that it uses, and in the case of the SD75 the box is not quite big enough for the next size up. Or, as you suggest, maybe it only has 1 size. I'm sure I've seen different sizes, though, so I'd need convincing of that.
twpol
commented
11 years ago | Property | Value |
|---|---|
| Posted by | Bill Currey (wjcurrey) |
| Date posted | Mon, 08 Apr 2013 21:42:15 GMT |
Corrections for above post #3
cabEdit_2.jpg Edit (44.0 KiB, image/jpeg; name="cabEdit_2.jpg")
cabEdit_1.jpg Edit (44.0 KiB, image/jpeg; name="cabEdit_1.jpg")
sd75_1.jpg Edit (191.7 KiB, image/jpeg; name="sd75_1.jpg")
sd75_2.jpg Edit (191.2 KiB, image/jpeg; name="sd75_2.jpg")James, Edward this is screen shoot from 3DTS Tachappi route
[image: Inline image 1] --- sd75_1.jpg
Below is screen shoot from CabEditor for the cab, notice green height/width box.
Properties: X: 106, Y:284 W:32 H:32 Text Justification: Center [image: Inline image 2] --- cabEdit_1.jpg
Here is corrected screen shoot. [image: Inline image 3] --- sd75_2.jpg
And the correponding CabEdit ---
Properties: X: 106, Y:292 W:32 H:16 Text Justification: Center
[image: Inline image 4] --- cabEdit_2.jpg
By changing the box parameters the font can be adjusted properly. However MSTS seems to correct for this aromatically. I am guessing here but believe MSTS centers on the box height and width to render the text, and along with window size dimensions.
twpol
commented
11 years ago | Property | Value |
|---|---|
| Posted by | Bill Currey (wjcurrey) |
| Date posted | Mon, 08 Apr 2013 22:47:34 GMT |
On Mon, Apr 8, 2013 at 2:39 PM, James Ross
It would not surprise me if MSTS only had a fixed set of sizes that it uses, and in the case of the SD75 the box is not quite big enough for the next size up. Or, as you suggest, maybe it only has 1 size. I'm sure I've seen different sizes, though, so I'd need convincing of that.
-- You received this bug notification because you are subscribed to Open Rails. Matching subscriptions: BillC https://bugs.launchpad.net/bugs/1166405
Title: Font scale needs adjusting.
==========================================================================
James, ORsmall.jpg is OR with properties reduced to : Properties: X: 106, Y:292 W:32 H:16 Text Justification: Center
MSTSsmall.jpg for MSTS same settings [image: Inline image 2] [image: Inline image 1]
Not quite sure what this means. But suggesting MSTS centers on the height box, and scales the font, from some base size. These shots are from 1280x1024x32 windowed display
twpol
commented
11 years ago | Property | Value |
|---|---|
| Posted by | Bill Currey (wjcurrey) |
| Date posted | Mon, 08 Apr 2013 22:55:18 GMT |
James, ORsmall.jpg is OR with properties reduced to :
Post #6 Properties: X: 106, Y:292 W:32 H:16 Text Justification: Center
SHOULD BE: Properties: X: 106, Y:292 W:32 H:8 Text Justification: Center
MSTSsmall.jpg for MSTS same settings [image: Inline image 2] [image: Inline image 1]
Not quite sure what this means. But suggesting MSTS centers on the height box, and scales the font, from some base size. These shots are from 1280x1024x32 windowed display
twpol
commented
11 years ago | Property | Value |
|---|---|
| Posted by | James Ross (twpol) |
| Date posted | Tue, 09 Apr 2013 08:10:18 GMT |
I'm sure it does center the text vertically but that means it does not expand the font to fill the box (vertically), which is what is currently implemented in OR. Instead, it must have a fixed list of sizes or other factors limiting the text size - which nobody has commented on yet.
If nobody wants to test this out, I'll add it to my list.
twpol
commented
11 years ago | Property | Value |
|---|---|
| Posted by | Edward Keenan (edwardk) |
| Date posted | Tue, 09 Apr 2013 19:06:44 GMT |
James,
How would you like me to help you out in this area?
Edward K.
twpol
commented
11 years ago | Property | Value |
|---|---|
| Posted by | James Ross (twpol) |
| Date posted | Wed, 10 Apr 2013 13:30:37 GMT |
Ideally, we could figure out how MSTS sizes the text completely. I have a few possible ways this could be, each of which can probably be investigated in turn:
Additionally, there is the question of whether the scaling is smooth or stepped; i.e. does it only use some pre-defined font sizes, or will it expand to fill (according to whichever method above is correct) regardless.
twpol
commented
11 years ago | Property | Value |
|---|---|
| Posted by | Edward Keenan (edwardk) |
| Date posted | Wed, 10 Apr 2013 19:43:45 GMT |
James,
Did you know that the default font used by MSTS for the digital cab display is the mono10pto.fnc font. MSTS uses a file called "gui_fonts.dat" to establish the fonts used in the program. If I am wrong, OR is currently guessing on what size font to utilize and trying to figure out the scaling process. If you did not know about the default font used then hopefully this will help.
Edward K.
twpol
commented
11 years ago | Property | Value |
|---|---|
| Posted by | James Ross (twpol) |
| Date posted | Thu, 11 Apr 2013 08:32:31 GMT |
I'm aware of the fonts inside MSTS, though I haven't read the data recently. Are you claiming that MSTS only use exactly that size, never scaling it at all? If so, that would be useful information to contribute (since I asked about it in comment #10). Otherwise, it's not particularly useful knowing which font MSTS uses, as we're not interested in duplicating the exact font, only the size(s) used by MSTS.
twpol
commented
11 years ago | Property | Value |
|---|---|
| Posted by | Edward Keenan (edwardk) |
| Date posted | Thu, 11 Apr 2013 18:52:05 GMT |
James,
Yes, point 10 is the exact size that is used by default. The only exception is if cab developers use a different size, but this does not appear to happen. Scaling is of course still done and I believe it is controlled via a flag in the gui_fnts.dat file. Other then that, there is nothing else.
Edward K.
twpol
commented
11 years ago | Property | Value |
|---|---|
| Posted by | James Ross (twpol) |
| Date posted | Thu, 11 Apr 2013 22:07:05 GMT |
So... that's not all that helpful. It's always 10pt, except when it's not. When it is not? But it's also scaled, but you don't know when/how? I really need the questions I posed in comment #10 answering, as we're not going anywhere here.
twpol
commented
11 years ago | Property | Value |
|---|---|
| Posted by | Bill Currey (wjcurrey) |
| Date posted | Mon, 15 Apr 2013 02:13:02 GMT |
James, Edward may be on the right track (pun intended ;-)
From the file 7segment.zip which can be obtained at trainsim.com see the following below :
QUOTE 7-Segment Cab Font by Joseph Realmuto
I was getting tired of digital displays that all looked like computer screen numbers, and wanted the digital displays in MSTS cabs to look like real 7-segment displays. After some trial and error, I managed to find out which font MSTS uses for the digital cab numbers(mono10pt0.fnc). I decided to use one of the larger fonts(mono13pa0.fnc) to get a clearer display, and I modified the numbers in that font to display as 7-segment style numbers. Since I turned off scaling for this font, it will only display at the correct size in 1024x768 resolution. If you are using another resolution it will be too large or too small. Also, all digital cab numbers will now display as 7-segment. Unfortunately, MSTS only is capable of using one font for this purpose, so this means the digital displays in the Acela and HHP-8 will no longer look like they did before. END QOUTE
Looking at a diff for gui_fnt.dat: gui_fnts_original.dat ----- "IDS_FONT_13" 1 -- has scaling
gui_fnts.dat HACKED -- "IDS_FONT_19" 0 -- no scaling
at end in both versions
num_fonts:
twpol
commented
11 years ago | Property | Value |
|---|---|
| Posted by | James Ross (twpol) |
| Date posted | Mon, 15 Apr 2013 10:22:27 GMT |
I would suggest people do not add further information to this bug unless they directly answer my questions in comment #10. Thanks.
twpol
commented
11 years ago | Property | Value |
|---|---|
| Posted by | Joseph Realmuto (jtr1962) |
| Date posted | Thu, 18 Apr 2013 04:14:32 GMT |
I played around with this a bit. As mentioned previously, MSTS uses the format (X, Y, W, H) to determine how to display a digital cab font. X and Y give the position of the upper right corner of the box. W and H determine the size of the box. In all cases, these numbers are based on a 640x480 resolution regardless of the resolution you run MSTS at. The justification (none, left, right, center) determines where in the box the font is displayed. If justification is "none", the font is displayed as far to the upper right of the box as possible. If justification is left, center, or right, the font is centered in the box vertically. Left justification means the font starts displaying from the left, right justification means it starts displaying from the right, and center justification means the font always remains centered, regardless of the number of digits. There's one caveat to setting the size of the box-it must be wide enough to display whatever number of digits you wish to display or some digits will disappear. The width per digit is the width in pixels of whatever font you're using for the cab display. Height doesn't appear to matter. I've set the height to one and the font still appears. However, the best practice for laying out cab displays is to make the box the same size as the area on the cab view ace file where that particular digital readout will appear. This ensures that no matter what font you use, it will always be centered if you use center justification.
Now let's get to scaling. If the font has no scaling,the size in pixels is the same no matter what resolution you're running MSTS at (i.e. it's a raster font). In other words, a font which looks fine at 640x480 will appear tiny at 1600x1200. Scaling simply makes the font appear the same size relative to the rest of the cabview as it would at 640x480 resolution no matter what resolution you're running at. In all cases, there is only one font size for all digital displays. This is obviously a severe limitation.
OK, that takes care of what is needed for MSTS backwards compatibility. I'm thinking Open Rails should have a means to scale fonts in to different sizes, and to use any font, without breaking backwards compatibility. Perhaps this could be in the form of a line added to each digital display in the .cvf. You would simply need to specify the font (which should be put in either that engine's cab folder or the MSTS GUI folder), and the height and width. The location would be centered over the location where the default MSTS font would have appeared so the readouts appear where they should. MSTS most likely will ignore this line just as it ignores lines specifying Open Rails parameters in the .eng and .wag files.
twpol
commented
11 years ago | Property | Value |
|---|---|
| Posted by | Joseph Realmuto (jtr1962) |
| Date posted | Thu, 18 Apr 2013 04:16:42 GMT |
Correction: X and Y give the position of the upper LEFT corner of the box, not the upper right. Sorry about the mistake.
twpol
commented
11 years ago | Property | Value |
|---|---|
| Posted by | Joseph Realmuto (jtr1962) |
| Date posted | Thu, 18 Apr 2013 04:18:56 GMT |
One more correction: If justification is "none", the font is displayed as far to the upper LEFT of the box as possible.
twpol
commented
11 years ago | Property | Value |
|---|---|
| Posted by | Joseph Realmuto (jtr1962) |
| Date posted | Thu, 18 Apr 2013 07:44:49 GMT |
I just noticed one more thing which Open Rails needs to do for backwards compatiblity. Some digital displays change resolution at a certain number. Suppose you put the following in the .cvf file for a digital display:
Accuracy ( 0 ) AccuracySwitch ( 99.95 )
What MSTS does is display to the first decimal place until the displayed parameter goes over 99.95, then it switches resolution to whole numbers. Note that Accuracy ( 0 ) would normally mean the display reads out in whole numbers, but when you add AccuracySwitch ( x ), it will read out to one more decimal point than specified by Accuracy() until the parameter reaches the value x. In the case above, when the parameter is 0 to 99.9499 it will display as 0.0 to 99.9. 99.95 will display as 100, and any value above 99.95 will be rounded to the nearest whole number.
twpol
commented
11 years ago | Property | Value |
|---|---|
| Posted by | James Ross (twpol) |
| Date posted | Thu, 18 Apr 2013 08:12:51 GMT |
Thanks Joseph, that's really helped. It sounds like using a non-scaling font in an MSTS cab view would be silly, so I presume that it simple always uses the one (of 22) fonts that has scaling enabled, i.e. "monotype 10pt white scaled"? Cab authors have no control over this, right?
I need to extend the font rendering in OR to support precise scaling (currently it jumps to different sizes kind of similar to how a word processor only has certain sizes listed), then we can correctly reproduce the fixed-relative-to-cab font rendering in MSTS. The result will be that instead of being 10pt monotype stretched up to the current resolution as in MSTS, we'll render the text at a size close to the one needed for the current resolution but stretch it a small amount to fit exactly.
twpol
commented
11 years ago | Property | Value |
|---|---|
| Posted by | Joseph Realmuto (jtr1962) |
| Date posted | Thu, 18 Apr 2013 13:27:26 GMT |
James, that's correct-it makes no sense to use a non-scaling font. The only reason I used one was because it ended up the same size as the default MSTS font at the resolution I was using for MSTS at the time. And yes, unfortunately cab authors have no control over which font is used. That's defined in the gui_fnts.dat file, and MSTS can only use one font for each install.
Your plan sounds like it'll work well. Any thoughts on my idea to extend things further to allow the use of multiple fonts and font sizes within a cab? I've been wanting that capability literally since MSTS came out.
twpol
commented
11 years ago | Property | Value |
|---|---|
| Posted by | James Ross (twpol) |
| Date posted | Thu, 18 Apr 2013 14:10:13 GMT |
Using alternative fonts poses some interesting issues (such as, should the fonts be distributed with the cab view and, if so, in what format?) but will ultimately have to be supported in any Open Rails-specific cab system IMO. Sizes are simpler, as it would just be a toggle - "enable scaling text to fit height of box" - and we'd scale to fit the box.
Both are good things to add, but I should note that we're being careful with development not to introduce any changes to MSTS file formats. An OR-specific file is not out of the question, but probably not until after 1.0. We could add options for the fonts used in-game, including for cab controls, though (currently they're all Arial of various sizes IIRC).
twpol
commented
11 years ago | Property | Value |
|---|---|
| Posted by | Jijun Tang (jtang-h) |
| Date posted | Sat, 20 Apr 2013 04:32:39 GMT |
I saw the following two lines in WindowText.cs, line 99:
var font = new Font(fontFamily, sizeInPt, style);
Font = new Font(fontFamily, (int)font.GetHeight(), style, GraphicsUnit.Pixel);If we want a font of height 30, after passing through these two lines, the height was scaled to 60 (doubled), and then the texture map for characters generated has a height of 138, doubled again, result in some cases 4 times the size of required.
twpol
commented
11 years ago | Property | Value |
|---|---|
| Posted by | Jijun Tang (jtang-h) |
| Date posted | Sat, 20 Apr 2013 04:59:50 GMT |
I think the problem is that the CVF file specified both width and height of the digital display. We use the height to determine font scales, which will present problems in the following situation: (the engine has problem can be download from http://www.trainsim.com/vbts/tslib.php?searchid=1203343)
The constructor of windows font looks like this: internal WindowTextFont(string fontFamily, float sizeInPt, FontStyle style, int outlineSize) { var font = new Font(fontFamily, sizeInPt, style); Font = new Font(fontFamily, (int)font.GetHeight(), style, GraphicsUnit.Pixel); Debug.Assert(Font.Height == (int)Math.Ceiling(Font.GetHeight()), "Font.Height is not expected value."); FontHeight = Font.Height; OutlineSize = outlineSize; Characters = new CharacterGroup(Font, OutlineSize); }
If we want sizeInPt to be 50, we will get font height of 68, making it larger.
So there are two sources of errors:
twpol
commented
11 years ago | Property | Value |
|---|---|
| Posted by | Jijun Tang (jtang-h) |
| Date posted | Sat, 20 Apr 2013 05:00:36 GMT |
The attached picture shows the large digital clock.
twpol
commented
11 years ago | Property | Value |
|---|---|
| Posted by | James Ross (twpol) |
| Date posted | Sat, 20 Apr 2013 06:21:16 GMT |
Jijun, we've already established (thanks to Joseph), that neither the height nor width should be involved in the font scaling. I've also already explained that the current font size selection is bound to specific sizes that are larger than requested directly in code. (That is a critical necessity for the other on-screen text to look good.)
twpol
commented
11 years ago | Property | Value |
|---|---|
| Posted by | James Ross (twpol) |
| Date posted | Mon, 29 Apr 2013 21:38:36 GMT |
Right, X.1588 should have a much better version of the cab digital controls. I've fixed the scaling according to the data in this issue and the rotation for superelevation as well. There's likely still some small issues (ACELA's clock is too wide, but I think MSTS cut off one of the digits of that anyway), so do check how it is working.
twpol
commented
11 years ago | Property | Value |
|---|---|
| Posted by | James Ross (twpol) |
| Date posted | Sat, 04 May 2013 22:01:10 GMT |
X.1594 fixes the font size being slightly too large - 12pt instead of 10pt like MSTS.
Imported from https://bugs.launchpad.net/bugs/1166405
Since the font rendering change in V1546, the fonts rendered in the cab look much better, but one area needs a little fix. The screen shot will show this.
Edward K.