[elvasleis]

Hi,
I saw this method of reducing the size of Digital numbers in the Cabview.
At the bottom of this web page below is how to reduce the size of the numbers.

http://railtm.com/forum/6-380-2#11194

Yes it is in Russian but Google translate is my friend.

The change in the code is to change 480 to 1000.

public class CabViewDigitalRenderer : CabViewControlRenderer
{
const float FontScale = 10f / 480;


public class CabViewDigitalRenderer : CabViewControlRenderer
{
const float FontScale = 10f / 1000;

I think for me the result is how I like the number size.

I am still to try if I can make the numbers just a little larger.

Regards Geoff.

[gpz]

By a programmer's view, changing value 480 is dumb, since that number comes from the reference screen resolution 640x480. You might have said you see the digits in cabview nicer if you change the font size from 10 to 5, and the variable declaration would look like this:

const float FontScale = 5f / 480;

I admit the divider should go directly to the equation FontScale variable is used, and a better name for this variable would be FontSize instead. And the font sizes are really too big in cabview, even in default locomotives.

[Csantucci]

I agree with Peter. I made tests on May 2013 and suggested in this forum to reduce default from size from 10 to 9.5 and to pass from Regular to Bold font style, as the best compromise I could find to approach what MSTS does.

Apparently elvasleis needs much smaller characters than those even MSTS allows. In fact having the possibility to define different fonts for different cabviews would be a welcome feature.

[elvasleis]

Hi Peter,
Since I am a complete novice as far as being able to change the code in Open Rails I am pleased to have done it and have achieved the result I wanted.
I had to install Visual C# 2008 Express and follow the translated instructions from the railtm.com forum.
I have no understanding of the parameters or rules of the code.

I had thought that this was just to hard for me to do.

Your reply gives me some understanding of the changes I made.
I will try the change that you have said.

const float FontScale = 5f / 480;

Thanks and Regards Geoff.

[markus_GE]

Csantucci, on 17 April 2014 - 10:59 PM, said:

I agree with Peter. I made tests on May 2013 and suggested in this forum to reduce default from size from 10 to 9.5 and to pass from Regular to Bold font style, as the best compromise I could find to approach what MSTS does.

Apparently elvasleis needs much smaller characters than those even MSTS allows. In fact having the possibility to define different fonts for different cabviews would be a welcome feature.

I know, I know, someone will now say, we have too many options already ;)

What about making the font.size user-adjustable, as a temporary solution? (-> Experimental Tab) I too feel, fonts are way too big, especially with some of the high resolution, wide angle photo.realistic cabs I use...

Cheers, Markus

[Maximus]

Up to version 1587 the font size of the entry in the cvf was determined.
So everyone had the opportunity itself easily change the font size.
Unfortunately,it was then changed to the fixed size.

Maximus

[roeter]

This is the definition of any 'digital' item in the cabview (e.g. clock, speed etc.) :

Position ( 175 345 45 16 )

The first two values are the position of the field, the last two are the size (width and height).
As far as I can tell, these last values are now not used in OR - for a particual cabview, I changed 'height' from 16 to 8 - and nothing changed.
So could not either of these last two values be used as font scale values?
That's much better than an overall cabview fontsize, as fontsizes may differ per cabview or even may be different for items within a single cabview.

The only problem to work out is what present setting should relate to which font-size - and, not unlikely, presently these values might differ greatly between cabviews which actually require the same fontsize. That would make life a little more difficult.

Regards,
Rob Roeterdink

[R H Steele]

roeter, on 18 April 2014 - 04:24 AM, said:

That would make life a little more difficult.
Regards,
Rob Roeterdink

"I long ago come to the conclusion that all life is 6 to 5 against." Damon Runyon (in Collier's 8 September, 1934 'A Nice Price') :wacko:

[ATW]

ORTS back then in 0.7.0 had a font option I really liked and think an option should be made as an option and be back.

https://scontent-a-sjc.xx.fbcdn.net/hphotos-ash2/t31.0-8/473259_250144611759837_2014470133_o.jpg

[James Ross]

roeter, on 18 April 2014 - 04:24 AM, said:

The first two values are the position of the field, the last two are the size (width and height).
As far as I can tell, these last values are now not used in OR - for a particual cabview, I changed 'height' from 16 to 8 - and nothing changed.
So could not either of these last two values be used as font scale values?

The values for height in particular are completely bogus on many stock and 3rd party locomotives - we did this before and it did not work very well.

[James Ross]

markus_GE, on 18 April 2014 - 02:34 AM, said:

I know, I know, someone will now say, we have too many options already :cool3:

What about making the font.size user-adjustable, as a temporary solution? (-> Experimental Tab) I too feel, fonts are way too big, especially with some of the high resolution, wide angle photo.realistic cabs I use...

If any options are useful, it would be one in the cab view file itself (and specific to that cab control). Alas, the height information in there is too unreliable to be useful but we might be able to add a custom option.

[ATW]

Any chance that bogus unreliable option back as an option placed in cvf file?

[James Ross]

ATW, on 19 April 2014 - 12:59 PM, said:

Any chance that bogus unreliable option back as an option placed in cvf file?

That's what the custom option would do; either by specifying that "you can trust the height of this control to set the font size" or by actually specifying a font size (relative to the MSTS default font).

[Sid P.]

James Ross, on 19 April 2014 - 01:22 PM, said:

That's what the custom option would do; either by specifying that "you can trust the height of this control to set the font size" or by actually specifying a font size (relative to the MSTS default font)....
Alas, the height information in there is too unreliable to be useful but we might be able to add a custom option.

Some thoughts on this (sorry if it is long-winded) ---
The code in ORTS that produces the digital lettering is fine- it does a great job of looking after the color, decimal point display, etc. The font size problem arises from the use of a single font size for all cabviews. This choice may have resulted (see James quote above) from the wide variation in the parameters of digital display boxes in the cabview (.cvf) files, in particular the values used in the .cvf file to define the size of the digital box.

In MSTS, as was observed earlier, the values of "Width" and "Height" in the .cvf file are ignored by MSTS. (That may explain the wide range of values found.) Instead, the font size of digital displays is modified by changing an entry in the "gui_fnts.dat" file; unfortunately this changes the digital fonts in all locomotive cabview digital displays, regardless of their cab layout details.

In ORTS, the method "CabViewDigitalRenderer(...)" in MSTSLocomotiveViewer.cs uses the values of the width and height of the box in the .cvf file to set up the DrawPosition parameters to draw the digital digits, using normalizing values ( apparently of a 640x480 display). But it choses the font size based on a constant "FontScale" which is, I assume, a best-guess to cover the wide range of values found in the .cvf files.
However, this produces some sub-optimum fits for some locomotive displays, as reported above.

I suggest that ORTS should use the "Height" of each digital box to set the font size for that box, and that the values in the .cvf file be adjusted to make the display acceptable. This has the following advantages:
1. The adjustments for a particular cab require only text editing of the .cvf file, with the result immediately visible by restarting ORTS; (The MSTS Cab Editor is NOT required, except optionally to see what the boxes look like). I would be happy to write some notes on editing the files.
2. These changes in the .cvf file do not have any effect on the MSTS display;
3. The resulting font size is appropriate for the particular cab;
4. It produces an appropriate font size for varying sizes of digital boxes in a single cabview (I notice that the clock and speedometer displays are typically significantly different from the displays of brake line pressures, for instance.)
5. IMHO, it works quite well and looks good.

The disadvantage ?
1. Some .cvf files would have to be modified to get an acceptable display.
2. Some users are not comfortable editing simulator support files.

If this is seen as a serious problem, an additional option (!!!) to retain the current calculation of font size could be added for those who prefer not to modify any files; i.e "Calculate Cab View Digital Font Sizes YES/NO".

My suggested changes to the code to calculate the font size:
"FontScale" would no longer be a const in the CabViewDigitalRenderer class, but would be replaced by a float value within the method CabViewDigitalRenderer(...) so that it is calculated for each digital box. The value would be simply based on the value of 'Control.Height', with a minimum value to guarantee visibility, e.g.

float fScale = Math.Max(8f, (float)Control.Height;

The line:

DrawFont = Viewer.WindowManager.TextManager.Get("Courier New", Viewer.CabHeightPixels * FontScale, System.Drawing.FontStyle.Regular);

would then become:

DrawFont = Viewer.WindowManager.TextManager.Get("Courier New", fScale, System.Drawing.FontStyle.Regular);

(Note that this gets rid of a multiplication by 'Viewer.CabHeightPixels'.)
Edit: I used the raw value of Control.Height because that worked for the first couple of .cvf that I tried.

Cheers,
Sid.

[markus_GE]

Long story short, we were missing one keyword in the previous discussion: Option!

I think, it´s a good idea. My two cents, FWIW :sign_sorry:

Cheers, Markus