There's only one RETURN value on the C side (g_RETURN), which is also referenced
from Lua. Upon entering an event, its value takes on the per-event default one,
and its value when the event code finishes is passed back to the game.
Independently of that, its value is always saved and restored across event calls.
git-svn-id: https://svn.eduke32.com/eduke32@3601 1a8010ca-5511-0410-912e-c29ae57300e0
In passing, fix a couple of omissions: gameactor() being passed nil's in the
middle, more than one moveflag to CON *actor.
git-svn-id: https://svn.eduke32.com/eduke32@3597 1a8010ca-5511-0410-912e-c29ae57300e0
This is so that files residing in GRPs (or anywhere the engine looks for them)
can be read, too.
git-svn-id: https://svn.eduke32.com/eduke32@3594 1a8010ca-5511-0410-912e-c29ae57300e0
Also, for the embedded translator: don't warn on unrecognized command line opt.
git-svn-id: https://svn.eduke32.com/eduke32@3590 1a8010ca-5511-0410-912e-c29ae57300e0
... into a macro MFLAGS_NOCONV(m). Since it currently expands to (0), some dead
code will be eliminated.
Introduce a "compilation option" macro DO_MD2_MD3_CONV in mdsprite.c.
git-svn-id: https://svn.eduke32.com/eduke32@3588 1a8010ca-5511-0410-912e-c29ae57300e0
So that it doesn't result in the -t (respawn on) command line switch.
git-svn-id: https://svn.eduke32.com/eduke32@3586 1a8010ca-5511-0410-912e-c29ae57300e0
This enables ART animations to take effect on voxels in classic, voxels and models in Polymost, and models in Polymer.
git-svn-id: https://svn.eduke32.com/eduke32@3580 1a8010ca-5511-0410-912e-c29ae57300e0
The unmodified behavior is completely wrong and I don't see how any mod could ever use it.
git-svn-id: https://svn.eduke32.com/eduke32@3578 1a8010ca-5511-0410-912e-c29ae57300e0
(Modders who used an older version: Take a look at the SVN diff, the fixes can easily be applied by hand.)
git-svn-id: https://svn.eduke32.com/eduke32@3577 1a8010ca-5511-0410-912e-c29ae57300e0
This now should look correct for both settings of r_usenewaspect.
git-svn-id: https://svn.eduke32.com/eduke32@3575 1a8010ca-5511-0410-912e-c29ae57300e0
- Make _buildargv[_buildargc] NULL.
- With SDL layer, pass argv and argc directly and get rid of _build* ones.
- Add tilesiz* to dynsymlists.
git-svn-id: https://svn.eduke32.com/eduke32@3573 1a8010ca-5511-0410-912e-c29ae57300e0
Also, fix an error() call in control.lua:gamearray_file_common().
git-svn-id: https://svn.eduke32.com/eduke32@3572 1a8010ca-5511-0410-912e-c29ae57300e0
(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
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
