-faketilesiz[MAXTILES] removed in favor of simple faketile[(MAXTILES+7)>>3] bitfield
-h_xsize/h_ysize (tile size overrides from .def) are now uint16_t instead of int32_t
-hudmem[2][MAXTILES] removed in favor of adding a hudmem ptr to mdmodel_t
-tilefromtexture performance improvements
-more tsectortype/twalltype usage in various engine functions that read but never write
-continued Polymost cleanups and refactors. Please report any odd rendering errors.
git-svn-id: https://svn.eduke32.com/eduke32@5079 1a8010ca-5511-0410-912e-c29ae57300e0
The latter means that running perpendicular thin sector is handled better
if there are e.g. TROR sectors in the same x/y space.
git-svn-id: https://svn.eduke32.com/eduke32@5024 1a8010ca-5511-0410-912e-c29ae57300e0
This fixes engine-side sprite animation in the following scenario: CON code
wants to draw a scene from EVENT_DISPLAYREST, but since it covers the whole
screen, disables the drawing of the 3D scene beforehand (RETURN set to 1 from
EVENT_DISPLAYROOMS). DONT_BUILD.
git-svn-id: https://svn.eduke32.com/eduke32@5020 1a8010ca-5511-0410-912e-c29ae57300e0
- In drawvox(), make view-relative x and y high-precision on desktops. To a
large extent (but not completely), this fixes "stray" fake floor shadow
sprites for voxels.
- In the mouse picking code for voxels, fix a possible integer overflow.
A new engine.c-private function mulscale_triple30() is added.
DONT_BUILD.
git-svn-id: https://svn.eduke32.com/eduke32@5017 1a8010ca-5511-0410-912e-c29ae57300e0
Since TILE_TILT is only allocated once, it must be done with the maximum
possible size.
git-svn-id: https://svn.eduke32.com/eduke32@4965 1a8010ca-5511-0410-912e-c29ae57300e0
This fixes the out-of-bounds read of former g_player[] in VM_EventCommon_().
git-svn-id: https://svn.eduke32.com/eduke32@4961 1a8010ca-5511-0410-912e-c29ae57300e0
This makes sure that the engine arrays have sufficient space allocated for usage
in Mapster32's 2D mode, for example from drawmapview().
git-svn-id: https://svn.eduke32.com/eduke32@4938 1a8010ca-5511-0410-912e-c29ae57300e0
In setview(), we now assert windowx2 < xdim. The only calling places where its
non-violation is non-trivial to ascertain are (1) showview from CON and
(2) draw-to-tile for look-sideways in game.c. AFAICS case 1 should be fine.
Case 2 is adapted; see comments there.
git-svn-id: https://svn.eduke32.com/eduke32@4935 1a8010ca-5511-0410-912e-c29ae57300e0
By setting DISTRECIPSIZ to 131072, as far as I can see the absolute maximum
that's possible with the integer scaling convention of the voxel drawing code.
BUILD_LUNATIC.
git-svn-id: https://svn.eduke32.com/eduke32@4881 1a8010ca-5511-0410-912e-c29ae57300e0
Also for polymost_scansector(). These were likely of little consequence
because collection in scansector() is the exception than the rule (see
added comments), and because the redundant drawwalls() would find the
x range done the second and following times.
Also, add a bound check for sectorborder[] (the limit was probably rarely
hit in practice, but the check is mandatory nontheless) and add functions
printscans() and printbunches() in the DEBUGGINGAIDS=2 build.
git-svn-id: https://svn.eduke32.com/eduke32@4877 1a8010ca-5511-0410-912e-c29ae57300e0
There were various issues with that code.
- It does not seem to be very meaningful to do so.
- It was carried out on the same range as the sprites sorted by z coordinate
(those with equal x/y) just a few lines away, effectively overriding it.
The former is very meaningful, though.
- It led to inconsistencies between editor and game, see
http://forums.duke4.net/topic/775-eduke32-20-and-polymer/page__view__findpost__p__214873
git-svn-id: https://svn.eduke32.com/eduke32@4876 1a8010ca-5511-0410-912e-c29ae57300e0
- factor out calculation of player-relative and screen+clipped-player-relative
coordinates into get_rel_coords() and get_screen_coords(), respectively
- the usual beautification stuff, especially since we're now on C99
git-svn-id: https://svn.eduke32.com/eduke32@4875 1a8010ca-5511-0410-912e-c29ae57300e0
Previously, the C function clipmove() returned negative values when hit a
wall (32768+wallnum) or sprite (49152+spritenum) because internally,
these values were encoded into a *signed* 16-bit integer. This made no
difference to C code using it, since it always proceeded by bit checks,
but was inconsistent with documentation on CON 'clipmove' on the wiki.
The following commands are affected too, since they use the value returned
by clipmove(): 'clipmovenoslide', 'movesprite'. Also, the value of
actor[].movflag ('htmovflag' from CON).
Also, fix 'clipmove*' in LunaCON and add lunatic/test/checknearwall.con
as an example of how to implement a being-close-to-a-wall checker as
requested in
http://forums.duke4.net/topic/7869-determining-closeness-to-a-wall/
git-svn-id: https://svn.eduke32.com/eduke32@4874 1a8010ca-5511-0410-912e-c29ae57300e0
Analogously to the way models are processed in a deferred manner for Polymer.
git-svn-id: https://svn.eduke32.com/eduke32@4836 1a8010ca-5511-0410-912e-c29ae57300e0
defs.c: sync some dup'd code for 'definevoxel' and 'voxel' DEF tokens.
engine.c: factor out PolymerProcessModels().
git-svn-id: https://svn.eduke32.com/eduke32@4835 1a8010ca-5511-0410-912e-c29ae57300e0
Now passed as last arg 'noFloorPal' to makepalookup(). Used as follows:
- from loadlookups(): *false*, i.e. do take over floor pal.
- from generatefogpals() [default fog pals] and fillemptylookups(): *true*,
i.e. don't take over floor pal
- from DEF 'fogpal': true
- from DEF 'makepalookup': take over flag from pal from which we are remapping,
or set to true if remapping from pal 0
- (CROSSHAIR_PAL: true)
This should make the issue reported in
http://forums.duke4.net/topic/775-eduke32-20-and-polymer/page__view__findpost__p__197583
resolve in a natural manner.
git-svn-id: https://svn.eduke32.com/eduke32@4812 1a8010ca-5511-0410-912e-c29ae57300e0
- 'nofloorpalrange' DEF token: now handled for both game and editor (for the
latter, it's effective only for "shade preview" mode, [']+[X]).
- in generatefogpals(), assign g_noFloorPal[] = 1 for every generated (default)
fog pal; get rid of its return value / g_firstFogPal
git-svn-id: https://svn.eduke32.com/eduke32@4811 1a8010ca-5511-0410-912e-c29ae57300e0
Since we're targeting C99/C++ now, we can finally declare variables as close
to their use as possible.
git-svn-id: https://svn.eduke32.com/eduke32@4797 1a8010ca-5511-0410-912e-c29ae57300e0
Analogously treat maskwallscan() and transmaskwallscan(), although I could
not get the respective accesses to be oob, too.
git-svn-id: https://svn.eduke32.com/eduke32@4757 1a8010ca-5511-0410-912e-c29ae57300e0
Optimizations are left to the reader :P. I would prefer to look for ways of
giving the compilers hints about loops to unroll instead of having to read
the resulting mess of manual unrolling, though.
git-svn-id: https://svn.eduke32.com/eduke32@4728 1a8010ca-5511-0410-912e-c29ae57300e0
They classify former uses of int64_t into two classes:
- coord_t: those that represent coordinates and need 64-bit precision for
proper functioning with large values
- inthi_t: those that were added for e.g. casts merely to prevent undefined
behavior on overflow
DONT_BUILD.
git-svn-id: https://svn.eduke32.com/eduke32@4578 1a8010ca-5511-0410-912e-c29ae57300e0
... and cull code that is dead with the X*alloc() versions since they never
return NULL on requesting memory.
Use something like
git grep '[^Xx]\(m\|c\|re\)alloc *('
and
git grep '[^Xx]strdup *('
to see places where I left the B*alloc() calls intact.
BUILD_LUNATIC.
git-svn-id: https://svn.eduke32.com/eduke32@4491 1a8010ca-5511-0410-912e-c29ae57300e0
That is, for every for palette (now, even ones created by the user) the last
shade is the (or rather, a color close to the) full fog color by construction.
In loadpalette(), reject a PALETTE.DAT with only one shade level.
git-svn-id: https://svn.eduke32.com/eduke32@4458 1a8010ca-5511-0410-912e-c29ae57300e0
Concretely, for all 1 <= i <= 255, make graypalookup[31][i] := graypalookup[31][0].
Also document 'fogpal' in the Lunatic doc.
git-svn-id: https://svn.eduke32.com/eduke32@4456 1a8010ca-5511-0410-912e-c29ae57300e0
Also,
- add a static assertion to engine.c
- gameexec.c: compile out an unused function in Lunatic builds
git-svn-id: https://svn.eduke32.com/eduke32@4451 1a8010ca-5511-0410-912e-c29ae57300e0
This makes the game not process as many ticks as have elapsed during the saving
afterwards.
git-svn-id: https://svn.eduke32.com/eduke32@4450 1a8010ca-5511-0410-912e-c29ae57300e0
The extended PALETTE.DAT format can now carry a trailing byte, called
'lognumalphatables'. If it is present, the engine assumes that alpha blending
tables are loaded at blend indices 1 to 1<<lognumalphatables and handles
rotatesprite's alpha and spriteext[].alpha accordingly.
The ability to save this new byte is added to engine.lua:savePaletteDat()
and the corresponding convenience functions in shadexfog.lua.
Examples test/screentext.con and test/sprite_access.con are updated for
demonstration purposes.
git-svn-id: https://svn.eduke32.com/eduke32@4426 1a8010ca-5511-0410-912e-c29ae57300e0
The overall situation is thus as follows:
- in C and from Lua, that member is called 'fogpal'
- In CON (both C-CON and LunaCON), it's 'fogpal' with 'alignto' being an alias;
'filler' wasn't available before, either.
- In m32script, it's 'fogpal' or 'alignto' ('filler' is not available any more)
git-svn-id: https://svn.eduke32.com/eduke32@4416 1a8010ca-5511-0410-912e-c29ae57300e0
With this mode, the near distance of the linear fog is always 0, unlike being
negative with r_usenewshading 2.
git-svn-id: https://svn.eduke32.com/eduke32@4393 1a8010ca-5511-0410-912e-c29ae57300e0
Make Mapster32 save as map-text if there is a wall with non-zero 'blend'.
git-svn-id: https://svn.eduke32.com/eduke32@4368 1a8010ca-5511-0410-912e-c29ae57300e0
- Mapster32: before loading LOOKUP.DAT, set palookup[0][239]=239 to
make an identity map of the base shade table's shade 0
- Rewrite color index remapping case of makepalookup() for clarity
BUILD_LUNATIC.
git-svn-id: https://svn.eduke32.com/eduke32@4336 1a8010ca-5511-0410-912e-c29ae57300e0
As opposed to the previous way, where the first fog pals was <numlookups>+1,
where <numlookups> is the first byte value of LOOKUP.DAT. This allows to
pack e.g. lookups [1 .. 25] and [30 .. <lastpal>] into LOOKUP.DAT and have fog
pals be generated at pals [26 .. 29] (i.e. the additional lookups don't
shift the fog pals, making user maps depending on these numbers not look as
intended.)
git-svn-id: https://svn.eduke32.com/eduke32@4335 1a8010ca-5511-0410-912e-c29ae57300e0
Also, error if didn't read enough data and account for TITLE and REALMS
swap between basepal number and on-disk order (sigh).
git-svn-id: https://svn.eduke32.com/eduke32@4334 1a8010ca-5511-0410-912e-c29ae57300e0
Lunatic: also, add an additional argument 'moreblends' to
engine.savePaletteDat() and document that function.
See test/shadexfog.lua for a "user-friendly" wrapper shadexfog.save() which
prints success or errors.
git-svn-id: https://svn.eduke32.com/eduke32@4312 1a8010ca-5511-0410-912e-c29ae57300e0
On the C side, slightly rewrite (now) getclosestcol_lim() for clarity.
git-svn-id: https://svn.eduke32.com/eduke32@4308 1a8010ca-5511-0410-912e-c29ae57300e0
Also, fix a missed .filler -> g_ambiencePlaying[] rewrite in the editor.
In C-CON, 'detail' is kept as alias to C-side (former) .filler / now .blend,
but that name is *deprecated*.
git-svn-id: https://svn.eduke32.com/eduke32@4305 1a8010ca-5511-0410-912e-c29ae57300e0
This fixes updating the viewscreen in Polymer's ART mapping mode.
git-svn-id: https://svn.eduke32.com/eduke32@4304 1a8010ca-5511-0410-912e-c29ae57300e0
Currently, sprite[].filler (to be renamed) selects a blending table. If none
is installed with that index, the blending table at index 0 is taken (which is
read from PALETTE.DAT on engine startup). Thus, for now, the non-Lunatic build
will never use a custom blending table because there's no way to register one!
But the functionality is there.
git-svn-id: https://svn.eduke32.com/eduke32@4301 1a8010ca-5511-0410-912e-c29ae57300e0
- use SPRITES_OF* iterator macros
- new function: E_SpriteIsValid(); add some safety checks
(e.g. hitag used as sprite index)
- the rest is mostly "the usual code transformations"
git-svn-id: https://svn.eduke32.com/eduke32@4281 1a8010ca-5511-0410-912e-c29ae57300e0
In the non-Lunatic build naturally, since the Lunatic one uses its own member.
git-svn-id: https://svn.eduke32.com/eduke32@4275 1a8010ca-5511-0410-912e-c29ae57300e0
EDuke32 has me so accustomed to straight C... using a template and pass-by-reference makes my day.
git-svn-id: https://svn.eduke32.com/eduke32@4267 1a8010ca-5511-0410-912e-c29ae57300e0
Concretely, in the "behind, outside" case, draw the sprite early if any of its
2 or 4 corner points are behind the masked wall, and inside the cone or on the
other outside.
git-svn-id: https://svn.eduke32.com/eduke32@4264 1a8010ca-5511-0410-912e-c29ae57300e0
This prevents a crash and maybe other badnesses when e.g. loading a map
with ART tiles, doing something that allocates a reserved tile (such as
looking into a viewscreen), then loading another map where the tilesiz*
of TILE_VIEWSCR is restored to 0.
git-svn-id: https://svn.eduke32.com/eduke32@4259 1a8010ca-5511-0410-912e-c29ae57300e0
When a map named <filename>.map is loaded (<filename> may also contain directory
separators), the engine checks for existence of <filename>_XX.art in the virtual
file system, where XX is a 0-padded number from 00 to 19. It loads a consecutive
sequence of these ART files, i.e. aborts whenever a number in the sequence isn't
found (in contrast to normal ART loading).
Restrictions:
- the per-map ART files must not reside in ZIP files
- if a tile number is attempted to be overridden that has a dummytile or is
cache1d-locked, per-map ART loading fails
On failure, the map is still loaded, but a diagnostic message is output to the
log/OSD.
Loaded per-map ART data are cleared whenever the map is "left". In particular:
- whenever another map is loaded
- in the editor: when a new map is started
- in the game: after the bonus ending screen of a finished level, after going
to the title screen via the menu
A final note: file names are supposed to be looked up and compared
case-sensitively. That is, <filename> must match EXACTLY between the map's and
per-map ART one; 'art' must be lowercase. Otherwise, the cookie monster will
come and eat you!
BUILD_LUNATIC.
git-svn-id: https://svn.eduke32.com/eduke32@4257 1a8010ca-5511-0410-912e-c29ae57300e0
Available in the game and editor. Provide test/shadexfog.lua, containing a
function to creating a set of 32 shade tables corresponding to different shades
of the same fog palookup table, together with some tests and convenience
functions.
Also,
- Add gv.LUNATIC_CLIENT{,_EDUKE32,_MAPSTER32}
- Add LUNATIC_FIRST_TIME in the global env for the game
- defs_m32.lua: add reload() convenience function
- Failed attempt at recreating the base shade table. It is NOT a linear ramp
of the base palette colors to (0,0,0). That is, it's not created by
build/util/transpal.exe!
git-svn-id: https://svn.eduke32.com/eduke32@4236 1a8010ca-5511-0410-912e-c29ae57300e0
Known as getactor/sprite[].xpanning from CON, values are 0-255. It should be
assumed that this is only valid for wall-aligned sprites (currently, face
sprites also pan).
A test is provided in lunatic/test/animatesprites.con. It should be run in E1L2
and only with the Lunatic build.
git-svn-id: https://svn.eduke32.com/eduke32@4170 1a8010ca-5511-0410-912e-c29ae57300e0
The functions mvlineasm1, mvlineasm4 and tvlineasm2 can now be set to clamp
the vertical texture coordinate (vplc), preventing the unsightly stray lines
on the bottom of non-y-flipped sprites. (The first part of this effort, r3483,
handled their top).
However, this is only enabled for the mvlineasm ones: the vectorized variants
suffered almost no slowdown (even though a PADDUSD SSE instruction would be a
nice thing to have), while it was pretty significant for the sequential
translucent ones.
Summarizing, this leaves two cases where stray lines may appear in the non-ASM
build (the saturation is NYI for a.nasm):
- at the bottom of y-flipped sprites
- at the bottom of translucent sprites (can be toggled by #define)
Another observation is that recent GCC generates much faster code for this
stuff than Clang from SVN.
git-svn-id: https://svn.eduke32.com/eduke32@4161 1a8010ca-5511-0410-912e-c29ae57300e0
Variables at global scope which share a name tend to actually be the same variable. Not good when you pass such a variable to function that immediately returns if the passed parameter (the variable) equals said variable (itself).
git-svn-id: https://svn.eduke32.com/eduke32@4090 1a8010ca-5511-0410-912e-c29ae57300e0
Most often, this had happened when casting comparison functions for qsort()
like these: "int yax_cmpbunches(const int16_t *b1, const int16_t *b2)"
to a function pointer type expecting "const void *". Alas, this is undefined
behavior: see
http://blog.frama-c.com/index.php?post/2013/08/24/Function-pointers-in-C
and posts linked from it.
At least two cases have not been fixed:
- The savegame system maintains pointers which are either to data or a function in
the generic "void *". This ought to be made into a union.
- Probably also:
#define OSD_ALIAS (int32_t (*)(const osdfuncparm_t*))0x1337
git-svn-id: https://svn.eduke32.com/eduke32@4068 1a8010ca-5511-0410-912e-c29ae57300e0
- engine.c: comment out some unused decls with RELEASE=0 DEBUGANYWAY=1
- Lunatic: update dump.lua and v.lua
- Lunatic: test/test_geom.lua: note a perf regression (wrt older LuaJIT,
or I mis-configured / built something wrong)
git-svn-id: https://svn.eduke32.com/eduke32@4048 1a8010ca-5511-0410-912e-c29ae57300e0
