Monogame ExhaustColor is broken RGB input is displayed as BGR!
#1
Posted 28 December 2018 - 08:25 PM
For reference please use this site:
https://html-color-codes.info/
Inside the engine file, under the ORTSDieselEngines section you can find an entry called:
ExhaustColor ()
The values that are used are poorly documented in the Open Rails manual, but lore and urban legend describe it as follows:
ExhaustColor (aa RR GG BB) where:
aa is the unused alpha channel value
RR is the red value, 00-FF
GG is the green value 00-FF
BB is the green value 00-FF
AFAIK, the dieselsmoke.ace MUST have color information for ExhaustColor () to work. In my case that is so.
In all versions of OpenRails using XNA that support ExhaustColor (), including today X4331 2018-12-26 17:58:14,
the displayed color conforms to HTML standards, aaRRGGBB.
After a lot of work, it was discovered that the values displayed ExhaustColor () in Monogame are not what they are in XNA. The culprit is that although the user can enter ExhaustColor (aaRRGGBB), what is actually displayed is ExhaustColor (aaBBGGRR)! I can only guess as to where the error lies, but the read in values at runtime are in reverse order.
As an example:
ExhaustColor ( 00F7FE2E ) yellow, is displayed in Monogame as ExhaustColor ( 002EFEF7 ) cyan....oops!?
I would assume that ExhaustTransientColor () also suffers from the same bug. I have not tested this, too late tonight!
Thank you for looking into this, I took me several hours to decipher what was going on, however simple the bug might seem.
Steve
#2
Posted 29 December 2018 - 07:45 AM
In the meaantime I believe I found a significant typo error in the standard OR code.
This is the PrepareFrame method for the diesel exhaust within MSTSDieselLocomotiveViewer.cs
public override void PrepareFrame(RenderFrame frame, ElapsedTime elapsedTime) { var car = this.Car as MSTSDieselLocomotive; // Diesel exhaust var exhaustParticles = car.Train != null && car.Train.TrainType == Train.TRAINTYPE.STATIC ? 0 : car.ExhaustParticles.SmoothedValue; foreach (var drawer in Exhaust) { var colorR = car.ExhaustColorR.SmoothedValue / 255f; var colorG = car.ExhaustColorG.SmoothedValue / 255f; var colorB = car.ExhaustColorG.SmoothedValue / 255f; drawer.SetOutput(exhaustParticles, car.ExhaustMagnitude.SmoothedValue, new Color((byte)car.ExhaustColorR.SmoothedValue, (byte)car.ExhaustColorG.SmoothedValue, (byte)car.ExhaustColorB.SmoothedValue)); } base.PrepareFrame(frame, elapsedTime); }
Line
var colorB = car.ExhaustColorG.SmoothedValue / 255f;
seems clearly wrong.
Attached are the runactivity exes which correct the error for the standard OR version (1.3.1)
Runactivities_RGBExhaust.zip (1.11MB)
Number of downloads: 260
Does this change something in the diesel exhaust color with the standard OR, for engines using the ORTSDieselEngines section and the ExhaustColor ()? For engines not using such section nothing should change, because the Exhaust color is grey, that is it has all color components with the same value.
The bug is present also in the Monogame version.
By the way in StackOverflow I found following page https://stackoverflo...lor-packedvalue , where this is written: "IIRC DirectX uses BGRA color while XNA uses RGBA". So there is no unique convention. This confuses me.
#3
Posted 29 December 2018 - 08:55 AM
Thank you for looking into this.
I am reading your full reply and I have some reading to do, but I can answer at least part of your reply.
The ORTS portion of the engine file used is right here in the forum:
Diesel exhaust is always black
Once I saw the bug with another engine I went back to an older test and used the same engine file.
Molte gracie,
Steve
#4
Posted 29 December 2018 - 09:09 AM
Csantucci, on 29 December 2018 - 07:45 AM, said:
I think we should try to follow what MSTS/ORTS have been using for well over a decade now (Light section in .eng file, etc), which is the RGB convention. Most if not all paint programs use the RGB convention (since the 1980s I have used that thought process/convention ) As indicated it also follows the HTML standard. This makes it quite easy for the user to copy and paste a value as opposed to reversing the sequence of numbers. I do not understand why ORTS has an entry for "aa" in the ExhaustColor () if we are not going to use it at all, this is confusing for the user, but as well it is what took me so much time to decipher what the bug was. The documentation is rather poor in this respect.
Steve
#6
Posted 29 December 2018 - 07:31 PM
Csantucci, on 29 December 2018 - 09:23 AM, said:
Carlo,
I cannot test the modified files, both have "corrupt" keyboard assignments that do not allow for proper testing. This includes cameras and elements like throttle increase/decrease. Did you send me a modified version for use with an EU/Italian keyboard? The key assignments do not correspond with a North American 101 keyboard.
Sorry about this, but thanks and hope you find the time to recompile at your leisure for testing,
Steve
#7
Posted 30 December 2018 - 02:30 AM
Eldorado.Railroad, on 29 December 2018 - 09:09 AM, said:
I agree. If you change certain things, then content developers have to start issuing patches, and we have better things to do with our time. "What do the people who actually build things for our platform think" ought to be one of the very first guiding questions, I think.
I mean, if we did what DirectX wanted us to do, we'd have to flip all of our textures to correspond to DirectX's native coordinate system, which is backwards from every other coordinate system on Earth... there's no sense in perpetuating Microsoft's mistakes for the sake of complying with Microsoft's mistakes.
#8
Posted 30 December 2018 - 07:59 AM
#9
Posted 30 December 2018 - 01:14 PM
Here
http://www.elvastowe...post__p__243764
the links are available to an OR MG version that should correct the error (that is they maintain compatibility with the standard OR and with MSTS).
#10
Posted 06 January 2019 - 06:58 AM
Eldorado.Railroad, on 29 December 2018 - 09:09 AM, said:
It doesn't make the slightest difference what web, paint programs or other software does; only what MSTS does. If we're reading the value differently to MSTS, it should be fixed. That's all there is to it.
With that said, quite often MSTS's behaviour will be defined entirely by how DirectX does something, because MSTS uses DirectX.