[Scummvm-devel] Tools have GUI now
Max Horn
max at quendi.de
Wed Dec 30 14:16:44 CET 2009
Am 29.12.2009 um 23:52 schrieb Eugene Sandulenko:
> Hi team,
>
> I just replaced the tools trunk with gsoc2009-gui branch. All tools
> work not worse than before, though several minor ones (those of
> developers' interest) haven't been tested yet. Those could be fixed
> anytime.
>
> Anyway, the work on the tools is not yet finished, and particularly
> there are several areas of interest:
>
> * GUI images. Currently they (a) bad quality, see at those JPEG
> compression artifacts, and (b) live as separate files at a weird
> places
> * GUI improvement. Current GUI looks not tha nice, at least on my
> computer. The buttons are not centered, labels stick to other
> widgets, overlap, etc. Eek.
> * More configure coverage. What is remaining is GTK+ autodetection.
> * Make the tools more automated, that is, process multiple files if
> they belong to same game. There are many examples like FT, DIG,
> COMI, BS1&2, Feeble etc.
> * More stuff found in TODO file, which would better be moved to Wiki.
There were more things Joost and me requested from Remere but that
never materialized; would be nice to collect these all in a TODO (e.g.
in the Wiki). Foremost in my mind is that the audio encoding API is
horrible (although Remere somehow didn't seem to agree with me on that
regard...).
I think we should merge Common::Stream into the tools code base, then
add a new audio encoding API which encodes the data from a given
(Seekable)ReadStream (or maybe even an AudioStream -- this way, the
same encoder can support encoding WAVE, VOC and raw data), writing the
result into a WriteStream. We then could gradually convert all tools
to use this new API, and get rid of the old one eventually.
This way, we can get rid of almost all the nasty "TEMPFILE" stuff.
Which is not just ugly and annoying to use, but also causes a major
slow down in general. Just to illustrate this by an example: for
encoding vorbis data with libvorbis, we currently read data from a big
file, then write it into a small file, then read that into memory,
then compress it, then write it into a small output file, then read
that in, then write that into a big output file... yay, way to go).
Note that it would still be possible to use e.g. lame to encode data
-- we'd just move the tempfile stuff from above *inside* the encoding
functions for this case. In particular, it would be possible to
implement the new API using the old API initially, to get a quick
prototype done.
However, since this would certainly risk introducing regressions, we
probably shouldn't do this on trunk right away. A branch might be the
way to go... in fact, I'd love if the tools SVN module was a git
repos, then I'd already be working on this (I just don't like using
SVN branches for such work very much, merging is so annoying)... ;-)
Bye,
Max
More information about the Scummvm-devel
mailing list