Thanks for the comments! The goal is to primarily support 0AD, so I'll do whatever is needed for the library to work with this project. If anyone sees this that is interested in helping, please contact me or just grab the code and start hacking. These are great guidelines for now, I'll comment briefly: * We don't need 64-bit Windows support. (We use a load of other libraries and it'd be a pain to recompile them all for 64-bit, and 32-bit is perfectly good). Sure thing. * Windows binaries should be compilable with MSVC (not e.g. MinGW), probably 2005 (for compatibility when people compile the game with that version). Currently we use the .vcproj files, I think; I don't know how it'd work with an autotools-based build. autotools and MSVC don't mix, so I'll use the vcproj your currently using as a starting point - will probably use those for binary building. * On Linux / OS X we need to be able to optionally build from a bundled copy instead of an installed system copy, because it'll be years before fcolladaCE is available on all Linux distros. That should work without needing to be root and installing things in /usr etc. We can point at whatever relative paths are needed. You're right about using a bundled copy at first. (Just for information regarding timing: It should take about a month after fcolladaCE is released to get into Debian since I have upload rights and it will appear in the next release of Ubuntu after I upload to Debian). Right now you can actually just drop the code (and updated makefile) from github into 0AD and it will build during the update-workspaces.sh, so it looks like this requirement can be met. Still needs more testing before shipping with 0AD, but it's good to know that it can work. * Currently we compile separate Debug and Release versions of FCollada (to different filenames), and use the appropriate one when the game is compiled in Debug or Release mode. I'm unsure whether that's necessary - we don't really need it for debugging, but I don't know if the library has problems when it's compiled in a different mode than the game. (Maybe on Windows, where debug vs non-debug CRT DLLs cause conflicts?) I'm still studying the code to see the differences between the two. For now it looks like the unixes can get by with just a release version, but you may be right about Windows and mixing debug/non-debug dlls. * For testing FCollada in the game, running binaries/system/test (or test_dbg) after building the game will test it a little. To use it in the actual game, first delete ~/.cache/0ad/ then launch the game. (We only convert a model once using FCollada, and then cache the result, because conversion is slow.) Thanks for the pointers, that's what I was looking for. I'll post updates and welcome any help if anyone has experience with or interest in this (showard@debian.org), or just grab the code and hack away.
