Ingame GUI improvement

[adfriz]

WIP.

not all tested, I mostly test with route viewer first.

i hope we could retire the F8 options window if all completed

Preview:

Screen.Recording.2026-06-27.092419.mp4

@leezer3 what do you think?

[ginga81]

Please forgive my limited understanding.
I thought that by using this technology, it might be possible to phase out WinForms.
I think it's amazing.

[adfriz]

i think that is different problem, winforms tied to system windowing, this one is for in game gui.

my plan is if this completed, we may add a new xml file or maybe extend train.xml file to have all options like door toggle, pantograph and other maybe pluginstates functions can be triggered by this ingame GUI.

Let say your shinkansen train has feature to open and close the coupler cover, we can make it as GUI toggle to trigger it than binding to a keyboard.

[leezer3]

Very neat :)
Can't say I'm personally sold on the pop out from the side (or most 'modern' UI design for that matter), but it looks good.

I'll try and test on the Mac next week. If it's going to fall over, it'll do it there- the Retina scaling is a total Apple mess...

[leezer3]

Haven't looked into this at the minute, but at least the viewing distance is buggy.

Start with a viewing distance of 4000.
Drop to 600.

Background glitches out. (you can actually see a grey square marching in as you drop it downwards)
Clipping distance wrong somewhere I'd suspect.

On the plus side, it handled changing the Windows display scaling without a hitch!
Need to get around to trying the Mac, spent most of today chasing Hmmsim bits....

[adfriz]

Haven't looked into this at the minute, but at least the viewing distance is buggy.

Start with a viewing distance of 4000. Drop to 600.

Background glitches out. (you can actually see a grey square marching in as you drop it downwards) Clipping distance wrong somewhere I'd suspect.

On the plus side, it handled changing the Windows display scaling without a hitch! Need to get around to trying the Mac, spent most of today chasing Hmmsim bits....

Yeah still long way to go until it stable... Idk if I can complete this PR, with a lot of recent stuff happens in real life, maybe this going to be another cliffhanger PR.

---

Off topic, about MacOS do you think we can do non parity feature between each OS? I mean Mac has limit of opengl 4.1 but windows and Linux are not limited.

As example I was developing volumetric clouds and atmospheric sky feature for my own test, if I limit it to ogl 4.1 the best we can do is using fragment shader, but with how the technique used a lot raymarching and samplings using fragment shader always make it bottleneck and not efficient (essentially we do heavy calculation for every pixel every frame) and it's scale up exponentially if we use large screen resolution.

So the way I try is make a ogl version check, if the device support ogl 4.3+ it will use compute shader if not, just fallback to 4.1 and use fragment shader, but the performance gap using compute shader if very very noticeable... Stable 60fps and didn't lag on window resize, with fragment shader it's always sub 20fps and always have 3 second of window not responding when resized.

[leezer3]

Not sure what to do about GL version levels TBQH.

I'd prefer to keep as one code path to make things simpler, but Apple are a mess. I suppose we could do a GL4.1 code path and a later path, but dunno...
Not sure how well volumetric clouds are likely to combine with the standards of existing content either; most stuff isn't exactly setup for nice 3D viewing, and you'd probably get away with a basic technique like the smoke shader in nearly every case.

Really need to get to removing the GL1.2 renderer. I've just pushed a build, and when this goes to the main site, I may publish the GL1.2 removal notice at the same time, so the 'next' public build after that would then withdraw GL1.2