[disc]

I'm reading that everywhere, that OR doesn't loads the textures of rolling stocks after a long session of a heavily populated route. The problem what causing this is probably, the ACE format which doesn't really supports GPU known compression other than DXT1, which is obviously not an option when the object have transparent windows windows, and some say the ACE dxt compressor have really low quality.
So that means an average MSTS route and rolling stock have huge amount of textures that are loaded into memory as uncompressed texture, and THAT causing the memory, stuttering, missing texture problems. Of course the LAA executables can help, but isn't a real solution.
If've just made a small app, that checks the texture format in ace files and can make statistics, and in the most popular hungarian MSTS route, about ~2500 textures were uncompressed(BGR565, BGRA5551, and BGRA4444) and 7500 textures were compressed with DXT1, which is extremely high amount compared to other games, and that's surely a memory hog.
The real solution would be a new texture format that doesn't have the limitations of ACE, and DXT3-5 compression is widely available, with high quality tools, and this is the DDS. It's native to XNA, it's widely supported, then why that doesn't implemented in OR already? With that the all of the ace textures could be converted to DXT1-3-5 compressed DDS textures, which could eliminate the memory problems, and could make the OR to run smoother.

[gpz]

Please see an other thread I opened: DDS texture loader.

Just a note: DDS isn't native in XNA, because DDS is a container format (just like ACE), that can contain many types of images, among them the DXT1-5. What native is the DXT1-5 itself.

[copperpen]

To accommodate the use of DDS textures we would need something to convert ACE files on the fly as the activity and route are loaded. Physically converting ACE to DDS removes all MSTS compatibility. For me, not a problem as I rarely use MSTS these days, however, there are a huge number of models and routes out there and conversion would be a very big job. I like the idea moving forward post version 1 of OR.

[PA1930]

Excuse me as I don't really understand about this stuff, but, imagining that we make ORTS use those DDS textures, how would MSTS content work afterall? They do have only ACE textures... Or would ORTS convert them somehow?
I'm sorry, I really don't understand much about this so excuse me if I'm saying something really silly...

[James Ross]

disc, on 02 February 2014 - 03:54 PM, said:

The real solution would be a new texture format that doesn't have the limitations of ACE, and DXT3-5 compression is widely available, with high quality tools, and this is the DDS. It's native to XNA, it's widely supported, then why that doesn't implemented in OR already?

ACE files actually support DXT3 and DXT5, and Open Rails has supported both in ACE files for some time (I can see the code being added in X1493 in March 2013). I am fairly sure that DXT3 and DXT5 are used in some 3rd party content too, though certainly not widely - the main issue is tools that'll generate them.

DDS has always been my preferred new texture format and I believe most people are in agreement about that; it is, however, quite useless for existing MSTS content in the current scheme of things, as copperpen rightly points out. There are much better things for me to spend my time on than on-the-fly conversions of texture formats right now.

[scottb613]

Morn'n Folks,

Just an OBTW - MSFS uses these same formats - so the tools to do conversions exist... FS9 uses DXT1 and DXT3 - and - I believe FSX uses DDS... I use a program called ConvImX which allows batch conversions of entire directories in all these formats...

Regards,
Scott

[markus_GE]

Instead of on-the-fly conversion, what about an external tool that looks through you MSTS installation and makes DDS-formatted copies of all ACEs found there?

That way, MSTS can still load its native ACE files, and ORTS can read it´s DDS files without any conversion built directly into it.

Cheers, Markus

[jared2982]

I'm with Marcus. If DDS is they way to go, and everything I've read on it seems to point that way, then simply supplying a converter to convert the textures would seem to be the way to go. At some point an install program will have to be created for those that can't manage to setup directory structures and copy and paste so the install could also run the conversion program to convert the texture files.

[Eldorado.Railroad]

From 03 February 2014 - 06:27 AM:

Instead of on-the-fly conversion, what about an external tool that looks through you MSTS installation and makes DDS-formatted copies of all ACEs found there?

That way, MSTS can still load its native ACE files, and ORTS can read it´s DDS files without any conversion built directly into it.

Cheers, Markus

In principle, a very good idea and you will have to convince a lot of people that disk storage is cheap to handle all of the duplicate .dds files.

[jared2982]

Eldorado.Railroad, on 03 February 2014 - 12:16 PM, said:

In principle, a very good idea and you will have to convince a lot of people that disk storage is cheap to handle all of the duplicate .dds files.

What about offering the option to use DDS or not? We already use ACE format but could we support both without ill effect on OR?