... 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
These wrap the x*alloc or xstrdup functions in compat.c. The handler gets passed
__FILE__, __LINE__ and __func__ (if available) in debugging builds.
Terminating the application process immediately in case of allocation failure
will let us prune many error handling paths and simplify a good portion of code.
git-svn-id: https://svn.eduke32.com/eduke32@4490 1a8010ca-5511-0410-912e-c29ae57300e0
- in mdloadskin() and gloadtile_hi(), use new function check_nonpow2()
(bit-twiddling) instead of loop
- Replace a couple of missed literals with CACHEAD_* enum labels
git-svn-id: https://svn.eduke32.com/eduke32@4488 1a8010ca-5511-0410-912e-c29ae57300e0
Note: in polymer.c, this was buggy (but harmless) because .r is a char:
if ((uint32_t)hictinting[MAXPALOOKUPS-1].r & 0xFFFFFF00) != 0xFFFFFF00)
git-svn-id: https://svn.eduke32.com/eduke32@4487 1a8010ca-5511-0410-912e-c29ae57300e0
Specifically, the handling of one-way walls ([1] in Mapster32) was slightly
different.
git-svn-id: https://svn.eduke32.com/eduke32@4484 1a8010ca-5511-0410-912e-c29ae57300e0
Mostly, these are rendering-related variables. We keep *writing* them to
mapster32.cfg so that older Mapster32 versions can be used side-by-side
for now.
git-svn-id: https://svn.eduke32.com/eduke32@4462 1a8010ca-5511-0410-912e-c29ae57300e0
This mode does not take a sector's visibility values into account for uniform
darkening of a texture. It is more faithful to classic with respect to
fog/visibility *distances*, but may be less so as far as the "tint" of the
texture due to visibility attenuation is concerned.
git-svn-id: https://svn.eduke32.com/eduke32@4459 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
That is, if that member has a nonzero value, that one is taken for the color of
the GL fog instead of (most of the time) sector[].floorpal. "Sky sectors", that
is, skyboxes or simply parallaxed floors/ceilings are *not* handled.
git-svn-id: https://svn.eduke32.com/eduke32@4415 1a8010ca-5511-0410-912e-c29ae57300e0
Also, extend the documentation for r_usenewshading a little. Specifically,
note when the different modes were introduced. BUILD_LUNATIC.
git-svn-id: https://svn.eduke32.com/eduke32@4410 1a8010ca-5511-0410-912e-c29ae57300e0
It was plainly noticeable in the editor's tile info display, for
example.
git-svn-id: https://svn.eduke32.com/eduke32@4409 1a8010ca-5511-0410-912e-c29ae57300e0
This is done by factoring out some polymer.c:polymer_getbuildmaterial() code
into polymer_eligible_for_artmapping() and using that. The one in polymer.c
can still determine to not use ART mapping on some ("rare"?) occasions, so
it's not 100% in sync.
git-svn-id: https://svn.eduke32.com/eduke32@4407 1a8010ca-5511-0410-912e-c29ae57300e0
- factor out eligible_for_tileshades()
- remove some rendmode 1 code
- move some auto vars further down
git-svn-id: https://svn.eduke32.com/eduke32@4406 1a8010ca-5511-0410-912e-c29ae57300e0
