[YoRyan]

 Csantucci, on 25 November 2020 - 01:13 AM, said:

I draw your attention also to another bug, which is present not only in the Unstable MG, but also in OR NewYear MG and that I wasn't able to solve.
If you start the game in windowed mode, then switch to full screen with Alt-Enter, the vertical pointing position of the mouse is no more correct. It points about 10-20 pixels under the displayed position.
If you instead start the game in full screen, the mouse points correctly. If you however switch to windowed mode, and back to full screen, the bug appears.

I personally cannot reproduce this on my system. Is it possible that James has already fixed it? In the Monogame PR, he lists 'Windowed -> full-screen window with "Fast full-screen alt-tab" is in the wrong position and the wrong size' as one of the bugs he fixed.

[ordp]

public void Draw(DrawArea drawArea)
{
UpdateCamera(drawArea);

//device.SamplerStates[0].AddressU = TextureAddressMode.Wrap;
//device.SamplerStates[0].AddressV = TextureAddressMode.Wrap;

foreach (string textureName in vertexBuffers.Keys)
{
basicEffect.Texture = textureManag......

[ckawahara]

 ordp, on 28 December 2020 - 08:05 PM, said:

public void Draw(DrawArea drawArea)
{
UpdateCamera(drawArea);

//device.SamplerStates[0].AddressU = TextureAddressMode.Wrap;
//device.SamplerStates[0].AddressV = TextureAddressMode.Wrap;

foreach (string textureName in vertexBuffers.Keys)
{
basicEffect.Texture = textureManag......

Suggest that you attach the OpenRail log file to aid in tracking down the error.

[YoRyan]

A better fix would be to preserve the sampler state change, but to do so in a way that doesn't crash Monogame. ;)

Still waiting on James to vet the fix...

[ordp]

public void Draw(DrawArea drawArea)
{
UpdateCamera(drawArea);

device.SamplerStates[0] = SamplerState.LinearWrap;
//device.SamplerStates[0].AddressU = TextureAddressMode.Wrap;
//device.SamplerStates[0].AddressV = TextureAddressMode.Wrap;

foreach (string textureName in vertexBuffers.Keys)
{
basicEffect.Texture = textureManager[textureName].Texture;
foreach (EffectPass pass in basicEffect.CurrentTechnique.Passes)
{
device.SetVertexBuffer(vertexBuffers[textu.....

[James Ross]

 eugenR, on 19 October 2020 - 11:00 AM, said:

With the Trackviewer in unstable Release Open Rails U2020.10.16-2036 2020-10-16 21-43-15 and newer
I can't start any Route in Trackviewer. Independant if I start it over OR-Menu or direct in the OR_Folder
I get the attached Error.
Trackviewer.jpg

This should be fixed in the next Unstable Version.

 YoRyan, on 24 November 2020 - 12:30 PM, said:

Thanks for the reports, everyone. I have submitted a patch to James to fix this crash.

Merged, thanks!

 YoRyan, on 28 December 2020 - 08:55 PM, said:

Still waiting on James to vet the fix...

Sorry about the delay, things should start moving again now. :)

 ordp, on 28 December 2020 - 10:23 PM, said:

public void Draw(DrawArea drawArea)
{
UpdateCamera(drawArea);

device.SamplerStates[0] = SamplerState.LinearWrap;
//device.SamplerStates[0].AddressU = TextureAddressMode.Wrap;
//device.SamplerStates[0].AddressV = TextureAddressMode.Wrap;

foreach (string textureName in vertexBuffers.Keys)
{
basicEffect.Texture = textureManager[textureName].Texture;
foreach (EffectPass pass in basicEffect.CurrentTechnique.Passes)
{
device.SetVertexBuffer(vertexBuffers[textu.....

Thanks for this code, I have used it instead of the earlier version, because it is simpler and neater.

[James Ross]

 dennisat, on 21 October 2020 - 03:29 AM, said:

It appears the Monogame base that has been used is missing many of the fixes and enhancements that are in the OR New Year version.

Yes, it was a deliberate choice to start again with fewer of the changes because we got stuck reviewing the code the first time due to too many unexplained and unrelated code changes.

We're not re-creating the fixes that have already been done, though, just making sure we only include the ones that are necessary for the migration and nothing more.

 Csantucci, on 25 November 2020 - 01:13 AM, said:

I draw your attention also to another bug, which is present not only in the Unstable MG, but also in OR NewYear MG and that I wasn't able to solve.
If you start the game in windowed mode, then switch to full screen with Alt-Enter, the vertical pointing position of the mouse is no more correct. It points about 10-20 pixels under the displayed position.
If you instead start the game in full screen, the mouse points correctly. If you however switch to windowed mode, and back to full screen, the bug appears.

Like Ryan, I am also not able to reproduce this problem. I've tried various things when interacting with windows/tabs/buttons and they all seemed to line up.

Do you have a specific example of this misalignment that you have experienced, or a straightforward way to show when the mouse is not aligned?

[Csantucci]

James,
1) select in the video options a window size smaller than your monitor resolution (I am selecting 1366x768 and I have a 1600x900 monitor);
2) start OR with the Windowed checkbox checked; when loading will be complete, OR will be paused at startup as usual;
3) press Alt-Enter to pass to full screen;
4) try clicking on the "Continue playing (escape) field; at least in my case, nothing occurs; I have to click on the lower part of "Save Your game (F2)" to exit Pause mode.

The behaviour is absolutely steady.

I have the "Fast full screen/alt-tab" option unchecked.

I have just tested with U2021.01.17-1521.

Using the testing version x.1.3.1-285 this does not occur.

[YoRyan]

No such luck, Carlo. I've followed your steps and matched your settings and my mouse clicks still line up perfectly.

Edit: Hang on, turns out I was using the testing version. I have tested on James's branch and the unstable branch and I am seeing this issue on both.

Do you have any unusual display configurations, like multiple monitors? What's your hardware? I have an Nvidia GPU on my dev machine but I could also test on my laptop with Intel graphics.

[YoRyan]

Ok, so I'm only seeing this bug when "Fast full-screen alt-tab" is unchecked and I'm running Monogame.

What's the purpose of this setting? Would there be any harm in removing it and keeping it permanently set? That might be easier than trying to track down the behavioral change in Monogame.