sdlmusic.c: disable FORK_EXEC_MIDI.
Also, if it were to be reenabled again, use execv() instead of execvp(), i.e. don't look up $PATH for the executable.
16 November 2013 · 8 commits by 1 author · SVN
------------------------------------------------------------------------
r4167 | helixhorned | 2013-11-16 10:47:23 -0800 (Sat, 16 Nov 2013) | 4 lines
sdlmusic.c: disable FORK_EXEC_MIDI.
Also, if it were to be reenabled again, use execv() instead of execvp(),
i.e. don't look up $PATH for the executable.
------------------------------------------------------------------------
r4166 | helixhorned | 2013-11-16 10:47:21 -0800 (Sat, 16 Nov 2013) | 7 lines
Game: make underwater blocking floor sprites w/ xvel 1 NOT act like sprite bridge.
Likewise for blocking wall sprites. This makes it possible to construct
underwater sections containing complex spritework without losing the
"underwater-ness" when over such sprites, in a backward-compatible way.
Actually, the check is for bit 1 being set, but all other bits should be
considered reserved.
------------------------------------------------------------------------
r4165 | helixhorned | 2013-11-16 10:47:19 -0800 (Sat, 16 Nov 2013) | 4 lines
lunatic/util/foreachmap.lua: don't expand .xxx after ']'.
Add an example searching for all maps containing blocking floor-aligned
sprites in underwater sectors.
------------------------------------------------------------------------
r4164 | helixhorned | 2013-11-16 10:47:16 -0800 (Sat, 16 Nov 2013) | 1 line
Mapster32: show a message when setting the initial position with SCROLL LOCK.
------------------------------------------------------------------------
r4163 | helixhorned | 2013-11-16 10:47:15 -0800 (Sat, 16 Nov 2013) | 4 lines
SDL2: fix Ctrl-F/Ctrl-G as "key FIFO" keys, used in Mapster32.
By detecting them in the SDL_KEYDOWN events. This list is getting a bit
ridiculous...
------------------------------------------------------------------------
r4162 | helixhorned | 2013-11-16 10:47:12 -0800 (Sat, 16 Nov 2013) | 4 lines
a-c.c: use GCC vector extensions only on 64-bit targets.
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).
------------------------------------------------------------------------
r4161 | helixhorned | 2013-11-16 10:47:11 -0800 (Sat, 16 Nov 2013) | 19 lines
a-c.c: prevent stray lines on bottom of sprites by saturating v. tex coords.
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.
------------------------------------------------------------------------
r4160 | helixhorned | 2013-11-16 10:47:07 -0800 (Sat, 16 Nov 2013) | 5 lines
a-c.c: in {v,mv}lineasm4, use vector types for vplc/vinc with GCC >=4.7.
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.
------------------------------------------------------------------------
See http://svn.eduke32.com/listing.php?repname=eduke32 for more details.
Also, if it were to be reenabled again, use execv() instead of execvp(), i.e. don't look up $PATH for the executable.
Likewise for blocking wall sprites. This makes it possible to construct underwater sections containing complex spritework without losing the "underwater-ness" when over such sprites, in a backward-compatible way. Actually, the check is for bit 1 being set, but all other bits should be considered reserved.
Add an example searching for all maps containing blocking floor-aligned sprites in underwater sectors.
By detecting them in the SDL_KEYDOWN events. This list is getting a bit ridiculous...
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).
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.
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.