RFS: 0ad

[Philip Taylor]

On Tue, Apr 5, 2011 at 6:58 AM, Paul Wise <pabs at debian.org> wrote:
> On Mon, Apr 4, 2011 at 10:55 PM, Philip Taylor <excors at gmail.com> wrote:
>
>> It can be created and parsed and rendered (but not modified) by the
>> game engine. It used to be exported by a custom 3ds Max plugin but we
>> no longer use that (we export to Collada since ~4 years ago). It's not
>> designed to be a modifiable format, but it's not theoretically
>> impossible to modify - there's a Python script at
>> http://trac.wildfiregames.com/ticket/461 to convert .pmd back into
>> editable Collada format so it can be imported into e.g. Blender,
>> though that currently only works for static meshes and not
>> skeletally-animated ones.
>
> I would suggest the the pmd files be removed from the source package
> and replaced with the _source code_ (the form for modifying) for the
> models and that the build scripts should convert them to the form used
> by the engine.

For new models and animations, that's effectively what we do (the
engine loads the Collada and converts to .pmd at run-time).

For old ones, we don't have the modifiable form (except as 3ds Max
files scattered around various people's disks and FTP sites - the art
process wasn't well organised).

For old static meshes, we could use that Python script to convert them
into modifiable Collada files and replace the .pmd files with those,
and I'd be happy to do that.

For old animated meshes, we'd need to extend that script to convert
them successfully into Collada, which might be significant work (or
might be impossible - I'm not quite sure). It'd be nice to do that,
but it probably won't happen any time soon since there's
higher-priority problems in this area.

For binaries/data/tests/collada/sphere.pmd (the file that was
originally mentioned), its purpose is to test the Collada-to-PMD
conversion code - we can't replace it with a Collada file and then
convert it automatically because that would defeat the point of the
test.

>> DejaVuSans.ttf, DejaVuSansMono.ttf, texgyrepagella-regular.otf,
>> texgyrepagella-bold.otf are unmodified originals.
>
> Best remove these and package the ones that aren't yet in Debian separately.

We don't use those files at build-time or at run-time (they're only
used at development-time), so there would be no point packaging them
for users. I can exclude those files from the distribution script
since that seems the easiest solution.

>> ConvertedPagella-Regular.ttf, ConvertedPagella-Bold.ttf are
>> non-original and derived from texgyrepagella-*.
>
> What modifications were done for this? Would it be possible to merge
> those upstream?

No modifications except what FontForge does automatically when saving,
which happens to make FreeType render them to bitmaps in a way that
looks prettier. But I can exclude those files so it won't matter here
anyway.

>> Changed the tarball generation script in
>> http://trac.wildfiregames.com/changeset/9160
>
> Why are you manually creating the tarball, doesn't your build system
> have the equivalent of `make distcheck` from automake?

It doesn't. (The build system is certainly far from ideal, but it sort
of works, and I don't have much experience with anything else, so I
haven't cared enough to learn and implement any replacement myself,
and nobody else has tried replacing it either. We'd probably need a
script anyway to generate the Windows installer via Wine and it seems
easy enough to do the tarballs the same way.)

-- 
Philip Taylor
excors at gmail.com