[FrancoisMart]

 Csantucci, on 20 November 2017 - 12:53 PM, said:

Thank you, I asked because latest MG-based OR versions run slower than standard OR versions in my slow computer.

An other good thing i found with MG is the very low "stress" of video stream, when disk access for big quantity of textures and shapes are loading during the game.

[dennisat]

The CabShader Problem

I think I've tracked down the reason for this not working in Monogame. However, I need a graphics programming expert to confirm my diagnosis.

In MSTSLocomotive.Viewer, the changes made included replacing groups of:

Shader.Begin();
Shader.CurrentTechnique.Passes[0].Begin();

in here somewhere was a Spritebatch.Draw statement.

Shader.CurrentTechnique.Passes[0].End();
Shader.End();

with a single statement:

Shader.CurrentTechnique.Passes[0].Apply();

followed somewhere by the Spritebatch.Draw statement.

This was because the previous groups of Shader statements were not valid in Monogame.

The Shader statements activate the function of Cabshader.fx which should dim the scene at night. However, my research seems to indicate that in XNA the Shader statements would act on Sprites but in Monogame they won't. The replacement function in Monogame is by way of a "Spritebatch.Begin", eg:

Spritebatch.Begin(effect: Cabshader)
Spritebatch.Draw
Spritebatch.End()

I've tried this and it causes problems because, I think, of the multithreading nature of OR. I keep getting failures due to "Begin has failed because a previous End has not been issued" or vice versa "End has failed because a previous Begin has not been issued".
Incidentally, I've tried just putting the Spritebatch draw in front of the Shader Apply - it didn't work but my research let me to suspect it wouldn't.

Having no further ideas on how to proceed, I think it's time for a graphics expert to look at the issue.

Dennis

[Icik]

 Csantucci, on 20 November 2017 - 01:33 PM, said:

That's interesting. What lets you affirm this?

I do not know what it is for AA. On my GTX 1080Ti runs AA in MG 3.6 automatically. In the drivers I have everything to default.

[FrancoisMart]

 dennisat, on 21 November 2017 - 07:17 AM, said:

The CabShader Problem

I think I've tracked down the reason for this not working in Monogame. However, I need a graphics programming expert to confirm my diagnosis.

In MSTSLocomotive.Viewer, the changes made included replacing groups of:

Shader.Begin();
Shader.CurrentTechnique.Passes[0].Begin();

in here somewhere was a Spritebatch.Draw statement.

Shader.CurrentTechnique.Passes[0].End();
Shader.End();

with a single statement:

Shader.CurrentTechnique.Passes[0].Apply();

followed somewhere by the Spritebatch.Draw statement.

This was because the previous groups of Shader statements were not valid in Monogame.

The Shader statements activate the function of Cabshader.fx which should dim the scene at night. However, my research seems to indicate that in XNA the Shader statements would act on Sprites but in Monogame they won't. The replacement function in Monogame is by way of a "Spritebatch.Begin", eg:

Spritebatch.Begin(effect: Cabshader)
Spritebatch.Draw
Spritebatch.End()

I've tried this and it causes problems because, I think, of the multithreading nature of OR. I keep getting failures due to "Begin has failed because a previous End has not been issued" or vice versa "End has failed because a previous Begin has not been issued".
Incidentally, I've tried just putting the Spritebatch draw in front of the Shader Apply - it didn't work but my research let me to suspect it wouldn't.

Having no further ideas on how to proceed, I think it's time for a graphics expert to look at the issue.

Dennis

Hello Dennis,

Do you mean that you can't see the night mode in a 2D cabview ? For me it works as usual...

[Csantucci]

No, the meaning is that the day cablight doesn't get darkened after sunset, before switch to night cabview.

[dennisat]

 FrancoisMart, on 21 November 2017 - 09:48 AM, said:

Hello Dennis,

Do you mean that you can't see the night mode in a 2D cabview ? For me it works as usual...

If there's a night texture, you get night mode correctly. If there's no night texture, the day texture is used and the CabShader should dim it at night. This doesn't work with Monogame but does with XNA.

Dennis

[Csantucci]

Hi Dennis,
reading here http://www.gamefroms...priteBatch.aspx it seems that there is a unique begin and a unique end and the spritebatch.Draw calls in between. I don't know if this is possible in OR.
By searching for SpriteBatch.Begin and .End, I saw that they are already used extensively in OR.
By the way spritebatch calls are also used for the windows superimposed to the main Runactivity window.

[dennisat]

 Csantucci, on 21 November 2017 - 10:32 AM, said:

Hi Dennis,
reading here http://www.gamefroms...priteBatch.aspx it seems that there is a unique begin and a unique end and the spritebatch.Draw calls in between. I don't know if this is possible in OR.
By searching for SpriteBatch.Begin and .End, I saw that they are already used extensively in OR.
By the way spritebatch calls are also used for the windows superimposed to the main Runactivity window.

Yes, I've tried this but run into the problem that the first of the inserted Begins fails with "no previous successful End". I then put an End in front of the Begin I just inserted and it fails with "no previous successful Begin"! Hmm.... I think this is because of the multi threading in OR. I don't understand a lot of the graphic programming in OR but it seems that the majority of Sprite Draws are batched between one Begin and one End and thus don't have the serialisation problem. This presumably also saves a lot of processing. It creates another problem in that if the Begin Draw End did work, the options being used need to be saved at the End and restored at the Begin. The Shader option is only needed for the Cab rendering. The superimposed Windows don't have this problem because they are completely self contained and have separate Spritebatch options.....? I think! I've never written any graphic programs so I'm inferring most of this from Google searches and tutorials. Which is why I hope one of our OR experts can come up with a solution.

Dennis

[Csantucci]

I've looked a bit at the code. It does not seem a problem of multithreading. Rather, it seems to me that the Spritebatch.Draw calls of the cabview are executed after Spritebatch.Begin and before Spritebatch.End within the SetState and ResetState methods within materials.cs.
The problem is that such begins and ends don't refer to the specific shader effect for the cab2Ds.

[dennisat]

 Csantucci, on 21 November 2017 - 01:15 PM, said:

I've looked a bit at the code. It does not seem a problem of multithreading. Rather, it seems to me that the Spritebatch.Draw calls of the cabview are executed after Spritebatch.Begin and before Spritebatch.End within the SetState and ResetState methods within materials.cs.
The problem is that such begins and ends don't refer to the specific shader effect for the cab2Ds.

I've examined that and decided that putting the Shader effect in at these points would activate it for all SpriteDraws which may not be a good thing.

Dennis