[Csantucci]

Gerry,
I should have been more precise.
First of all, the first two lines of your logfile excerpt (the ones starting with ParticleEmitterShader.fx()) have nothing to do with the subsequent ones (the ones starting with Warning: System.InvalidOperationException:).
The first two lines are indeed MG OR specific, and log a harmless issue. You should live with that.
The subsequent ones are common with the standard OR version, and log an execution excepton warning (not a crash as I erroneously said) concerning counters used in the Debug HUD. This exception occurs sometimes to someone both in the standard and in the MG OR versions. It is a longtime existing and unresolved problem, which also seems quite harmless.

[EricF]

jtr1962, on 13 June 2018 - 10:06 AM, said:

Just wondering if perhaps a registry setting, as opposed to adding a menu item, would be easier to code for now.

I'm also wondering how much the graphics engine for OR has been optimized. I know we added instancing, which helps considerably. There might be other tweaks, although obviously I realize this would be a major undertaking (and maybe pointless as fewer and fewer people will have low-spec graphics cards as time goes by).

With respect to coding the graphics settings and multisampling issues for AMD drivers, I wonder if it might be safer/more prudent to leave the issue alone. Multisampling is a great at limiting performance hits on lower-power GPUs, but it can only do so much with lower-resolution images -- which is what we have a lot of while we're still running content created for MSTS. To remove jaggies from MSTS graphics may require cranking multisampling up to fairly high levels, at which point the performance hit increases -- which leads to diminishing returns.

Supersampling on the other hand is essentially just rendering the graphics at a higher resolution than the screen and then scaling the result back down. (It can be made more precise than that, but most implementations seem to tend toward the brute-force approach) This tends to do better at reducing jagged edges from low-res objects, but at a higher overall performance cost. But it may be simpler to create a render-at 200% / 300% / 400% scale-up setting and let the GPU handle it, rather than try to cater to various graphics driver implementations of multisampling (or spending time tweaking the builti-in multisampling in Monogame.) This would still require decoupling OR's output resolution from the Windows desktop resolution, however, wouldn't it?

[R H Steele]

Csantucci, on 15 June 2018 - 11:01 PM, said:

Gerry,
I should have been more precise.
First of all, the first two lines of your logfile excerpt (the ones starting with ParticleEmitterShader.fx()) have nothing to do with the subsequent ones (the ones starting with Warning: System.InvalidOperationException:).
The first two lines are indeed MG OR specific, and log a harmless issue. You should live with that.
The subsequent ones are common with the standard OR version, and log an execution excepton warning (not a crash as I erroneously said) concerning counters used in the Debug HUD. This exception occurs sometimes to someone both in the standard and in the MG OR versions. It is a longtime existing and unresolved problem, which also seems quite harmless.

Thank you Carlo, I now see I should have read the log warning more closely, indeed there are two separate issues, the shaders in the first two line --- I can live with that -- and the performance counters issue. I never have had a performance counter warning ( although I have read threads about these warnings) until I started using the Monogame version. Now I have the warning in both the testing and monogame versions.
I was concerned that it was a problem affecting the OS, as long as it is something that is limited to the Debug HUD, I can also live with that.

[perpetualKid]

new to the forum and MSTS/OR scene, apologize if appearing ignorant.


I took the liberty building on top of Carlos MG patch, updating the code to use MonoGame 3.6, and upgrade all solution projects to compile AnyCPU and run true 64bit enabling more than 4GB of memory:




This also shows in the details i.e. 8 GB upper limit as per machine hardware, instead of only 4GB previously (and all of the screenshots I've found in the forum):




Minor annoyance though, memory use does not seem to be displayed correctly but only shows 0, not sure why?

For MonoGame 3.6 there were only few little changes needed.
To get true x64-compatibility, some code related to OpenAL needed to be fixed (mostly WAVE file definitions), but else seems to work.

I'm struggling a bit getting familiar with the SVN code repository and patch files being posted here, so I shared my code on GitHub, for the time being I'll try to keep the repository in sync.
If someone is interested to test, there's a precompiled Binary version release.

To run on clean Win10 x64, there are two prerequisites:
- The MonoGame Pipeline Compiler has a dependency on d3dcompiler_43.dll. While one could simply copy that file from somewhere else to the Program folder, the clean solution would be to install the latest DirectX Runtime (however that's a 95MB download)
- Also, OpenAL needs 64bit Wrapper, which comes as part of the OpenAL Installer

Aside, over last few days I did also run some performance profiling and noticed couple code sections which could easily be improved to lower system load. The "low hanging fruits" would not help much on the threads topic (overall memory usage), but certainly help on lower end systems. Is there an existing/common effort for such which I could align with (code refactoring/performance optimization)?

[Csantucci]

Hi perpetualKid,
nice that you are operating with the code.
Take into account that the MG version I'm using is more recent than 3.6 (It's an intermediate version).

[jtr1962]

perpetualKid, on 21 June 2018 - 04:23 AM, said:

Minor annoyance though, memory use does not seem to be displayed correctly but only shows 0, not sure why?

Same thing for me. Another issue is that the text in the HUD appears blurry, as if overaliased. I also needed to install the latest DirectX runtime to get your MG version to work at all, even though Carlo's MG versions work fine without it.

Quote

Aside, over last few days I did also run some performance profiling and noticed couple code sections which could easily be improved to lower system load. The "low hanging fruits" would not help much on the threads topic (overall memory usage), but certainly help on lower end systems. Is there an existing/common effort for such which I could align with (code refactoring/performance optimization)?

I mentioned something similar earlier about optimizing the graphics engine for OR but unfortunately I don't have the programming knowledge to do so.

[jtr1962]

jtr1962, on 21 June 2018 - 02:07 PM, said:

Another issue is that the text in the HUD appears blurry, as if overaliased.

I think I figured out why. For some reason the resolution in your version is stuck at 1280x1024 regardless of the settings. I have the resolution set for 1600x1200, which is the resolution of my monitor. When the monitor changes its resolution to 1280x1024, the end result is that text looks lousy.

[James Ross]

jtr1962, on 13 June 2018 - 10:06 AM, said:

I'm also wondering how much the graphics engine for OR has been optimized. I know we added instancing, which helps considerably. There might be other tweaks, although obviously I realize this would be a major undertaking (and maybe pointless as fewer and fewer people will have low-spec graphics cards as time goes by).

A few people, including myself, spent lots of time on optimising the graphics engine and other code back in... 2010 through 2013. There's probably a load of things that have regressed since then, and a load of new opportunities, as I've not had much time to look at the performance in detail.

perpetualKid, on 21 June 2018 - 04:23 AM, said:

Aside, over last few days I did also run some performance profiling and noticed couple code sections which could easily be improved to lower system load. The "low hanging fruits" would not help much on the threads topic (overall memory usage), but certainly help on lower end systems. Is there an existing/common effort for such which I could align with (code refactoring/performance optimization)?

I don't believe there's any current work going on for performance or code refactoring (although I've done both extensively in the past).

If you'd like to contribute here, I'd recommend starting a new thread and highlighting the code that you've found, any profiling data you think is useful (e.g. screenshot of the profiler's call tree), and details of any changes you've already tried and their effects.

I'd be happy to accept patches where:

• Code is demonstrated or known to be performance sensitive (render and updater code is pretty much guaranteed to be, loader less so but still worth it for large improvements)
  
• Code is getting to the same result in a more optimised way
  
• Code is still readable to an average C# developer, with comments to help if the algorithm is complex (using C#'s "unsafe" keyword is not okay, for example)

And to clarify: performance improvements will be accepted for all of the following things:

• CPU time spent executing
  
• Memory allocation rate (i.e. amount of new allocations per frame or per second)
  
• Memory allocation size (i.e. amount used overall while running)

[edwardk]

I am slowly trying to play catch up. I did notice that as of the latest update from Carlo, many of the updates from steamer_ctn are not present.

Edward K.

[Csantucci]

With the end activity evaluation a major feature has been added to OR. Therefore I've decided to generate the corresponding OR MG version. It includes also a patch by dennisat which removes the obstacles that didn't allow to use the TrackViewer within the OR MG pack.
Here the runtime kit
 OR4157_MG.zip (9.1MB)
Number of downloads: 2418
and here the dev kit
 OR_MG_DevKit_x4157.zip (7.72MB)
Number of downloads: 515