[Csantucci]

perpetualKid, on 24 August 2018 - 03:36 AM, said:

As this is not Monogame specific, we may split that into a separate thread?

Yes, you could open a separate thread in the "Maybe it's a bug" subforum.
Re this
http://www.elvastowe...post__p__240204
I'd prefer that, before I commit, you make a test that the fix at least does not harm the official OR XNA version.

[James Ross]

perpetualKid, on 24 August 2018 - 03:36 AM, said:

James, based on that statement I did some more digging. I think the issue comes through AddAutoPrimitive from RenderFrame.cs - actually seems with Dynamic Shadows the materials on shadow map are not grouped but just added in AddShadowPrimitive, whereas other materials are properly grouped in AddPrimitive.
So sorting and grouping the RenderItem collections for shadowmap either while inserting or afterwards should give result how you describe. The alternative approach how I fixed that equally ensures the correct index is used.
Your approach will save the GPU from changing the IndexBuffer (it's only a pointer which buffer to be used since they are already setup before), at the cost of sorting the Materials.

Ah right, the problem is with the shadow map rendering not the main rendering. It should be fixable with a new group for shadow map primitives (using the shared terrain material) so I don't think it's actually a real sorting cost - and although it seems like it's "just" setting a pointer for the index buffer, in practice we've found that many GPU-related things are much more costly than they appear, but I haven't looked at index buffers specifically.

[HansJansen]

Csantucci, on 05 July 2018 - 07:40 AM, said:

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
and here the dev kit
OR_MG_DevKit_x4157.zip

Hello all,

I have been reading this thread during the last few days, and downloaded the above-mentioned package. Just to look how far I could get, I installed it in my Linux system (XUbuntu 18.04) and tried to run OpenRails.exe using Wine. The result is shown in the attachment. Does anybody have an inkling as to why it insists on using libpng.so.12, instead of the current version libpng.so.16?
The programs seems to continue running, but without any visible output. The last two lines appear after I break it with ctrl-C.

Regards,

Hans.

Attached File(s)

•  OR-errors.txt (1.97K)
  Number of downloads: 274

[perpetualKid]

HansJansen, on 03 September 2018 - 12:00 PM, said:

Hello all,

I have been reading this thread during the last few days, and downloaded the above-mentioned package. Just to look how far I could get, I installed it in my Linux system (XUbuntu 18.04) and tried to run OpenRails.exe using Wine. The result is shown in the attachment. Does anybody have an inkling as to why it insists on using libpng.so.12, instead of the current version libpng.so.16?
The programs seems to continue running, but without any visible output. The last two lines appear after I break it with ctrl-C.

Regards,

Hans.

I've no idea of Wine implementation, but the LockWindowUpdate call in second last line is a call to native Win32 function outside of .NET to suspend or resume drawing a window or control, in that case it's the main window of the Menu.exe, and null (nil) parameter means this unlocks the drawing.
My starting point would therefore be such native Win32 calls which may cause issues, the libpng may be negligible at this point.

[HansJansen]

Hi PerpetualKid,

Thanks for your answer. So it seems I have to get in at the deep end...
I'm only just beginning to learn C# etc., and never have done any Windows programming (I come from the Unix world, but have been retired some 15 years now. So it's all a bit rusty anyway).
I will have to study things quite a bit more before I can produce anything significant, I am afraid...

Regards,
Hans

[edwardk]

This post is for Monogame, but the question I have could still apply to the regular version. On my own, I would modify the width box size to 2000 (The default size is 1500) to create a better snowfall area in case the tracks happen to turn to far in one direction. This would naturally require more use of memory, but I would not have problems. Both the regular version using LAA and monogame. Its been a while since I have done this, but I am now experiencing out of memory issues for both the regular version using LAA and monogame. Monogame seems the most sensitive.

This leads to the question, is OR is using more memory now than lets say a year ago? I know the route being loaded is one variable, but I do not recall experiencing out of memory issues this much before. I do not normally shut down background apps, but even doing that, monogame still has issues and the regular version at times. Is the experimental version that is downloaded compiled in release mode or debug mode?

Edit: Just did a quick experiment compiling in release. This did not help the memory issue and there are over 1000 warnings based on proper naming conventions and object creation.



Edward K.

[perpetualKid]

edwardk, on 15 September 2018 - 03:57 PM, said:

This post is for Monogame, but the question I have could still apply to the regular version. On my own, I would modify the width box size to 2000 (The default size is 1500) to create a better snowfall area in case the tracks happen to turn to far in one direction. This would naturally require more use of memory, but I would not have problems. Both the regular version using LAA and monogame. Its been a while since I have done this, but I am now experiencing out of memory issues for both the regular version using LAA and monogame. Monogame seems the most sensitive.

This leads to the question, is OR is using more memory now than lets say a year ago? I know the route being loaded is one variable, but I do not recall experiencing out of memory issues this much before. I do not normally shut down background apps, but even doing that, monogame still has issues and the regular version at times. Is the experimental version that is downloaded compiled in release mode or debug mode?

Edit: Just did a quick experiment compiling in release. This did not help the memory issue and there are over 1000 warnings based on proper naming conventions and object creation.



Edward K.

would be interesting to see if that also happens in the 64bit MG version I've build (mentioned earlier in this thread) which goes beyond 4GB.
How much memory does your setup need?
If you're interested, my code clone is kept (almost) in sync with ORTS repo, but running MG.
I'd be interested seeing your changes, but most likely don't have the same tracks and materials to create the same condition.

[edwardk]

perpetualKid, on 15 September 2018 - 11:08 PM, said:

would be interesting to see if that also happens in the 64bit MG version I've build (mentioned earlier in this thread) which goes beyond 4GB.
How much memory does your setup need?
If you're interested, my code clone is kept (almost) in sync with ORTS repo, but running MG.
I'd be interested seeing your changes, but most likely don't have the same tracks and materials to create the same condition.

Will your code compile and run on Windows 7?

[perpetualKid]

edwardk, on 16 September 2018 - 05:36 AM, said:

Will your code compile and run on Windows 7?

working with Edward offline on that, we'll report back on findings.


on a side note, Monogame community has released version 3.7 http://community.mon...7-release/10971,
so expect the ORTS MG clones will move forward also.

[HansJansen]

perpetualKid, on 24 September 2018 - 10:26 PM, said:

...
on a side note, Monogame community has released version 3.7 http://community.mon...7-release/10971,
so expect the ORTS MG clones will move forward also.

Hi perpetualKid,
I have tried to run your latest ORTS-MG with MG3.7 on my Linux system, but without much success, alas.
The binary package starts running with Wine, up to the point of pressing the Start button; then it vanishes without a trace (:(). If I start it with the mono command (I have installed the latest MonoDevelopment, including the MonoGame V3,7), it comes up with a small window stating it needs .NET Framework 3.5 SP1 and XNA Framework 3.1, and shuts off when I hit the OK button.

So I downloaded the source package from GitHub and tried to compile it. Needless to say I got a number of errors and warnings. Concentrating on the (8) Error messages, I found the following solution for three of them:

- In Contrib/ActivityEditor/ActivityEditor/ActivityEditor.csproj, changed line

<Compile Include="ActionProperties\ControlStartProperties.designer.cs">

into

<Compile Include="ActionProperties\ControlStartProperties.Designer.cs">

- In Menu.csproj, changed line

<Compile Include="ImportExportSaveForm.designer.cs">

into

<Compile Include="ImportExportSaveForm.Designer.cs">

– Renamed file Orts.Formats.Msts/ACEFile.cs to Orts.Formats.Msts/AceFile.cs

So three occurrences of the case-sensitive nature of Linux, as opposed to Windows.
Maybe you can put these changes into your sources?

After that, when built individually, the following 5 projects produce this error:

The command “echo $Revision: 000 $>Revision.txt
	date /t>>Revision.txt
	time /t>>Revision.txt exited with code 127. (MSB3073)

– ContentChecker
– Launcher
– Menu
– RunActivity
– TrackViewer

(“Build All” results in the same error for only Launcher, Menu and RunActivity.)

I have no idea how to tackle these errors. Could you point me to possible cause(s)?
It would be nice to at least finish the building of the solution (not to mention running the result!)
I am quite willing to delve further into that problem, should you wish me to do so.

Regards,
P.S. please also check my next message!