[P Escue]

This may be a known problem. I’ve been running the unstable and the NewYear MG of Open Rail and decided to turn on the MSTS environments in the Experimental feature tab. When I got into a route with Season set to Summer and Weather Set to Clear, I noticed that the sky out the windows of the locomotive didn’t look quite right. I turned the camera so that it was pointing to the zenith and did a screen capture (see photo).

 monogame-msts-envirsm.jpg (291.25K)
Number of downloads: 7

I tested this in both MonoGame versions of OR and compared it with the current release and it appears only in the two MonoGame versions that I tested. My system configuration is:

IOS = E16P1IMS.102 (American Megatrends Inc.)
Processor = Intel® Core™ i7-7700HQ CPU @ 2.80GHz (8 threads, 4 cores, 2.8 GHz) (L1 Cache 256 KB) (L2 Cache 1024 KB) (L3 Cache 6144 KB)
Memory = 15.9 GB
Video = NVIDIA GeForce GTX 1070 (4.0 GB RAM) (nvlddmkm 26.21.14.4120)
Video = Intel® HD Graphics 630 (1.0 GB RAM) (igdkmd64 26.20.100.7584)
Display = \\.\DISPLAY4 (1920 x 1080, 32-bit, primary, 0 x 0)
Sound = NVIDIA High Definition Audio (nvhda64v 1.3.38.21)
Sound = Realtek High Definition Audio (rtkvhd64 6.0.1.8328)
Disk = C: (Local Fixed Disk, NTFS, 464.3 GB, 116.7 GB free)
Disk = D: (Local Fixed Disk, NTFS, 465.8 GB, 115.5 GB free)
OS = Microsoft Windows 10 Pro 64-bit (10.0.18363)
Runtimes = 2.0.50727 SP2 3.0 SP2 3.5 SP1 4 Client 4 Full 4.0 Client
Runtime = 4.0.30319.42000 (32bit)
--------------------------------------------------------------------------------

Tested and the problem exhibited in the following releases and older on the unstable release:
Version = U2020.01.13-0851
Build = 2020.01.13.0851 (2000-01-14 00:28:22Z)
Version = NewYear MG (unofficial)-U2020.01.05-0906 Rev. 48.6.
Build = 0.0.7312.40654 (2020-01-08 22:35:08Z)

The MSTS environments was turned on and working in the following release and older for the official release of OR:
Version = 1.3.1.4328
Build = 1.3.1.4328 (2000-01-02 02:24:16Z)

I made sure that all versions of OR was using the NVIDIA GeForce GTX 1070 card and not the Intel.

I know that using the Experimental feature tab items is at your own risk, but if it works in the official version, it should work in the MonoGame versions as well. Also, this could be a symptom to other problems in the MonoGame versions as well. Which is the reason I’m reporting it. If you need more information from me, please let me know what you would like.

Another problem I noticed on the both MonoGame versions that on full screen, the Windows Taskbar stays visual and during the route load you don’t see the load bar and during the route you lose the bottom of the screen where the Taskbar is.

I hope this is helpful,

Phil

[Csantucci]

Yeah, you are right, when I did the big porting to MG I didn't dedicate the necessary attention to the MSTS sky environments. With OR NewYear MG Rev. 49.2 they should have now the same look as in the testing version. If this is confirmed, the same change will be introduced in the unstable version.

Re the second point unfortunately I'm not an expert in windows management.

[P Escue]

I downloaded 49.2 OR NewYear MG and it does fix the MSTS environment problem.

On the taskbar showing, I've not looked at your code (plus I'm not a C# or graphic programmer), but looking at some of the MonoGame forums, it appears that if the Windows Size that is selected in the game is equal to the native screen width and height for full screen then graphics.IsFullScreen = true; needs to be set to get the taskbar to not show. Again, you may be already doing this and I apologize for trying to second guess you.

Let me say that I think you all are doing a great job of coding and I don't mean to appear to criticize. I'm looking forward to when the MonoGame conversion gets moved into production.

Phil

[Csantucci]

Hi,
are you able to provide the link for that thread in the Monogame forum?

In the meantime I have inserted the fix also in the Monogame PR to the official OR, so that it should be included in few minutes in the Unstable version.

[P Escue]

Hello Csantucci,

It looks like I should have waited a day to post. I usually try to keep the betas (or I should say the alphas) up to date for testing.

Again, I'm not a graphic programmer but doing some searches on the full screen in MonoGame, it looked to me that several things need to happen. One, get the screen resolution that the user has set. Two get the native screen resolution. Then compare, and if equal set to full screen. Since I don't know MonoGame it may be you only need to do a few steps. Look at the last link and at lozzajp response.

Here were some of the links that I found:

This first one was the first I came across with two problems, the taskbar showing and performance,
full screen in Monogame
The StackOverflow shows two ways for fullscreen,
stackoverflow full screen MonoGame
StackExchange has about how to detect display resolution,
Detect display resolution
And another one of getting the game to fit the full screen,
Make game window fill full screen


I will try to see if I can find a few more tomorrow. We got some snow yesterday and I've got to dig out so I can get somethings in town.

I hope the above will be helpful,

Phil

[Csantucci]

Thank you for the research done, there's useful info inside. Sun here.

[Csantucci]

I've uploaded Rev. 49.3, which solves the taskbar problem, at least here.

[P Escue]

Hello Csantucci,

I tried it and I’m still getting the taskbar on launch of a route and when the route is fully loaded, if I do nothing but let it load. However there is some difference in behavior from 49.2 compared to 49.3. First, let me briefly state the behavior for each version. In the stable release (the one people normally download), when you launch the route, you get the route opening screen in full screen, with a load bar at the bottom that I would say is about 2 or 3 mm. You also get a very small part of the title bar of the window at the top (maybe 2 mm). This is true for either with Fast full-screen alt-tab checked or not. If you use your mouse cursor to move the title bar it will make the title bar full with losing the bottom of screen (no load bar, but also no task bar). If you don’t do this you pretty much get a full screen (with only the small amount of the title bar showing, as I said maybe 2 mm or less). In the unstable release and version 49.2 of newyear you got again the small amount of the title bar at the top, but you didn’t see the load bar because it was being hidden by Windows task bar at the bottom.

Now what is different in 49.3, (this is for me) when the Fast full-screen alt-tab is not checked behavior is like before (task bar visible at the bottom, no load bar). When the Fast full-screen alt-tab is checked, you get the small part of the title bar visible and you get the load bar visible, however you can also see the desktop (about 2 to 3 mm) on the left hand side of the OR window and you can see about 3mm of the task bar at the bottom. The right hand side and the top of the windows appear to be in the correct location on the screen (at the right side of the screen, no space and at the top with no space). If I use my mouse cursor to move the title bar, I can get it to spring to a full screen with a full title bar (option for minimized the window, full screen (greyed out) and close windows on the right and the OR logo on left), and the load bar it at the bottom (no task bar visible). It acting like the point of the window for OR is off on the left and bottom at launch. I am running Windows 10, is that the OS you are using? Also, can you get a few more people to test this and see what they get? And, is there any more information I can give you that would help with diagnosing the problem that I'm seeing? If you need screen shots, let me know. With it working somewhat with 49.3 (for me) in Fast full-screen alt-tab (with a little help with moving the title bar) its almost there. I'm not sure why the window is not going to full screen at launch, when I can manually do it.

Phil

[MMax]

It seems to me that you are trying to use not fullscreen, but to just maximize Open Rails in windowed mode. If you set a resolution that is as big as your screen, it will then end up behind the taskbar, just like any other program window that is too big to fit the desktop.
Have you unchecked "Windowed" in the main menu? This may be the problem here – or I have totally misunderstood what you were aiming to do.

Greetings

Edit: Have you tried clicking on the loading screen? Sometimes the taskbar was like that for me to, but clicking on the loading screen / OR "Window" hid it.

[Csantucci]

Hi Phil,
some statements and questions:
1) I don't get the taskbar when launching OR, when I have the Windowed checkbox unchecked, neither with Fast full-screen alt-tab enabled nor in the opposite case
2) I am testing with an OR window size smaller than the screen size, that is 1366x768 vs. 1600x900
3) I am having OR using the full screen at startup, bothj with Fast full-screen alt-tab enabled and in the opposite case
4) switching at game time from windowed mode to full screen causes OR to occupy the full screen, both with Fast full-screen alt-tab enabled and in the opposite case
5) What the stable release of OR actually does is not necessarily the only acceptable solution
6) What resolution has your screen, and what resolution have your set as window size?
7) Pictures including info about the parameters used can help focussing the issue.

[P Escue]

Hello Csantucci,

Sorry, it took a while to edit the screenshots to make them smaller (in size and storage).

On my display resolution, the monitor is 1920x1080 native. The Window size in OR (all versions) is set to 1920x1080.

The first screenshot is what the MonoGame both the unstable release and the newyear (before 49.3) release were doing regardless if the Fast full-screen alt-tab was checked or not.

 or-mgus2smb.jpg (116.87K)
Number of downloads: 3

In the above the taskbar is active.

Now, with newyear 49.3 there is a great improvement in that the taskbar is now mostly hidden and what part is visible is not active (where before you could click on any of the items on the taskbar it would make that the active windows with OR behind it).
This screenshot is with Fast full-screen alt-tab off (unchecked).

 or-mg49-3uc3smb.jpg (220.33K)
Number of downloads: 3

As can be seen, the width is correct, but the height is a little short at the bottom.

Next, is the screenshot with Fast full-screen alt-tab on (checked).

 or-mg49-3c3smb.jpg (221.79K)
Number of downloads: 2

Here the width is off on the left by a very small amount and height is off by a very small amount at the bottom. Also, the title bar more of it is visible.

Using a smaller screen resolution only gives me a smaller window for OR with the size-dependent on the window size selected or inputted.

 or-smscreen49-3sm.jpg (49.91K)
Number of downloads: 1

One interesting thing is that if you drag the OR Window with your cursor (any of the three above) in 49.3 to much, it will disappear and the OR launch menu window reappears after a few seconds.

With 49.3 as I said before, this is a great improvement on the full-screen size. I’m pretty sure that MonoGame can handle the higher screen resolutions. If you don’t see fast solutions for what I’ve found, I would recommend that you see what happens with it with other people testing it at different window screen sizes and their results, before you spend a lot more time on this. If this is what is decided, I will be happy to continue researching it and will post anything new.

Phil

[perpetualKid]

P Escue, on 19 January 2020 - 06:54 PM, said:

Hello Csantucci,

Sorry, it took a while to edit the screenshots to make them smaller (in size and storage).

On my display resolution, the monitor is 1920x1080 native. The Window size in OR (all versions) is set to 1920x1080.

The first screenshot is what the MonoGame both the unstable release and the newyear (before 49.3) release were doing regardless if the Fast full-screen alt-tab was checked or not.

or-mgus2smb.jpg

In the above the taskbar is active.

Now, with newyear 49.3 there is a great improvement in that the taskbar is now mostly hidden and what part is visible is not active (where before you could click on any of the items on the taskbar it would make that the active windows with OR behind it).
This screenshot is with Fast full-screen alt-tab off (unchecked).

or-mg49-3uc3smb.jpg

As can be seen, the width is correct, but the height is a little short at the bottom.

Next, is the screenshot with Fast full-screen alt-tab on (checked).

or-mg49-3c3smb.jpg

Here the width is off on the left by a very small amount and height is off by a very small amount at the bottom. Also, the title bar more of it is visible.

Using a smaller screen resolution only gives me a smaller window for OR with the size-dependent on the window size selected or inputted.

or-smscreen49-3sm.jpg

One interesting thing is that if you drag the OR Window with your cursor (any of the three above) in 49.3 to much, it will disappear and the OR launch menu window reappears after a few seconds.

With 49.3 as I said before, this is a great improvement on the full-screen size. I’m pretty sure that MonoGame can handle the higher screen resolutions. If you don’t see fast solutions for what I’ve found, I would recommend that you see what happens with it with other people testing it at different window screen sizes and their results, before you spend a lot more time on this. If this is what is decided, I will be happy to continue researching it and will post anything new.

Phil

I wonder if you want to try my "Ultimate" version which does a few things differently in that area. You can download a base verion from here https://github.com/p...g/144-d77821976, and use the updater as described to get the latest version.
If this improves things for you, this gives us and Carlo some ideas what needs to be changed.

[Csantucci]

Hi Phil,
thank you for your reporting. I suspect that all your screenshots are made with the "Windowed" checkbox checked in the main menu, and therefore they are made in windowed mode, with a window wide as the screen. If you want to run full screen, you should uncheck that box. I'd like also to remind that you can switch at runtime between full screen and windowed mode by pressing Alt-Enter.
Here is what I get during game loading with a 1600 x 900 screen, 1600 x 900 window definition, windowed checkbox unchecked and Fast full-screen Alt-tab unchecked:
 Nofast.jpg (214.3K)
Number of downloads: 1
And here is what I get in the same conditions, but Fast full-screen Alt-tab checked:
 Fast.jpg (214.29K)
Number of downloads: 1
As you see, it's a real, centered full screen in both cases.

All in all, IMHO it's not so important that, when runnung in windowed mode (which I suppose is the mode you had when taking your screenshots), a window big as the screen is not perfectly centered (which seems to be the problem you are reporting). BTW also the testing version of OR is not vertically centered when running with a window of the dimensions of the screen. However if I have time I'll see if something can be done.

P.S.: I have studied and checked a bit more and I think that the actual solution is not bad. When in windowed mode (Windowed checkbox checked) the OR window is centered within the working area of the screen (which does not include the taskbar). This is correct, and in this way a window that is high as the screen height minus the taskbar heignt does not cover the taskbar. However, if the window height is higher than that (e.g. is high as the screen), it partly extends above the screen and partly extends over the taskbar (as it does in the non-Monogame version). Should an exception be made in this particular case, and the window should be centered at the center of the screen, fully covering the taskbar? Another solution would be not to accept window sizes greater than the working area of the screen. However, in both cases, there would be changes that are not present in the testing version either.

[P Escue]

Yes, you are correct, I do have the Windowed checked in the main menu. But in my defense, I have it checked in the standard release of OR which was what I was judging the unstable and newyear by. I still think that the Windowed checked in the unstable and newyear should if the Window size is the same as display size, that it should go the full screen as it does in the standard release. I'm not sure why its not in MonoGame and will continue to look into it. As I said before the fix that was done 49.3 is a vast improvement where you now have the taskbar hidden.

I will be happy to try the "Ultimate" version and I will continue to try to break things and let you know about it. Like I said, I'm really looking forward to when you get the MonoGame version out. With 64 bit (and yes all my testing on newyear has been with the 64 bit version) and from what I've seen of what some people have done with Monogame in 3D, it should be a pretty good step in the graphics from the XNA. The “Be the Astronaut” exhibit with the Mars rover game is very impressive.

Phil

[Csantucci]

Hi Phil,
if we are talking about aesthetic aspects, may I say that I don't like the way the standard OR handles the screen layout when a window size equal to the screen size is selected, and the windowed checkbox is checked? On top of the window you see only half of the window bar, which is not nice either. And looking at other programs, when they run in window mode the taskbar is seen.
Moreover the only difference that I see now is that in one case there is that left vertical bar not covered by the window. Also in the testing version there is a small part of the taskbar that can be seen when you run in windowed mode with the window having the same definition as the screen.
So, I'm not sure that how the standard OR handles the screen layout in this case is the best solution, neither am I sure what the best solution could be. Therefore at the moment I have the intention to leave things as they are, waiting that the situation clarifies. Things might be changed, but a shared objective must be defined.