What changed in EDuke32, build by build

- forgot a glogy --> logy in a-c.c - comment out stretchhline and slopevlin2 in a.nasm, the former also in a-c.c - make transmaskvline2 use a uintptr_t where appropriate

With VBOs enabled, the virtual pointer to the geometry of frame 0 of a model is always NULL. This was confusing the polymer code responsible for deciding whether to enable smooth animations or not, which meant that any animation that would loop to frame 0 would do it as if animation interpolation was disabled, which looks very choppy.

- Conditional disabling of the build for each architecture - Conditional enabling of debug building - Detection of the OS X version, disabling incompatible builds and establishing a minimum version - Fail-safe assembly of fat binaries and the archive (each item is checked first) - Lovely factored 'for' loops and parameter expansion

Syntax: echo "Your text here."

Note: I'm not really sure whether I'm initializing it in the right places.

When drawing from inside the mirror, there may be no 'bunches' (BUILD lingo, not TROR ones) collected, but following code used the first one unconditionally.

Hlines for masked and translucent masked ceiling/floor (sprites). - apply the --> 'do { ... } while (--cnt)' transformation, making these functions iterate cnt+1 times like the asm version. This also fixes an off-by-one issue where sprites or masked ceilings/floors had a one-pixel non-drawn line to the right. - This time, only declare-as-local two 'extern' globals (asm1 and asm2). It seems that I was too eager with "localing" all file-scoped vars earlier. GCC is able to remove the loads from memory inside the loop by itself, whereas clang is not. This is not trivial, since it has to prove that the 'screen' pointer passed to the functions will never alias these globals.

I have to admit, I like its grumbling.

See E4L1 for what this means.

The apparent horizon (in units proportional to pixels by a constant factor) was being calculated without normalizing to viewingrange, resulting a discrepancy between the drawn and actual up/down angle with non-default viewingranges (e.g. with r_usenewaspect=1, or when setting it from setaspect). This also means that the center-of-aim will now be the same regardless of the aspect. This fixes many derived bugs: * inconsistency w/ crosshair when shooting a gun and aiming up/down (obviously) * bugs resulting from being able to look up/down too far (garbage non-slope texture-mapping and viewing BIGORBIT skies above the borders in classic). Note: mods that had workaround logic for this bug will have to remove it...

added: sector extra; viewingrange and yxaspect before the main drawrooms call removed: randomseed

This has no measureable difference. Oh well, maybe it benefits weaker machines, since the generated loop code should definitely be prettier.

This doesn't give much, maybe 0.5 fps more, probably because the loop body is pretty long.

Affected functions: hlineasm4, vlineasm1, mvlineasm1, tvlineasm1. Optimizations: - declare all used variables as possibly const-qualified locals in each function. This removes unnecessary loads from memory in the loops. - rewrite "for (; cnt>=0; cnt--) {...}" to "cnt++; do {...} while (--cnt);" in the three last ones (yes, these function iterate cnt+1 times). This makes them functionally equivalent to the asm versions (madness ensues for cnt < 0) and allows the compiler to remove one 'test' instruction at the end of each loop. - in the translucence function, replace addition by ORing Observations (system: Core2 Duo Linux x86_64): With a 1680x1050 window fully covered by the respective type of wall (simple, masked, trans. masked), fps increases by 3-4 from the baseline of approx. 60.

- remove the objects too on 'clean' - fix warning with 'transpal' on x64 (generates translucency and shade tables)

- print compilation status for building the final executable - add 'cleanutils' target in build/Makefile - don't link against pthread, seems unnecessary - don't build nedmalloc.o when not requested in Makefile.common