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
I'm not getting this warning (synthesis is) but I think it's justified because
the VOC block parsing code isn't terribly validating...
git-svn-id: https://svn.eduke32.com/eduke32@2364 1a8010ca-5511-0410-912e-c29ae57300e0
The following functions have const qualifiers attached for the 'destination'
arguments: kdfwrite, dfwrite in cache1d.c and copybuf{byte,reverse,} in the
pragmas source or headers. A couple uses of the latter ones were replaced
with calls to standard library functions.
git-svn-id: https://svn.eduke32.com/eduke32@2361 1a8010ca-5511-0410-912e-c29ae57300e0
- RENDERER SETUP is now also accessible from classic, with only 2 options:
'aspect ratio' and 'ambient light level'
- remove the latter option from the VIDEO SETUP menu
- When compiled with OpenGL, the aspect ratio option cycles between 3 states:
r_usenewaspect=1 (the modern way), and r_usenewaspect=0 but r_widescreen=0/1.
In non-GL builds, there are only 2 states.
- don't display black translucent overlay in COLOR CORRECTION menu
git-svn-id: https://svn.eduke32.com/eduke32@2358 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
- Maintain a position relative to the start of the data. VOC doesn't
mandate an EOF marker (blocktype 0). If we go over the end, fake
that marker, so as to restart a looping sound or stop a one-shot one.
This fixes an uninitialized mem access with the corrupt SNAKRM.VOC.
- When encountering the EOF marker, don't read the 3 bytes of block size,
since they may not be there.
- Read blocksize by ORing and shifting the 3 bytes, not with *(int32_t *)...
git-svn-id: https://svn.eduke32.com/eduke32@2346 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
This fixes updateanimation picking up foreign (and thus potentially oob)
frame numbers at "3: c > n".
git-svn-id: https://svn.eduke32.com/eduke32@2339 1a8010ca-5511-0410-912e-c29ae57300e0
Uncomment #define DEBUG_VALGRIND_NO_SMC in duke3d.h to be able to
valgrind --smc-check=none (or the default stack-only)
with Polymost and Polymer renderers.
git-svn-id: https://svn.eduke32.com/eduke32@2337 1a8010ca-5511-0410-912e-c29ae57300e0
It was causing update issues when many tints were applied simultaneously,
like being shot and spit at by enforcers while being on rails barefeet.
Also, the GL modes were calling gltexinvalidate8() when picking up goodies
or being hurt with that change, so it needs much more thought.
git-svn-id: https://svn.eduke32.com/eduke32@2322 1a8010ca-5511-0410-912e-c29ae57300e0
This fixes a bug in passing: 'int32_t j' was assigned to as a temporary inside
one instance of the code, but used as if it were the previous sprite index
further on. Would only happen with projectiles that "work like" both SPIT
and RPG_IMPACT.
git-svn-id: https://svn.eduke32.com/eduke32@2321 1a8010ca-5511-0410-912e-c29ae57300e0
- make PGUP/PGDN and HOME/END behave as expected across all menus
- in keyboard/mouse button mapping menu, draw function names that have been given
custom names via CON with pal 8 for easier recognition
- fix tinting of function names in mouse button mapping menu
git-svn-id: https://svn.eduke32.com/eduke32@2313 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
So that the game won't exit if you write 'vidmode 4' when intending
'setrendermode 4'.
git-svn-id: https://svn.eduke32.com/eduke32@2311 1a8010ca-5511-0410-912e-c29ae57300e0
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
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
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
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
- 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
- '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
Since the original source code release of Duke3D, there was a potentially
dangerous hack where actor[].dispicnum was set to -4 to signal "this actor
should not have a floor shadow for this moment" (it doesn't really work,
if you ask me).
Now, use another bit of actor[].flags for that purpose because setting
any picnum members to negative values asks for trouble.
git-svn-id: https://svn.eduke32.com/eduke32@2249 1a8010ca-5511-0410-912e-c29ae57300e0
E.g. this should work correctly now:
// FLY_BY, PIPEBOMB_EXPLODE, OCTA_DYING
animsounds logo { 1 244 64 14 64 144 }
git-svn-id: https://svn.eduke32.com/eduke32@2243 1a8010ca-5511-0410-912e-c29ae57300e0
The syntax is as follows:
animsounds <anim> { frame1 sound1 frame2 sound2 ... }
<anim> has to be one of the tokens: cineov2, cineov3, RADLOGO, DUKETEAM,
logo, vol41a, vol42a, vol4e1, vol43a, vol4e2, or vol4e3, corresponding
to hard-coded Duke3D anims.
The frameN's (1-based frame numbers) have to be in ascending order (but not
necessarily strictly ascending, so that a frame may have more than one sound).
Example: for Duke3D's XBLA nuke logo animation (IVF extracted from nuke.webm),
the following definition overlays the video with a sound sequence similar
(identical save for timing) to the original nuke animation:
// frame 1: FLY_BY, frame 64: PIPEBOMB_EXPLODE
animsounds logo { 1 244 64 14 }
git-svn-id: https://svn.eduke32.com/eduke32@2242 1a8010ca-5511-0410-912e-c29ae57300e0
the loop. For the release build and the test animation, this lowers the time
to 3-4 ms per conversion of one frame on my desktop machine.
git-svn-id: https://svn.eduke32.com/eduke32@2241 1a8010ca-5511-0410-912e-c29ae57300e0
the SE ones douple, triple, ... after each save. Maphack lights are reloaded
with polymer_resetlights() (though I've had them disappearing after load, I
couldn't reproduce it afterwards).
- in debugging builds, print a message when polymer_resetlight is called on a
nonexistent one. The problem is not so much the call itself (it's guarded),
but the fact that resources on the caller side may not have been freed if it
thinks that those lights do in fact exist. Right now, it's not the case though.
- add 'loaded map hack' messages after some other successful loadmaphack calls
git-svn-id: https://svn.eduke32.com/eduke32@2236 1a8010ca-5511-0410-912e-c29ae57300e0
crashes.
Usually, after loading a game, some wall tiles are tweaked depending on whether
adult mode is enabled or not. If it's not, those wall picnums are replaced
with blank or broken screens. If it is, they are restored from the wall's
.extra member. Apparently though, Mapster32 leaves some .extra members
floating around even after deleting a TROR nextwall link (it's used as the
'lower wall index'). Because MAXWALLS is greater than MAXTILES, this may
produce out-of-bounds accesses and corrupt memory (besides setting wall
tilenums to nonsensical values) later in the game.
Other than that, the change only affects loading savegames created with adult
mode OFF. Kinky TV screenies simply won't be restored then.
git-svn-id: https://svn.eduke32.com/eduke32@2235 1a8010ca-5511-0410-912e-c29ae57300e0
check one 'if' down since mirrors are only created when the condition holds
git-svn-id: https://svn.eduke32.com/eduke32@2233 1a8010ca-5511-0410-912e-c29ae57300e0
Resetting the gamevars might produce inconsistencies between an earlier loaded
game (for example, if it was saved with different/earlier CON code), and worst
of all, the gamevars that reference C variables might be overwritten (i.e. the
addresses to those variable, which is very bad!).
git-svn-id: https://svn.eduke32.com/eduke32@2230 1a8010ca-5511-0410-912e-c29ae57300e0
certain situations (mostly cutscenes etc). This commit removes bit 1 from all
flags that make it to setbrightness, the meaning of which is "don't actually
update the palette". I have no idea what it was for and since the corresponding
P_SetGamePalette() calls were from places like the mentioned cutscenes, I don't
think it matters performance-wise.
git-svn-id: https://svn.eduke32.com/eduke32@2223 1a8010ca-5511-0410-912e-c29ae57300e0
the constants 0 and 1, and moveptrs may reference the script up to index 2
then (though I'm not sure whether the code is reachable with moveofs either
0 or 1), so make sure it's nulled instead of whatever happened to compile at
the first two positions. Move 1 is only used once in the original cons,
when frozen and being shattered.
git-svn-id: https://svn.eduke32.com/eduke32@2211 1a8010ca-5511-0410-912e-c29ae57300e0
Now we don't need to worry about the numbers running out soon.
Bump BYTEVERSION by three to celebrate this, too.
git-svn-id: https://svn.eduke32.com/eduke32@2209 1a8010ca-5511-0410-912e-c29ae57300e0
This makes savegames practically the same as the initial snapshot of a demo.
Saves are now named 'dukesavX.esv' (demos: 'edemoX.edm').
Additionally, many changes that couldn't/needn't be cleanly separated are added
with this commit:
- make spriteext_t have the same size across 32/64 bit platforms (actor_t partially)
- prevent saving/loading in MP games (it certainly didn't work and still doesn't)
- it's time we start using assertions! Define NDEBUG for releasse builds.
- reset savegame major and minor versions (we have a new magic string, so no conflict)
git-svn-id: https://svn.eduke32.com/eduke32@2207 1a8010ca-5511-0410-912e-c29ae57300e0
It was identified with the clearfrags rewriting, but not corrected.
git-svn-id: https://svn.eduke32.com/eduke32@2203 1a8010ca-5511-0410-912e-c29ae57300e0
There were two instances of nearly identical code in premap.c and savegame.c.
Also identifies a (harmless) problem with realloc'ing, we had:
if (len+1 > sizeof(MapInfo[...].musicfn))
MapInfo[...].musicfn = Brealloc(MapInfo[...].musicfn, len+1)
which reallocs almost all the time (since .musicfn is a pointer). Now we do
realloc every time...
git-svn-id: https://svn.eduke32.com/eduke32@2202 1a8010ca-5511-0410-912e-c29ae57300e0
