- use SPRITES_OF* iterator macros
- new function: E_SpriteIsValid(); add some safety checks
(e.g. hitag used as sprite index)
- the rest is mostly "the usual code transformations"
git-svn-id: https://svn.eduke32.com/eduke32@4281 1a8010ca-5511-0410-912e-c29ae57300e0
- Make Win+F* also make play and RTS sound, since modern OS's window managers
like to eat Alt-F*. (Some Win+F* may be inaccessible too, but together all
10 should hopefully be covered.)
- Fix an issue where keys other than F1-F10 were considered as starting an RTS
sound and crashing EDuke32 in the process
git-svn-id: https://svn.eduke32.com/eduke32@4278 1a8010ca-5511-0410-912e-c29ae57300e0
When a map named <filename>.map is loaded (<filename> may also contain directory
separators), the engine checks for existence of <filename>_XX.art in the virtual
file system, where XX is a 0-padded number from 00 to 19. It loads a consecutive
sequence of these ART files, i.e. aborts whenever a number in the sequence isn't
found (in contrast to normal ART loading).
Restrictions:
- the per-map ART files must not reside in ZIP files
- if a tile number is attempted to be overridden that has a dummytile or is
cache1d-locked, per-map ART loading fails
On failure, the map is still loaded, but a diagnostic message is output to the
log/OSD.
Loaded per-map ART data are cleared whenever the map is "left". In particular:
- whenever another map is loaded
- in the editor: when a new map is started
- in the game: after the bonus ending screen of a finished level, after going
to the title screen via the menu
A final note: file names are supposed to be looked up and compared
case-sensitively. That is, <filename> must match EXACTLY between the map's and
per-map ART one; 'art' must be lowercase. Otherwise, the cookie monster will
come and eat you!
BUILD_LUNATIC.
git-svn-id: https://svn.eduke32.com/eduke32@4257 1a8010ca-5511-0410-912e-c29ae57300e0
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
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
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
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
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
Variables at global scope which share a name tend to actually be the same variable. Not good when you pass such a variable to function that immediately returns if the passed parameter (the variable) equals said variable (itself).
git-svn-id: https://svn.eduke32.com/eduke32@4090 1a8010ca-5511-0410-912e-c29ae57300e0
Unfortunately, SDL2 does not (yet?) provide a Yes/No box for wm_ynbox().
git-svn-id: https://svn.eduke32.com/eduke32@4085 1a8010ca-5511-0410-912e-c29ae57300e0
Most often, this had happened when casting comparison functions for qsort()
like these: "int yax_cmpbunches(const int16_t *b1, const int16_t *b2)"
to a function pointer type expecting "const void *". Alas, this is undefined
behavior: see
http://blog.frama-c.com/index.php?post/2013/08/24/Function-pointers-in-C
and posts linked from it.
At least two cases have not been fixed:
- The savegame system maintains pointers which are either to data or a function in
the generic "void *". This ought to be made into a union.
- Probably also:
#define OSD_ALIAS (int32_t (*)(const osdfuncparm_t*))0x1337
git-svn-id: https://svn.eduke32.com/eduke32@4068 1a8010ca-5511-0410-912e-c29ae57300e0
DONT_BUILD, because there have been no significant changes of the non-Lua build.
git-svn-id: https://svn.eduke32.com/eduke32@4006 1a8010ca-5511-0410-912e-c29ae57300e0
- libs and headers are expected in platform/Windows/* (not there yet)
- prefix Lua #includes with luajit-2.0/
- build bytecode objects with absolute path name (used for debug info)
git-svn-id: https://svn.eduke32.com/eduke32@4000 1a8010ca-5511-0410-912e-c29ae57300e0
- Rename sky_t members: yscale -> horizfrac, bits -> lognumtiles.
- Add default sky (8 tiles, horizfrac=32768 (i.e. 1/2 the scene horiz), offsets
all zero) and CLOUDYOCEAN sky (8 tiles, horizfrac=65536, offsets all zero)
to multipsky[].
- Get rid of "psky_t g_psky", merely maintaining a g_pskyidx instead. Set it up
at map load time so as to keep the behavior of the legacy per-map psky:
the last sector index with a matching psky ceiling wins.
- In mapstate_t, save g_pskyidx too, not (former) pskybits and pskyoffs[].
- Make on-map-load global psky setup consistent for the game and editor by
factoring it out into common.c: G_SetupGlobalPsky().
- Remove a couple of useless initializations, add some static assertions.
This commit is more likely to introduce subtle differences in behavior.
Specifically, getpsky() now always returns the default sky properties instead of
the global sky ones (but with all-zero offsets) when no match for a suiting
multi-psky is found. This is only likely to affect the yscale/horizfrac of
non-multi-pskies when a global non-default multi-psky has been set up.
Bump BYTEVERSION again.
git-svn-id: https://svn.eduke32.com/eduke32@3976 1a8010ca-5511-0410-912e-c29ae57300e0
- Consolidate psky* arrays into a "typedef struct psky_t" "g_psky" and
"multipsky[]".
- Factor out getting parallaxed sky properties into getpsky().
- Condense initial multi-psky setup by memcpy'ing from multipsky[].
- New function: MultiPsky_TileToIdx().
- Add new define PSKYOFF_MAX and related consistency-checking assertions.
- Lower MAXPSKYTILES to 8 to reflect current usage (was 256).
- Game: make multi-pskies consider dynamically-remapped MOONSKY1, BIGORBIT1
and LA. (Not very useful as the editor will still only act for the static
values -- 80, 84 and 89, respectively.)
An attempt has been made to preserve behavior even in strange cases, so this
commit is unlikely to introduce regressions. Because of point 6, BYTEVERSION
had to be bumped.
git-svn-id: https://svn.eduke32.com/eduke32@3975 1a8010ca-5511-0410-912e-c29ae57300e0
Having to tag these few variables and functions as ATTRIBUTE((used))
seems sensible, but what follows is just strange. OSD_Printf? headspritesect?
git-svn-id: https://svn.eduke32.com/eduke32@3932 1a8010ca-5511-0410-912e-c29ae57300e0
