- 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
so try and steal it back"), prevent calling IDirectDrawSurface_SetPalette()
with NULL arguments, causing a crash. It's happened for me on Vista, when
initially changing from 8-bit to 32-bit mode.
git-svn-id: https://svn.eduke32.com/eduke32@2255 1a8010ca-5511-0410-912e-c29ae57300e0
I didn't have much success in finding bugs using it, but it works
out-of-the-box on my setup, so it may be useful in the future.
git-svn-id: https://svn.eduke32.com/eduke32@2254 1a8010ca-5511-0410-912e-c29ae57300e0
The second one is passed to the 'mouseb' variable, but the game currently
can't map it since ud.config.MouseFunctions[] would have to be enlarged,
breaking savegame compatibility.
Works both for the Windows and SDL layers. For the latter, instead of using
the SDL_BUTTON_X1/X2 macro constants, I'm using 8 and 9, since that is what
SDL (and incidentally or not, xev) gives me for those buttons.
git-svn-id: https://svn.eduke32.com/eduke32@2252 1a8010ca-5511-0410-912e-c29ae57300e0
It turns out that with model interpolation, out-of-bounds frame numbers may
be generated with thinned out models, so disable it until I can sort out
what's wrong with it.
Also, minor code cleanup.
git-svn-id: https://svn.eduke32.com/eduke32@2251 1a8010ca-5511-0410-912e-c29ae57300e0
Also, for debugging builds, show this message from verbosity level 1 on.
git-svn-id: https://svn.eduke32.com/eduke32@2250 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
the only visible change is that polymost_trytexcache (formerly two
instances of nearly duplicate code) now prints a diagnostic after
a cache miss. The one that one is most likely to encounter is
"r_downsize doesn't match", meaning that this setting likely differs
between Mapster and the game.
git-svn-id: https://svn.eduke32.com/eduke32@2248 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
let it hang around causing trouble later on; delete it right now and inform
the user.
Add a couple of 'static's to some functions and file scope data in mdsprite.c
git-svn-id: https://svn.eduke32.com/eduke32@2237 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
'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
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
This is in the similar vein as the set-palette deferring and it's this
that fixes the low FPS in the radioactively contaminated area in AMC TC:
Megabase (since setgamma() is called from setbrightness()).
Again, update issues might be expected, but changing focus between EDuke32
and the desktop and back seems to restore the gamma settings properly on
Kubuntu. Looks like X (or whatever above handles this stuff) maintains it
on a per-application basis.
git-svn-id: https://svn.eduke32.com/eduke32@2222 1a8010ca-5511-0410-912e-c29ae57300e0
CON code sometimes uses 'setgamepalette' from withing actors, which is a bit too
frequent. Deferring the actual palette updating means that multiple requests in
between two screen redraws are coalesced into one, which is desirable for
performance reasons and for the reduction of 'tearing' artefacts (but not
prevention, since the drawing isn't synced to the screen refresh rate with
vsync off).
(Did-not-)update issues might be introduced.
Windows isn't touched because
- I expect it to be more brittle, especially in light of the ATI HW gamma
problems.
- I haven't tested whether the particular performance penalty that lead to this
change ('gas' in AMC TC) exists there too
git-svn-id: https://svn.eduke32.com/eduke32@2221 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
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
Bmemset(..., 0, sizeof(...)) instead of clearbuf(..., MAX..., 0),
because the latter would clear only half of the data on 64-bit platforms.
git-svn-id: https://svn.eduke32.com/eduke32@2189 1a8010ca-5511-0410-912e-c29ae57300e0
some information about it instead of simply omitting it.
Internally, struct savegame --> struct savegame_ for easier grepping.
git-svn-id: https://svn.eduke32.com/eduke32@2188 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
already have MAXSPRITESONSCREEN of them, return 1 to signal that the caller
should break out of the loop.
git-svn-id: https://svn.eduke32.com/eduke32@2183 1a8010ca-5511-0410-912e-c29ae57300e0
to negative numbers. Previously, only checks for being zero were performed,
but CON code in the wild also has WEAPONx_SPAWN -1, which would propagate to
the sprite picnum...
git-svn-id: https://svn.eduke32.com/eduke32@2180 1a8010ca-5511-0410-912e-c29ae57300e0
Usage: press the ['] (quote) modifier together with the PERIOD key.
Aligns only the immediate upper and lower neighbors of each wall that got
aligned by following point2s or nextwalls. Doesn't play well with Alt
(carry over xrepeat) yet, might need two subsequent alignment passes.
git-svn-id: https://svn.eduke32.com/eduke32@2178 1a8010ca-5511-0410-912e-c29ae57300e0
Various code checked for switch tiles in the following manner,
for (ii=0; ii<2; ii++)
switch (DynamicTileMap[sprite[i].picnum-1+ii]) { case SOME_SWITCH: ... }
which blows for picnum 0. Now, we simply disallow it.
git-svn-id: https://svn.eduke32.com/eduke32@2174 1a8010ca-5511-0410-912e-c29ae57300e0
(getzrange, hitscan, clipmove, drawmapview).
They're reproducible with DNE1.3D; Since these angle values most likely come
from CON code, my suggestion would be to bit-and all values representing angles
with 2047 when setting the from CON, but I'd have to think about potential
side-effects of doing this.
git-svn-id: https://svn.eduke32.com/eduke32@2170 1a8010ca-5511-0410-912e-c29ae57300e0
callback 'G_Polymer_UnInit'.
- In astub.c, reset spritelightid to -1 when nulling the spritelightptr of
a sprite (no crashes observed, just precaution)
- In sdlayer.c, catch SIGILLs with our signal handler too, since illegal
instructions are what the instrumented debug builds will execute when
attempting to carry out an undefined (per C) operation.
git-svn-id: https://svn.eduke32.com/eduke32@2169 1a8010ca-5511-0410-912e-c29ae57300e0
How in the name of hell this could pass undetected for so long is a
mystery to me.
git-svn-id: https://svn.eduke32.com/eduke32@2163 1a8010ca-5511-0410-912e-c29ae57300e0
values; check the color index that is potentially gotten from the string to
be printed.
git-svn-id: https://svn.eduke32.com/eduke32@2162 1a8010ca-5511-0410-912e-c29ae57300e0
menu. If some sectors are highlighted, save their indices. The highlighting
of those particular sectors can then be restored at a later time (but careful
across structural modifications that tweak sector indices) by running the same
function. Shares a 'gamearray' with function 'collect_teleporting_sectors',
so the latter will reset this one when run.
git-svn-id: https://svn.eduke32.com/eduke32@2155 1a8010ca-5511-0410-912e-c29ae57300e0
one sector was filled and the 'clear bunch' message was displayed even if the
operation was canceled.
git-svn-id: https://svn.eduke32.com/eduke32@2153 1a8010ca-5511-0410-912e-c29ae57300e0
represents a pointer into the script for label types other than LABEL_DEFINE
instead of checking inclusion of the value in the script bounds. This
assertion was tested with WGR2 SVN.
git-svn-id: https://svn.eduke32.com/eduke32@2150 1a8010ca-5511-0410-912e-c29ae57300e0
them has a different height, print the sectnums of two differing sectors
to so that the mapper can find and examine them with Ctrl-J.
git-svn-id: https://svn.eduke32.com/eduke32@2146 1a8010ca-5511-0410-912e-c29ae57300e0
The texture warping mode will need to be set depending on whether we're
actually drawing a parallaxed sky or not.
git-svn-id: https://svn.eduke32.com/eduke32@2142 1a8010ca-5511-0410-912e-c29ae57300e0
This fixes the vertical (~1 texel wide) stripes that are especially
noticable with tiled art skies and Polymost with r_parallaxskyclamp=1
or Polymer (which always uploads skies with repeating s and t coords).
What constitutes a sky tile is currently hardcoded to be >=78 and <=99.
git-svn-id: https://svn.eduke32.com/eduke32@2141 1a8010ca-5511-0410-912e-c29ae57300e0
and restore_highlighted_sector functions. What this means is that TROR bunches
are now correctly duplicated too (only if all sectors of a given bunch are
highlighted).
git-svn-id: https://svn.eduke32.com/eduke32@2138 1a8010ca-5511-0410-912e-c29ae57300e0
(i.e. first press RAlt, then hold RShift to make it active), consider all
sectors, even the grayed out ones.
This makes 6 modifier keys in 4 categories for RAlt. Can you name them all?
Also spell out the labels that get drawn near the reticle when applying
some of the modifiers and make them not show when not actually selecting
(e.g. pressed RShift alone, but have highlighted sectors)
git-svn-id: https://svn.eduke32.com/eduke32@2137 1a8010ca-5511-0410-912e-c29ae57300e0
that bunches and nextwall links are restores, too. Now, to coalesce two
TROR maps (e.g. for a CBP), one could
do for i allsectors, sethighlightsector i 1
on the console, and then load the 'other' map to copy over the contents
of the first, including all TROR stuff. Note that neither selecting
all sectors with RAlt, nor duplicating them with Insert would lead to
the desired effect (yet).
Internally,
- yax_setbunch() now has different behavior for bunchnums -1, -2 and -3
(it either clears the nextwalls or not)
- build.c has a helper function free_n_ptrs(). This could be handy in
other situations where many blocks of memory must be allocated
consecutively and freed in case of failure
git-svn-id: https://svn.eduke32.com/eduke32@2136 1a8010ca-5511-0410-912e-c29ae57300e0
suboptimal, but at least 'correct' and won't produce the aforementioned
corruptions anymore.
git-svn-id: https://svn.eduke32.com/eduke32@2135 1a8010ca-5511-0410-912e-c29ae57300e0
can be caused by copying map parts from one map to another (or a new one).
The copying system is slightly broken right now....
git-svn-id: https://svn.eduke32.com/eduke32@2133 1a8010ca-5511-0410-912e-c29ae57300e0
next{wall,sector} indices instead of using checksectorpointer() so
that the nextwalls will be restored exactly as they were (provided
that they are copied). Also fix tweaking the sectnums of sprites.
git-svn-id: https://svn.eduke32.com/eduke32@2132 1a8010ca-5511-0410-912e-c29ae57300e0
Called 'loop punching'. In addition to duplicating the loop, the inner
portions of the original and cloned loop are made into a new bunch, and
the loop walls are made to be neighbors, linking their movement to each
other. This gives a way to create island sectors with a differing
bunchnum in the midst of an already extended area.
Usage:
For an extended sector containing a CCW inner loop, select its points
using Ctrl+Shift. Press Ctrl-E to be queried whether to duplicate the
points into the upper or lower extension (even if it's unambiguous).
A number of conditions must be met for a successful 'punch', which
should hopefully be more or less obvious. Among them:
- loop walls should all be red
- the starting wall is only considered among the non-grayed-out ones
- the neighboring sector must not contain points inside or at the loop
git-svn-id: https://svn.eduke32.com/eduke32@2130 1a8010ca-5511-0410-912e-c29ae57300e0
would break out of the 2D mode loop when splitting a sector would exceed
limits.
git-svn-id: https://svn.eduke32.com/eduke32@2129 1a8010ca-5511-0410-912e-c29ae57300e0
- Don't crash when sector joining fails under certain circumstances.
- Increase the point lock (Manhattan) distance from 1/16th to 1/8th
of the grid square length, making it easier to snap to vertices not
lying at the grid points with grid lock on
- When drawing walls, don't snap to any of them except the first drawn
git-svn-id: https://svn.eduke32.com/eduke32@2126 1a8010ca-5511-0410-912e-c29ae57300e0
When having drawn N new points (and having one 'free') and pressing
ENTER, the N line segments between the new points are checked one by
one for intersection with every non-grayed-out wall and a wall vertex
is inserted at every intersecting point. This may be viewed as a
prerequisite for a 'cutter' style tool.
git-svn-id: https://svn.eduke32.com/eduke32@2125 1a8010ca-5511-0410-912e-c29ae57300e0
This function only handles the actual insertion, also taking care of
constrained TROR walls. Anything around the inserting such as backing up
drawn walls or snapping the x/y position to the grid is handled outside.
git-svn-id: https://svn.eduke32.com/eduke32@2123 1a8010ca-5511-0410-912e-c29ae57300e0
The main change consist of adding a key press (and release) callback
whose only purpose is to be used from m32script as EVENT_KEYPRESS.
When entering that event, the RETURN variable will be set to the
keystatus code of the key, and whether it was pressed or released can
be checked by looking at keystatus[] at that code (ifholdkey and
ifhitkey do this). The purpose of this, then, is to be able to remap
keys in a more general (and complicated) fashion than is possible with
the mapster32.cfg 'remap' option. Various other additions build around
this central one:
- add an example EVENT_KEYPRESS to a.m32, among other things emulating
the keypad arrows with Alt-<normal arrows> for notebook convenience;
disabled initially
- a.m32: set 'owner' with Alt-KP2: now Alt-Shift-KP2, because of
collision with the above
- new m32script command: setkey <keycode>, setting keystatus[<keycode>]
to 1 (note: may be restricted to use in EVENT_KEYPRESS only in the
future)
- fix indexing an m32script array with a defined label, there used to
be a 'not a gamevar' error instead
- add the following constant labels for some key codes:
KEY_SCROLL, KEY_F1 .. KEY_F12
git-svn-id: https://svn.eduke32.com/eduke32@2122 1a8010ca-5511-0410-912e-c29ae57300e0
with no highlighted sectors; and when entering 3D mode, even if there are
highlighted sectors. This should have almost no effect, but I find it cleaner
that way.
- Check map for corruption every time an editing change is done. This was
accidentally disabled when commenting out the undo code (which I've yet
to debug).
git-svn-id: https://svn.eduke32.com/eduke32@2121 1a8010ca-5511-0410-912e-c29ae57300e0
of SPACE and C when in side-view mode. Now, this is accomplished by checking
directly in the overheadeditor code.
git-svn-id: https://svn.eduke32.com/eduke32@2119 1a8010ca-5511-0410-912e-c29ae57300e0
selector. This could lead to a crash when OpenGL wasn't initialized before.
git-svn-id: https://svn.eduke32.com/eduke32@2117 1a8010ca-5511-0410-912e-c29ae57300e0
helixhorned
hendricks266
terminx