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
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
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
For a 1680x1050 scene standing directly in front of a mirror, this increases
FPS from ~90 to ~95 for me.
git-svn-id: https://svn.eduke32.com/eduke32@4363 1a8010ca-5511-0410-912e-c29ae57300e0
One potential use is to add r_togglecomposition "0" if you don't like Aero turning on and off every time you switch between 2D mode and 32-bit 3D mode.
git-svn-id: https://svn.eduke32.com/eduke32@4344 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
- Added preprocessor value NETVERSION, to be incremented in the source whenever changes are made to the network protocol.
- Implemented proper server-side version verification of all clients upon connection.
- Implemented connection refusal when we reach MAXPLAYERS. (Should be expanded to implement server player caps.)
- Protected against OOB array accesses if an invalid player id is received.
- Renamed all "Recieve" to "Receive".
git-svn-id: https://svn.eduke32.com/eduke32@4322 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
- Make Win+F* also make play and RTS sound, since modern OS's window managers
like to eat Alt-F*. (Some Win+F* may be inaccessible too, but together all
10 should hopefully be covered.)
- Fix an issue where keys other than F1-F10 were considered as starting an RTS
sound and crashing EDuke32 in the process
git-svn-id: https://svn.eduke32.com/eduke32@4278 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
In simple cases, it should be added. Combinations of alignment across TROR
boundaries and bottom-swapping will probably not work right.
git-svn-id: https://svn.eduke32.com/eduke32@4265 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
The scrollwheel is unique among PC input because it has no innate "hold length". Previously, the layers gave the mousewheel a fake hold length to allow the not-necessarily-synchronous game/editor code to pick up the input before the layers marked it as "no longer pressed". This passed under Windows, but it didn't slide under SDL.
Besides the two problems listed above, it also potentially limited the rate of weapon selection, where scrolling too fast would not register every clicks. [Unrelatedly, this is still the case when you scroll faster than the game's own tickrate, but addressing that would require rewriting input handling to go through a list of "events" for each tic instead of looking at overall pressed/unpressed states.]
git-svn-id: https://svn.eduke32.com/eduke32@4200 1a8010ca-5511-0410-912e-c29ae57300e0
- Move ARRAY_SIZE() macro to compat.h, add another one ARRAY_SSIZE()
- In A_RadiusDamage(): note maybe-unaligned access issue, prevent unlikely oob
- sector.c: use SPRITES_OF* macros where appropriate
git-svn-id: https://svn.eduke32.com/eduke32@4199 1a8010ca-5511-0410-912e-c29ae57300e0
This requires enabling the same workaround as for Linux. Maybe it's not
system-dependent at all.
git-svn-id: https://svn.eduke32.com/eduke32@4193 1a8010ca-5511-0410-912e-c29ae57300e0
I was checking for GCC >= 4.7, while Clangs pretends to be GCC 4.2. Use a
feature test macro instead. The comment I made in r4161 regarding GCC vs.
Clang code was wrong. Now, Clang generates slightly faster code for these cases
(solid and masked 4-pixel wide vlines).
git-svn-id: https://svn.eduke32.com/eduke32@4182 1a8010ca-5511-0410-912e-c29ae57300e0
Which was especially noticeable in the Lunatic build. Also, use
glPushAttrib/glPopAttrib there.
git-svn-id: https://svn.eduke32.com/eduke32@4176 1a8010ca-5511-0410-912e-c29ae57300e0
This "simply" requires an appropriate factor in the projection matrix.
Also, get rid of a special-case factor for >=1.6 aspects (making HUD models
wider then, I think).
git-svn-id: https://svn.eduke32.com/eduke32@4172 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
By detecting them in the SDL_KEYDOWN events. This list is getting a bit
ridiculous...
git-svn-id: https://svn.eduke32.com/eduke32@4163 1a8010ca-5511-0410-912e-c29ae57300e0
Compiling a 32-bit NOASM build resulted in code containing a MOVAPS instruction
that accessed a memory location not aligned to 16 bytes (MinGW, GCC 4.8).
git-svn-id: https://svn.eduke32.com/eduke32@4162 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
For a full 1680x1050 screen drawing a solid/masked wall, the FPS increases
from 118 to 133 and from 114 to 116 (respectively) for me.
Guarded by the macro USE_VECTOR_EXT in the source.
git-svn-id: https://svn.eduke32.com/eduke32@4160 1a8010ca-5511-0410-912e-c29ae57300e0
This fixes some init and update anomalies: before,
- init would always be the graphical mode (0), but writing
merely "osdtextmode" would switch it
- osdtextmode would not get saved to the cfg
git-svn-id: https://svn.eduke32.com/eduke32@4139 1a8010ca-5511-0410-912e-c29ae57300e0
These were too much "looking into the implementation of a module" for my
taste, hence OSD_GetShadePal() earlier.
git-svn-id: https://svn.eduke32.com/eduke32@4138 1a8010ca-5511-0410-912e-c29ae57300e0
This renders tweaks like r4122 unnecessary.
Also, note a "bug" with the program generating that C code.
git-svn-id: https://svn.eduke32.com/eduke32@4135 1a8010ca-5511-0410-912e-c29ae57300e0
I updated the help windows to prefer these variants because they are superior to the -xSquished versions.
Also, factor out the command-line processing code for the above, plus con/def modules and clipmaps.
git-svn-id: https://svn.eduke32.com/eduke32@4128 1a8010ca-5511-0410-912e-c29ae57300e0
So that there are no error messages like "M32 file `a.m32.m32' not found."
Also, in build.c's 'save as' code, add a bound check that would probably
always pass in practice, but looks a bit safer and may fail in very cornerly
cases.
git-svn-id: https://svn.eduke32.com/eduke32@4124 1a8010ca-5511-0410-912e-c29ae57300e0
Instead of directly in build.c:app_main(). Previously, it was possible that an
argument to an option, e.g. "WGR2" with "-game_dir WGR2", would get interpreted
as the initial map to load. This in turn would attempt to execute WGR2.cfg as
sequence of OSD commands -- where that file is an EDuke32 config file instead!
Now: maps are passed without any options, e.g. "mapster32 [opts...] debug.map".
The map file name is not added to the "additional parameters" for map testing.
git-svn-id: https://svn.eduke32.com/eduke32@4121 1a8010ca-5511-0410-912e-c29ae57300e0
Because the one implemented on top of X shows a special mark for tabs instead of
whitespace.
Also, in wm_msgbox(), use vsnprintf.
git-svn-id: https://svn.eduke32.com/eduke32@4120 1a8010ca-5511-0410-912e-c29ae57300e0
This fixes ESC in certain situations such as the editor map selection menu.
git-svn-id: https://svn.eduke32.com/eduke32@4117 1a8010ca-5511-0410-912e-c29ae57300e0
The leak happened because a struct was hashed that had uninitialized
bytes in padding inserted by the compiler. The hash string in now constructed
as concatenation of three CRC32s as 8-byte hex strings, i.e. the individual
CRC32s are padded with leading zeros.
Note to users: because of the hash change, it's sensible to delete the
'textures' and 'textures.cache' files.
git-svn-id: https://svn.eduke32.com/eduke32@4096 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
NOTE TO TEAM MEMBERS: Please review this, as I am not sure what is actually intended here.
git-svn-id: https://svn.eduke32.com/eduke32@4087 1a8010ca-5511-0410-912e-c29ae57300e0
- Don't print osd.szCSDVersion when it is empty, preventing an extra space between the OS name and version number. (An example of what this field holds is "Service Pack 1".)
- Under SDL, allow the "console" edit field to repaint after "OK" is clicked. Important when a long def file is loading.
git-svn-id: https://svn.eduke32.com/eduke32@4086 1a8010ca-5511-0410-912e-c29ae57300e0
Unfortunately, SDL2 does not (yet?) provide a Yes/No box for wm_ynbox().
git-svn-id: https://svn.eduke32.com/eduke32@4085 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
- Currently: only tvlineasm1 and tvlineasm2, but incomplete (no reverse
translucency, nonpow2 textures will crash)
- For System V AMD64 calling conventions; requires YASM
git-svn-id: https://svn.eduke32.com/eduke32@4066 1a8010ca-5511-0410-912e-c29ae57300e0
This reverts commit c7e51147f1869d42fc8365f748bb8f6bd4c6fc2f. [r3835]
Conflicts:
eduke32/build/src/defs.c
[Dunno what caused this, but I cleaned this out. Also, the change from
build.c was not reverted.]
git-svn-id: https://svn.eduke32.com/eduke32@4061 1a8010ca-5511-0410-912e-c29ae57300e0
This reduces the proportion of time the trig calculations take of the whole
preprocessing from 50% to about 13%.
git-svn-id: https://svn.eduke32.com/eduke32@4060 1a8010ca-5511-0410-912e-c29ae57300e0
The offsets (that will translate the axes for .pitch/.roll rotation) were
calculated improperly with screen sizes other than 1280 x 1024 and were
dependent on other related variables. The fix proceeded empirically, i.e. mostly
trial, error, and some educated guesswork. (It's telling that the magic constant
1280 is needed.) A test for Lunatic is added to test.lua that will rotate
SEENINES.
Bug pointed out by Mblackwell.
git-svn-id: https://svn.eduke32.com/eduke32@4058 1a8010ca-5511-0410-912e-c29ae57300e0