New Texture format and the memory problems
#1
Posted 02 February 2014 - 03:54 PM
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.
#2
Posted 03 February 2014 - 12:46 AM
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.
#3
Posted 03 February 2014 - 05:05 AM
#4
Posted 03 February 2014 - 05:11 AM
I'm sorry, I really don't understand much about this so excuse me if I'm saying something really silly...
#5
Posted 03 February 2014 - 05:19 AM
disc, on 02 February 2014 - 03:54 PM, said:
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.
#6
Posted 03 February 2014 - 05:43 AM
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
#7
Posted 03 February 2014 - 06:27 AM
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
#8
Posted 03 February 2014 - 12:10 PM
#9
Posted 03 February 2014 - 12:16 PM
From 03 February 2014 - 06:27 AM:
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.
#10
Posted 03 February 2014 - 12:20 PM
Eldorado.Railroad, on 03 February 2014 - 12:16 PM, said:
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?