1. We have added the ability to collapse/expand forum categories and widgets on forum home.
    Dismiss Notice
  2. Photobucket has changed its policy concerning hotlinking images and now requires an account with a $399.00 annual fee to allow hotlink. More information is available at: this link.
    Dismiss Notice
  3. All Civ avatars are brought back and available for selection in the Avatar Gallery! There are 945 avatars total.
    Dismiss Notice
  4. To make the site more secure, we have installed SSL certificates and enabled HTTPS for both the main site and forums.
    Dismiss Notice
  5. Civ6 is released! Order now! (Amazon US | Amazon UK | Amazon CA | Amazon DE | Amazon FR)
    Dismiss Notice
  6. Dismiss Notice
  7. Forum account upgrades are available for ad-free browsing.
    Dismiss Notice

Decoder and encoder for FTXTInterface UI textures

Discussion in 'CivBE - Utility Programs' started by LRN, Dec 16, 2014.

  1. LRN

    LRN Chieftain

    Joined:
    Dec 12, 2014
    Messages:
    9
  2. LRN

    LRN Chieftain

    Joined:
    Dec 12, 2014
    Messages:
    9
    One thing that is kind of bothering me is that currently automatic block size detection is extremely dumb: it just encodes at all plausible block sizes (ones where worst-case number of blocks is < 0xFFFF, because that's the limit of a 16-bit block map; all the files that i've seen use 8- or 16-bit block maps) and picks the one that results in the smallest file.

    This can take a long time on images that are large enough to be slow to encode, but small enough to be plausibly encodeable with small blocksizes.

    My gut feeling is that Firaxis has some heuristic for this (say, images larger than 4096 are encoded with blocksize 8, images larger than 2048 - with blocksize 4, and so on), but i was unable to figure it out due to the limited data set. Do you, guys, have any ideas? I haven't looked at CivV resources, maybe the logic is more apparent there.
     
  3. Lord Tirian

    Lord Tirian Erratic Poster

    Joined:
    Nov 30, 2007
    Messages:
    2,724
    Location:
    Liverpool, UK
    Wow, this was totally overlooked, I guess... does this tool essentially does what this one does (i.e. decode the RLE DDS files), but can do so in reverse?

    If so, what's the impact on the file size? At the moment, I have the dilemma that full RGBA DDS files are huge and that compression is sometimes very noticeable on the Civ5-style icons (especially seeing how Firaxis' files never seemed to have that issue).

    In any case, I'll have to dig into this, just need to get a Python3 install on my Windows box. :)
     
  4. LRN

    LRN Chieftain

    Joined:
    Dec 12, 2014
    Messages:
    9
    Yes

    Depends on the input. Input that is highly regular (significant amount of areas of constant color or same features repeated often) compresses farily well (given that it's lossless). You can just uncompress existing FTXTInterface DDS files and compare the size - that should give you a good idea. Obviously, this works well only on artificial images (UI elements), not on real-life images (textures for game models). Hence the 'Interface' in 'FTXTInterface'.

    Yes, this is exactly the case for this kind of compression. Mods like Colour-filtered Tech Web" should use it (although, obviously, adding color makes image somewhat less compressible; original Firaxis icons often use shades of a single color).
     
  5. Lord Tirian

    Lord Tirian Erratic Poster

    Joined:
    Nov 30, 2007
    Messages:
    2,724
    Location:
    Liverpool, UK
    I quickly tested it on the golden age yields I made here (showing the PNG).

    Result:
    Uncompressed: 321 KB
    DXT5: 81 KB
    RLE: 94 KB (53 KB texture + 41 KB index)

    Of course, that's not a super-stringent test but considering the full quality despite the use of gradients there for the actual icon, I suspect that a lot is gained from the heavy use of transparency in all UI atlases (e.g. every icon is a 172px circle in a 256px square) and similar UI elements.

    In any case, good job, you should post it in the corresponding Civ 5 section as well! This could improve the file sizes for almost every mod (as almost every Civ5 mod has some sort of icons). :goodjob:
     
  6. LRN

    LRN Chieftain

    Joined:
    Dec 12, 2014
    Messages:
    9
    Does it actually work for CivV? That is, have you tried putting the compressed image into a mod and loading it, does CivV grok the image?
     
  7. Lord Tirian

    Lord Tirian Erratic Poster

    Joined:
    Nov 30, 2007
    Messages:
    2,724
    Location:
    Liverpool, UK
    I was overly enthusiastic, it seems. I assumed if the tool works for Civ:BE, it would work for Civ5... but it doesn't. :(

    What is the expected format of the input DDS? I'm feeding it 8.8.8.8 ARGB files and get files out that are at least readable in an editor... but I don't know what you intended it with, so maybe there's an issue.
     
  8. LRN

    LRN Chieftain

    Joined:
    Dec 12, 2014
    Messages:
    9
    Doesn't how exactly? The game claims that it has failed to read the texture (in BE, if you give the game a bad texture file, it will show a message box with an error when it tries to load it)?

    Expected input is uncompressed DDS. The decompressor preserves the format of the original: copies over the header, rewrites the width/height fields, then copies pixel blocks from the compressed image into appropriate places of the decompressed image. It never tries to interpret the pixels. Compressor does the same thing in reverse.

    I've tested it in Civ:BE by decompressing and then compressing again various interface textures (technology atlas most prominently, at various resolutions, as it's the biggest interface texture in the game). Try something similar with CivV - pick a few interface textures, recompress them, see if the game is still able to load them. If it is, then there's some kind of incompatibility with the input images you provided. If it isn't, then V uses a different format than BE.

    I don't have CivV available at the moment, so i can't check this.

    I've skimmed Dragon Unpacker source code after publishing my FPK unpacker, and from the comments there i've gathered that V used a bit different FPK format than BE (with dumb filename scrambling, for example). It's possible that FTXTInterface format also differs.
     
  9. LRN

    LRN Chieftain

    Joined:
    Dec 12, 2014
    Messages:
    9
    I've mentioned FPK differences earlier. Turns out, i misremembered this: filename scrambling was used in CivIV, not in CivV.

    Since there seems to be a demand for this, i've managed to get a copy of CivV (BNW) and tested the program on it by doing the following:
    • Unpacked UITextures.fpk with my FPK unpacker
    • Moved the fpk file away (so that the game won't be able to load it)
    • Moved the unpacked files into assets subdirectory (so that the game will be able to load them)
    • Found a file to test (buildingatlas.dds and buildingatlas-index.dds)
    • Decompressed buildingatlas.dds and buildingatlas-index.dds into buildingatlas.decompressed.dds
    • Moved the buildingatlas.dds and buildingatlas-index.dds files away from the assets subdirectory
    • Ran the game, looked at a building (Monument) in the civopaedia. The game said that it couldn't load buildingatlas.dds
    • Closed the game
    • Compressed buildingatlas.decompressed.dds into buildingatlas.dds and buildingatlas-index.dds
    • Ran the game, looked at a building (Monument) in the civopaedia. The image displayed correctly, no errors.
    Therefore i would conclude that FTXTInterface (de)compressor is CivV-compatible.
     

Share This Page