Original log file · 20111217-2184.txt
------------------------------------------------------------------------
r2184 | helixhorned | 2011-12-17 10:51:50 -0800 (Sat, 17 Dec 2011) | 6 lines
Add new actor[].flags flag 2048 (SPRITE_NOCLIP), for 'spriteflags' CON usage.
Actors are always moved such that _they_ clip against blocking sprites, even
if their blocking bit is clear. Setting the new bit make them not clip against
anything. The promary use of this is for decorative moving sprites that are
spawned in masses, such as rain or snow.
------------------------------------------------------------------------
r2183 | helixhorned | 2011-12-17 10:51:29 -0800 (Sat, 17 Dec 2011) | 3 lines
engine.c, in engine_addtsprite: if we can't add more tsprites because we
already have MAXSPRITESONSCREEN of them, return 1 to signal that the caller
should break out of the loop.
------------------------------------------------------------------------
r2182 | helixhorned | 2011-12-15 14:43:01 -0800 (Thu, 15 Dec 2011) | 8 lines
Tweaks to compile the release build with clang. Now if it only would not
generate curious code like this one (Ubuntu 11.10's clang 2.9 on i386):
0x080a57ea <+538>: xor %al,%al
0x080a57ec <+540>: test %al,%al
0x080a57ee <+542>: jnz 0x80a57f2 <initgroupfile+546>
=> 0x080a57f0 <+544>: jmp 0x80a57f0 <initgroupfile+544>
0x080a57f2 <+546>: shl $0x4,%edi
------------------------------------------------------------------------
EngineCON
Add new actor[].flags flag 2048 (SPRITE_NOCLIP), for 'spriteflags' CON usage.
Actors are always moved such that _they_ clip against blocking sprites, even
if their blocking bit is clear. Setting the new bit make them not clip against
anything. The promary use of this is for decorative moving sprites that are
spawned in masses, such as rain or snow.
Engine
engine.c, in engine_addtsprite: if we can't add more tsprites because we
already have MAXSPRITESONSCREEN of them, return 1 to signal that the caller
should break out of the loop.
Already listed in build
2182
Tweaks to compile the release build with clang. Now if it only would not
generate curious code like this one (Ubuntu 11.10's clang 2.9 on i386):
0x080a57ea <+538>: xor %al,%al
0x080a57ec <+540>: test %al,%al
0x080a57ee <+542>: jnz 0x80a57f2 <initgroupfile+546>
=> 0x080a57f0 <+544>: jmp 0x80a57f0 <initgroupfile+544>
0x080a57f2 <+546>: shl $0x4,%edi