[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