Testers with OLDER routes required (Fixed transparency errors!)

I'm looking for people with (primarily) older routes / trains to test a slightly experimental build:
https://github.com/leezer3/OpenBVE/files/1211593/TransparencyFixTest.zip

This build (should) have fixed *all* transparency issues with all older content, with no user intervention required

I don't think there should be any side effects (Other than a marginal increase in memory usage, probably ~8kb per texture loaded), but this has a small possibility of unintended side-effects on bitmaps with lower than 16-bit color depth.

Assuming this works OK, it'll be merged into the main nightly builds, but it's experimental enough I want to get feedback here first!

Chris, I tried this build with an old Aussie route, Kurrajong which has transparency issues. This build does resolves these issues. This was previously rendered with the transparency colour of black displayed instead of being transparent.

I've tested this build with the old LU Bakerloo Line and the Bentschen U1 routes, which both had transparency issues, and all the problems are gone, everything looks great!

I used the 1972 Stock train to test the Bakerloo Line and also noticed that the traction/brake overlay in trains with a single controller looks white instead of blue, but I guess this may be a side effect from the recent message colour changes in the master branch of OpenBVE.

Marc Riera wrote:I've tested this build with the old LU Bakerloo Line and the Bentschen U1 routes, which both had transparency issues, and all the problems are gone, everything looks great!

I used the 1972 Stock train to test the Bakerloo Line and also noticed that the traction/brake overlay in trains with a single controller looks white instead of blue, but I guess this may be a side effect from the recent message colour changes in the master branch of OpenBVE.

Rats, yes the color is wrong on single handle trains. Minor cosmetic detail at least though.........
(TLDR: It's to do with the horribly hacky method which Michelle used to produce the text background color which broke when I fixed the ability to use actual blue text in messages, thought I'd caught all of those.....)

Glad it's working OK though, although I'll note that this is not 'free' , and has a small performance impact when any texture is loaded.
With the sorts of route this is designed to work with though, I don't think that's really an issue.

I'll move this into the main branch as an 'Advanced' option later in the week, which might mean the order of the options pages gets rejigged a little.
I think we probably need an Options switch a-la ObjectVisibility so that route developers can specifically disable this also.

Technical Details:
If a texture is detected as having a restricted color palette (e.g. not 32-bit RGBA or 24-bit RGB), the color palette information is now stored along with the texture.
When the texture is loaded, we find the nearest color in the restricted palette to that supplied by the SetTransparentColor , which at present is simply that which is nearest in the RGB space. (No fancy playing with hues or anything)

I can't guarantee that this will fix everything, but I haven't seen anything broken in my reasonably extensive collection

Since restricted palettes can have sensible applications even today, I'd say the option to disable this behaviour in both route and object files is a must! My reasoning being that modern day developers are careful to reference all colours exactly, so there is no need to clog up the memory with palette information.

Though, on second thought, I think there is indeed a more elegant solution to this. It would increase initial loading time a little bit, but would minimise RAM usage: After the "find the nearest colour" part, add another check, whether this "nearest colour" is exactly the one supplied by SetTransparentColor. If yes, drop the palette information; if no, keep it.

Quork wrote:Since restricted palettes can have sensible applications even today, I'd say the option to disable this behaviour in both route and object files is a must! My reasoning being that modern day developers are careful to reference all colours exactly, so there is no need to clog up the memory with palette information.

Though, on second thought, I think there is indeed a more elegant solution to this. It would increase initial loading time a little bit, but would minimise RAM usage: After the "find the nearest colour" part, add another check, whether this "nearest colour" is exactly the one supplied by SetTransparentColor. If yes, drop the palette information; if no, keep it.

Small issue with that approach:
There's nothing stopping you calling the same texture in two different places with two different transparent colors specified

Memory usage:
If we assume a 256 color palette * 3 primary colors * 8 bytes per primary color, that gives us a total extra memory usage of ~7kb per texture, which is pretty insignificant in the grand scheme of things.
TBQH, the fuzzy match algorithm probably has more of a performance impact
It also only applies to plain bitmaps, as PNGs are already color-mapped internally via the decoder (And for that matter were never supported by BVE2/4 anyways).


Having said all of that though, fuzzy matching is not a good thing in general.
The only reason I'm doing this is because BVE2/4 worked in that way, and much better / easier backwards compatibility is I think worth a small performance sacrifice in this case.

I shortly thought about trying to automatically determine the probable era the route was created in by looking for which commands are used (using Track.Turn instead of Track.Curve for example), but I think the limitation to bmp files is close enough. One simply doesn't use plain bitmaps nowadays.

Sounds relatively reasonable.

I've improved things slightly, and have added two routefile specific options to control this, and the use of various small hacks which fix buggy BVE2 / BVE4 content:

Options.CompatibleTransparencyMode Mode

Mode: The mode determining how transparencies are processed in BVE2/ BVE4 objects which use a restricted color pallete. This may be used on a per-route basis to override the value set in 'Options'.

▸ Available options for Mode:

0: Colors are matched specifically. If the specified transparent color does not exist within the color pallete, no transparency will be added. 1: Fuzzy matching. If the texture uses a restricted color pallete, the transparent color will be clamped to the nearest available color in the pallete.

---

Options.EnableBveTsHacks Mode

Mode: The mode determining whether various hacks are applied in order to fix BVE2 / BVE4 content. This may be used on a per-route basis to override the value set in 'Options'.

▸ Available options for Mode:

0: Hacks are disabled. 1: Hacks are enabled.

The only thing I can see left to do now is to plumb these up into the main options menu and merge into the main daily builds.

Any more thoughts most welcome though

Now in the main builds, including a main menu option for both

Please note that 'Advanced Options' and the options for the Raildriver have been swapped, in order to give a little more space to work with.

I've also added a further hack to fix issues in the Richmond- Kurrajong and Campbelltown - Campden BVE2 routes ( http://bve_fan.tripod.com/bvefan/index.html )


I'll see about updating the main documentation later, as well as adding a page describing all the current hacks.
Whilst harmless, these should be disabled if you're developing to ensure no unintended effects on different machines.

Thank you for sorting those issues in the Kurrajong and Camden routes as these are one of the very few routes from Australia made for BVE. I had previously thought the issues were because these routes couldn't work properly with OpenBVE which I didn't expected to change.

No trouble (I'd have fixed them sooner if I'd noticed, just ran across the issue whilst looking for test cases.......)
IIRC these were actually the first ever routes to get rain and lightning to visually work way back in ~2001, on what was then the CroTrainz forums.

BVE2 didn't support pitch or roll for objects, and the author for these added comments describing each object after the command.
These were getting misinterpeted as pitch values, producing the mess you saw.

If you know of anything else that's completely broken or just looks wrong compared to BVE2 / 4, let me know, and I'll investigate a fix.

Note:
Hacks and new features are only really being applied to the main sim going forwards, as opposed to Route Viewer.