[copperpen]

Goku, on 15 October 2017 - 09:47 AM, said:

So you don't understand my question. It was about fps dirrerence between monogame versions.

I am only using the compiled OR versions supplied in this thread. Thus far there has been zero difference in FPS for me. I would not expect to see any changes unless the monogame version used had a major negative impact on OR.

[dennisat]

Goku, on 15 October 2017 - 09:47 AM, said:

So you don't understand my question. It was about fps dirrerence between monogame versions.

Attached are 3 screenshots showing the differences between XNA, Monogame 3.5 and Monogame 3.6 versions of OR at Clapham Junction on the Dorset Coast route. This location is very heavy on resources. I have vsync enabled, anisotropic filtering and antialising. As can be seen from the Monogame 3.5 shot, it does not accept antialiasing. Monogame 3.6 resource usage is slightly worse than XNA except for memory usage but Monogame 3.5 is much better than both. Unfortunately, 3.5 does seem to have some shortcomings as mentioned elsewhere in this thread.

Dennis

XNA


Monogame 3.5


Monogame 3.6

[Csantucci]

I summarize here the state of the art of this operation.
The actual working MG pack for OR is based on an actual development version of MG minus some changes that were lately done to the MG code and that cause bad terrain shadowing.
There are some things that don't work:
1) screenshots: this is mainly due to the fact that MonoGame doesn't implement the XNA function GetBachBufferData; lately MonoGame has this available for the OpenGL releases, but not for the DirecX releases, so it can be hoped that it will be available also for the DirectX ones;
2) pixellation: a significant amount of people sees pixellations when dynamic shadows aren't selected;
3) 2D cab shadowing: this probably could be easily solved by someone experienced in HLSL programming.
Maybe there are other points.

I think it is consolidated that MG uses significantly less memory resources that XNA, which is of course important.
Referring to performance (FPS) instead OR built with the actual MG releases behaves worse than XNA (accordingly to my experience not much worse, but not everyone could agree with that).


There are other issues:
1) D3DCompiler_43.dll and D3DCompiler_47.dll must be present in the computer: this seems obvious, but there are people that didn't have the MG OR version working before installing such dlls
2) There is at least a computer where the MG OR version crashes, and it's the second notebook I have here at home; the crash occurs with no log information; so I'd expect that the same problem could occur also on other computers.

I also tried generating an OpenGL version. I could convert the .dx files, I could generate an OR MG build with OpenGL interface; however at runtime various exceptions are generated because apparently some Windows calls are no more accepted, and I miss the knowledge to find workarounds.

In conclusion: I stop my work here, although I have the intention to follow MG's code development to check if something interesting for OR comes out. I'd be happy if, starting from the last release of the dev pack I generated, that I linked some post above, someone with knowledge in graphics programming would solve the open issues.
However my impression is that, at the moment a switchover to MG were done with OR, there would be some trouble in getting this working well on all the computers where now OR works with no problems.

If there is definite interest in having from time to time a MG version of the actual OR experimental release, maybe I could make that available.

[FrancoisMart]

Hello Carlo and all ! It's my first post here. I ran your last MG version and everything works well excepte erratics dynamic shadows and many errors with "SceneryShader.fx", i find for the first time in log.  OpenRailsLog.txt (109.65K)
Number of downloads: 760. Do you have an idea for these errors ?

[dennisat]

FrancoisMart, on 20 October 2017 - 08:44 AM, said:

Hello Carlo and all ! It's my first post here. I ran your last MG version and everything works well excepte erratics dynamic shadows and many errors with "SceneryShader.fx", i find for the first time in log. OpenRailsLog.txt. Do you have an idea for these errors ?

I know nothing about HLSL but searching the web, these warnings are nearly all about variable format mismatches in equations, eg vector and position. They are not necessarily errors in that they probably nearly all produce the correct result from Monogame's assumptions. Monogame seems to be very fussy about this and warns you that you should be more specific in your equations and provide, where appropriate, what are effectively attribute casts to ensure you get the result you expect.

Dennis

[farrmp]

Carlo,

You are truly a WIZARD and a Gentleman! I am not only talking about MonoGame but EVERYTHING you do. Thank you so much
for taking the time to make all of these contributions available. Now to the MonoGame compile of Open Rails. Even with its limitations
it is for me the New Gold Standard. (I use current XNA builds only for comparison.) On my hardware the MG builds always run about
1.6 times faster than XNA, use about half the memory and just look better graphically. I have attached an OpenRails log file that was made
with the prior MG build, running Marc Nelson's Sherman Hill in downtown Cheyenne where frame rates often fall into the teens. I am seeing 35-38 fps
with very demanding Graphic settings, including Dynamic Shadows, Shadow ALL Shapes and long viewing distances. (Typically- 20 to 30 THOUSAND
Primitives!) On the most demanding routes in just about ALL locations I am NOT seeing frame rates drop below 60 (My Monitor Refresh rate).
I do hope that you or someone will continue to make periodic MonoGame Updates available -- I am not going back!! I do want to thank Peter (gpz)
for pioneering this MonoGame experiment. (You are missed around here, Peter!)

Paul

Attached File(s)

•  OpenRailsLogSherman.txt.zip (3.74K)
  Number of downloads: 397

[dennisat]

Csantucci, on 20 October 2017 - 04:23 AM, said:

If there is definite interest in having from time to time a MG version of the actual OR experimental release, maybe I could make that available.

Carlo,

I would be interested in trying new releases of MG OR if you produce them.
Thanks for putting in all the effort to try this solution.

Dennis

[edwardk]

For anybody who was able to convert from 3.5 to 3.6, did you have to make necessary changes to how png files are loaded? I found out that 3.6 is no longer using the content pipeline so the continued use of this from 3.5 could be a problem.

According to a post I found, the line below which is suppose to be the original XNA method is suppose to be used

"var tex = Texture2D.FromStream(graphicsDevice, stream);"

Edward K.

[SP 0-6-0]

If I remember correctly there is an issue with rain in MG? I know GPZ had mentioned some of the problems he was having with the MG and ORTS but don't remember the specifics now?

Robert

[Csantucci]

edwardk, on 21 October 2017 - 09:34 AM, said:

For anybody who was able to convert from 3.5 to 3.6, did you have to make necessary changes to how png files are loaded? I found out that 3.6 is no longer using the content pipeline so the continued use of this from 3.5 could be a problem.

According to a post I found, the line below which is suppose to be the original XNA method is suppose to be used

"var tex = Texture2D.FromStream(graphicsDevice, stream);"

Edward K.

Edward,
you can see from my patch what was necessary to be changed. I hadn't to make changes to the way of loading png files with respect to 3.5.

[edwardk]

I was able to compile using 3.6, but it appears that I am getting Thread errors. This could be coming from runactivity since the menu comes up fine and the hang takes place after selecting an activity.

Error: Orts.Viewer3D.Processes.ThreadHangException: Thread 'Render Process' has hung; the consistent stack trace is shown below:
at Orts.Common.ORTraceListener.TraceEvent(TraceEventCache eventCache, String source, TraceEventType eventType, Int32 id, String format, Object[] args) in C:\Users\Edward\Documents\ORS Storage\Open Rails-MonoGame\Source\Orts.Simulation\Common\ErrorLogger.cs:line 122
at System.Diagnostics.TraceInternal.TraceEvent(TraceEventType eventType, Int32 id, String format, Object[] args)
at System.Diagnostics.Trace.TraceError(String format, Object[] args)
at Orts.Common.ORTraceListener.WriteLine(Object o) in C:\Users\Edward\Documents\ORS Storage\Open Rails-MonoGame\Source\Orts.Simulation\Common\ErrorLogger.cs:line 205
at System.Diagnostics.TraceInternal.WriteLine(Object value)
at System.Diagnostics.Trace.WriteLine(Object value)
at Orts.Viewer3D.Processes.WatchdogProcess.WatchdogThread() in C:\Users\Edward\Documents\ORS Storage\Open Rails-MonoGame\Source\RunActivity\Viewer3D\Processes\WatchdogProcess.cs:line 133
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()


Warning: Orts.Viewer3D.Processes.ThreadWaitException: Thread 'Updater Process' is waiting; the consistent stack trace is shown below:
at Orts.Common.ORTraceListener.TraceEvent(TraceEventCache eventCache, String source, TraceEventType eventType, Int32 id, String format, Object[] args) in C:\Users\Edward\Documents\ORS Storage\Open Rails-MonoGame\Source\Orts.Simulation\Common\ErrorLogger.cs:line 122
at System.Diagnostics.TraceInternal.TraceEvent(TraceEventType eventType, Int32 id, String format, Object[] args)
at System.Diagnostics.Trace.TraceWarning(String format, Object[] args)
at Orts.Common.ORTraceListener.WriteLine(Object o) in C:\Users\Edward\Documents\ORS Storage\Open Rails-MonoGame\Source\Orts.Simulation\Common\ErrorLogger.cs:line 207
at System.Diagnostics.TraceInternal.WriteLine(Object value)
at System.Diagnostics.Trace.WriteLine(Object value)
at Orts.Viewer3D.Processes.WatchdogProcess.WatchdogThread() in C:\Users\Edward\Documents\ORS Storage\Open Rails-MonoGame\Source\RunActivity\Viewer3D\Processes\WatchdogProcess.cs:line 137
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()

[Csantucci]

Paul and Dennis,
thank you for appreciation and interest. I foresee to provide OR MG updates when there will be some significant new function available in OR or MG.

Edward,
I didn't experience thread hangs. I must say however that usually I comment out the watchdog control to avoid watchdog intervention when I perform line-by-line debugging.
3.6 has another problem, that is it generates crashes at game start in low-performance computers (like mine) allowing only MultiSampling less than 32. So I jumped to subsequent development versions, that have solved this problem.

[Goku]

Quote

3.6 has another problem, that is it generates crashes at game start in low-performance computers (like mine) allowing only MultiSampling less than 32.

What is wrong with MultiSampling less than 32? Maybe this computer doesn't support it?

[Csantucci]

Goku, if a computer does not allow at least 32 as multisampling, MonoGame 3.6 crashes, see here http://community.mon...3-6-0-1625/8819 . This has been fixed few days after 3.6, see here https://github.com/M...oGame/pull/5477 .

[Csantucci]

Here you can download OR release 3976, Monogame version http://www.interazio...e/OR3976_MG.zip .
Apart from having an up-to-date release of OR here, this version solves one of the remaining problems: it provides correct screenshots when pressing the Print key.