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
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
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
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
'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
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
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
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
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
(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
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
