[Scummvm-devel] Help with tool details

Max Horn max at quendi.de
Tue Aug 4 17:28:28 CEST 2009


Hi Remere,

good to see this email of yours, I hope you'll get all the info you  
need. In the meantime, I'll make some remarks.

Am 02.08.2009 um 03:37 schrieb Remere:

> Hello everyone,
>
> As the tools GUI is almost finished by now, I'd like some help with
> the finishing touches.
> A very important part of the new tools is the automatic detection of
> input files, which largely depends on the extension, as such I would
> like everyone who knows what input files are expected for the
> following tools:

Good question. And based on the results (and on what you already  
know), it would be *excellent* if you improved the tools README resp.  
the output of "--help" for the relevant tools, to also make this  
information crystal clear. Both users and devs will be grateful for  
that.


> compress_agos, [...], extract_agos

Kirben should be able to give details; but in the meantime, there are  
several AGOS demos on <http://www.scummvm.org/demos/>, in particular  
of Simon 1 & 2 and Feeble Files. Maybe you can take a look at them to  
figure out the filenames and for testing the extractor & compressor?

For encode_dxa, this takes a bunch of PNG files, a WAV file and a SMK  
file, e.g. intro.smk', 'intro.wav' and 'intro*.png' (this is also  
described in the tools README). The output is called 'intro.dxa' and  
'intro.flac/mp3/ogg'. Actually, considering that we now have a Smacker  
decompressor in ScummVM, it should be possible to rewrite this tool to  
require *only* 'intro.smk' as input. Maybe somebody is interested in  
this? Alternatively, "somebody" should add this to our TODO.

I can't really comment on extract_parallaction, but I hope peres will  
eventually! For gob & kyra & scumm_mac you already got replies.

[...]

> compress_touche and compress_tucker also requires special attention,
> both of these tools at the moment expect input *directories* unlike
> all the other tools. If there is any way to take a single input file
> instead. A patch or information on how to do that (most likely just
> provide the filename), would help greatly. Both these two tools cannot
> be run from the GUI at the moment as there is no way to select a
> directory in a file picker ctrl. If there is an alternate solution to
> this problem I'd like to hear it (note: presenting two picker
> controls, one for directories and one for files is not a really a
> solution in my eyes as it confuses the user, especially since all but
> two tools expects files).

Actually, from my perspective it would be a lot nicer for the user if  
all tools would ask you to pick an input *directory* instead of input  
file(s). Much easier this way: I just point it at the directory my  
game is in, and click "go". And I'd say for most (all?!) games this is  
possible.

Well, actually, there is on caveat: Users seem to sometimes be  
confused if they have to select a directory. We had "bug reports"  
because of this on our "Add game" dialog: People would somehow think  
they *must* select a certain file and then get confused when they  
cannot do that in the "Add game" dialog.
To avoid that, one could use a file picker, and ask the user to select  
any file in the source directory.



> Finally, the tools present a selection of target platform, which
> affects the default audio settings, right now it only sets audio
> format to vorbis for iPhone/NDS/PPC. But if anyone knows what the
> optimal settings would be for a target platform (to acheive maximum
> performance). That information would be greatly appreciated, also, it
> might make sense to make Vorbis the default for all platforms? MP3 was
> the default prior to my intervention, and I haven't changed it, but
> that format doesn't have much over Vorbis does it?

I'd be fine with using Vorbis as default on desktop platforms. It has  
the advantage of not being license encumbered; in particular, we can  
link an Ogg Vorbis encoder directly into the tools, and distribute the  
binary; for MP3, we cannot do that without having to pay license fees.  
Also, many Linux distros do not ship binaries for MP3 encoders (and  
some don't even ship binaries containing MP3 *decoders*).

But Ogg Vorbis generally seems to require some more resources for  
playback, so not all our ports support it well.


Cheers,
Max




More information about the Scummvm-devel mailing list