[cjakeman]

copperpen, on 06 March 2024 - 08:13 AM, said:

I have been doing some testing on this "pulsing" phenomenon using the old PRR East Region V2. I have the following observations which indicates that somewhere after the release of the base 1.5.1 version a code change took place which introduced this "pulsing". As Rogue has stated 1.5.1 does not have it. The latest Testing version does as does ORMG. I will test further versions over the weekend to track down where the change took place.

Thanks for this.

Rogue suggests that it isn't in every Testing version. But it would still be very useful to find out the cause, so we can understand it and then guard against it.

[hroch]

Gentlemen
Take a good look at Rogue's log file. The official version runs automatically 64-bit in 64-bit Windows.
Rogue has only 32bit version set in ORMG.

[Csantucci]

Boris,
you should test ORNYMG using the same option setup you are using for the official releases, therefore:
- you should disable the option to run at 32 bit on 64-bit systems, because official releases always run at 64 bit (as hroch has pointed out)
- you should enable the Reduce Memory option, which is enabled by default on official releases.

[Rogue]

Hi everyone,

I just created a test-path so that every aspect for an examination should be identical.
All the settings should be the same now and I altered the options as Carlo suggested on the MG-Version.
Alas the MG-Version is still pumping and the regular Version is running smoothly.

I attached both Log-Files.
As I said: in both rides, the same Train/Consist starts at the exact same location.

Boris

Attached File(s)

•  OpenRailsLog_MG.txt (12.98K)
  Number of downloads: 21
•  OpenRailsLog_regular Vers.txt (15.17K)
  Number of downloads: 24

[engmod]

>PerformanceTunerTarget = (user set) 70

I don't believe this setting is wise with such a low power cpu.

[Rogue]

>PerformanceTunerTarget = (user set) 70

Where can I alter this setting?
I couldn't find anything in the options which has the value '70'

[copperpen]

Found in Options on the system tab at the bottom

Attached thumbnail(s)

• 

[copperpen]

I have tested random versions all the way back to the start of the U series of updates, about the middle of 2019 and every one has shown evidence of this " pulsing " of the video. I then looked at file creation dates and picked two testing versions as close to either side of the dates of version 1.5.1 as possible. That gave me U2022.11.24.0835 and U2022.11.28,1936. Both of these when tested showed the "pulse" of the video, but slap in the middle of those two is version 1.5.1 which runs smoothly.

So I sat and scratched my head and pondered the problem and realised that the only common denominator in all of the tests I ran was the activity. It was an activity with a number of loose consists in the area which was also a high density scenery area. I retested the same location in Explore mode and there were no more video pulses. It would seem then that there is something different in version 1.5.1 that allows high density activities to run smoothly on high density routes

[copperpen]

Upon further thought and testing with a different route and activity I consider this problem to be route and activity specific, nothing to do with OR itself. I draw this conclusion after comparing Loader data with two different routes. The PRR East Region gives an average of 273,750,295 bytes over three different versions and showed the video pulsing in any version of OR except 1.5.1 The MidEast plus route gave me a loader value of 460,155,170 which is close to double that of the PRR East route and runs as smooth as most other routes, zero video pulsing.

[Rogue]

Just the information that all my test were done in Explorer-Mode.
Furthermore I had the observation, that the FPS-Rate does not drop while the pulsing occurs.