[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: 298

[dennisat]

Csantucci, on 05 November 2017 - 10:13 AM, said:

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

Interesting, I have d3dcompiler_43.dll already present in my copy of Windows 10 (v1709), also a later version, d3dcompiler_47.dll.


I know nothing about HLSL but with Mr Google at hand I've been able to clear all but 2 of the startup warning messages. Monogame doesn't seem to like syntax where it has to assume the intention of the programmer.

The first outstanding message is :

SceneryShader.fx(371,5): warning X4000: use of potentially uninitialized variable (rv)

Looking at the logic this is true. I presume that there can never be a situation where the tested conditions are never satisfied. However, it doesn't look like good programming and perhaps should be fixed. Not really knowing enough about what's going on, I can't suggest a "default".

The second outstanding are:

ParticleEmitterShader.fx(127,15-34): warning X3556: integer modulus may be much slower, try using uints if possible.
ParticleEmitterShader.fx(128,15-34): warning X3556: integer divides may be much slower, try using uints if possible.

I could resolve this but I'm not sure it's worth making the logic more obscure. The performance of the operations depend on the implementation of the relevant instructions on the processor. Any solution may perform worse than the existing code.


Dennis

[Icik]

dennisat, on 05 November 2017 - 11:06 AM, said:

I know nothing about HLSL but with Mr Google at hand I've been able to clear all but 2 of the startup warning messages. Monogame doesn't seem to like syntax where it has to assume the intention of the programmer.

Maybe you can help to resolved the problem with shader of cabs.

[James Ross]

Csantucci, on 05 November 2017 - 10:13 AM, said:

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

Yeah, the main DirectX runtime is just part of the OS now; but if you use the extra bits like the compiler, you must include the appropriate redistributable files from the Windows SDK that you compiled against.

For example, my version of the Windows 10 SDK has the following files in "C:\Program Files (x86)\Windows Kits\10\Redist\D3D\x64":

• d3dcompiler_47.dll
  
• d3dcsx_47.dll
  
• dxcompiler.dll
  
• dxil.dll

You put these files in the same directory as your application. See "Redistribution" here.

[SP 0-6-0]

I've been following this and have some questions? It would appear MonoGame is still in it's early stages and not fully compatible with .XNA? If that is true then would it not be more worth while to bridge from .XNA 3 to .XNA 4? What are the problems with going to .XNA 4? I know .XNA 4 drops support for sprites which I believe gives us the rain effects in ORTS amongst other things.

Not sure if there is anything useful here? According to the .XNA Wikipedia Page
An open source cross platform version of the Microsoft XNA 4 Application programming interface called MonoGame is being developed, and a crossplatform reimplementation of the XNA API called FNA exists as well.

So, Since MonoGame is a reimplementation of .XNA 4 I thought I would post a link to FNA for those interested. FNA

I am hoping a switch to a new platform will bring about some nice improvements to visuals as well as FPS.


Robert

[Csantucci]

I've tried using Git.
I have a stupid problem that I can't solve cleanly. When cloning the OR repository, I get one or two files that are unstaged (one example is file OR_MG_LaunchpadGit\Website\openrails.org\shared\mysql\create_db.sql .


After a search on the web this seems a problem of line endings (CR-LF versus LF only). I could get rid of it only committing such files, therefore creating unwanted commits.