The scrollwheel is unique among PC input because it has no innate "hold length". Previously, the layers gave the mousewheel a fake hold length to allow the not-necessarily-synchronous game/editor code to pick up the input before the layers marked it as "no longer pressed". This passed under Windows, but it didn't slide under SDL.
Besides the two problems listed above, it also potentially limited the rate of weapon selection, where scrolling too fast would not register every clicks. [Unrelatedly, this is still the case when you scroll faster than the game's own tickrate, but addressing that would require rewriting input handling to go through a list of "events" for each tic instead of looking at overall pressed/unpressed states.]
git-svn-id: https://svn.eduke32.com/eduke32@4200 1a8010ca-5511-0410-912e-c29ae57300e0
- Move ARRAY_SIZE() macro to compat.h, add another one ARRAY_SSIZE()
- In A_RadiusDamage(): note maybe-unaligned access issue, prevent unlikely oob
- sector.c: use SPRITES_OF* macros where appropriate
git-svn-id: https://svn.eduke32.com/eduke32@4199 1a8010ca-5511-0410-912e-c29ae57300e0
This requires enabling the same workaround as for Linux. Maybe it's not
system-dependent at all.
git-svn-id: https://svn.eduke32.com/eduke32@4193 1a8010ca-5511-0410-912e-c29ae57300e0
I was checking for GCC >= 4.7, while Clangs pretends to be GCC 4.2. Use a
feature test macro instead. The comment I made in r4161 regarding GCC vs.
Clang code was wrong. Now, Clang generates slightly faster code for these cases
(solid and masked 4-pixel wide vlines).
git-svn-id: https://svn.eduke32.com/eduke32@4182 1a8010ca-5511-0410-912e-c29ae57300e0
Which was especially noticeable in the Lunatic build. Also, use
glPushAttrib/glPopAttrib there.
git-svn-id: https://svn.eduke32.com/eduke32@4176 1a8010ca-5511-0410-912e-c29ae57300e0
This "simply" requires an appropriate factor in the projection matrix.
Also, get rid of a special-case factor for >=1.6 aspects (making HUD models
wider then, I think).
git-svn-id: https://svn.eduke32.com/eduke32@4172 1a8010ca-5511-0410-912e-c29ae57300e0
Known as getactor/sprite[].xpanning from CON, values are 0-255. It should be
assumed that this is only valid for wall-aligned sprites (currently, face
sprites also pan).
A test is provided in lunatic/test/animatesprites.con. It should be run in E1L2
and only with the Lunatic build.
git-svn-id: https://svn.eduke32.com/eduke32@4170 1a8010ca-5511-0410-912e-c29ae57300e0
By detecting them in the SDL_KEYDOWN events. This list is getting a bit
ridiculous...
git-svn-id: https://svn.eduke32.com/eduke32@4163 1a8010ca-5511-0410-912e-c29ae57300e0
Compiling a 32-bit NOASM build resulted in code containing a MOVAPS instruction
that accessed a memory location not aligned to 16 bytes (MinGW, GCC 4.8).
git-svn-id: https://svn.eduke32.com/eduke32@4162 1a8010ca-5511-0410-912e-c29ae57300e0
The functions mvlineasm1, mvlineasm4 and tvlineasm2 can now be set to clamp
the vertical texture coordinate (vplc), preventing the unsightly stray lines
on the bottom of non-y-flipped sprites. (The first part of this effort, r3483,
handled their top).
However, this is only enabled for the mvlineasm ones: the vectorized variants
suffered almost no slowdown (even though a PADDUSD SSE instruction would be a
nice thing to have), while it was pretty significant for the sequential
translucent ones.
Summarizing, this leaves two cases where stray lines may appear in the non-ASM
build (the saturation is NYI for a.nasm):
- at the bottom of y-flipped sprites
- at the bottom of translucent sprites (can be toggled by #define)
Another observation is that recent GCC generates much faster code for this
stuff than Clang from SVN.
git-svn-id: https://svn.eduke32.com/eduke32@4161 1a8010ca-5511-0410-912e-c29ae57300e0
For a full 1680x1050 screen drawing a solid/masked wall, the FPS increases
from 118 to 133 and from 114 to 116 (respectively) for me.
Guarded by the macro USE_VECTOR_EXT in the source.
git-svn-id: https://svn.eduke32.com/eduke32@4160 1a8010ca-5511-0410-912e-c29ae57300e0
This fixes some init and update anomalies: before,
- init would always be the graphical mode (0), but writing
merely "osdtextmode" would switch it
- osdtextmode would not get saved to the cfg
git-svn-id: https://svn.eduke32.com/eduke32@4139 1a8010ca-5511-0410-912e-c29ae57300e0
These were too much "looking into the implementation of a module" for my
taste, hence OSD_GetShadePal() earlier.
git-svn-id: https://svn.eduke32.com/eduke32@4138 1a8010ca-5511-0410-912e-c29ae57300e0
This renders tweaks like r4122 unnecessary.
Also, note a "bug" with the program generating that C code.
git-svn-id: https://svn.eduke32.com/eduke32@4135 1a8010ca-5511-0410-912e-c29ae57300e0
I updated the help windows to prefer these variants because they are superior to the -xSquished versions.
Also, factor out the command-line processing code for the above, plus con/def modules and clipmaps.
git-svn-id: https://svn.eduke32.com/eduke32@4128 1a8010ca-5511-0410-912e-c29ae57300e0
So that there are no error messages like "M32 file `a.m32.m32' not found."
Also, in build.c's 'save as' code, add a bound check that would probably
always pass in practice, but looks a bit safer and may fail in very cornerly
cases.
git-svn-id: https://svn.eduke32.com/eduke32@4124 1a8010ca-5511-0410-912e-c29ae57300e0
Instead of directly in build.c:app_main(). Previously, it was possible that an
argument to an option, e.g. "WGR2" with "-game_dir WGR2", would get interpreted
as the initial map to load. This in turn would attempt to execute WGR2.cfg as
sequence of OSD commands -- where that file is an EDuke32 config file instead!
Now: maps are passed without any options, e.g. "mapster32 [opts...] debug.map".
The map file name is not added to the "additional parameters" for map testing.
git-svn-id: https://svn.eduke32.com/eduke32@4121 1a8010ca-5511-0410-912e-c29ae57300e0
Because the one implemented on top of X shows a special mark for tabs instead of
whitespace.
Also, in wm_msgbox(), use vsnprintf.
git-svn-id: https://svn.eduke32.com/eduke32@4120 1a8010ca-5511-0410-912e-c29ae57300e0
This fixes ESC in certain situations such as the editor map selection menu.
git-svn-id: https://svn.eduke32.com/eduke32@4117 1a8010ca-5511-0410-912e-c29ae57300e0
The leak happened because a struct was hashed that had uninitialized
bytes in padding inserted by the compiler. The hash string in now constructed
as concatenation of three CRC32s as 8-byte hex strings, i.e. the individual
CRC32s are padded with leading zeros.
Note to users: because of the hash change, it's sensible to delete the
'textures' and 'textures.cache' files.
git-svn-id: https://svn.eduke32.com/eduke32@4096 1a8010ca-5511-0410-912e-c29ae57300e0
