Original log file · 20130203-3458.txt
------------------------------------------------------------------------
r3458 | helixhorned | 2013-02-03 04:48:25 -0800 (Sun, 03 Feb 2013) | 10 lines
Lose the packed attribute on / rearrange some game struct types.
actors.h: remove 'packed' from projectile_t, tiledata_t. In tiledata_t,
make .cacherange member an int32_t so that the following member
"projectile_t defproj" is aligned on a 4-byte boundary.
player.h: remove 'packed' from playerspawn_t, DukeStatus_t, input_t.
In Lunatic, correct packing attribute of the base type of the unrestricted
actor_t and DukePlayer_t pointer types (the declaration was used without
Bump BYTEVERSION.
------------------------------------------------------------------------
r3457 | helixhorned | 2013-02-03 04:48:20 -0800 (Sun, 03 Feb 2013) | 1 line
player.c: remove a couple of unnecessary casts.
------------------------------------------------------------------------
r3456 | helixhorned | 2013-02-03 04:48:17 -0800 (Sun, 03 Feb 2013) | 1 line
Lunatic: conditionally compile out more legacy code, remove old mixed mode code.
------------------------------------------------------------------------
r3455 | helixhorned | 2013-02-03 04:48:11 -0800 (Sun, 03 Feb 2013) | 20 lines
Lose the 'packed' attribute for types declared in build.h.
Most of them are already aligned to their natural boundaries, so lowering
the alignment to 1 byte can only worsen things by making the C compiler
generate poorer (unaligned access) code for some platforms.
The layout of structures is not specified by the C Standard, but is rather
given by a particular platform + toolchain's ABI (application binary interface).
Most ABIs follow the expected pattern "alignment of scalars is their size,
alignment of arrays is that of its element type, alignment of structs is the
maximum alignment of its members". A couple of links to particular ABIs are
given in build.h.
Problems are expected with archs that care about unaligned access when a pointer
to a non-packed struct is taken that resides in a packed aggregate, but these
uses should be weeded out (I'm not sure if there are any in our codebase).
The following types are affected, only hitdata_t changes its size:
sectortype, walltype, spritetype, spriteext_t, spritesmooth_t,
struct validmode_t, picanm_t, palette_t, vec2_t, vec3_t, hitdata_t.
------------------------------------------------------------------------
r3454 | helixhorned | 2013-02-03 04:48:06 -0800 (Sun, 03 Feb 2013) | 1 line
Lunatic translator: codegen for actor-tsprite accesses, sync some RO members.
------------------------------------------------------------------------
Lose the packed attribute on / rearrange some game struct types.
actors.h: remove 'packed' from projectile_t, tiledata_t. In tiledata_t,
make .cacherange member an int32_t so that the following member
"projectile_t defproj" is aligned on a 4-byte boundary.
player.h: remove 'packed' from playerspawn_t, DukeStatus_t, input_t.
In Lunatic, correct packing attribute of the base type of the unrestricted
actor_t and DukePlayer_t pointer types (the declaration was used without
Bump BYTEVERSION.
player.c: remove a couple of unnecessary casts.
conditionally compile out more legacy code, remove old mixed mode code.
Lose the 'packed' attribute for types declared in build.h.
Most of them are already aligned to their natural boundaries, so lowering
the alignment to 1 byte can only worsen things by making the C compiler
generate poorer (unaligned access) code for some platforms.
The layout of structures is not specified by the C Standard, but is rather
given by a particular platform + toolchain's ABI (application binary interface).
Most ABIs follow the expected pattern "alignment of scalars is their size,
alignment of arrays is that of its element type, alignment of structs is the
maximum alignment of its members". A couple of links to particular ABIs are
given in build.h.
Problems are expected with archs that care about unaligned access when a pointer
to a non-packed struct is taken that resides in a packed aggregate, but these
uses should be weeded out (I'm not sure if there are any in our codebase).
The following types are affected, only hitdata_t changes its size:
sectortype, walltype, spritetype, spriteext_t, spritesmooth_t,
struct validmode_t, picanm_t, palette_t, vec2_t, vec3_t, hitdata_t.
Engine
Lunatic translator: codegen for actor-tsprite accesses, sync some RO members.