- add LuaJIT's 'v' module printing trace info
- translator: fix game function name definitions
- revert math.fmod -> math.modf, they are different!
- disable JIT compilation for a function we're getting strange crashes with
- Make some of DukePlayer_t's members 'bool' on the Lua side. It's way
too easy to write something like "ps.jetpack_on" where "ps.jetpack_on~=0"
was meant. [Background: Kyle873 observed that Duke was always floating.]
- Error out if looping in our_module(). I find this behavior more logical
than returning true.
- fix a couple of missed FORBID variables
git-svn-id: https://svn.eduke32.com/eduke32@3530 1a8010ca-5511-0410-912e-c29ae57300e0
We must not call these functions using the FFI, since the Lua state is
considered locked across such calls.
git-svn-id: https://svn.eduke32.com/eduke32@3520 1a8010ca-5511-0410-912e-c29ae57300e0
- some more outer commands
- gamearray persistence
- faster 'mod': use math.modf instead of math.fmod (the former is JIT-compiled)
- checkavail*
- THISACTOR special handling
- Fix building in Windows (export A_ShootWithZvel instead of A_Shoot).
git-svn-id: https://svn.eduke32.com/eduke32@3516 1a8010ca-5511-0410-912e-c29ae57300e0
Previously, actor[].shootzvel (implementation detail, not available to CON)
was checked, and if it was !=0, that was the overridden velocity. The value
0 meant "hardcoded, projectile-dependent velocity". But that neccesiated a
hack where if zvel 0 was passed and really meant, it needed to be set to
1 instead. Now we have A_ShootWithZvel() taking an additional last argument
plus a macro SHOOT_HARDCODED_ZVEL permissible for that argument.
git-svn-id: https://svn.eduke32.com/eduke32@3465 1a8010ca-5511-0410-912e-c29ae57300e0
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.
git-svn-id: https://svn.eduke32.com/eduke32@3458 1a8010ca-5511-0410-912e-c29ae57300e0
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.
git-svn-id: https://svn.eduke32.com/eduke32@3455 1a8010ca-5511-0410-912e-c29ae57300e0
Pass types via ffi.typeof() instead of declaring them in the
global namespace when possible.
git-svn-id: https://svn.eduke32.com/eduke32@3437 1a8010ca-5511-0410-912e-c29ae57300e0
