The Feeble Files

BassiB · Post by **BassiB** » Sun May 28, 2006 10:10 am

when i run the batch-file after a time my computer hangs up? why?
while flac is converting ...

Xqwtzs · Post by **Xqwtzs** » Sun May 28, 2006 11:50 am

ok i did it correctly and the programme works, but it only makes datas called tempfile i hope i do it right

jaycee · Post by **jaycee** » Tue May 30, 2006 11:22 pm

Hi

Well, I'm the guy who did most of the SimonII and Feeble porting work to Mac & Amiga (actually I can't remember that we did an Amiga version of Feeble, but we must have

I came here after a friend mentioned he was trying to run Feeble in ScummVM. I was quite surprised you had managed it because of the Smacker files, which we had to remove ourselves as we could not afford to licence Smacker. I was very surprised you had resorted to using the DXA format!

The DXA format was something that was written pretty quick as our deadline was getting tight. Personally, I wouldn't have recommended you use this format - FLC with the audio in a seperate file, or even the Quake II .cin format would have been a better choice.

I wish I could help you guys out as I have clean up to date source code for both SimonII and Feeble, with all of the assembly language ported to C by myself. Sadly, there is no way my employer would allow this to be released I think. I could ask, but the answer will probably be no.

I'm happy to answer some queries about this game, but it was quite a while ago that I did this

-----
Peter Mulholland

Post by **sev** » Wed May 31, 2006 12:34 am

jaycee wrote:Well, I'm the guy who did most of the SimonII and Feeble porting work to Mac & Amiga (actually I can't remember that we did an Amiga version of Feeble, but we must have

Wow, it's always amazing and amuzing to see original developers stopping by our project. Welcome.

jaycee wrote: The DXA format was something that was written pretty quick as our deadline was getting tight. Personally, I wouldn't have recommended you use this format - FLC with the audio in a seperate file, or even the Quake II .cin format would have been a better choice.

You know, I investigated several open 8bit lossless formats and even tried to extend DXA player with some ideas. Our main goal was size. Let me quote myself (sizes are given for Broken Sword videos and compared to current bad quality MPEG2 files which we offer for free download):

Code: Select all

for comparison. MNG results&#58;
> advmng -S 64 -3
> BS1&#58; 67MB video
> BS2&#58; 136MB video
Taking into account insane complexity and nearly indefinite time to
encode MNG with above options makes DXA an absolute winner.

Ratios&#58;
against Low Q MPEG2&#58;
  ZMBV       MNG    DXA
BS1&#58; 2.9x    2.1x   2.25x
BS2&#58; 6x      5x     5.4x

against High Q MPEG2&#58;
  ZMBV       MNG    DXA
BS1&#58; 1.4x    1x     1x
BS2&#58; 2.3x    1.9x   2.1x

Resulting archives with OGG audio&#58;
BS1&#58; 73MB
BS2&#58; 147MB

So you may see, even super-advanced MNG compressor which took about 12 hours to encode those cutscenes on my Athlon64 3000+ did not give a big gain. ZMBV is format used by Dosbox appeared to be considerably worse, though it tries to implement some motion compensation scheme. Neither was a good alternative to DXA. Only ptoblem which we are going to resolve is that huge audio chunk at file beginning. May be we will compress it with some modern lossy coder like Ogg Vorbis or MP3.

jaycee wrote: I wish I could help you guys out as I have clean up to date source code for both SimonII and Feeble, with all of the assembly language ported to C by myself. Sadly, there is no way my employer would allow this to be released I think. I could ask, but the answer will probably be no.

We ourselves obtained Feeble and Simon source code from AdventureSoft and this helped us to start work on Feeble. Kirben did an enormous work of extending our Simon1/2 engine to support this game and as a result the engine is practically complete. There are left only several (i.e. three) minor graphics glitches which will eventually be eliminated as well. You may read about current engine status at this page.

jaycee wrote: I'm happy to answer some queries about this game, but it was quite a while ago that I did this

What would be of interest is some historical information about the game, maybe some interesting experiences with it which you are allowed to share. And of course, Kirben may have some questions as well.

Eugene

john_doe · Post by **john_doe** » Wed May 31, 2006 8:33 am

sev wrote: You know, I investigated several open 8bit lossless formats and even tried to extend DXA player with some ideas.
Our main goal was size. Let me quote myself (sizes are given for Broken Sword videos and compared to current bad quality MPEG2 files which we offer for free download):

I also tried to improve compression in the Dxa encoder.
I implemented some kind of diff-compression, it's basically LZSS that uses the previous frame as history. It uses all three methods (pure zlib, zlib with xoring, and the new method+zlib) for each frame and uses the smallest result. In my test files it's better than "pure" Dxa but of course takes longer to compress, but the files are smaller by some MB. The musosp file was around 3 MB smaller with this.

Tech-wise, it creates a suffix array of the previous frame, and uses binary search over the suffix array to find the longest matching string from the current frame in the previous frame. If the match has a certain length, it writes the offset/length to the output, otherwise just the pixel at the current position. It uses simple variable-length codes to store the offset and length. Also, for speed, the minimum and maximum match length can be set, which compresses faster but not so well. The mode (length/offset or raw byte) is stored in bit in a flag-byte. After all this, the result is compressed again with zlib since it doesn't compress the raw data itself.

Also, for the decoder, this is simple to implement as it's just copying from the previous frame.

I also tried to implement something Smacker-like (just conceptionally, of course) that splits up the frame in 4x4 blocks and tries several methods on each block (skip, solid color, rle, delta) but that was getting rather messy and the decoder would be more complex. Also, in my first tests, compression wasn't much better than the other LZ-like method.

So that's it

Sordid · Post by **Sordid** » Wed May 31, 2006 10:41 pm

The newest SVN works with compressed dxa files but the sound is very bad compared to the uncompressed. Is this a problem with scumm or is compression that bad?

Post by **eriktorbjorn** » Wed May 31, 2006 11:17 pm

Sordid wrote:The newest SVN works with compressed dxa files but the sound is very bad compared to the uncompressed. Is this a problem with scumm or is compression that bad?

I don't know. I noted in another thread that ADPCM-compressing the sound made it sound much worse for me, and that this problem seemed to happen in the compression, not the decoding. But from what I understand we use a library for doing that conversion, and I had the same problem when converting that WAV file with SoX instead, so the encoding should be well-tested.

Noize reported that he had no such problem, though. But he was using the 4CD version. Maybe the combination of more aggressive Smacker compression and ADPCM is what's causing the problem? They are, presumably, both lossy compression algorithms. (Lossy meaning that they throw away information so that the exact original signal cannot be re-created. It's not, generally speaking, a bad thing for sound compression.)

Sordid · Post by **Sordid** » Thu Jun 01, 2006 2:08 pm

Hm, I'm using the 4 disc version, too.

Is there a dxa player so I could test the converted video files without scumm?

JamesWoodcock · Post by **JamesWoodcock** » Thu Jun 01, 2006 3:25 pm

I have spent all yesterday converting the videos, and they work fine. The sound is a bit crackly, but easy to put up with. Great stuff from the ScummVM team yet again.

noize · Post by **noize** » Sun Jun 04, 2006 8:24 pm

I tried the new encoder today (latest build), besides icetrench there where about ten files uncorrectly encoded with the older encoder.

Found one bug in the encoder, tell me if I need to report this.
When encoding "Get Car", lame fails with: excess arg Get.
Input for lame by encode_dxa seems to be Get Car instead of "Get Car".

Post by **sev** » Sun Jun 04, 2006 8:56 pm

noize wrote:Found one bug in the encoder, tell me if I need to report this.
When encoding "Get Car", lame fails with: excess arg Get.
Input for lame by encode_dxa seems to be Get Car instead of "Get Car".

Yes, please. This is important, especially before 0.9.0.

Eugene

Raziel · Post by **Raziel** » Sun Jun 04, 2006 10:46 pm

jaycee wrote:Hi

Well, I'm the guy who did most of the SimonII and Feeble porting work to Mac & Amiga (actually I can't remember that we did an Amiga version of Feeble, but we must have

<snip>

-----
Peter Mulholland

Hi Peter, nice to see you around here...

I believe the Amiga version of Feeble Files was done by Paul Burkey http://www.shoecake.com/projects.html
He also released patches for the Amiga version of Simon II, which (i think) he also did

Take care

UruBoo · Post by **UruBoo** » Tue Jun 06, 2006 3:32 am

Hi,

I see that there is a SCUMM version (0.9.0) that actualy play The Feeble Files but I tried it with no luck (keep getting dxa files errors). Since I'm not a tech that understands those .dxa and .smk files, will it be a SCUMM version to play Feeble Files for those that don't know how to mess with converting files? I mean, the Windows Feeble Files, that comes with 2 CDs?

Thanks,

UruBoo

Kirben · Post by **Kirben** » Tue Jun 06, 2006 3:37 am

UruBoo wrote:I see that there is a SCUMM version (0.9.0) that actualy play The Feeble Files but I tried it with no luck (keep getting dxa files errors). Since I'm not a tech that understands those .dxa and .smk files, will it be a SCUMM version to play Feeble Files for those that don't know how to mess with converting files? I mean, the Windows Feeble Files, that comes with 2 CDs?

You need to re-encode the Smacker files included with the Feeble Files, using encode_dxa. There is a short guide in the readme included with tools.

encode_dxa is included with the Windows snapshots of ScummVM SVN. If you are on other platform, you will need to check out the tools module of SVN and compile encode_dxa yourself.

Vinterstum · Post by **Vinterstum** » Tue Jun 06, 2006 4:45 am

Kirben wrote: encode_dxa is included with the Windows snapshots of ScummVM SVN. If you are on other platform, you will need to check out the tools module of SVN and compile encode_dxa yourself.

I just put up a Universal Binary snapshot of the tools at the same spot the Mac OS X SVN snapshot are at.