[Csantucci]

I did a test by passing to 64 bit an older release of OR NewYear MG, that is release 22 dating May 21st, 2019. The shaking is still there. So it is an issue which does not come from recent times.

[edwardk]

Csantucci, on 04 November 2019 - 01:07 AM, said:

I did a test by passing to 64 bit an older release of OR NewYear MG, that is release 22 dating May 21st, 2019. The shaking is still there. So it is an issue which does not come from recent times.

When you mentioned in your previous post about math precision, were you serious? My research into converting 32bit to 64bit showed that there can be a math precision issue since many of the variables use float which is single precision. Double is preferred for 64bit and since this is a train simulator, precision is important. The question here is how to determine the problem area?

[Csantucci]

Of course I was serious. In the meantime I had some other test, using a diesel railcar that shows a significant shaking of the bogies with respect to the body, even at low speed (which is as always absent when running at 32 bit). The shaking is there also if there is only the railcar in the consist. So it is not a problem of forces between traincars. I don't know with which order the position of the various car parts is calculated: is first the car body position calculated (with method ComputePosition) and then the position of the bogies? Anyhow the problem seems to reside in one of these calculations IMHO.

[perpetualKid]

edwardk, on 04 November 2019 - 03:03 PM, said:

When you mentioned in your previous post about math precision, were you serious? My research into converting 32bit to 64bit showed that there can be a math precision issue since many of the variables use float which is single precision. Double is preferred for 64bit and since this is a train simulator, precision is important. The question here is how to determine the problem area?

with the abstraction of .NET framework, precision for a given numeric data type should be same regardless of the platform and does not change. Although deep down to the hardware, there may be some differences in implementation. As far I understand on x64, SSE is preferred for float operations while in 32bit mode, regular FPU registers are used), which may lead to different result in calculations which I assume sum up over time. This may lead to differences comparable to the limited precision precision of the float data type, in effect causing issues like the one we see here, purely speculation at this point in time.

Other than that, it may also be caused in some of the abstraction layers (Monogame, SharpDX) in interop calls. But I'd assume in that case to find some reports in the respective communities from other users, which I can't seem to find any indication.
Monogame is all based on float (single precision) and that should be sufficient for rendering, but we may have some intermediary math which should leverage double better and only downcase for rendering. Unless we're able to pin down the exact variables in question causing the issue (and if thats the root cause, there may be any more similar issue not yet identified), it's hard to tell.

[Csantucci]

Rel. 38 of OR NewYear MG is available as always here http://www.interazio..._NewYear_MG.zip .
It is aligned with unstable rel. U2019.10.26-0321 of the official OR, which does include Monogame. To see what the official unstable release includes, check here https://james-ross.c...&utm_medium=app

The list of additional features to such unstable release present in OR NewYear MG is as follows:

- addition of track sounds in the sound debug window (by dennisat)
- F5 HUD scrolling by mbm_OR (with improvement requested by steamer_ctn)
- checkbox in General Options tab to enable or disable watchdog
- increase of remote horn sound volume level
- when car is selected through the F9 window, the car's brake line in the extended brake HUD is highlighted in yellow, see here http://www.elvastowe...post__p__248023 (by mbm_or)
- improved distance management in roadcar camera
- signal script parser (by perpetualKid): reduces CPU time needed for signal management
- true 64-bit management, allowing to use more than 4 GB of memory, if available, in Win64 systems (by perpetualKid, with some small tailoring by myself)
- general options checkbox for optional run at 32 bit on Win64 (to avoid slight train shaking bug)
- NEW: reverted bug fix about rain in 3DCab, to avoid lack of display of digital indicators (see http://www.elvastowe...post__p__252352 )
- NEW: added trace log for precipitation crash (see http://www.elvastowe...n-monogame-v36/ )

So, when running on Win64, if the player privileges having more than 4GB of memory available, he will let the option box unchecked (which is default); if instead he prefers to avoid unneeded train shaking, he will check the box and will have only a maximum of 4GB memory available. In this second case RunActivity32.exe is run. Note that this hopefully is only a temporary solution.
Note that Runactivity32.exe is not generated by building the pack, but manually doing a copy of Runactivity.exe, renaming it Runactivity32.exe, and using on the Developer Command Prompt command corflags with the modifier -32BITPREF+

OpenRails64.exe is available in the pack, which has to be pointed by ReShade when running at 64 bits to have it working.


It is suggested to unpack the .zip using 7zip, if other unpackers lead to problems.

Release 37 can still be downloaded from here http://interazioni-e...G_oldrecent.zip .

November 6th, 2019, 11:14 CET: uploaded release with different precipitation bug trace message

[edwardk]

perpetualKid, on 04 November 2019 - 11:36 PM, said:

with the abstraction of .NET framework, precision for a given numeric data type should be same regardless of the platform and does not change. Although deep down to the hardware, there may be some differences in implementation. As far I understand on x64, SSE is preferred for float operations while in 32bit mode, regular FPU registers are used), which may lead to different result in calculations which I assume sum up over time. This may lead to differences comparable to the limited precision precision of the float data type, in effect causing issues like the one we see here, purely speculation at this point in time.

Other than that, it may also be caused in some of the abstraction layers (Monogame, SharpDX) in interop calls. But I'd assume in that case to find some reports in the respective communities from other users, which I can't seem to find any indication.
Monogame is all based on float (single precision) and that should be sufficient for rendering, but we may have some intermediary math which should leverage double better and only downcase for rendering. Unless we're able to pin down the exact variables in question causing the issue (and if thats the root cause, there may be any more similar issue not yet identified), it's hard to tell.

There was another post that was indicating a problem with a route, tile height and precipitation. When we go from no problems to all of a sudden having problems then something is different. Considering that float variables are widely used, you would think that we should not have any issues with them and for the most part that is probably the case. The question is the code that is in place and how its being used and how to trouble shoot this issue.

[Csantucci]

Icik, on 24 October 2019 - 10:31 AM, said:

Hi Carlo,
in the current version of OR NewYear MG is a problem in the train model shake. You can see it in the video. It does this all the time, even if I turn off (Ctrl + V) to 0. The unstable version does not do this.

https://youtu.be/PNbpsgZ7yoc

Hi Icik,
I wasn't able up to now to find a train that shakes also at zero speed, like the one you have shown in the video. As it is easier to investigate what is occurring when the train is at zero speed, can you provide a link to download that train?

[Csantucci]

November 6th, 2019, 11:14 CET: uploaded release with different precipitation bug trace message : people having downloaded rev. 38 before that time are kindly requested to re-download.

[andybest69]

Hi Carlo,
Since release 36 I've not been able to use my raildriver, it won't start, I just get the 3 lines in display. It was fine for release 35.
 OpenRailsLog.txt (14.88K)
Number of downloads: 2

[Icik]

Csantucci, on 06 November 2019 - 12:27 AM, said:

Hi Icik,
I wasn't able up to now to find a train that shakes also at zero speed, like the one you have shown in the video. As it is easier to investigate what is occurring when the train is at zero speed, can you provide a link to download that train?

Hi Carlo,

can be downloaded from here...

https://ulozto.cz/fi...=cd-841-016-rar