Cosa è cambiato in EDuke32, build per build

In the non-Lunatic build naturally, since the Lunatic one uses its own member.

Also, improve -Wnumber-conversion warning by printing the resulting number. BUILD_LUNATIC.

In simple cases, it should be added. Combinations of alignment across TROR boundaries and bottom-swapping will probably not work right.

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.

Also, in LunaCON, make player .palette member read-only. BUILD_LUNATIC.

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.

Actually, right now, any first arg starting with '-' will show the usage.

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.

BUILD_LUNATIC.

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!

Also don't compile three multiplayer related OSD commands there.

BUILD_LUNATIC.

Also, bound-check two .yvel meant as sprite indices in actors.c.

It is unacceptable that yvel is on one hand modifiable without restriction from scripting, but can be used as an array index without prior bound check in the C code. Because that member has an overloaded meaning and is also used for innocuous purposes such as the green color intensity of an SE light, it's infeasible to restrict access from scripting. Consequently, we must add bound checks on the C side. This is the first part of the effort to make .yvel safe, adding two functions P_Get() and P_GetP(). There are a couple of other uses as some kind of index.

Also add test/damagehplane.lua with these demonstrations: - custom breakable ceilings - breakable TROR glass

- in the function itself: for floor, currently, do nothing (but this commit is in preparation of the next one, again) - In Proj_MaybeDamageCF(), Proj_MaybeDamageCF2() and the A_RadiusDamage() use if the function, generalize to floors, but with the special case that parallaxed floors keep blocking projectiles, as before (in constrast to parallaxed ceilings). However, Sect_DamageCeilingOrFloor() is only called for non-parallaxed ceilings *and* floors.

- factor out: G_WallSpriteDist() - factor out: Proj_MaybeDamageCF() and Proj_MaybeDamageCF2() in preparation for the next commit - Make PROJ_DECAYVELOCITY macro take an arg for readability's sake

- 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

Exposed by this snippet from a.m32: getnumber256 .owner "OWNER (projection picnum): " -MAXTILES Now, Alt+KP2 works as expected in 3D mode.

And issue warnings whenever the assignment would fail (error) at game time.

May come in handy at times. BUILD_LUNATIC.

This requires enabling the same workaround as for Linux. Maybe it's not system-dependent at all.

This generally fixes demo playback. Before, tilesizx[]/tilesizy[] were written into twice as many bytes as needed. Now, don't do that at all.

Important because in Lua, a value of zero yields true in a boolean context. BUILD_LUNATIC.

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).

In particular, (int32_t)j != -1 is replaced by (uint32_t)j < MAX_WEAPONS to prevent a value >= MAX_WEAPONS to be assigned to p->wantweaponfire (it's used as a weapon index in P_CheckWeapon().

Because p->scream_voice is an int8_t. This is an unlikely situation (126 voices ought to be playing simultaneously while starting the "scream" sound), but still...

Which was especially noticeable in the Lunatic build. Also, use glPushAttrib/glPopAttrib there.

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).

For sanitizing underwater sections, see r4166. Also, don't print "Menu function executed successfully" when the function printed something itself.

DONT_BUILD.

Also, if it were to be reenabled again, use execv() instead of execvp(), i.e. don't look up $PATH for the executable.

Likewise for blocking wall sprites. This makes it possible to construct underwater sections containing complex spritework without losing the "underwater-ness" when over such sprites, in a backward-compatible way. Actually, the check is for bit 1 being set, but all other bits should be considered reserved.

Add an example searching for all maps containing blocking floor-aligned sprites in underwater sectors.

By detecting them in the SDL_KEYDOWN events. This list is getting a bit ridiculous...