[Jovet]

Genma Saotome, on 30 March 2016 - 01:11 PM, said:

Does .dds use more memory than .ace?

In memory, no. On disk yes. The graphics hardware will end up treating both like 32-bit bitmap files, once they're loaded into memory. Compressed .ace files are decompressed, etc., while they reside in video memory.

I've never been very clear on the push for .dds support in Open Rails, other than it's a standard image format which .ace is not.

[James Ross]

jovet, on 31 March 2016 - 12:04 AM, said:

In memory, no. On disk yes. The graphics hardware will end up treating both like 32-bit bitmap files, once they're loaded into memory. Compressed .ace files are decompressed, etc., while they reside in video memory.

The picture is slightly complicated by RGB vs DXTn:

• ACE/RGB: gzip compressed on disk, 32bit bitmap in memory.
  
• ACE/DXTn: DXT-compressed on disk, DXT-compressed in memory.
  
• DDS/RGB: 32bit bitmap on disk, 32bit bitmap in memory.
  
• DDS/DXTn: DXT-compressed on disk, DXT-compressed in memory.

So for RGB images, ACE has the advantage of gzip which DDS cannot do (AFAIK), but for DXTn images, they're equivalent. I'm not sure exactly how many bytes of header either format has off-hand, but I believe this will almost always be swamped by the image data too.

jovet, on 31 March 2016 - 12:04 AM, said:

I've never been very clear on the push for .dds support in Open Rails, other than it's a standard image format which .ace is not.

That's a pretty big gain for some people. It may also (not sure if this is implemented at present) be simpler/faster to load in to DirectX due to it being an expected format unlike ACE. Plus DDS natively supports things like cubemaps and the like, which we want to be adding at some point.

[disc]

jovet, on 31 March 2016 - 12:04 AM, said:

In memory, no. On disk yes. The graphics hardware will end up treating both like 32-bit bitmap files, once they're loaded into memory. Compressed .ace files are decompressed, etc., while they reside in video memory.

DXT compressed images will always stay as DXT in memory, other formats are always uncompressed then loading to memory, so these take much more memory than DXT compressed textures.

[Jovet]

One other point is that since a loading screen is only shown when a route is loaded, its memory impact doesn't matter since it's never needed again.

[Nicolò]

strawberryfield, on 30 March 2016 - 10:41 AM, said:

Implemented in X3494

Now you can have a load.dds loadscreen for the route in any size.
The parameter 'loadingscreen' in the .trk is handled properly and accepts both .ace and .dds files (of course .dds files aren't read by MSTS); if both files exist the .dds has precedence if the corresponding flag in options is set.

another new parameter 'ortsloadingscreenwide' is available for a loading screen to use on a widescreen monitor (both .ace and .dds available in any size)

In case 'loadingscreen' parameter in the .trk is pointing to an .ace file, if there are both in the directorty and the flag in options is set, OR will use the .dds one and MSTS the .ace one?

[James Ross]

Nicolò, on 01 April 2016 - 11:30 AM, said:

In case 'loadingscreen' parameter in the .trk is pointing to an .ace file, if there are both in the directorty and the flag in options is set, OR will use the .dds one and MSTS the .ace one?

MSTS does not use the LoadingScreen parameter, so you can use it set a different image for OR and MSTS without using different formats.

For completeness, I believe this is what OR will try (until it finds one which exists):

• OrtsLoadingScreenWide DDS - if widescreen window/monitor and DDS loading enabled
  
• OrtsLoadingScreenWide ACE - if widescreen window/monitor
  
• LoadingScreen DDS - if DDS loading enabled
  
• LoadingScreen ACE
  
• load.dds - if DDS loading enabled
  
• load.ace

MSTS only loads "load.ace" AFAIK.