Issue with some PNG files

[leezer3]

I also faced now another kind of issue... When I opened an extensions.cfg file of a train in Object Viewer, I saw these errors. There are 2 textures with .png extension, and the sizes are not too large: both's resolution is 5906 x 3543 px with 510 kilobytes and 301 kilobytes. I think making these 2 textures visible was not a problem in my previous (2024-01-04) OpenBVE version.

Did it happen, that from the beginning of this year (2024) the Texture.BmpGifJpegPngTiff plugin got a new restriction on the texture resolution? If yes, could You please write the maximum allowed resolution into the OpenBVE Developer Documentation, or just here? Could 4096 x 4096 px be the last (or largest) that can be displayed in Object Viewer, maybe?

Originally posted by @BPI-919 in https://github.com/leezer3/OpenBVE/issues/990#issuecomment-1950249333

This is going to be an issue with the new PNG decoder. Looks like a variant it's not handling nicely.

[leezer3]

@BPI-919 do you have a link to the exact train variant please? (or just the broken PNG files)

It doesn't appear to be the one from BVEKlub or from OpenBVEWorkshop on facebook, and this is where I need to see the file to figure out what's going wrong. It ought to just fall back to the old PNG decoder if the new fails.

Notes on the file (from your description):

• It's not to a power of 2. This means it'll be upsized to 8192 x 4096 in memory.
• The biggest sensible size should be 2048 x 2048 (and really this is too large for what appears to be a destination blind?)

[BPI-919]

Unfortunately, I rarely have time to use my own PC, but I will send You the 2 .png files and the related .b3d file sections as well. I hope I won't forget to do this in the near future... (The funniest thing is that I rather use the company's laptop, where I work than my desktop computer... And I only use that laptop for work, OpenBVE has never been installed to that laptop, so far. :D )

[leezer3]

May well be fixed by the build from today, but without the offending file I can't check.

[BPI-919]

It is very interesting, because sometimes I can see this... (when I load the entire car-animated) ...and sometimes this: (when I load only the sub-animated file)

When I load the .b3d file, which contains the problematic textures, I can see this:

...and then I tried to load the extensions.cfg file of this train, and suddenly the Object Viewer closed automatically (without my interruption). :|

I can see this, after I opened the Object Viewer again, and tried to load the extensions.cfg file, again... There are no errors, right now, but some textures are entirely black (colored) ...

Then I pressed the "F5" (refresh), and the error messages appeared again... :/

After that I opened the Task Manager. Here you can see the current memory usage. (I have successfully expanded the RAM memory in my Desktop computer from 32 GB to 64 GB today, so this is the reason why you cannot see the memory usage as full. :) ) Perhaps memory leak is in the background. (?) I also faced that for the Object Viewer app, there is no separate 32 and 64 bit version... And if I see well, Object Viewer is handled as a 32 bit version. :/

[leezer3]

32-bit .Net only supports ~1.5gb of RAM per process, which is going to be why Object Viewer is suddenly closing on you. I don't think it's a leak per-se, just one of those things.

TBQH, I think Object Viewer could probably be made 64-bit only. The only real reason for keeping the 32-bit version of OpenBVE about is for legacy plugins. The proxy works with nearly all of these, but there are a couple of 32-bit .Net ones, which are a real pain to proxy.

I'll think about things a little more with regards to 64-bit and Object Viewer. but I don't think we've now actually got a bug, just 'expected' behaviour (and a train in need of optimisation)

[leezer3]

Black textures are also a probable side-effect of hitting the 32-bit memory limit. Basically, if the process runs out of memory, bad / unexpected things can and do happen.....

[BPI-919]

Ah, okay. The most interesting thing is that these textures appear in OpenBVE (main program) properly. So when I select a route with this train, no issue, and now I can also press the start button, and the game has started successfully.

I also have a new friend, who is working on some useful tools related to OpenBVE. He works in Windows XP system and he told me that he had not been able to open the newest OpenBVE applications... He also told me that an older .NET framework version was removed from the project, which was still compatible with Windows XP. I think he would be happy, if he had a chance to run the latest OpenBVE version in Win-XP.

I also faced another kind of issue, related to Route.Runinterval command... :

If I also add negative values as parameters for this command, the other train has already placed to the starting station after the successfully game loading. And from that reason I am not able to start moving with my train. :(

[leezer3]

Unfortunately, XP went end of life 10 years ago. For that matter, Windows 7 is technically EOL, but at present there's no real support difference between Windows 7 and 10.

I'm not sure what the latest version to work on XP would be (It'd be relatively early, as we switched to targeting .Net 4.5 as soon as Mono gained support for this- A bunch of really useful stuff), and I don't intend making any changes on tihs front.

---

Will take a look at negative runintervals. I don't believe anything has been changed in this regard for a long time however. My first immediate thought would be to question whether your route has a section / signal before your starting station.

[BPI-919]

I do not think that there is a section / signal before the starting station. However the starting station is very near to the 0 and negative track values...

The first Track.Sta command starts at track position 46 meters. Perhaps this could be a reason. (?) In this picture you can see the negative value of the Route.RunInterval command, too.