Cosa è cambiato in EDuke32, build per build

is picked" but still not perfect. In particular, sometimes a wrong wall is selected, and sprites don't get picked through portals. As a rule of thumb, don't be too far away from the objects you're modifying in 3D mode.

before, and additionally a mode that doesn't clip against masked walls and sprites.

traverse the TROR neighbors.

uint64_t gethiticks() and gethitickspersec(). For SDL 1.2, the timer has the same resolution as getticks (1000 Hz). For Windows and SDL 1.3, the resolution of the underlying perf-timers is used. The only user of these functions right now is some TROR on-screen debugging code. Revert an earlier change regarding r_preview_mouseaim. We can't do the check because editstatus is set later.

the additional rendering pass - Remove r_preview_mouseaim cvar from the game, since it's only for Mapster - sdlmusic.c: (Failed) attempt to fix a call of waitpid() with a non-existent process ID in the external MIDI playing code. I think there's a race there...

functionality, Polymost). The new feature can be enabled/disabled with the 'r_tror_nomaskpass' cvar. The basic idea is that when drawing lower or upper levels, a first pass is performed that ignores all red walls for which the TROR nextwall link 'towards' the viewer arrives at a red wall. Thus, in the worst case, there can be up to twice as many rendering passes now (when it is discovered that the no-mask-pass isn't different that what would be drawn with the ordinary one, the latter is skipped, since we've already drawn all needed geometry). Hovever, this kind of multi-pass splitting is only suitable for simple scenes, like the upper subway in the TROR test map. In particular, multiple islands shouldn't 'see' each other. Two issues are worth mentioning: first, care needs to be taken for translucent ceilings or floors, since drawing them twice isn't the same as drawing them once. This is done for classic, but not for Polymost. Second, sprites (which are always drawn _after_ the geometry for a given pass) are still clipped to the geometry of the ordinary pass, resulting in their disappearance from certain angles. -- Additionaly, a change made it into this commit that fixes redundant collection of sprites in TROR:classic/Polymost.

- remove 'imageSize' global which was always yres*bytesperline and only used once - some clearbuf() -> Bmemset() because I find the latter easier to read - remove some clearbufs to 0 of some global arrays on init

always like this now: ExtUninit -> (writesetup, misc.) uninitengine -> (uninitsystem -> (uninit timers, mouse, ...)) exit() Some paths still lead to a plain exit(), like failures in cache1d.c or mdsprite.c

- one reported by Micky: http://forums.duke4.net/topic/3911-true-room-over-room/page__view__findpost__p__106610 - malloc(0) call when saving a map with no sprites - update 'asksave' after Alt-S and corrupt-check on starting a new map

palette changed from the last one (either globally or within the last call of one of the function). This fixes the ugly OSD flickering in 8-bit mode when a screen tint effect is in action (such as when being hurt or snotted on).

engine, since it had no users.

This will prevent it from calling gltexinvalidateall() when e.g. submerging and resurfacing, mimicking the behavior of the game, where only gltexinvalidate8() is called in such situations.

with 'corruptcheck now', but still print each corrected one on tryfix.

effects: 1) Mouse turning works with SDL 1.3 2) The mouse pointer can't leave the window area with the console up, so that focus always stays with the application 3) Menu selection using the mouse doesn't work. Not dramatic IMO.

is present (like in E4L1). Also sneak in a trivial change in cache1d.c

fix two issues with signed integer overflow. One is related to clipping and the other to Polymost mouse-picking for overlong walls. Many more remain especially in the 8-bit rendering code, but I expect many of them to be intended.

is to remove a couple of 'inline's for functions with external linkage, which seems to be a GCC convenience.

name into m->head.nam after loading (but before preprocessing for Polymer)

Specifically, now also consider the sprite tile's yoffset, and fix an issue when a tsprite got duplicated 'toward' the viewer. Also add a couple of tests in trueror1.map.

hold file lengths is certainly very frownworthy.

This makes the latter also correct when testing a map from the editor.

With script_expertmode enabled, SHIFT-BACKSPACE clears the upwall link and CTRL- BACKSPACE the downwall link. These functions are useful because the automatic nextwall determination code sometimes gets it wrong (not corrupting anything) or if you want to vertically displace a sector attached to a higher or lower level. Also add the exploding ceiling example to the TROR test map.

TROR portals that works with a little help from updatesectorz() (change not visible from CON code). Relies only on the presence of an extension whose portal isn't blocked and also plays nicely with corner cases like being shrunk and enabling the jetpack. This should fix the upward moving platforms in WGR2.

on the command-line isn't found (instead of saying nothing) * editor: Move inconsistent (stat&2)/heinum detection into the corruption checker. This makes a lot of original maps spew countless 'errors', but it's preferable for new maps since such floors and ceilings could behave strangely with TROR.

In cases where performing occlusion queries for multiple red walls leading to the same sector, we would sometimes leak a number of query objects. This was apparently harmless on NVIDIA drivers, but would leak tons of memory on ATI.

The code was using the Polymer-cached version of the sector cstat to determine the translucency of its diffuse material, meaning it would never get it right on the first try; that's what you get for having completely different variables named 's' and 'sec'.

We normally enable backface culling always, but turn it off for two-sided sprites; we need to make sure it's re-enabled after that as sector masks are drawn after.

Some of the ROR code was operating under the assumption that drawasks always correspond to one call of polymer_displarooms(), but that's not necessarily the case; external view draws all sectors from the top polymer_drawrooms(), which was causing crashes. Just ignore the sector mask queues in external view mode, we already don't draw masked walls.

Check all the bunch siblings if we get a floor/ceiling hit and walk them if their own planes hit.

When walking the sectors in displayrooms, detect floor/sector masks to place them in a mask queue. The queues are allocated on the heap, but a stack pointer is maintained by the displayrooms to allow it to play nice with mirror recursion. Right now the masks are drawn after all of drawmasks is finished; that means you can see sprites and wall masks through sector masks, but not the opposite. There is a slight attempt at blending far to near, but nothing too conclusive yet; that means that in some cases some sector masks won't be visible through other sector masks, but it should work for trivial cases. The next step would be to copy all the drawmasks logic into Polymer and have it (attempt to) properly interleave sector masks where they belong in the blending order.

Previously they would get counted both as 1-way walls for immediate drawing and as mask walls for delayed drawing.

Doesn't actually matter that much.