(Or '0's, but that case is handled automatically.) The resulting generated
number is taken by looking at the 8 lower nibbles and interpreting them as
a signed 32-bit integer.
Also add some number parsing tests to test/nlcf_break.con.
git-svn-id: https://svn.eduke32.com/eduke32@3571 1a8010ca-5511-0410-912e-c29ae57300e0
Toggling whether a getactorvar for a global or per-player gamevar issues
a warning or a hard error, the latter being the default.
Also, make it possible to readgamevar/savegamevar per-actor gamevars and
add userdefs member "idplayers" (read-only).
git-svn-id: https://svn.eduke32.com/eduke32@3570 1a8010ca-5511-0410-912e-c29ae57300e0
The first transformation makes the "control structure too long" error appear
only with larger if/else cascades, though it's still possible.
git-svn-id: https://svn.eduke32.com/eduke32@3569 1a8010ca-5511-0410-912e-c29ae57300e0
The only operation for which proper code is generated is reading a single value
from a system gamearray.
git-svn-id: https://svn.eduke32.com/eduke32@3562 1a8010ca-5511-0410-912e-c29ae57300e0
...at the beginning of each function called back from C, and each case/default
function. Called -fcache-sap. Disabled by default.
git-svn-id: https://svn.eduke32.com/eduke32@3561 1a8010ca-5511-0410-912e-c29ae57300e0
Also,
- an optimization for sprite[]:setpos(). Calls to get_sprite_index()
seem to be pretty slow (at least when they're not compiled).
- add getzrange to the dynsymlists
git-svn-id: https://svn.eduke32.com/eduke32@3560 1a8010ca-5511-0410-912e-c29ae57300e0
Fix 'setsprite' and 'music'. A good timing test for actors performance is
the starfield of WGR2's E1L1 ("Nexus").
git-svn-id: https://svn.eduke32.com/eduke32@3558 1a8010ca-5511-0410-912e-c29ae57300e0
This is the only gamevar of its kind that is handled for Lunatic, neither
PLR_MORALE nor LOGO_FLAGS are.
git-svn-id: https://svn.eduke32.com/eduke32@3556 1a8010ca-5511-0410-912e-c29ae57300e0
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
