.rtext files in the assembly object files. Now I can avoid doing this at
runtime, which means that ZDoom is now UPX-compatible if anyone wants to
pack it.
You will need to do a rebuild or manually delete the old assembly .obj files
for the first build from this revision to succeed, since there are no
changes to the assembly files themselves, and the build process will not be
able to automatically detect that they need to be rebuilt.
SVN r473 (trunk)
down version of the library with the ZDoom source. (It actually uses less
space than zlib now.) Unix users probably ought to use the system-supplied
libjpeg instead. I modified Makefile.linux to hopefully do that. I'm sure
Jim or someone will correct me if it doesn't actually work.
SVN r293 (trunk)
or not SSE2 is available at runtime. Since most of the time is spent in
ClassifyLine, using SSE2 in just this one function helps the most.
- Nodebuilding is a little faster if we inline PointOnSide.
- Changed FEventTree into a regular binary tree, since there just aren't enough
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.
- Added a "vertex map" for ZDBSP's vertex selection. (Think BLOCKMAP for
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.) 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 r173 (trunk)
memcpy to copy the player structures.
- Fixed compilation with MinGW again and removed most of the new warnings.
And following is the log that I forgot to paste in for the previous commit:
- Changed the memory management for FString. Instead of using a garbage
collected heap, it now uses normal heap calls and reference counting to
implement lazy copying. You may now use bitwise operators to move
(but not copy!) FStrings around in memory. This means that the
CopyForTArray template function is gone, since TArrays can now freely
move their contents around without bothering with their specifics.
There is one important caveat, however. It is not acceptable to blindly 0
an FString's contents. This necessitated the creation of a proper
constructor for player_s so that it can be reset without using memset. I
did a quick scan of all memsets in the source and didn't see anything else
with a similar problem, but it's possible I missed something.
- Fixed: Build tiles were never deallocated.
- Fixed: Using Build's palette.dat only got half the palette right.
SVN r117 (trunk)
Randy Heit
Christoph Oelckers