[Scummvm-devel] Help with tool details

[Remere]

On Tue, Aug 4, 2009 at 5:28 PM, Max Horn<max at quendi.de> wrote:
> 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.
>
Indeed it would, and I'm thinking of improving the manual page on the
tool with inforamition on how to use the GUI instead (it's very thin
(and soon to be outdated) now), although I can't really supply all
details I'd like since I don't know them :(.
>
>> 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?
>
I'll try that, thank you.

> 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.
>

The .smk file is the logical choice then, especially if it's reduced
to the only required argument. Changing the behaviour is out of scope
for now.

[...]

>
>> 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.
>
That would be possible, and very nice to be honest, but it would be a
massive undertaking to figure out all input files, since many tools
works on multiple games. For some (like compress_queen) it would be
trivial however.

> 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.
>
I changed the behvaiour of compress_touche to accept an input file,
but actually ignore it and probe the directory it was in for a few
select files instead. This could probably be applied to many of other
tools.
>
>> 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*).
>
I'll change the default to Vorbis instead then.
> But Ogg Vorbis generally seems to require some more resources for
> playback, so not all our ports support it well.
>
This was my understanding as well, and even if it ends up wrong,
changing this in the future would be trivial .
>
> Cheers,
> Max
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
>