On Thu, 29 Oct 2009 at 14:17:04 +0100, Bruno Kleinert wrote: > Am Samstag, den 24.10.2009, 15:28 +0100 schrieb Simon McVittie: > > Unfortunately, it appears that this is correct: > > > > * openarena-data contains .pk3 files (zip files) > > * of those, pak0.pk3 contains .qvm files (the "cgame", "game" and "ui" > > modules), which are bytecode for a VM built in to the Quake 3 engine > > * the .qvm files are compiled from C in http://www.openarena.ws/svn/source/ > > using a non-free compiler (lcc) > Yes, 100% absolutely correct! :)
The source code for these *might* be in openarena-modSDK-0.8.1, as found in http://www.openarena.ws/svn/source/081/openarena-modSDK-0.8.1.tar.bz2 (yes, that's a tarball checked-in to Subversion...) This tarball is not suitable for Debian as-is (it contains lcc, which is non-free) but it's a start. Running "make" in this tree produces (at least for me) files with these SHA1sums: s...@reptile(sid)% ( cd build/release-linux-i386 && sha1sum -b */vm/*.qvm ) 58b414ebf18e39a770f030164299c7fe822eb6bb *baseq3/vm/cgame.qvm 39f937662e927183d82c71d1063347d1bfab291d *baseq3/vm/qagame.qvm f3d6968f008d5c9125379292e4fa68cdc23dcaf3 *baseq3/vm/ui.qvm 66392fcc7de452e38c8004b3c887ba070185becf *missionpack/vm/cgame.qvm 6e91088de0757ddb6d7e50b0c54e2ec95993641d *missionpack/vm/qagame.qvm dce23cee6df160453d1a6ce31651539ebd35aef9 *missionpack/vm/ui.qvm */qagame.qvm are not byte-identical to the versions in OA svn, but the others are: s...@reptile% sha1sum -b vm/* missionpack/vm/* ~/src/debian/bugsquash/oa 58b414ebf18e39a770f030164299c7fe822eb6bb *vm/cgame.qvm 0e000ca4e1e5591c82b08494e2839589e1e2a98f *vm/qagame.qvm f3d6968f008d5c9125379292e4fa68cdc23dcaf3 *vm/ui.qvm 66392fcc7de452e38c8004b3c887ba070185becf *missionpack/vm/cgame.qvm 24cb18f50875a5f22420bd2408011d833e48ff44 *missionpack/vm/qagame.qvm dce23cee6df160453d1a6ce31651539ebd35aef9 *missionpack/vm/ui.qvm I'll investigate this further. If I can hack up the qagame sources to produce a QVM identical to upstream's, or determine that the changes are insignificant, then we can consider this to be suitable source code to compile native shared objects. One caveat is that when I tried rsync'ing the "mod SDK" into the openarena source package (which is upstream's "engine" tarball), I got differences in some files that are common to the engine and the QVMs (the "mod SDK" and the engine were both, independently, forked from ioQuake3). This is also something that'll need further analysis. So, I now have two directions in which to investigate: Engine ====== * Does my patch work? (i.e. add debug printfs) * Write a perl script as I described in my earlier mail, to strip the QVMs out of the PK3 and (as a side-effect) produce the file containing faked checksums Game logic ========== * How do we transform the mod SDK source into something from which the "canonical" upstream qagame.qvm can be compiled? If we can't, does it matter? * Is it safe to use the mod SDK source in a subdirectory to build modules for the engine (duplicating common files, to avoid having to reconcile the differences), or would it be better to reconcile them, or is it in fact *necessary* (for API/ABI compatibility) to reconcile them? * Does it work with gcc on miscellaneous architectures? (I have a powerpc here, and since I run i386 with an amd64 kernel, I can hopefully make an amd64 chroot to test in) In addition, someone needs to educate upstream about the correct use of svn (tags, not checking in derived files, having a reproducible build process, and similar considerations), and about the fact that what distributions really care about is the source release, not the binary release. I'm not going to do that, because I'd just end up flaming and alienating them... Regards from the Cambridge BSP, Simon
signature.asc
Description: Digital signature
