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
On Linux, it started manifesting itself since r4719 as crashes whose
backtraces pointed to malloc() and were not helpful. Valgrind finally
uncovered this.
git-svn-id: https://svn.eduke32.com/eduke32@4724 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 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
Fix a case in G_MovePlayers(), where the player sprite's shade is approached
toward the ceiling/floor's shade. Before, it could stop at one above or below!
git-svn-id: https://svn.eduke32.com/eduke32@4392 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
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
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
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
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
DONT_BUILD, because there have been no significant changes of the non-Lua build.
git-svn-id: https://svn.eduke32.com/eduke32@4006 1a8010ca-5511-0410-912e-c29ae57300e0
- Rename sky_t members: yscale -> horizfrac, bits -> lognumtiles.
- Add default sky (8 tiles, horizfrac=32768 (i.e. 1/2 the scene horiz), offsets
all zero) and CLOUDYOCEAN sky (8 tiles, horizfrac=65536, offsets all zero)
to multipsky[].
- Get rid of "psky_t g_psky", merely maintaining a g_pskyidx instead. Set it up
at map load time so as to keep the behavior of the legacy per-map psky:
the last sector index with a matching psky ceiling wins.
- In mapstate_t, save g_pskyidx too, not (former) pskybits and pskyoffs[].
- Make on-map-load global psky setup consistent for the game and editor by
factoring it out into common.c: G_SetupGlobalPsky().
- Remove a couple of useless initializations, add some static assertions.
This commit is more likely to introduce subtle differences in behavior.
Specifically, getpsky() now always returns the default sky properties instead of
the global sky ones (but with all-zero offsets) when no match for a suiting
multi-psky is found. This is only likely to affect the yscale/horizfrac of
non-multi-pskies when a global non-default multi-psky has been set up.
Bump BYTEVERSION again.
git-svn-id: https://svn.eduke32.com/eduke32@3976 1a8010ca-5511-0410-912e-c29ae57300e0
