This should have no adverse effects or side-effects. The changes only apply if a modder chose to use completely broken functionality in the first place.
git-svn-id: https://svn.eduke32.com/eduke32@3544 1a8010ca-5511-0410-912e-c29ae57300e0
All non-option positional arguments after an @ sign are taken as list files:
hashes at the beginning of a line denote comments, truly empty lines are
ignored, all other lines should contain one root CON file name.
git-svn-id: https://svn.eduke32.com/eduke32@3539 1a8010ca-5511-0410-912e-c29ae57300e0
From the PM conversation "gamearrays in 64-bit". A test case is the breaking
glass at the beginning of the DukePlus map.
git-svn-id: https://svn.eduke32.com/eduke32@3536 1a8010ca-5511-0410-912e-c29ae57300e0
Instead of those of the translated code. Also some codegen tweaks and fixes.
git-svn-id: https://svn.eduke32.com/eduke32@3535 1a8010ca-5511-0410-912e-c29ae57300e0
Also update test/dangling_else.con. See there for how if* cascades are handled
in CON. It's actually kind of pretty. Also, take care to handle code deferred
to after the if/if-else properly (ifpdistl, ifpdistg, ifcanseetartet).
git-svn-id: https://svn.eduke32.com/eduke32@3534 1a8010ca-5511-0410-912e-c29ae57300e0
- 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
Notes:
- MAXJOYBUTTONS is out of sync between the two definitions
- In menus.c, NUMMOUSEFUNCTIONS must equal MAXMOUSEBUTTONS,
fail to compile if this becomes false.
git-svn-id: https://svn.eduke32.com/eduke32@3527 1a8010ca-5511-0410-912e-c29ae57300e0
This fixes an update issue: start EDuke32 without warping to a map in Polymost,
change to classic, and change to Polymost again. The OSD background will be
displaced.
git-svn-id: https://svn.eduke32.com/eduke32@3525 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
Thus making the identical source and destination quote number case into the
expected no-op instead of being undefined behavior.
git-svn-id: https://svn.eduke32.com/eduke32@3510 1a8010ca-5511-0410-912e-c29ae57300e0
If m32script gamevar "move_by_one" is nonzero, the some keys move the
"player arrow" by increments of 1:
- Without SHIFT: LEFT/RIGHT absolute x, DOWN/UP absolute y, A/Z absolute z.
- With SHIFT: DOWN/UP (unbounded!) horiz, LEFT/RIGHT angle.
This can be useful to debug renderer bugs that show a high sensitivity to the
exact location ("are transient in space").
git-svn-id: https://svn.eduke32.com/eduke32@3509 1a8010ca-5511-0410-912e-c29ae57300e0
Face- and wall-aligned sprites are drawn using the wall routines in BUILD.
However, the per-x-screen-coordinate distance (swall[]) is calculated in a way
that potentially incurs great precision loss (for example 5 bits for
xdimen=1280, yxaspect=65536). This leads to the starting (top) vertical texture
coordinate possibly wrapping to large values, leaving an unsightly "stray line"
on top of the sprite from certain viewing angles/horiz values.
The approach to fix it has two parts: first, the distance is calculated using
float values, preventing the precision loss. Because this doesn't fully prevent
the unwanted lines, the texture coords are clamped to the mininum and maximum
(0 and UINT32_MAX respectively) when calculating them for sprites.
Note that stray lines may still appear at the *bottom* of sprites under certain
circumstances, for example when viewing at a y-flipped sprite from above.
These should be less noticable in real-world usage though.
The feature is guarded by a macro HIGH_PRECISION_SPRITE in case using floating
point or 64-bit integers is undesirable/impossible on some platforms.
git-svn-id: https://svn.eduke32.com/eduke32@3483 1a8010ca-5511-0410-912e-c29ae57300e0
That is, first check if the sprite is in the game world and then if it
already has the desired sector or status number. This doesn't change anything
in our codebase, since the return values of these functions are never examined.
git-svn-id: https://svn.eduke32.com/eduke32@3474 1a8010ca-5511-0410-912e-c29ae57300e0
The usual: declare locals more tightly, const-qualify them where it helps
readability, remove dead code...
git-svn-id: https://svn.eduke32.com/eduke32@3470 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
And const them appropriately. Also remove #if 0'ed code related to an MSVC
pragma.
git-svn-id: https://svn.eduke32.com/eduke32@3451 1a8010ca-5511-0410-912e-c29ae57300e0
Meaning that only *ettsprite[THISACTOR] makes sense from CON. It did before
too, because .tspr was set before each event run (and not before all runs),
only that it was never nulled, which was kind of untidy.
git-svn-id: https://svn.eduke32.com/eduke32@3450 1a8010ca-5511-0410-912e-c29ae57300e0
