[ scummvm-Patches-1611503 ] DXA: Improved encoder (filesize and speed)

SourceForge.net noreply at sourceforge.net
Fri Dec 8 14:14:25 CET 2006


Patches item #1611503, was opened at 2006-12-08 13:14
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=418822&aid=1611503&group_id=37116

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Benjamin Haisch (john_doe)
Assigned to: Nobody/Anonymous (nobody)
Summary: DXA: Improved encoder (filesize and speed)

Initial Comment:
Hi,

Long promised to Kirben I finally finished the new and improved version of the DXA encoder.

The changes include:
- Frame type 12 was removed and replaced by type 13
- The new type produces files a lot smaller (depending on the input, of course)
- Encoding should be faster (if only a bit)
- The height scaling from Smacker animations (interlacing and line doubling) is now taken into account, too

The DXA files of the current SVN encoder can still be used in ScummVM as long as the code for type 12 isn't removed for some reason.

The DXA files from Feeble Files are now about 1.0 GB big, the Smacker animations 1.4 GB. I also compressed the videos from Broken Sword 2, the Smacker files are 130 MB big, the DXA files 96 MB. (Note that these do not include the audio files.)

Attached is the patch for the current SVN version, a win32 exe of the encoder and source/exe for the standalone DXA player (needs SDL and doesn't play files produced by the "old" encoder).

I haven't added the new code to the ScummVM DXA player yet as I wanted to hear what you think first.

Now for some technical details:
The new type 13 uses the basic ideas from type 12 but adds two new block types:

1. Blocks with 4 colors or less now use a bitmap for each pixel and store the pixel data. E.g. if a block has only two colors, it stores a 16-bit bitmap and two bytes for each actual pixel. Now bit 0 in the map means 'use pixel 1' while bit 1 means 'use pixel 2'.

2. Blocks are now also divided into 4 subblocks, each 2x2 pixels. For each of the subblocks the same methods as for a 4x4 block are tried and the smallest one is chosen.

Also the data layout has been modified to improve compression with zlib. Before the data has been stored sequentially (e.g. "block type, block data, block type" etc.) which hurt compression. Now each type of data is stored in its own "section" which improves compression a lot.

Encoding should also be faster now since only so much data is compressed until compression wouldn't gain anything. This is simply done by limiting the available output size to zlib's compress2 function to the size of the previously compressed data (in the order type 13->xor->full).

The CPU requirements shouldn't be drastically different.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=418822&aid=1611503&group_id=37116




More information about the Scummvm-tracker mailing list