When drawing from inside the mirror, there may be no 'bunches' (BUILD lingo,
not TROR ones) collected, but following code used the first one unconditionally.
git-svn-id: https://svn.eduke32.com/eduke32@2427 1a8010ca-5511-0410-912e-c29ae57300e0
The apparent horizon (in units proportional to pixels by a constant factor)
was being calculated without normalizing to viewingrange, resulting a
discrepancy between the drawn and actual up/down angle with non-default
viewingranges (e.g. with r_usenewaspect=1, or when setting it from setaspect).
This also means that the center-of-aim will now be the same regardless of
the aspect.
This fixes many derived bugs:
* inconsistency w/ crosshair when shooting a gun and aiming up/down (obviously)
* bugs resulting from being able to look up/down too far (garbage non-slope
texture-mapping and viewing BIGORBIT skies above the borders in classic).
Note: mods that had workaround logic for this bug will have to remove it...
git-svn-id: https://svn.eduke32.com/eduke32@2414 1a8010ca-5511-0410-912e-c29ae57300e0
This has no measureable difference. Oh well, maybe it benefits weaker
machines, since the generated loop code should definitely be prettier.
git-svn-id: https://svn.eduke32.com/eduke32@2408 1a8010ca-5511-0410-912e-c29ae57300e0
This doesn't give much, maybe 0.5 fps more, probably because the
loop body is pretty long.
git-svn-id: https://svn.eduke32.com/eduke32@2406 1a8010ca-5511-0410-912e-c29ae57300e0
(Classic renderer). We don't need 64-bit integers; also use the nice
asm version of divscale32() if possible.
git-svn-id: https://svn.eduke32.com/eduke32@2390 1a8010ca-5511-0410-912e-c29ae57300e0
This was discovered because viewscreens (TILE_VIEWSCR) ceased being drawn
with the MAXTILES increase (reported by Hank, who also did the bisect).
git-svn-id: https://svn.eduke32.com/eduke32@2376 1a8010ca-5511-0410-912e-c29ae57300e0
That is, everyplace a user input is to be converted. The only remaining
instance of atoi() is now atoi(s_buildDate).
git-svn-id: https://svn.eduke32.com/eduke32@2374 1a8010ca-5511-0410-912e-c29ae57300e0
Internally, the last argument to neartag is now a pointer to a function
int32_t (*blacklist_sprite_func)(int32_t i),
which is supposed to return 1 if sprite[i] should NOT be considered for hitting.
This is now used in the hard-coded neartag() calls in sector.c, but not in any
way in CON (there's neither a C blacklist function provided, nor is there a
possibility to define one in CON). There, all sprites with picnums >=1 and <=10
(i.e. the effectors) will be blacklisted. This remedies problems where such
sprites would get in the way of switches.
Note that a whitelist approach (only consider a predefined set, namely those
picnums which will be checked afterwards) has back-compatibility implications
since people may have used e.g. lotagged window sprites to cover a switch.
Also, the >=1 to <=10 range is [sic] (the static, not dynamic values are used),
since anyone redefining effector picnums is clearly out of their mind.
git-svn-id: https://svn.eduke32.com/eduke32@2373 1a8010ca-5511-0410-912e-c29ae57300e0
The bulk are whitespace changes; the only exception is a
"if (expr) { stmt; }" --> "if (expr) stmt;"
git-svn-id: https://svn.eduke32.com/eduke32@2353 1a8010ca-5511-0410-912e-c29ae57300e0
The reason was that drawmasks(), which was where the resetting of the fake
RoR textures happened under Polymer, can be called from polymer_displayrooms()
when mirrors are present. I was assuming that drawmasks() was only ever called
after the 'main' drawrooms and that hence the sequence of fake RoR tile tweaking
was set, reset, set, reset, ... which it was not.
Now, do the resetting explicitly after every drawmasks() in the editor.
git-svn-id: https://svn.eduke32.com/eduke32@2350 1a8010ca-5511-0410-912e-c29ae57300e0
I find this cleaner for two reasons. First, lotags won't get in the way of
neartag(), so that doors and switches near constrained TROR walls can be
pushed. Second, this removes the information leak so that CON coders aren't
tempted to read that values directly before a proper API for that comes along.
When writing out a map in-game (e.g. with dndebug), restore the respective
members so that it can be loaded in the editor again.
git-svn-id: https://svn.eduke32.com/eduke32@2349 1a8010ca-5511-0410-912e-c29ae57300e0
getzrange() returns the floor rather than the sprite if their heights are
equal. Now, make an exception for extended floors (analogously, ceilings).
git-svn-id: https://svn.eduke32.com/eduke32@2347 1a8010ca-5511-0410-912e-c29ae57300e0
- guard cansee() against negative sectnums (return 0 immediately), since
it's often called with the player sectnum as one argument
- in resetpspritevars(), don't inset APLAYER sprite if sectnum < 0, which
can happen if a map is started in void space accidentally (e.g. from
the editor)
- two checks before accessing sector[] with a player sectnum
git-svn-id: https://svn.eduke32.com/eduke32@2342 1a8010ca-5511-0410-912e-c29ae57300e0
Internally, there's a new function fade_screen_black() that implements the
fading more efficiently than calling rotatesprite for classic, and uses
tile 0 (assumed to have at least 64x32 size) in the GL modes.
The black background of the user map selector is still done with rotatesprite
and tile BLANK in every renderer.
git-svn-id: https://svn.eduke32.com/eduke32@2312 1a8010ca-5511-0410-912e-c29ae57300e0
It looks like GCC doesn't honor the 'used' attribute with LTO. This is
"fixed" by declaring the variables in question with external linkage
(i.e. removing the 'static'). I consider such behavior a GCC bug, though.
git-svn-id: https://svn.eduke32.com/eduke32@2286 1a8010ca-5511-0410-912e-c29ae57300e0
This may fix compilation for optimized builds with GCC or clang where
the compiler would otherwise decide that those symbols are unused.
git-svn-id: https://svn.eduke32.com/eduke32@2271 1a8010ca-5511-0410-912e-c29ae57300e0
If enabled, this makes the following arrays be allocated statically:
spriteext, spritesmooth, sector, wall, sprite, tsprite, while
necessarily disabling the clipshape feature (because it relies on
setting sector/wall to different malloc'd block temporarily).
To compile, pass DEBUGANYWAY=1 in addition to RELEASE=0 to 'make',
and it's really only useful with CC=clang, of course.
git-svn-id: https://svn.eduke32.com/eduke32@2270 1a8010ca-5511-0410-912e-c29ae57300e0
- fix one bound-checking line
- rewrite two lines in astub.c to potentially not overflow an int16
- make tiletovox[] an array of int16's
git-svn-id: https://svn.eduke32.com/eduke32@2266 1a8010ca-5511-0410-912e-c29ae57300e0
Always malloc that buffer. This allows us to remove suckcache() from
cache1d.c, which I believe to be buggy (see comments in the source).
git-svn-id: https://svn.eduke32.com/eduke32@2261 1a8010ca-5511-0410-912e-c29ae57300e0
- 'whitecol' was defined in the engine and in build.c, use only the engine one
- make cachesize, artsize, artversion static in engine.c
- undo some formatting havoc presumably done by astyle
git-svn-id: https://svn.eduke32.com/eduke32@2260 1a8010ca-5511-0410-912e-c29ae57300e0
It is likely that this is the value it used to have at some point, because
the MAXTILEFILES macro equals 256 and is as old as the Duke3D source.
loadpics() now refuses to load an ART file with localtilestart or localtileend
out of bounds, or if localtileend<=localtilestart (i.e. no tiles in ART file, or
nonsense). Also, on 'invalid art file version', continue instead of returning.
Note: this does not increase the maximum number of tiles, which is still 15360,
it only gives a bit more freedom to arrange them (well, into more art files).
Also, I don't see what anyone keeps off from packing any number of tiles (from
1 to 15360) into an art file. Old EDITART limits?
git-svn-id: https://svn.eduke32.com/eduke32@2259 1a8010ca-5511-0410-912e-c29ae57300e0
The cause was a combination of many factors. First, Polymer requires the
start-drawing position to be inside the sector to draw (deviations lead to
incorrect drawing). This was violated by the game, because it interpolated
the current and next tic position without updating the sectnum, leading to
inconsistencies especially when passing through narrow sectors. Polymer
worked around it by doing an updatesector() each frame, however this works
poorly for maps with overlapping geometry such as SoS or RoR.
The solution to this is to add a new engine function,
updatesector_onlynextwalls(), which searches the sectors (via nextsector)
in breadth-first fashion instead of from 0 to numsectors-1, like updatesector
does when it fails for the *immediate* nextwall neighbors.
Internally, the breadt-first search helpers are moved into the engine.
git-svn-id: https://svn.eduke32.com/eduke32@2256 1a8010ca-5511-0410-912e-c29ae57300e0
'frequently' isn't such a good idea. Assume an actor constantly changes the
palette to some value and you're attacked by a newbeast at the same time. Then
the pain tinting would be reset each time the actor's code is run. This commit
adds a new flag 16 to setbrightness(), meaning "don't reset the fade tinting".
Its only use right now is from CON's setgamepalette command (and there, always).
The change is done in the engine and thus affects all platforms.
git-svn-id: https://svn.eduke32.com/eduke32@2225 1a8010ca-5511-0410-912e-c29ae57300e0
color-inversed shots. For both PNG and TGA, change the way they're
done in 8-bit mode: instead of XORing every byte with 15, save the
inverse palette (each component taken 255-x).
git-svn-id: https://svn.eduke32.com/eduke32@2219 1a8010ca-5511-0410-912e-c29ae57300e0
instead of shorts. This fixes their values' overflow in AMC TC megabase and
probably a couple of other large maps.
git-svn-id: https://svn.eduke32.com/eduke32@2216 1a8010ca-5511-0410-912e-c29ae57300e0
32- and 64-bit platforms. Also, make struct type actor_t also have a common
size of 128 bytes. New code currently disabled and #ifdef'd for comparison.
This requires certain t_data[] entries ([1]: move ptr, [4]: action ptr and
[5]: ai ptr with actors) to be converted to script offsets instead of pointers,
breaking savegame and net packet compatibility (we could in theory try hard not
to, but it would be too much trouble).
git-svn-id: https://svn.eduke32.com/eduke32@2185 1a8010ca-5511-0410-912e-c29ae57300e0
Actors are always moved such that _they_ clip against blocking sprites, even
if their blocking bit is clear. Setting the new bit make them not clip against
anything. The promary use of this is for decorative moving sprites that are
spawned in masses, such as rain or snow.
git-svn-id: https://svn.eduke32.com/eduke32@2184 1a8010ca-5511-0410-912e-c29ae57300e0
