[REF][11.11.09] CFC - THE Manila/TF3D Image Editor - Tech Reference (Q)(W)VGA

Search This thread


Senior Member
Jan 14, 2010

-I downloaded and ran the 'cfc-0.60+gui-0.60.35.zip' (the app within, CFC GUI) -I extracted a .cab with both .png and QTC-files to a folder of it's own, checked and all the files were there
-I then selected the folder in CFC GUI
-I then replaced all the manilla files with .PNG's where I wanted changes
-I pressed 'Finish Up' and then selected 'trim' in the end.

..now the manilla files are gone from the folder, and when I go to [Device]->[Export Changes to CFC/QTCs]->[Select folder (original one)] and there I get an error.. reading:

'Error: Could not Initialize RAPI!


What am I doing wrong? All I want to do is take a slider-.cab and change the graphics, all the .PNG's are changed but without difference, so I have to change the graphics in the manilla-files.....

Thankfull for positive response! (I'm pretty clueless so please explain point-by-point and not in any internal lingo..)
Last edited:


Nov 1, 2009

This might be a silly question or not. But on roms's theres a list of what files are for what. I realize asking the following is phone dependent and time consuming, but has anybody made a list of manila files for phones so we know exactly what we are looking for?

Top Liked Posts

  • There are no posts matching your filters.
  • 2
    @Chainfire: so if i understood it correctly from some of your last posts, if you cook it it you'll kinda have the option to take away manila files that are not needed to be there and therefor it will be faster than noncooked?..

    well i've patched mine (noncooked) so if it were cooked it will work faster than noncooked?
    yeah he has done that in his unrealesed v4.2 .. he also states that he didn't get any more free space than he had but tf3d does run faster and smoother than before...
    Update November 11, 2009
    CFC and CFC GUI have been updated to 0.60 and 0.60.35 respectively. CFC runtime files have been updated. This thread has also been update to add information about the new file formats.

    - (CFC GUI) Support for new filenames (and categories) used in TF3D v2.5+
    - Support for new file formats (read only, "replace" write is always in old format) used in TF3D v2.5+
    - Support for new compressed formats that correspond to the new formats mentioned above
    - (CFC GUI) If you are using this with 2.5, please do read the 2.5 specific notes (in the CFC GUI thread).
    - At this time I STRONLY recommend patching Manila files manually instead of using the auto-patching! See the tech thread referenced below.

    Update June 5, 2009
    CFC and CFC GUI have been updated to 0.55 and 0.55.25 respectively. The CFC runtime files have not been updated. Changes:

    - Better compression ratio (backwards compatible with old runtime)
    - UltraHQ en/de-coding support (CFC)
    - "Patch Manila on device" function has been improved to work-around the issue of Manila no longer starting that some people have (CFC-GUI)

    Update April 20, 2009
    CFC and CFC GUI have been updated. Many changes! For the changelog see the CFC GUI thead. The CFC runtime has also been updated to v0.50, so there is a new libgles_mn file required. See the cfc-support-dll zip attached a few posts down.

    Update Feb 26, 2009
    CFC and CFC GUI have been updated to 0.46.15. Fixed an issue with PNGs without alpha channel.

    Update Jan 15, 2009
    CFC Live Patch 0.45.01 has been released. You can run this tool on your phone to make your current Manila installation compatible with CFC compression.

    See this post.

    Update Jan 14, 2009
    CFC GUI 0.45.15 released. No changes to CFC core, only GUI stuff. Attached download updated.

    CFC GUI thread: http://forum.xda-developers.com/showthread.php?t=470798
    Changelog: http://forum.xda-developers.com/showpost.php?p=3164604&postcount=3

    Update Jan 13, 2009
    CFC 0.45 and CFC GUI 0.45.12 released.

    CFC (core) changes:
    - Heavily modified encoding algorithm. It is often slower but the quality should be much better. Please read this post!

    CFC GUI changes:
    - No longer freaks out if the wrong file attributes are set on some files
    - Added background color selection
    - Added tool to patch a complete Manila package for CFC compatibility and optimization

    Also, non-technical discussion of CFC GUI (only) should go to this thread:

    Update Jan 12, 2009
    Yes I know, too many updates today!

    CFC 0.42 attached. Was something weird going on with the encoding sometimes. Furthermore it seems like the encoding works great on the original files, but it drops the ball here and there with other files. Going to look into that ASAP and finetune the encoding algorithm!

    Most important about this update is, CFC now also comes with a GUI!

    Update Jan 12, 2009
    CFC has been updated to version 0.4. Added features are:
    - QTC -> PNG (+- 30% faster than 0.4b2)
    - PNG -> QTC
    - CFC -> QTC (finally)
    - QTC padding
    - QTC trimming

    With QTC <-> PNG conversion now available from CFC, it seems the Compressonator is no longer needed!

    Further EDIT: All posts updated.

    Further EDIT: 0.41 added... There was a small bug in CFC compression in 0.4, it didn't always set PayloadSize correctly, which could create errors with padding/trimming.

    Update Jan 8, 2009
    CFC has been updated to version 0.3. It can now fully handle the RGB format as well. CFC compression has been slightly optimized. QTC and ATC headers are now completely written correctly.

    This now also allows for larger than original images :)

    Also lots of info in the first 6 posts has been updated to reflect these changes and add information.

    Update Jan 7, 2009
    Thanks to myself and D-MAN666, it seems the QTC format is now completely known!

    Also today brings CFC compression for (W)VGA devices, if chefs choose to implement it. The needed stuff is here.

    The CFC tool itself still needs an update (0.3 ?) to handle QTC/ATC_RGB conversion to ATC/ATC_RGB conversion (and back) and to decompress the CFC files. Donor headers won't be needed anymore then either in some cases (but they will remain handy in others!), and with that some parts of the first 5 posts will have to be rewritten as well (sigh...)

    Note that some other parts of the first few posts are marked with changes. Look for the red letters.
    - end of updates -

    As some of you may have seen, me, djboo, pcarvalho, "he who shall not be named" and several other enthousiasts have ported TouchFlo3D (to be specific, the version that came on my Raphael) to QVGA. A large part of this effort involved hacking into Manila/Mode9 and even OpenGL ES itself to get it operating decently, but after that, a lot of effort went into optimizing, which was largely done by scaling the images. While working on this, I encovered a lot of information and wrote quite a bit of code to 'get it done'. As always, a lot of it ultimately redundant, but we did pull it off! (barring some issues that are driver related).

    Before continuing, people need to be acknowledged for their parts in this. I could hardly have done it alone. A lot of these credits go out to people involved in the TF3D QVGA porting, but also drivers porting, they all had a hand in this information being 'discovered', and hence are mentioned here.

    - djboo Keeping all this stuff going. I looked at this stuff once when herg did an attempt, never really got involved, but because of him did get involved this time around. As he seems to be forgotten in the credits here and there, he's #1 in this thread!

    - pcarvalho A bit of competition that led to great stuff. In the end, our intended methods of porting complement eachother nicely - 'my' part got it going, but the QVGA port didn't really shine 'til we did the other things 'his way' as well.

    - "he who shall not be named" The anonymous HTC-CA hacker, about whom probably everybody knows who he is (it aint me ;)) Did some cracking work on this too.

    - The P3D Team A bunch of them did a lot of testing

    - D-MAN666 Mentioned last but certiainly not least! Cracked the file format first, and generally found out and published a hell of a lot of information. Also the author of Manila Editor.

    For all this, you will need and/or want the following:

    - "The Compressonator", image conversion/compression/viewer tool by ATI/AMD. You may need to sign up at the AMD website, but it is free of charge and I haven't received any spam from them yet. Update: The version of Compressonator on AMD's site is no longer able to do ATC. The correct version of Compressonator is attached to this post. Update: The Compressonator is now no longer strictly needed due to CFC being able to do the QTC en/decoding.

    - "Manila Editor", Manila image editor. You will not be using this for the actual good stuff, but you may be using this for testing things quickly, and you will definitely want to use it for finding the files you actually want to replace. Update: no longer needed, use the CFC GUI instead!

    - CFC, (attached), tool by yours truely to convert between QTC, ATC, CFC and PNG formats

    - Knowledge of the Windows command line - Though CFC now comes with a GUI as well, yay!

    - The files attached to this post. These are all the images from Manila (the version that came with my Raphael) converted to PNG by "The Compressonator". It's kind of a ***** to do, so if you want to save yourself some trouble, just see that post. VGA as well as (rescaled using Lanczos3) QVGA images are attached to that post. Update: this image packs need to be updated, will do some time

    CFC download
    Notice: you do not need the compressonator files to use CFC. They are just here in case you want to do things the old-school way :)

    ( < 0.60 : 3408 downloads )
    Textures, ATC, CTES, QTC, CFC (tech background)

    The imageon 3D chip in our devices support texture compression, and Manila (Mode9) uses this. The format used is a special format created by AMD/ATI for low size and lower power use on mobile devices, called ATC (ATI Texture Compression).

    There are three ATC formats:

    - ATC_RGB: 4 bits per pixel (4 bits RGB)
    - ATC_RGBA_EXPLICIT_ALPHA: 8 bits per pixel (4 bits RGB + 4 bits Alpha)
    - ATC_RGBA_INTERPOLATED_ALPHA: 8 bits per pixel (not sure on the format)

    Almost all images used in Manila are of the 'ATC_RBGA_EXPLICIT_ALPHA' variant, and this article will focus on these. ATC_RGB is also used for a small number of images, though I have not further investigated its format.

    The image data for these formats are stored in one of the following file formats:
    - ATC: The file format generally used by AMD/ATI
    - CTES: ATC related, some weirdness, see below. Seems to be forward compatible with ATC, but not backwards.
    - QTC: Qualcomm adapted version of ATC, used by Manila/Mode9

    The formats are very similar, though we will focus only on ATC/QTC, that's all we need.

    Image data (ATC_RGBA_EXPLICIT_ALPHA) - Updated January 12, 2009
    A lot of the original information comes from D-MAN666's posts here.
    I will skip over the headers (32 bytes), they are listed below for ATC and QTC specifically. This is about the actual image.

    The image is divided into blocks of 4x4 pixels. An 8x8 image would be stored like this: (A, B, C and D are 'pixel blocks')


    A 4x4 pixel block is 16 pixels and 16 bytes. So in effect, you can see it as 8 bits per pixel. An image is always stored using these 4x4 pixel blocks. A 5x5 images would thus use 4 blocks!

    bytes 0-7 are alpha values for each pixel, 4 bits per pixel (4 bits * 16 = 64 bits = 8 bytes) - this is not present for the ATC_RGB format. Scale these to the 0..255 range by multiplying each alpha value by 17.

    bytes 8-11 are color keys, there are two keys of 16 bits (2 bytes). The keys are stored like this:

    word 1: XRRRRRGG GGGBBBBB (1-bit method, 5-bit R, G, B)
    word 2: RRRRRGGG GGGBBBBB (5-bit R, 6-bit G, 5-bit B)

    Where X is the decoding method to use, there are two.

    bytes 12-15 are mixdown values, 2 bits per pixel (2 bits * 16 = 32 bits = 4 bytes). The per-pixel mixdown value, combined with the color keys mentioned above determine the actual color that is outputted. You must scale the scolor keys to the 0..255 range and apply a formula to them.

        if HasAlpha then begin // skip for ATC_RGB
          sIn.Read(dw, 4); // read dword
          for i := 0 to 7 do begin
            alpha[i] := (dw and $F) * 17;
            dw := dw shr 4;
          sIn.Read(dw, 4); // read dword
          for i := 8 to 15 do begin
            alpha[i] := (dw and $F) * 17;
            dw := dw shr 4;
          // alpha[0..15] now contain the scaled 4x4 pixel block alpha values
        sIn.Read(w, 2); // read a word, key1
        Method := (w shr 15);
        Keys[iR, 0] := ((w and $7C00) shr 10) * (255/31);
        Keys[iG, 0] := ((w and $03E0) shr 5) * (255/31);
        Keys[iB, 0] := (w and $001F) * (255/31);
        sIn.Read(w, 2); // read a word, key2
        Keys[iR, 1] := ((w and $F800) shr 11) * (255/31);
        Keys[iG, 1] := ((w and $07E0) shr 5) * (255/63);
        Keys[iB, 1] := (w and $001F) * (255/31);
        sIn.Read(mixdown, 4); // read a dword, mixdown values
        for i := 0 to 15 do begin
          pixels[i] := (mixdown and $3);
          mixdown := mixdown shr 2;
        // pixels[0..15] now contain the still-encoded 4x4 pixel block mixdown values

    When thinking about the color keys and mixdown values, think of the keys as a color-range start and end value. The mixdown values decide which value to pick inside the range. (for each R,G,B)

    For example, let's take a key1 of 10 and a key2 of 40 for Green. Then the decoded Green values would be:
        mixdown   00  01  02  03
        value     10  20  30  40

    This is only true, however, when the 'method' bit (X) is 0. Full decoding of both methods:

    for i := 0 to 15 do begin
      a := alpha[i];
      if (method = 0) then begin
        r := Round( Keys[iR, 0] + ((pixels[i] / 3) * (Keys[iR, 1] - Keys[iR, 0])) );
        g := Round( Keys[iG, 0] + ((pixels[i] / 3) * (Keys[iG, 1] - Keys[iG, 0])) );
        b := Round( Keys[iB, 0] + ((pixels[i] / 3) * (Keys[iB, 1] - Keys[iB, 0])) );
      end else begin
        case pixels[i] of
          0: begin
               r := 0;
               g := 0;
               b := 0;
          1: begin
               r := Round( Keys[iR, 0] - ((1/4) * Keys[iR, 1]) );
               g := Round( Keys[iG, 0] - ((1/4) * Keys[iG, 1]) );
               b := Round( Keys[iB, 0] - ((1/4) * Keys[iB, 1]) );
          2: begin
               r := Round( Keys[iR, 0] );
               g := Round( Keys[iG, 0] );
               b := Round( Keys[iB, 0] );
          3: begin
               r := Round( Keys[iR, 1] );
               g := Round( Keys[iG, 1] );
               b := Round( Keys[iB, 1] );

    Both methods have various way of formulating them. I thought the ways I have chosen here are clearest for how it works.

    Update Jan 7, 2009
    Image data (ATC_RGB)
    The image data here is exactly the same as ATC_RGBA_EXPLICIT_ALPHA, except that the alpha bits aren't includes. So, each 16-pixel block becomes 8 bytes instead of 16, as bytes 0-7 from ATC_RGBA_EXPLICIT_ALPHA are not there. This means 4 bits per pixel.
    - end of update -

    This image data seems to be the same across all formats - and it should be, as this data is sent directly to the 3D chip. You would not want to have to process it first.

    Let's first pick out CTES, as I have very little to say about it. It seems to be nearly the same as ATC and QTC, however, for some reason, "The Compressonator" will output CTES files we can use as ATC, but will not read our own Manila-based ATC's in CTES mode (only in ATC mode). What's up with that? I don't know. Perhaps one of you will figure it out.

    QTC header
        Magic: DWORD; // 0x31435451 : "QTC1"
        Magic2: DWORD; // always 1 ?
        Width: DWORD;
        Height: DWORD;
        Format: DWORD; // 0x14, 0x15
        Dummy1: DWORD; // formerly known as Unknown1, may be 0 - Jan 7, 2009
        PayloadSize: DWORD; // formerly known as Unknown2 - Jan 7, 2009
        Dummy3: DWORD; // formerly known as Unknown3, may be 0 - Jan 7, 2009

    The meaning of the unknowns has not been deciphered yet. Setting them to weird values does muck-up the decoding of the images, however, they do not seem to be actually sent to the 3D chip. Or perhaps I just have not found where and when!

    For format, 0x14 is used for ATC_RGB_EXPLICIT_ALPHA. The small number of images that use 0x15, I suspect, are ATC_RGB. Either way, they do not decode using the ATC_RGB_EXPLICIT_ALPHA method and I know ATC_RGB is used some places, so it would make some sense to make this assumption.

    Update Jan 7, 2009
    Unknown2 has been replaced by PayloadSize, thanks to myself, D-MAN666 and eidolen.

    The PayloadSize is the number of bytes after the header that contain content.

    For images of type 0x14 (ATC_RGB_EXPLICIT_ALPHA) this is: Width * Height, where both Width and Height are multiples of 4, due to how the format itself works, in other words: (RoundUp(Width / 4) * 4) * (RoundUp(Height / 4) * 4).

    For images of type 0x15 (ATC_RGB) this is half of type 0x14, because ATC_RGB uses 4 bits per pixel instead of 8. The multiples of 4 rule still stands, so the PayloadSize is: Round(((RoundUp(Width / 4) * 4) * (RoundUp(Height / 4) * 4)) / 2)

    Note that all Manila image files (at least the ones I have) are padded to be a multiple of 512 bytes in size. This is probably a speed optimization for when these files are cooked into a ROM.

    Dummy1 and Dummy3 (aptly renamed from Unknown1 and Unknown3) seem to be irrelevant. After we figured out how PayloadSize (Unknown2) was relevant, we tried blanking out Dummy1 and Dummy3 with 0's, and TF3D still works without a hitch. The original values do not seem to be related to the dimensions nor the payload size, and they are not sent to the graphics chip either.
    - end of update -

    Update November 6, 2009
    Manila 2.5 uses 4 additional file formats:

    0x01 - 8888 RGBA, 32bpp
    0x02 - 888 RGB, 24bpp (I have not encountered an actual image in this format, so processing may be faulty by CFC and CFC GUI)
    0x03 - 565 RGB, 16bpp
    0x05 - 4444 RGBA, 16bpp
    - end of update -

    ATC header
    Updated 08/Jan/2009
        Magic: DWORD; // 0xCCC40002
        Width: DWORD;
        Height: DWORD;
        Format: DWORD; // ATC_FORMAT, 0x01 for RGB, 0x02 for RGBA_EXPLICIT_ALPHA, 08/Jan/2009
        Magic3: DWORD; // 0x20 ... mucks up colors... not clear?
        Magic4: DWORD; // 0x01, 08/Jan/2009
        Magic5: DWORD; // 0x01, 08/Jan/2009
        FormatMagic: DWORD; // 0x8C92 for RGB, 0x8C93 for RGBA_EXPLICIT_ALPHA, 08/Jan/2009
    - end of updated content -
    CFC format + historic Compressonator editing

    CFC format
    I use the CFC format (yes, that's why the tool is called CFC) for the Manila QVGA port. It saves a lot of space and even seems to improve performance a bit. It uses standard gzip/zlib compression on the QTC image data (which compresses to about 20% on average) and hides the compressed data inside the QTC file itself. Decompression of this is over 5 MB/s on our devices, but images are only a few KB each. The proxy libgles_cm is what actually decodes this and sends the decompressed data to the 3D chip.

    CFC adjusts the QTC header to the proper values. Beware when doing this yourself that Mode9 uses these values internally as well). The image data ('payload') is replaced as follows:

        Magic: DWORD; // 0x31434643 : 'CFC1'
        Format: DWORD; // CFC_FORMAT...
        Width: DWORD;
        Height: DWORD;
        CompressedSize: DWORD;
        UnCompressedSize: DWORD;
        ... compressed data ...

    Format can be one of the following:
      CFC_FORMAT_COMPRESSED_QTC_RGB = 0x3002; // 0x15 from QTC - used since CFC 0.3
      CFC_FORMAT_COMPRESSED_RGBA = 0x3101; // April 20, 2009 - RGBA format - used since CFC 0.5
      CFC_FORMAT_COMPRESSED_RGB = 0x3102; // April 20, 2009 - RGB format - used since CFC 0.5

    Width and height are included for historic reasons, and it also opens up the possibility to do some weird mods. RGBA format is included for possibly allowing use of uncompressed textures for Manila support on non-HTC/Qualcomm/ATI/AMD based devices.

    Update April 20, 2009
    (A)RGB formats are gzip/zlib compressed just as QTC/CFC variants and require the CFC 0.50 runtime files. The uncompressed data is actually stored as (height x width x) BGR(A) (from x86 viewpoint) as this is the format the graphics chip can handle.

    Update November 6, 2009
    The following formats have been added to CFC. Note that the QTC header always says RGB or RGBA_EXPLICIT_ALPHA. This actually allows the new formats to be used on older Manila versions that do not directly support them, if you are using CFC 0.60 runtimes.

    // CFC 0.60 additional formats
      CFC_FORMAT_COMPRESSED_QTC_8_8_8_8 = 0x3003;
      CFC_FORMAT_COMPRESSED_QTC_X_8_8_8 = 0x3004;
      CFC_FORMAT_COMPRESSED_QTC_5_6_5 = 0x3005;
      CFC_FORMAT_COMPRESSED_QTC_4_4_4_4 = 0x3007;

    Notice: the text below in this post is here for historic reasons. It is no longer completely relevant

    Right, well I did tell you to get "The Compressonator" from AMD's site, right? You should have done this by now. You should also have the CFC tool attached to the first post of this thread.

    Say we want to manipulate an image from Manila. First we need to find out which image it is. Easiest way to find them is to use Manila Editor (also linked in first post), so you get the 'magic' filename.

    You may want to ask why we dont simply use Manila Editor for doing these things, simply put, the image quality from The Compressonator is better than the current version of Manila Editor. Also, we can do stuff in batch in The Compressonator.

    Manila to PNG (single)
    Now, say this image is 7d3f1247_manila (the globe on the internet page), we use the CFC tool to convert it to ATC format:
    cfc -qa 7d3f1247_manila 7d3f1247_manila.atc

    You can open this file in The Compressonator. It may look a bit weird, because alpha is not displayed. Right click on the image and select "Show RGBA", there, that looks better.

    Something you will not directly notice with the globe image, but you will with other images, is that the image is UPSIDE DOWN. You will need to flip the image over if you want to put it back into Manila. For some reason I haven't figured out yet, decoding goes upside down, but encoding needs to be the correct side up.

    Now we may wish to edit this file, so we save it as PNG: File -> Save Original.

    Open it in photoshop, flip it vertically, and save it.

    Manila to PNG (batch)
    We will need to use batch mode to convert back to Manila anyways, so lets just start using it for converting it to PNG as well (for some reason doing it non-batch doesn't work right).

    This will assume you have a bunch of .atc files in a directory. Batch converting Manila (QTC) files to ATC files is also possible with CFC:
    cfc -qaf orgfiles atcfiles
    Assuming you have your original Manila files in the folder 'orgfiles' and created a new empty directory 'atcfiles'.

    Open The Compressonator, and go to File -> Batch Compress (or press F4). Navigate to your folder containing all the ATC files, set the "Files of type" box to "ATC Textures (*.ATC...)". set the "Output File Format" to PNG and "Output Format" to "ARGB8888". Punch the "Compress All" button and wait a bit.

    Note that some files will not decompress correctly and crash The Compressonator. You will have to look at the crash dump to find out which file was the culprit and remove it from your batch directory. IIRC, there are about 10 files that have this issue, so be prepared for 10 minutes of infuriating work.

    You MUST set "Output directory" to "Use Input Directory", or you will not be able to decompress more than one file!

    In the end, you will have a large bunch of PNG files. Note that these PNG files are also available already done for you, see the link in the first post of this thread.

    Files known to crash The Compressonator: 08/Jan/2009

    PNG to Manila (single + batch)
    Even for single files, we are using the batch function, as there seems to be an issue with doing this in The Compressonator normally.

    The operation is exactly the same, but for single you select the file and press "Compress", and for many files you do not select a file and press "Compress All".

    Note that as previously mentioned, decoding ATC to PNG files results in the PNG's being upside down, but to make ATC files from PNG files the correct side needs to be up!

    This time around we set "Files of type" to "PNG Textures" (duh) and "Output File Format" to "CTES Textures". As previously mentioned CTES is compatible with ATC, but ATC is not compatible with CTES. You won't notice this though.

    The magic is the "Output Format" setting. Set it to "CTES Texture Compression" and hit the "Options" button. In the "Compress Texture" dialog that pops up, select "ATC RGBA Explicit Alpha (8 bits per pixel)", or "ATC RGB (4 bits per pixel)", depending on which format you want, hit OK, and you're there. Hit "Compress" or "Compress All", and wait 'til it's done.

    You MUST set "Output directory" to "Use Input Directory", or you will not be able to decompress more than one file!

    Now we want to convert these CTES/ATC files back to Manila files, and for this, again, we use the CFC tool:
    cfc -aqf atcfolder qtcfolder orgfolder

    You can also use -aq instead of -aqf for a single file. Note that the CFC tool does NOT change filenames, so you have some renaming to do.

    Update 08/Jan/2009
    With CFC 0.3, donor headers are not longer necessary, and have become an optional parameter.
    - end of update -

    Rescaling to QVGA
    Converting Manila images to QVGA is pretty simple. Just use the techniques described above.

    What you want to do is scale ONLY images 32x32 and larger, and you will want to divide the width and height exactly by two. That's all there is to it.

    If you have a bunch of PNG files you want to scale, the CFC tool can even do this for you, including the needed vertical flip:

    cfc -nsf vgapngfolder qvgapngfolder

    This will rescale using the Lanczos3 algorithm.

    CFC Compression
    The QVGA port supports the CFC format as mentioned above. This can save a lot of space and is the preferred way of using textures for the QVGA port.

    To compress your QVGA QTC files to CFC:
    cfc -cf qvgaqtcfolder qvgacfcfolder