- Do not count the segs in a separate pass in CreateNode(). This can be computed trivially
in SplitSegs() as the sets are being built.
- Calculate jump offsets for backpatching without reading the original value. This makes it
thread-safe (if that ever becomes an issue).
SVN r2478 (trunk)
- Add headers to generated CMake projects.
- Made SSELevel global so that ClassifyLineBackpatch can see it without being part of
FNodeBuilder. With backpatching enabled, it's rather pointless to have a different one
per nodebuilder instance, anyway.
- Change ClassifyLineBackpatch so it doesn't need any inline assembly to do its magic.
- Change the ClassifyLine functions to be extern "C" linkage.
SVN r2410 (trunk)
pretty much sucks, this is slower than the unvectored version I get when I let the compiler
compile the regular function with SSE2 instructions. It will have to be converted to assembly,
and then it ought to be a bit faster. Since more than half of ZDBSP's time is spent in this
one function, it will hopefully be a measurable speedup.
SVN r2392 (trunk)
- Fixed: ZDBSP stored seg vertices in 16-bit words, so it failed to write proper nodes for
maps that ended up with more than 65536 vertices after node building, even though it can
write formats that could support it.
- Sync debugging output between ZDBSP and ZDoom's internal node builder.
SVN r2388 (trunk)
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)
