What changed in EDuke32, build by build

Introduced in r3207. Oops.

This may happen if no title/end music is defined from CON. Thanks to Zaxtor for the bug report.

- At a given time, at most one viewscreen may display TILE_VIEWSCR, namely that one which is g_curViewscreen - sync kinds of distance to compare against VIEWSCREEN_ACTIVE_DISTANCE (was Manhattan vs. dist(), now both the latter) - fix resetting to VIEWSCREEN tile when player is greater from it than that distance. When the player is closer to it again, it is *not* reset to TILE_VIEWSCR. - more sync'd g_curViewscreen and sprite[i].yvel (for 'i' being the viewscreen sprite) Note: in a multiplayer context, this needs to be thought about once more.

Also, rewrite the loops in Gv_Free() and Gv_Clear() in the plain fashion so that they are correct even if the number of gamearrays exceeds the number of gamevars.

Specifically, we must make sure that dasizeof <= LZWSIZE (or so) in c1d_{read,write}_compressed() (what the assertion in the last commit was about, and is now redundant). This fixes saving of e.g. large gamearrays with the C-CON build. Bump BYTEVERSION. An alternative for setting dasizeof to 1 would be to factor it and keep dividing as long as it's > LZWSIZE.

Fixes bug reported here: http://forums.duke4.net/topic/1348-mapster32-problems-and-bugs/page__view__findpost__p__213759

Also, some minor style cleanup in game.c. DONT_BUILD.

This reverts/corrects two semantic changes of r4639 as far as what is now voxmodel.c (formerly part of mdsprite.c) is concerned. One correction ends up having no effect (m->bscale is always 1.f for voxel models, as far as I can see), but is the proper rewrite. Also, in osdcmds.c:registerosdcommands(), tweak two help strings.

Specifically, this fixes edit lines for 2 members, e.g. "(X,Y)pan".

This DOES NOT fix the more complex issue discussed at the forums.

The winding of a loop -- with clockdir() -- is determined by examining the two line segments spanned between the points following a leftmost point of the loop. If the loop contains a leftmost point that belongs to the "right" side (as can happen with sliding door constructions), there's a chance that an outer loop is misclassified.

They classify former uses of int64_t into two classes: - coord_t: those that represent coordinates and need 64-bit precision for proper functioning with large values - inthi_t: those that were added for e.g. casts merely to prevent undefined behavior on overflow DONT_BUILD.

NOTE: lizmen may walk on water. I don't yet know why.

Such as "vid_gamma". In that case, setbrightness() would have been called without basepaltableptr having been initialized. The fix is by moving the preparational setbasepaltable() call from ExtPostStartupWindow() to ExtInit(), just before the OSD command dispatching.

This could happen when building outside the "classic" grid limits and would then lead to e.g. incorrect loop assignment on sector splitting. Bug reported by MetHy.

Inspired by http://forums.duke4.net/topic/7506-tror-question/page__view__findpost__p__199151 the corruption checker now checks for certain conditions of the loops of each sector. Recall that CW loops are outer and CCW loops are inner. - If a sector has no or more than one outer loop, count that as corruption (level 4 and 3, respectively). - (Disabled) For sectors with exactly one outer loop, check that all inner ones are inside it. This is currently not compiled due to an asymmetry of loopinside() for degenerate cases, similar to pre-r3898 inside().

- LunaCON: support for setting userdef[].m_volume_number, getting .last_level - bump con_lang.MAXEVENTS - fix compilation of astub.c

DONT_BUILD.

DONT_BUILD.

-sdlayer: Apple and GTK are not mutually exclusive. -Makefile.common: Specify WITHOUT_GTK?=1 by default. -Makefile: Limit linking with the QuickTime framework to OS X 10.6 and below. One fix from me: -osxbuild.sh: Fix building tools.

https://bugs.gentoo.org/attachment.cgi?id=342598&action=edit

1 compiler error. 2 compiler warnings. 1 runtime warning. Note that at this time, CPLUSPLUS=1 LUNATIC=1 fails to build due to C++ function mangling, and Win64 Lunatic crashes. DONT_BUILD.