What changed in EDuke32, build by build

The remaining checks now "continue;" when an oob tilenum is found where an oob access would ensue else. Also, it's now checked for negative numbers (the message remains the same though).

The primary reason for doing this is that handing of moving sectors is significantly simplified. Because moving sectors usually don't move containing SEs/effector-statnum sprites, no special handing code is needed to move light SEs with them. Thus, this commit sets light SEs to a new statnum when they're spawned *from premap*, and a new G_Move*-like function (called G_DoPolymerLights) is added to process every sprite in that status list. This should "fix" light SEs moving together with a variety of moving sectors, but CON programs expecting the old behavior may break, therefore this commit is marked as experimental. Additionally, a problem with the old implementation is identified: it seems like the correct functioning is dependent upon the order of processing between the sector movement effector and the light SE, so this makes it another good reason for the change. (A third one is that all lights can be processed with a per- statnum loop, but CON coders should not do this until the change is considered final).

- Make MAXXDIM and MAXYDIM macros be 860 and 490, respectively. tueidj says max. screen size is 848x480, but there are oob access bugs in the classic renderer when running with the maximum possible resolution - don't allocate additional sector/wall storage for Mapster (saves ~16k) - Add ud.config.UseJoystick = 1 in config.c, but make it conditional on Wii - remove one comment I no longer believe true, add one TODO comment

This is so that it may be intercepted in the future. The only code that's not replaced by the function call is with the CON interface to g_player[].ps->pals via player[].pals X and .pals_time. Also, comment out one instance because it's overwritten by a succeeding one.

Besides being the compiler's job nowadays, they significantly inflate the size of the debugging builds.

Among other things, comment out very seldomly (or not at all) used sprite member macros: SV, ZV, RX, RY, CX, CY, CD, PL.

- in actors.c, make a static array const (the original patch removed the staticness) - remove one comment and change some compiled-out code - remove commented out pre-Makefile.common stuff Some changes were not adopted from tueidj's patch: - whitespace cleanup - ud.config.UseJoystick = 1 in config.c - Makefile.common, as mentioned before - proper read-in of g_numRealPalettes, because it was done with r2503

- BIGX -> BIGX_, likely again because of a name clash - make a loop in animlib.c iterate in forward direction

This part is a mixture of the original patch and my changes. It seems like tueidj had some trouble 1) getting OGG to work, which is why it's conditionally compiled out 2) struggling with endianness with the mixing routines? This may be also due to him missing to define two others BIGENDIAN macros (our code is in need of cleanup there). Note the change in jaudiolib/src/mix.c! Because I added my share to this part, I might have actually broken sound mixing on big-endian platforms.

On the Wii, V7 (i.e. original) map limits are used and the maximum screen size is 1600x1200.

- conditionally compiles out some code intended for the PC platforms - compat.c: get home directory routine, access() implementation - game.c: don't use ioctl(), lower cache1d size to 8 MiB, Wii-specific initialization code and application directory ("apps/eduke32")

This simply macro-defines various low-level networking functions.

For the Wii, SDL's mutex functionality is used. The implementation in the original patch was wrong though, so this part required non-trivial changes.

- the crosshair is displayed at the position read from the absolute pointing device - in the menus, use the hat input (that was mapped to mouse buttons in part 4) for navigation

- sdlayer.c: custom "get joystick button names" routine - jmact/mouse.c: packs some joystick events into the value returned by MOUSE_GetButtons(): bits used are 256, 512, 4096, 8192 - MOUSE_Init() --> Mouse_Init(), presumably because of a name clash? - comments out right-shift of joystick analog values by 5, maybe this fixes the scale problems with the joystick on the PC too?

This part adds support for an absolute pointing device.

Because gltexinvalidate*() could be called too often when setgamepalette is used while having a tint overlaid else. Pending thorough analysis/reworking of the 32-bit mode base palette handling / texture invalidation.

That is, have a second loop over all models run for each deleted tex and null the texname. This is ugly, sure, but it's better than calling glDeleteTextures on stale names.

- factor out a longish expression - whitespace, move a var down - remove unneeded casts (recall: "usual arithmetic conversions") - strcat -> Bstrcat, strcpy -> Bstrcpy

- bump lpeg stack limit to 1024 (hack) for long if/if/if...else chains - lexical: newline, EOF and whitespace; "bad" identifiers; hex literals, newline terminated strings (allow empty string) - syntax: allow nesting of array expressions, it's easier than special-casing; handle issues with structs expecting parm2 (hackish); userdef; switch/case/default - fix parsing some commands; mind prefixes! - frontend: if failing match, print last keyword and its position; warn on "bad" identifiers (one per such); batch processing from command line - Files that locate finds from my linux box now pass (except where there are really syntax errors).

Specifically, it was in the "determine searchwall when aiming at floor or ceiling" part. Now, if prsectors[]->ceil.plane (or ->floor.plane) is NULL, we set the searchwall to the sector's firstwall and return.

- 4 instances -> HandleSE31 - 4 instances -> MaybeTrainKillPlayer - 2 instances -> MaybeTrainKillEnemies - move a couple of variables into inner blocks and add 'const' for easier reading In passing, fix a minor glitch where the squishing sound of an enemy that got run over by an SE 6 or 14 car would appear to originate from the SE instead of the enemy's last position.

This properly fixes the unwanted vertical lines.

Of course, it's just for the heck of it, since this setting is not saved into MAP files. I kinda like the cylindrical projection...

This has been there since searchbottomwall introduction in r1466.

Previously, we only set the viewingrange according to the physical screen's dimensions, but didn't correct yxaspect for a potential non-square pixel ratio.

Consequently, it's not saved as a setting in either the game or editor config files. We do this by calling "GetSystemMetrics(SM_CXSCREEN)" (accordingly for y) and calculating the cvar by dividing common factors, since it has to be in the form WWHH. This may fail for _really_ strange screen dimensions, so a log message is printed at the very beginning.

Because this doesn't even seem to work on XP, we're being spammed with DDERR_SURFACELOST messages...

Previously, it was possible to leave a sector with less than three walls if a point got deleted transitively by a TROR link. Now, a proper check is done for all deletion candidates and a message stating which wall and sector is problematic is printed. Thanks for Diaz for pointing out the brokenness.

Currently syntax only. Parses the original scandcode 0x1d files, which is harder than you'd imagine given the relatively simple structure. Chokes on new-gen custom stuff.

- strip 'inline' from animateoffs() definition, remove declaration in build.h - one min/max -> clamp - one malloc/strlen/strcpy -> strdup

If one next instruction happened to be interpreted, madness would ensue, because the pointer wouldn't be aligned on the "opcode" part anymore. Also, with "seti", set current sprite index only after a successful validation.

This get into the writable variable the "linking type" of the sprite with index <spritenum>. The result is a bit field of ORed values: 1: lotag has linking semantics 2: hitag 4: extra, 8: xvel, 16: yvel, 32: zvel, 64: owner (custom only) Custom setting about which sprites have what kind of linking can be programmed via EVENT_LINKTAGS: it receives a sprite index as the 'current sprite' and is supposed to return the bit field in RETURN. An example which lists sprites and their linking hi- and lotags is provided in the state 'listusedtags' in a.m32.

- factor out many identical checks in a convenient function; some messages may read slightly differently now and tile ranges may be handled more strictly (error out if one of the limits is invalid) - factor out two instances of identical (up to one arg) code into tile_from_truecolpic - factor out setting picsiz[] and stuff into set_picsizanm - some checks - Make "undefmodelof" non-functional and warn. - in "animtilerange", if the tile difference is >= 64, error out since we can't store it in picanm[]

This was more or less done by trial and error rather than understanding what exactly is going on there. In any case, the code for all the different ending scenes ought to be factored out instead of being duplicated with subtle differences every time.

This requires one tweak in drawrooms' umost/dmost setup to prevent oob access. Specifically, a coordinate difference of 0 is allowed. In the classic renderer, this would mean a one-pixel (real screen coords) height or width. In Polymost, it would currently mean a one-pixel height and zero-pixel width, but this might be subject to change.

The showview command transforms the 320-based screen bound coordinates to the real screen bounds like xreal = (x*xdim)/320, which shows a bias towards zero: for example, for a 1680 screen width, the maximum permissible value 319 is mapped to round_to_zero((319*1680)/320) == 1674. (The rounding is implicit in the integer division). This makes it impossible for a view to cover the whole screen with any other resolution than 320x200. The new command transforms the bounds like xreal = (x*(xdim-1))/319, which would map 319 to 1679 in the preceding example.