[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#646377: d0_blind_id version



Hi,

as for the version of d0_blind_id: use the latest tagged version in the v1.0 form. The Xonotic-specific tags should not be needed there, as the only differences since xonotic-v0.7.0 affect only the standalone key generator tool which does not come with Xonotic anyway (it is the file crypto-keygen-standalone.c that comes with DarkPlaces).

And in fact, the xonotic-v0.8.0 tag and the v1.0 tag in the repository are equivalent anyway.

As for building the pk3 files from source: I highly advise against that, as the build process is very lengthy and involves non-free tools (which you can - at a quality loss - replace by free ones):

- Textures are stored in tga form in git, but converted to S3TC using AMD Compressonator. An alternate free Debian-packaged tool would be the s2tc compressor, which can be told to use the S3TC libtxc_dxtn instead if you want. This will however mean a quality loss. Logic for which files should be compressed at all is in xonotic.git misc/tools/cached_converter.sh and misc/tools/all/release.subr (our master build script). The cached_converter already can be told to use the s2tc binary, and you can use e.g. LD_PRELOAD to force it to use the S3TC libtxc_dxtn. This whole process, from zero, will take about 6 hours.

Please, absolutely, do NOT ship a version of Xonotic by default that doesn't use compressed textures, as this means a HUGE slowdown in startup/loading times which users find really annoying!

- QuakeC code is built using gmqcc. You can mostly assume that using a recent gmqcc build should do, as long as the code compiles. If you're paranoid, use our integration test "./all serverbench" from our repository, which runs a pre-defined botmatch with fixed random number generator and no timing influence; to verify it, it outputs a checksum of the server log. This should stay the same across gmqcc changes.

- Maps are compiled with q3map2. Command-line flags for it are stored in two places:

misc/tools/xonotic-map-compiler contains the "default" flags we use when nothing else is specified. You can adapt this to your build process, use it as is, or just copy the default flags from there.

data/xonotic-maps.pk3dir/maps/mapname.map.options contains the non-default options. Essentially, any line starting with - is used as command line options passed to misc/tools/xonotic-map-compiler.

Also, misc/tools/xonotic-map-compiler-optionsfile parses the options file and runs xonotic-map-compiler for convenience. This is actually what our map build service is using, which we insist on to ensure well-documented and repeatable map builds.

- I strongly advise against recompiling the maps with q3map2. First of all, it really must be the NetRadiant fork of q3map2, as we have features and bug fixes there not in any other q3map2 (the fork is a sad story and was created because id software, owning q3map2 at the time, refused patches to clear bug fixes that strongly affected us in Nexuiz - now the situation is better, but it diverged too much from ZeroRadiant's q3map2 that there's little hope of ever unifying them, unless someone can skip their full-time job for a few months). But more importantly, q3map2's light pass is one of the most inefficient raytracers I have ever seen, and will take about 2 days for all our maps together. I really don't think you want to put up with that compile time.

After all this, I'd really prefer if you didn't recompile the pk3 files. The only part that is easily servicable and also patch-worthy is the QuakeC code, which I'd be fine with if you patched/recompiled it and replaced the progs.dat/csprogs.dat/menu.dat files generated by its compilation in our xonotic-data pk3 file.

Best regards,

Rudolf Polzer


Reply to: