The problems still remains that rotatesprite behaves differently in classic and
OpenGL modes with clipping boundaries specified (and maybe in some other cases)
git-svn-id: https://svn.eduke32.com/eduke32@2304 1a8010ca-5511-0410-912e-c29ae57300e0
This means that when e.g. emerging from water hurt will change the
palette instantly, but because bit 16 is added to the P_SetGamePalette
call, the tinting is retained.
git-svn-id: https://svn.eduke32.com/eduke32@2303 1a8010ca-5511-0410-912e-c29ae57300e0
The implementation uses the recently introduced updatesector_onlynextwall when
setspritez fails.
git-svn-id: https://svn.eduke32.com/eduke32@2302 1a8010ca-5511-0410-912e-c29ae57300e0
Of course, only when the mod/TC in question doesn't use that feature.
git-svn-id: https://svn.eduke32.com/eduke32@2301 1a8010ca-5511-0410-912e-c29ae57300e0
led out or not. Removing features that certain mods may depend on to operate correctly without throwing any kind of
error or warning at startup other than a logged message is bad.
git-svn-id: https://svn.eduke32.com/eduke32@2300 1a8010ca-5511-0410-912e-c29ae57300e0
for an assertion failure with clang. Really ought to file a bug report instead.
git-svn-id: https://svn.eduke32.com/eduke32@2292 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
The "double-click button4" had to make way for MOUSE5 in the button binds menu,
but I don't think anyone cares. Savegame compatibility was actually silently
broken with the MAXTILES update earlier, but I forgot updating the version...
git-svn-id: https://svn.eduke32.com/eduke32@2284 1a8010ca-5511-0410-912e-c29ae57300e0
Also a couple of other cleanup lines... might need more though, I'm not sure
it's all good there.
git-svn-id: https://svn.eduke32.com/eduke32@2278 1a8010ca-5511-0410-912e-c29ae57300e0
Internally, updateanimation() now takes a third parameter 'lpal'.
git-svn-id: https://svn.eduke32.com/eduke32@2277 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
Ideally, we would also warn when setting WEAPONx_SHOOTS to negative values, but
we'd have to intercept CON's setvar's and it wouldn't be pretty.
git-svn-id: https://svn.eduke32.com/eduke32@2268 1a8010ca-5511-0410-912e-c29ae57300e0
I'm decreasing EXTRATILES because I feel that it's way overcommitted. It's the
max number of model-tiles that have their own skin for a certain palette,
like the slimer egg in the HRP.
git-svn-id: https://svn.eduke32.com/eduke32@2267 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
