What changed in EDuke32, build by build

Classic HUD now has correct aspect in widescreen modes, so with the full status bar, there may be patches of free room left to the left and right.

setaspect(), which is called by setaspect_new, already uses the *dimen variables, so it's the same thing done twice. Now, a change from the original full status bar to the original mini status bar keeps the horizontal FOV again and only bumps the view a little higher, as with the classic aspect determination.

Compare with revision 2584.

This means that classic and the GL modes now look the same as far as e.g. hud_bgstretch or HUD weapons are concerned.

That is, use the view boundries instead of the whole screen.

See the source for why this hack is ugly.

This makes the code rather more readable in some places. Unlike the two preceding commits, this one is actually purely textual replacement.

Functions affected are G_Move* in actors.c and A_Shoot in player.c. Here, the p variable had function scope, now it's redeclared in shorter blocks. I'm still relatively sure that no observable behavior was changed, though not as sure as in part 1. Also, some dead assignments and the like are eliminated.

The p variable (sometimes named differently) has short scope in all cases, so I'm almost sure that the replacements amount to an identity transformation.

... against invalid weapon indices and arguments accessed from arrays/structs.

Also, rewrite the mapastats iterator and the LIZTROOP hitscan timing in terms of that.

The build script now has two more presets: helix and installtools (which was previously attempted after the build; untested). Also, - when detecting git, run commands such that the SVN repo isn't accessed - package kextract, kgroup and arttool into tools/ in the zip - try to exit on failure in some places, though that doesn't seem to work

The idiv instruction also signals an FPE when the resulting *signed* quotient overflows, so we simply use div instead.

erratum in r2844 commit message: ydim vs. bytesperline --> xdim vs. bytesperline

This was narrowed to int8_t in r1625, breaking CON code that wanted to lock the player for a longer time than 127 game tics.

The tiles used are BIGHOLE (1141) and VIEWBORDER (3250). Ideally we'd draw the console background using something specially-coded instead of rotatesprite if it's fully black anyway.

These could manifest themselves as garbage lines on the bottom and happened because of the ydim vs. bytesperline discrepancy again.

Instructions on how I built the libs are in Windows/src/minipng.dfa.

If input is cleared before, it can become impossible to cancel the video when decoding and displaying a frame takes longer than a frame.

The library was built with GCC 4.6.1 and configured like ./configure --disable-vp8-encoder --disable-multithread --disable-spatial-resampling On the aforementioned AMD system, this reduces the mean time for decoding a frame from 18.2 to 15.4 ms, so IMO it's worth the somewhat hefty addition of 430 Kb.

On an AMD Phenom II X4 system with generic memory modules, this brings down the mean time for this conversion from 16.5 to 10.5 ms. (GCC 4.6.1, optimized build)

This changes a constant inside the panning calculation from 256 to 255 (making e.g. panning 255 and 0 the same in the "San Andreas fault" sign in E1L5) and uses the correct reference wall for the "do panning correction?" conditional. Now, the problematic walls should look the same as in Polymost.

This makes the corrections conditional on where they appear in (under-, over-, white or mask wall).

I'm willing to make this one concession to correctness in the name of backward- compatibility. I think that one reason why this has never cause a crash is that tiles in BUILD are allocated in Ken's big allocache buffer, so oob accesses were dampened by that (though they hit uninitialized data).

The event is run after drawing the scene, but before the overlays. To make a screenshot from a script, set DOSCRSHOT to non-zero. It will then be scheduled to run once after the drawing but before the above-mentioned event. The screenshots will be called mcapXXXX.{png,tga}.

This would only hit when polymost_printext256 erred out (mem alloc failure, glGenTextures failure), i.e. "almost never". Also, tweak a bound check in polymost_printext256.

The editor colors are the ones listed on page 9 of the Mapster32 built-in help.

Non-pow2 wall/mask drawing in classic introduced cases where walls are drawn "incorrectly" because they were constructed with the old behavior in mind. Polymer appears to "correct" for it partially, but doesn't cover all cases. Specifically, now we have: - E1L1 first inside secret room (5000, 50000): Polymer draws like Duke 1.5, classic now draws with an offset. - E3L2 near the vault (-20000, 25000): both classic and Polymer draw with offsets compared to Duke 1.5, but they're different! This means that more research is needed into what makes these two cases diverge, even though both have the same root cause. !!! Also, mappers should abstain from using non-power-of two textures on walls until this issue is resolved in a satisfactory fashion !!!

This was introduced with r2771, which fixed e.g. AMC TC city_si's mirrors, but instructed the base drawrooms inside yax_drawrooms to not correct the passed sectnum. Therefore, stuff would get drawn wrongly when passing sector boundaries, like from the platform to the rails in trueror1.map.

Some more drawing glitches remain.