File di log originale · 20121223-3312.txt
------------------------------------------------------------------------ r3312 | helixhorned | 2012-12-23 06:00:00 -0800 (Sun, 23 Dec 2012) | 1 line Fix build.lua's loadarts(), add bigytiles.lua. ------------------------------------------------------------------------ r3311 | helixhorned | 2012-12-23 05:59:56 -0800 (Sun, 23 Dec 2012) | 4 lines engine.c: remove some old "#if 1"s, add compilation switch MULTI_COLUMN_VLINE. Unconditionally enabled, but useful for comparing the behavior of the 1-column vline functions against the 2- or 4-column ones. ------------------------------------------------------------------------ r3310 | helixhorned | 2012-12-23 05:59:52 -0800 (Sun, 23 Dec 2012) | 17 lines Classic: fix drawing tilesizy=512 walls, use non-pow2 routines with pskies. The former is really only a workaround. Walls/vertical sprites/pskies with ysize 512 (and presumably greater, but this was not tested) are rendered with one shade higher at the borders (1 pixel vlines) because of a certain assumption in the ASM (see comments there). With very dark shades, the palookup[] buffer is accessed oob. We simply allocate 256 bytes more at the end for each. The latter is only for CLASSIC_NONPOW2_YSIZE_WALLS builds, which is not enabled yet. It seems to matter only for the uncommon case where the such pskies repeat in the height. A 1680x1050 window fully covered with such a sky is then rendered at about 60/85 the FPS for me (mostly due to not using the 4 pixel vline routines), so it may be leaning a bit too much on the side of correctness. A compilation switch DEBUG_TILESIZY_512 is introduced in engine.c for demonstration purposes. ------------------------------------------------------------------------
engine.c: remove some old "#if 1"s, add compilation switch MULTI_COLUMN_VLINE.
Unconditionally enabled, but useful for comparing the behavior of the 1-column vline functions against the 2- or 4-column ones.
fix drawing tilesizy=512 walls, use non-pow2 routines with pskies.
The former is really only a workaround. Walls/vertical sprites/pskies with ysize 512 (and presumably greater, but this was not tested) are rendered with one shade higher at the borders (1 pixel vlines) because of a certain assumption in the ASM (see comments there). With very dark shades, the palookup[] buffer is accessed oob. We simply allocate 256 bytes more at the end for each. The latter is only for CLASSIC_NONPOW2_YSIZE_WALLS builds, which is not enabled yet. It seems to matter only for the uncommon case where the such pskies repeat in the height. A 1680x1050 window fully covered with such a sky is then rendered at about 60/85 the FPS for me (mostly due to not using the 4 pixel vline routines), so it may be leaning a bit too much on the side of correctness. A compilation switch DEBUG_TILESIZY_512 is introduced in engine.c for demonstration purposes.