[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.

[dennisat]

Csantucci, on 03 November 2017 - 02:07 PM, said:

Here you can download OR release 3976, Monogame version

Thank you for your continued work on this Carlo.
Could you also supply your latest "Dev Kit" as well. I have many personal updates to OR and like to test the Monogame versions with my updates applied also.

Dennis

[Csantucci]

Here is the kit
http://www.interazio...DevKit_Rev4.zip .

[dennisat]

Csantucci, on 04 November 2017 - 01:46 AM, said:

Here is the kit
http://www.interazio...DevKit_Rev4.zip .

Thank you.

Dennis

[Csantucci]

After various trials I was able to solve also the other open problem, that is the 2D cabview that didn't darken at night.
Simply unzip and replace this file within the Content subfolder of your OR_Monogame folder.
 CabShader.zip (1.41K)
Number of downloads: 475

Same file must also replace the original one within the DevKit, in folder Source\Runactivity\Content.

So I don't have other open problems that I am able to reproduce, because I'm not able to reproduce pixellation (if this problem remains to someone).

[Goku]

I have stupid idea how to "solve" pixellation. If it appears only if dynamic shadows are disabled, then maybe just always render dynamic shadows, but empty scene if dynamic shadows disabled? xD

[Hamza97]

Yes, i have also experienced the same, with dynamic shadows disabled (which i usually keep disabled) their were pixelation effects on screen. enabling dynamic shadows got rid of pixelation. Also, in my case the resolution of screen remained at something like 1156x542 instead of my native 1366x768..... :unknw:

[Icik]

Csantucci, on 04 November 2017 - 02:12 PM, said:

After various trials I was able to solve also the other open problem, that is the 2D cabview that didn't darken at night.
Simply unzip and replace this file within the Content subfolder of your OR_Monogame folder.
CabShader.zip

Same file must also replace the original one within the DevKit, in folder Source\Runactivity\Content.

So I don't have other open problems that I am able to reproduce, because I'm not able to reproduce pixellation (if this problem remains to someone).

Hello Carlo,I have just copied but nothing happened. Cab is still without change. Pls check that.

[Csantucci]

You're right, I don't know what I saw yesterday... :sign_oops:

[James Ross]

Goku, on 27 September 2017 - 09:11 AM, said:

But .. how DirectX works?
If I use 32 bit TSRE, OpenGL still wokrs in 64 bit on 64 bit machines, so textures send to OpenGL are not counting towards 2GB limit.

The Windows 2000 Display Driver Model (XDDM) (in 2000 and XP) provide a fairly direct interface to the GPU memory; if you run out of GPU memory, or there's a device reset (e.g. resolution change), you're on your own.

DirectX 9 provides an optional feature called "managed" resources (see the D3DPOOL_MANAGED option), which XNA takes advantage of, which keeps an extra copy of GPU resources in-process (i.e. inside the OR process). This allows it to handle device resets and other conditions without reloading any content. Note that this is not the default behaviour.

The Windows Display Driver Model (WDDM) (in Vista and later) takes a different approach, providing system-wide virtualisation and paging resources in and out of GPU memory dynamically.

DirectX 10+ therefore, does not need to have its own copy of GPU resources in-process to have the same level of functionality.

Hence, I'd expect upgrading from DirectX 9 to 10+ to significantly reduce the system RAM used by Open Rails.

Csantucci, on 03 October 2017 - 05:50 AM, said:

Following this http://www.elvastowe...post__p__198081 I checked out with SVN gpz's MonoGame OR solution and built it with AnyCPU set. In fact I got no errors and OR does work, so that the 4 GB limit seems to be overcome with MonoGame, and Peter (gpz) really did a remarkable job. Now my question to an expert of versioning: Peter's modified version of OR is related to the OR version x.3503. How can I easily update it to the actual version x.3936 (maintaining Monogame specific changes) without manually checking file-by-file what must be modified and what not?

I guess you've figured out by now, but as long as gpz forked the git repo at https://code.launchp...wpol/or/+git/or you can simply bring in the changes with a merge or rebase. I'd really like to keep the MonoGame work in git so that we correctly credit people (like gpz) and maintain the history of how the changes came to be. If you have not kept the changes since gpz's version that would be a shame, and it might be troublesome to merge your work together depending on how you've updated to the latest code. Git does this properly, but Subversion will not.

Genma Saotome, on 03 October 2017 - 10:34 AM, said:

Q: Seeing as Peter did do a monogame conversion -- and it works -- why didn't it become the go-forward release?

There were still a number of problems (e.g. screenshots not working), and it didn't work on Windows XP IIRC. This is a big migration and we'll take it slowly and carefully. :)

Csantucci, on 04 October 2017 - 12:57 PM, said:

Starting from Peter Gulyas work I was able to generate a MonoGame version of the actual release x.3956 of OR.

Woo!

Csantucci, on 04 October 2017 - 12:57 PM, said:

I found out that, in order to run, d3dcompiler_43.dll must be present in windows\System32. My Win10 release hadn't it and I had to copy it from my Win7 release.

This is definitely the wrong thing to do; install the correct version of DirectX (I'll have to look up the exact defaults but MonoGame ought to tell you what redistributable installer to use).

Csantucci, on 05 October 2017 - 06:09 AM, said:

To ease developers' operations I attach here an OR Monogame developer's kit, that includes a patch file and the Monogame libraries.

Would be good to know where this stuff came from.

Csantucci, on 05 October 2017 - 06:09 AM, said:

I hope that this transient phase will last few time and that it will be decided that OR Monogame becomes the official OR version.
Patches to correct the few small remaining issues are welcome (in fact the main aim the developer's kit is that one), because in general I won't work on that: I've done the sherpa work, but I'm not able to introduce improvements.

I am not inclined to allow this to be committed to Subversion, but rather wait for the Git migration, because it will be very important to review all the code changes made for it (and to keep attribution, etc.).

[Csantucci]

James Ross, on 05 November 2017 - 09:35 AM, said:

I guess you've figured out by now, but as long as gpz forked the git repo at https://code.launchp...wpol/or/+git/or you can simply bring in the changes with a merge or rebase. I'd really like to keep the MonoGame work in git so that we correctly credit people (like gpz) and maintain the history of how the changes came to be. If you have not kept the changes since gpz's version that would be a shame, and it might be troublesome to merge your work together depending on how you've updated to the latest code. Git does this properly, but Subversion will not.

Yes, I figured it out.
My work has started from gpz work. I'll see if I'm able to return everything under Git.

James Ross, on 05 November 2017 - 09:35 AM, said:

This is definitely the wrong thing to do; install the correct version of DirectX (I'll have to look up the exact defaults but MonoGame ought to tell you what redistributable installer to use).

There is the non-negligeable problem that Microsoft no more makes available the latest DirectX versions for download, as far as I could see.

James Ross, on 05 November 2017 - 09:35 AM, said:

Would be good to know where this stuff came from.

I had to revert the changes that commit bd22d49 (Compressed texture fallback formats (#6003)), dated 12/10/17, introduced in Monogame.
Such commit causes parts of terrain being rendered in black.
I'm sure it's possible to change something in OR so as to get it working also with such commit, but it's not within my capabilities.
Here is the patch of my personal reverse commit
 Nuovonoombrenerepatch.zip (2.45K)
Number of downloads: 371