-bsp -deep - include detail brushes into BSP tree generation (but at lowest possible priority), but still ignore them for vis
-vis -mergeportals - only merge vis portals on the same plane, but don't merge clusters (much faster vis, but only slightly worse - will evaluate later why it's worse vis at all)
git-svn-id: svn://svn.icculus.org/netradiant/trunk@244 61c419a2-8eb2-4b30-bcec-8cead039b335
- better BSP tree splitting (experimental, option -altsplit)
- also compare shaders when sorting surfaces (should give slightly more fps)
- misc_model spawnflag 32: set vertex alpha from vertex color (for terrain blending)
git-svn-id: svn://svn.icculus.org/netradiant/trunk@240 61c419a2-8eb2-4b30-bcec-8cead039b335
This adds a special VFS providing textures/radiant/notex and shadernotex.
This way, game packs does not have to provide them using the hardcoded
textures/radiant/[shader]notex path (some games prefer other prefixes).
It also allows GtkRadiant to not crash at startup when a wrong game
path is set.
It would also prevents radiant to fail where it tries to load these
textures on very early stage when the whole VFS is not yet loaded,
for example on pk3dir scenario.
The notex and shadernotex textures come from Unvanquished's tex-common
package and are distributed under public domain-like CC0 1.0 Universal license: https://creativecommons.org/publicdomain/zero/1.0/
See: https://github.com/UnvanquishedAssets/tex-common_src.dpkdir/blob/master/about/tex-common.txt
- vfsqlpk3 was removed, so scons does not have to build it and don't
fail anymore.
- when I was maintaining offline unvanquished branch I got so much pain
each time I rebased on master because of stupid merge conflict since
git knows well how to merge line addition/deletion but not to merge
addition/deletion within the same line… setting each gamepack names
on its own line will save hours of manual stupid merge solve to people
wanting to add games in the future.
- I also added a comma on another list because python allows to put comma
on last element and that's great to reduce diff noise (adding another
line after the last one does not require to modify the one that was
the last one before).
The logic isn't entirely legitimate, since fixedWinding_t is a
fixed-size type that is *sometimes* treated as a variable-sized type,
but it would require deeper refactoring to make this strictly
conforming. As it is, we just keep the offset computation as a
reasonable way to calculate the allocation size.
Fixes#583.