Cosa è cambiato in EDuke32, build per build

Face- and wall-aligned sprites are drawn using the wall routines in BUILD. However, the per-x-screen-coordinate distance (swall[]) is calculated in a way that potentially incurs great precision loss (for example 5 bits for xdimen=1280, yxaspect=65536). This leads to the starting (top) vertical texture coordinate possibly wrapping to large values, leaving an unsightly "stray line" on top of the sprite from certain viewing angles/horiz values. The approach to fix it has two parts: first, the distance is calculated using float values, preventing the precision loss. Because this doesn't fully prevent the unwanted lines, the texture coords are clamped to the mininum and maximum (0 and UINT32_MAX respectively) when calculating them for sprites. Note that stray lines may still appear at the *bottom* of sprites under certain circumstances, for example when viewing at a y-flipped sprite from above. These should be less noticable in real-world usage though. The feature is guarded by a macro HIGH_PRECISION_SPRITE in case using floating point or 64-bit integers is undesirable/impossible on some platforms.

Bump BYTEVERSION.

That is, first check if the sprite is in the game world and then if it already has the desired sector or status number. This doesn't change anything in our codebase, since the return values of these functions are never examined.

Also taking care that the USE_OPENGL=0 build builds.

Previously, actor[].shootzvel (implementation detail, not available to CON) was checked, and if it was !=0, that was the overridden velocity. The value 0 meant "hardcoded, projectile-dependent velocity". But that neccesiated a hack where if zvel 0 was passed and really meant, it needed to be set to 1 instead. Now we have A_ShootWithZvel() taking an additional last argument plus a macro SHOOT_HARDCODED_ZVEL permissible for that argument.

Also, simplify a couple of other lines.

actors.h: remove 'packed' from projectile_t, tiledata_t. In tiledata_t, make .cacherange member an int32_t so that the following member "projectile_t defproj" is aligned on a 4-byte boundary. player.h: remove 'packed' from playerspawn_t, DukeStatus_t, input_t. In Lunatic, correct packing attribute of the base type of the unrestricted actor_t and DukePlayer_t pointer types (the declaration was used without Bump BYTEVERSION.

Most of them are already aligned to their natural boundaries, so lowering the alignment to 1 byte can only worsen things by making the C compiler generate poorer (unaligned access) code for some platforms. The layout of structures is not specified by the C Standard, but is rather given by a particular platform + toolchain's ABI (application binary interface). Most ABIs follow the expected pattern "alignment of scalars is their size, alignment of arrays is that of its element type, alignment of structs is the maximum alignment of its members". A couple of links to particular ABIs are given in build.h. Problems are expected with archs that care about unaligned access when a pointer to a non-packed struct is taken that resides in a packed aggregate, but these uses should be weeded out (I'm not sure if there are any in our codebase). The following types are affected, only hitdata_t changes its size: sectortype, walltype, spritetype, spriteext_t, spritesmooth_t, struct validmode_t, picanm_t, palette_t, vec2_t, vec3_t, hitdata_t.

Introduced in r3358, where I missed a condition inside an 'if'.

And const them appropriately. Also remove #if 0'ed code related to an MSVC pragma.

Meaning that only *ettsprite[THISACTOR] makes sense from CON. It did before too, because .tspr was set before each event run (and not before all runs), only that it was never nulled, which was kind of untidy.

Its only use is to have a actor -> tsprite mapping for the EVENT_ANIMATESPRITE event and .tspr will be set before it is run.

Pass types via ffi.typeof() instead of declaring them in the global namespace when possible.

Use a new flag to mark hard-coded enemies, not SPRITE_BADGUY. This fixes an issue where in E1L4, a pigcop would appear in the area you have to crawl under shrunk. Thanks to LLCoolDave1 for pinpointing the range of relevant revisions.

... when 'make' is invoked like "make ... STRIP=some_strip".

Whenever it should be not, STRIP is set to the empty string. This fixes the Lunatic RELEASE=1 build.

The pixel doubling now only applies to the area where the world scene is drawn, i.e. it may be smaller than the physical screen / WM window size. The optimized version is slightly faster than for non-doubled pixels for me (optimized build), but see code for caveats. Some other minor issues: - won't work when the world is drawn from demo cameras (and offscreen, but that matters less) - will leave a few pixels empty when running with x resolutions not evenly divisible by 4

... to have a little moew overview.

- more predefined vars - fix recursive states and ones with a stray "else" before the end

- Fix "gv" access. - camera - translator: comparison predicates, predefs...

Whether a sprite is considered for texel-hitscan is determined on the base tile number, not the individual animated tile numbers.

* Make the "classic status bar fullscreen viewport" mode accessible in classic too. * Make range of status bar scale 36..100 * Update ud.statusbarmode when executing OSD command r_size (ud.screen_size). NOTE: ud.statusbarmode is considered internal. Don't use from CON! * Make sure 1) loading any configuration and 2) menu bars work correctly. (The "classic status bar fullscreen viewport" mode will never be restored though because ud.statusbarmode isn't handled by the OSD var system).

One use was in determining the ray vector for the mouse-aiming hitscan in the editor. Unfortunately, the change doesn't make it any less broken in Polymost, even if the two instances were out of sync.

If enabled, dragging wall vertices will correct the xrepeat after the mouse button is released, so that the pre-drag absolute stretching is restored.

- Run it twice, since the first one is wrong. - Warn when attempting to align based on a top-oriented wall. When the sequence of walls to align has "windows", only the bottom parts will be correct. - Make the modifiers actually useful: * Pressing SHIFT aligns at most one wall, remove the old CTRL modifier. * The rest is as before: ALT makes the walls have (approximately) equal texture stretching, ['] (quote) aligns the immediate TROR-nextwalls.

Also, factor out 2x dup'd code of insertsprite() into do_insertsprite() and add searchwall-displaying code into package/samples/a.m32.

Also, add another flag, signifying that from the editor, also the "lastwall"s (i.e. the CCW-linked points) should get collected. This is to signal the editor that their wall lengths should be displayed, too.