because MinGW's GCC 4.5.0 made some seemingly-dumb-to-me changes to their default link
settings, so I've removed all traces of GCC 4.5.0 and am currently rebuilding clang to see
if that fixes it.)
SVN r2387 (trunk)
warning: converting to non-pointer type 'int' from NULL
- Force static linking to libstdc++ and libgcc, because MinGW GCC 4.5.0 wants to do it
dynamically.
SVN r2362 (trunk)
that violate the GL node spec and thus cannot be saved. ClassifyLine() looks like the right
place to handle this, but I'd prefer not to touch it unless somebody produces a map that shows it's
absolutely necessary, since this single function is responsible for the vast majority of the time
spent by the nodebuilder.
SVN r2093 (trunk)
* Fixed: Polyobject detection was disabled for UDMF maps due to an incorrect
namespace check.
* Fixed: The polyobject spawn type PO_SPAWNHURT_TYPE (9303) was not recognized
as a valid spawn spot, so split avoidance would not be enabled for any polyobjects
that used them.
* Added a -c (--comments) command line option to write entity numbers in comments
next to each entity in UDMF maps (ala the upcoming Doom Builder 2).
SVN r1702 (trunk)
- Fixed the OrgSectorMap generation in FLevel::RemoveExtraSectors().
- Added a version of ClassifyLine compiled with SSE (but not SSE2) optimization
for people with Pentium 3/Athlon XPs to use.
- Added ClassifyLine backpatching for the GCC Windows build. The first time a
function calls ClassifyLine, it has to check which version to use and jump
to the appropriate one. After that, it calls the desired one straight away.
SVN r227 (trunk)
ClassifyLine routine or a version compiled with SSE2 optimizations. This
pretty much removes any reason to do a separate SSE2 build, since most of
the time is spent in ClassifyLine, so using SSE2 in just that one function
helps the most.
SVN r172 (trunk)
nodes inserted into it to make a red-black tree worthwhile.
- Added more checks at the start of ClassifyLine so that it has a better chance
of avoiding the more complicated checking, and it seems to have paid off with
a reasonably modest performance boost.
SVN r169 (trunk)
vertices instead of lines.) On large maps, this can result in a very
significant speed up. (In one particular map, ZDBSP had previously
spent 40% of its time just scanning through all the vertices in the
map. Now the time it spends finding vertices is immeasurable. Now 68%
of its time on that map is spent inside ClassifyLine--because that
routine is called more than 16 million times, which suggests that even
a minor speedup in that routine should have a big impact--if I could
just think of how that might happen.) On small maps, this won't make
much of a difference, because the number of vertices to search was so
small to begin with.
SVN r167 (trunk)
the runtime is spent in that function. I should probably write a faster
vertex finding routine, since I currently just do a linear search through
all the vertices. That ought to help speed up SplitSegs, the second most
time-consuming routine. I also tried storing vertices as doubles instead
of fixeds, but that made performance drop across the board, so that's a
change that didn't make it in.
Ironically, the GCC compiled version is noticeably faster than the VC
version for x87 math, but VC produces a marginally faster SSE2 version.
SVN r163 (trunk)
- AddIntersection() should convert to doubles before subtracting the vertex
from the node, not after, to avoid integer overflow. (See cah.wad, MAP12
and MAP13.) A simpler dot product will also suffice for distance calculation.
- Splitters that come too close to a vertex should be avoided. (See cata.wad.)
- Red-Black Tree implementation was broken and colored every node red.
- Moved most of the code for outputting degenerate GL subsectors into another
function.
- Removed forgotten debugging file dump from WriteSSectors2().
- Enabled reference optimization and COMDAT folding in the linker for a slightly
smaller executable.
SVN r155 (trunk)
- MapSideDef.sector was declared signed but treated as unsigned.
- Degenerate (one-dimensional) subsectors could throw away segs when
output for GL nodes depending on the seg ordering.
SVN r152 (trunk)
