Cosa è cambiato in EDuke32, build per build

Let's BUILD_LUNATIC to see whether it still works...

Factor out a block of code into C_SetCfgName() and use that from lunacon.lua.

That is, one that doesn't break the control flow.

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

These were too much "looking into the implementation of a module" for my taste, hence OSD_GetShadePal() earlier.

This renders tweaks like r4122 unnecessary. Also, note a "bug" with the program generating that C code.

This was caused by mismatched for types mapstate_t's animateptr[] and the global one (int32_t vs. int32_t *). Bump BYTEVERSION.

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.

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.

Because the one implemented on top of X shows a special mark for tabs instead of whitespace. Also, in wm_msgbox(), use vsnprintf.

This fixes ESC in certain situations such as the editor map selection menu.

Each scene is disabled in its entirety, there's no way to disable only a particular part. DONT_BUILD.

- Add SDL scancode -> our key code map for SDL_SCANCODE_APOSTROPHE - Remove duplicate map for SDL_SCANCODE_PAUSE

That is, now it's not necessary to write e.g. "io. write" -- .xxx is translated to <what>[i].xxx only if it's a matching member name.

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.

References: - r3742 - r4038 (fixing savegame screenshots, but introducing the now fixed bug)

That change confounded character-based input with e.g. HUD control under certain circumstances, see http://forums.duke4.net/topic/6845-eduke32-savegame-annoyances/ Also, BUILD_LUNATIC ... just for the hit.sect -> hit.sector change.

This also exposes an actual issue. The sound definitions may be dynamically remapped, in which case they are not necessarily <=255 any more. BUILD_LUNATIC.

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

- Currently: only tvlineasm1 and tvlineasm2, but incomplete (no reverse translucency, nonpow2 textures will crash) - For System V AMD64 calling conventions; requires YASM

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

This reduces the proportion of time the trig calculations take of the whole preprocessing from 50% to about 13%.

Also, add hitscan test to test.lua -- a crosshair-like sprite is spawned and continuously updated to the position of where the player aims at.

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.

The 'colenemy' module searches for colored enemies in maps, excluding pal-21 liztroops. DONT_BUILD.

Specifically, for the tables returned with require"DEFS" etc. This allows to check if maybe parts of a bundle of files is missing (because comparisons like "spr.picnum == D.NONEXISTENT_NAME" do not yield errors normally).

Permitting to enable various debugging options. See "eduke32 -debughelp" for which ones those are: they were previously settable from defs_common.lua, and a new option 'strict' has been added that makes accesses to void sprites error. (That is, already "sprite[i]", not "sprite[i].some_member".)

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

That is, here: http://lunatic.eduke32.com/ or more specifically in lunatic.html. BUILD_LUNATIC.

(Auto-insertion of an inner sector from a loop happens either because the loop is created in an extended sector, or because it has been punched through a ceiling/floor into the upper/lower neighbor sector.)

- add gv.GET, gv.WEAPON, gv.RETURN - specify that sprite[].x/y/z and wall[].x/y are 32-bit ints - add an example for con.longjmp() - add an appendix listing the RETURN usage of various events

Note: the wall line will not light up periodically, but point insertion will be possible nontheless. A bit inconsistent, but I didn't want to do a full analysis of which side effects allowing a sprite highlight and a line highlight to coexist at the same time would have.

BUILD_LUNATIC, third attempt.

This makes CLANG=1 RELEASE=0 DEBUGANYWAY=2 OPTLEVEL=1 builds definitely pretty playable (only Polymost tested) while having a decent amount of sanitization.

Redundant for the same reason as the preceding one: the pointer has already been dereferenced at the point the check is made. Also, all 5 calls of that function pass a valid pointer (provided the pointers from which the expressions are derived are valid). Reported by Stack, too.

The check is dead because it is made after the fact (oob access), but the cheat string matching logic below actually assures that cheatbuflen < sizeof(cheatbuf) at all times. Exposed using the Stack tool from http://css.csail.mit.edu/stack/ . Also, in gamedef.c's definecheat handling, print the string length (19), not the buffer length (20) if the cheat was truncated.

Clang's UBSan reports this as undefined behavior. I think that the reason is as follows: C99 6.5.3.2#1 (Constraints) says: The operand of the unary & operator shall be either a function designator, the result of a [] or unary * operator, or an lvalue that designates an object that is not a bit-field and is not declared with the register storage-class specifier. But in case of an expression like "&array[-1]", the operand ("array[-1]") does not designate a valid object. Moral: check first -- assure that an expression is valid for a particular operation before carrying it out. Keep in mind that otherwise, the compiler is absolutely free to optimize out the *check*.

- Use the proper tile sequence when multiple pskies are present in a map. However, there's still only *one* psky chosen at map load time. - Handle three horizfrac cases: * 0, psky always at same level wrt screen * 65536, psky horiz follows camera horiz (e.g. E4L9) * otherwise, fall back to default hard-coded parallax implemented as an angle fraction

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

- Consolidate psky* arrays into a "typedef struct psky_t" "g_psky" and "multipsky[]". - Factor out getting parallaxed sky properties into getpsky(). - Condense initial multi-psky setup by memcpy'ing from multipsky[]. - New function: MultiPsky_TileToIdx(). - Add new define PSKYOFF_MAX and related consistency-checking assertions. - Lower MAXPSKYTILES to 8 to reflect current usage (was 256). - Game: make multi-pskies consider dynamically-remapped MOONSKY1, BIGORBIT1 and LA. (Not very useful as the editor will still only act for the static values -- 80, 84 and 89, respectively.) An attempt has been made to preserve behavior even in strange cases, so this commit is unlikely to introduce regressions. Because of point 6, BYTEVERSION had to be bumped.

The old extension is an artifact from when I was thought that extensions should label whether a Lunatic module is to be used in internal/external contexts. Also, change test.lua slightly and commit a little updated documentation.

Its members are already laid out on the natural alignment boundaries. Compilation tested with {32-bit, 64-bit} x {Lunatic, non-Lua} builds.

It didn't turn out that useful and was giving a warning with one of the preceding changes.

Also, very slightly tweak a factor toward a "brighter" (farther visible) scene overall to account for the "circular" nature of the fragment distance (as opposed to an "ortho" distance in Build).

It was only ever used as upper bound to the time that a visibility change decays, but since it does that in an exponential fashion, there's really no point.

Now, if p->visibility differs from the constant visibility, the former converges toward the latter by three-quartering the difference each second totalclock increment (1/60th second). Negative player visibilities are not handled consistently throughout the different renderers, so make it look the same as 0 (can view to infinity).

So there's no "jump" from vis!=0 to vis=0 making the texture appear brighter.