e.
> Also the ./public/art/LICENSE.txt file indicates that all the
> materials from CGTextures are missing their source form.
For most of the textures we can't usefully distribute the original
source version since it's either lost or in a format like .psd; for
the ones using CGTextures materials we couldn't distribute them in any
case since CGTextures doesn't allow distribution of their work in
unmodified form (but we got explicit permission to distribute the
derived bitmap textures as CC-BY-SA).
> I find it completely bizarre that they are using an Excel spreadsheet
> to store techtree info. Does the game really require a Excel file
> reading code??
That file is just documentation. Not sure what it's doing in SVN there
- should delete it some time (probably when implementing techtrees and
verifying that it's obsolete).
> There are two RAR files.
Those aren't used and should be deleted some time (after verifying
they don't contain anything useful).
> Those xmb files look like binary versions of the corresponding xml
> files.
Yep, via step 6.
> There are some weird binary formats. One of them contained a string:
> "God Knows", perhaps that should be replaced with "God Knows WTF these
> files are and how to modify them" ;)
I think those would be the .pmd/.psa files, which are generated either
by step 6 or step 3 (exported directly to the custom binary formats).
> I wonder about the DDS files. They can be opened in GIMP with gimp-dds
> but their names seem to indicate that there are TGA files that are the
> source form of them.
Indeed, they're from step 6 (conversions of the texture files in SVN
that are .tga or .png or .dds).
> IMO the DDS files should be created at
> runtime/build time from their source TGA files, or the game should
> simply switch to using the TGA files.
We need mipmapping, which is only really supported by DDS. Also we
want S3TC compression (saves >75% video memory) which needs DDS.
Creating the compressed DDS at runtime can take a couple of seconds
per texture - we do that when running the game from an SVN checkout,
but that's not good for normal players. So we do do it at build time
(but in the build step before creating the tarball).
> There are a bunch of pre-encoded Ogg files. I don't know what is the
> source but Ogg definitely is not it.
I think most audio files we only have in .ogg format, but we're
gradually replacing them and trying to be more organised with storing
.wav versions of the replacements. But storing .wav in the main SVN
repository sounds non-ideal (the music alone will add a few hundred
megabytes to the download), so we're currently sticking them in a
separate parallel SVN repository and ought to find a better way to
handle them eventually.
--
Philip Taylor
exc...@gmail.com
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
