The pixel doubling now only applies to the area where the world scene is drawn,
i.e. it may be smaller than the physical screen / WM window size. The optimized
version is slightly faster than for non-doubled pixels for me (optimized build),
but see code for caveats. Some other minor issues:
- won't work when the world is drawn from demo cameras (and offscreen, but that
matters less)
- will leave a few pixels empty when running with x resolutions not evenly
divisible by 4
git-svn-id: https://svn.eduke32.com/eduke32@3421 1a8010ca-5511-0410-912e-c29ae57300e0
* Make the "classic status bar fullscreen viewport" mode accessible
in classic too.
* Make range of status bar scale 36..100
* Update ud.statusbarmode when executing OSD command r_size (ud.screen_size).
NOTE: ud.statusbarmode is considered internal. Don't use from CON!
* Make sure 1) loading any configuration and 2) menu bars work correctly.
(The "classic status bar fullscreen viewport" mode will never be restored
though because ud.statusbarmode isn't handled by the OSD var system).
git-svn-id: https://svn.eduke32.com/eduke32@3402 1a8010ca-5511-0410-912e-c29ae57300e0
FLAC source from git commit 0920bc1ffb07f038b317e7e8056509fe0e4b680e, patched by me.
Windows libFLAC.a built using i686-MinGW-w64 and x86_64-MinGW-w64.
HUGE thanks to rhoenie for building the Mac fat library (ppc, i686, x86_86).
git-svn-id: https://svn.eduke32.com/eduke32@3335 1a8010ca-5511-0410-912e-c29ae57300e0
In the normal game, these arrays are conceptually [MAX_WEAPONS][MAXPLAYERS],
allocated as CON per-player gamevars (e.g. WEAPONx_WORKSLIKE).
For Lunatic, they are replaced with
weapondata_t g_playerWeapon[MAXPLAYERS][MAX_WEAPONS].
git-svn-id: https://svn.eduke32.com/eduke32@3328 1a8010ca-5511-0410-912e-c29ae57300e0
Rotation-fixing happens for a couple of hard-coded statnums that presumably
never move (DEFAULT, STANDABLE, FX, FALLER, LIGHT), but for actors it wouldn't
make sense since the common case is that they do move. For this reason, bit 4
was introduced in r1934. The position of such useractors will not diverge
due to error roundoff accumulation in rotating sectors (SE0, train).
git-svn-id: https://svn.eduke32.com/eduke32@3316 1a8010ca-5511-0410-912e-c29ae57300e0
The size of that struct is currently 4, and its layout almost the same as
what is read in with loadpics(). The number of tiles in an animation is
bumped to 256, so that the max. tile difference in DEF's animtilerange is
255. (There's no way to have such animations from ART.)
git-svn-id: https://svn.eduke32.com/eduke32@3202 1a8010ca-5511-0410-912e-c29ae57300e0
NOTE: changes such as these are best viewed with something like
git diff (...) --color-words='[a-zA-Z0-9_]+|[^[:space:]]'
git-svn-id: https://svn.eduke32.com/eduke32@3176 1a8010ca-5511-0410-912e-c29ae57300e0
This reverts r3159..r3161.
Conflicts:
eduke32/build/include/compat.h
(Handled so that r3163's changes are kept applied.)
git-svn-id: https://svn.eduke32.com/eduke32@3165 1a8010ca-5511-0410-912e-c29ae57300e0
I think there's also a fix for the CON precache system breakage in here (lost it in my local tree when I started getting the C++ build working in MSVC, sorry!)
git-svn-id: https://svn.eduke32.com/eduke32@3159 1a8010ca-5511-0410-912e-c29ae57300e0
On the engine side (functions starting with L_), there are now the basic
parts like state creation and running code from strings and files.
The game and editor can add to that by e.g. loading whatever they please
into the state. Their functions start with El_ and Em_, respectively.
The Lua scripts still reside in source/lunatic, even for the common ones.
This is because they will be embedded into the binaries as bytecode or
compressed source eventually, so their location on disk will be irrelevant.
git-svn-id: https://svn.eduke32.com/eduke32@3148 1a8010ca-5511-0410-912e-c29ae57300e0
Credit to Plagman for the idea and doing the work on the game side, which is included in this commit.
(Building as C++ will give us features with which we can make improvements and optimizations on the multiplayer code and Polymer.)
git-svn-id: https://svn.eduke32.com/eduke32@3116 1a8010ca-5511-0410-912e-c29ae57300e0
These control the maximum difference in height between two sectors that the player will automatically traverse without needing to jump.
The latter controls the special case when the player's sector's lotag is ST_1_ABOVE_WATER or p->spritebridge == 1.
BYTEVERSION bumped.
git-svn-id: https://svn.eduke32.com/eduke32@3100 1a8010ca-5511-0410-912e-c29ae57300e0
Hendricks found a bug caused by that commit, so this one enables exprimentation
with setbrightness() bit 1 behavior.
git-svn-id: https://svn.eduke32.com/eduke32@3025 1a8010ca-5511-0410-912e-c29ae57300e0
For reference, they are the following:
- cache1d.c: suckcache()
- build.c: compare_wall_coords()
- make switch-invisible heuristic
- Mapster32: old sprite search
- Mapster32: manual z range
- m32script: read/writearray, qgetsysstr
- menus.c: savetemp()
git-svn-id: https://svn.eduke32.com/eduke32@2981 1a8010ca-5511-0410-912e-c29ae57300e0
This really fixes clearing the borders to the left and right with widescreen
and hud_bgstretch=0. Also, it seems to fix glitches when the "screen size"
is small (ud.screen_size is large).
git-svn-id: https://svn.eduke32.com/eduke32@2924 1a8010ca-5511-0410-912e-c29ae57300e0
Also, change type of g_numPlayerSprites (global and mapstate) from inconsistent
uint8_t/char to int8_t.
git-svn-id: https://svn.eduke32.com/eduke32@2897 1a8010ca-5511-0410-912e-c29ae57300e0
The story: Duke3D 1.5 source had "short frags[MAXPLAYERS][MAXPLAYERS]" and
"clearbufbyte(&frags[0][0],(MAXPLAYERS*MAXPLAYERS)<<1,0L);". In r1625,
g_player[].frags[MAXPLAYERS] was changed from an array of int32_t to one of
uint8_t, but the clearing code
("clearbufbyte(&g_player[i].frags[0],MAXPLAYERS<<1,0L);") stayed. In r2201, I
rewrote clearfrags() under the assumption that it really is supposed to clear
stuff beyond .frags[].
The moral:
1. Write clean code.
2. Use sizeof.
3. Write clean code!
git-svn-id: https://svn.eduke32.com/eduke32@2878 1a8010ca-5511-0410-912e-c29ae57300e0
This was introduced with r2771, which fixed e.g. AMC TC city_si's mirrors,
but instructed the base drawrooms inside yax_drawrooms to not correct the
passed sectnum. Therefore, stuff would get drawn wrongly when passing
sector boundaries, like from the platform to the rails in trueror1.map.
git-svn-id: https://svn.eduke32.com/eduke32@2810 1a8010ca-5511-0410-912e-c29ae57300e0
-Wwrite-strings is useful to detect code where string literals and e.g. alloc'd
strings are used side-by-side, potentially creating dangerous situations, or to
find uses of old, non-constified APIs. However, enabling it would still flood
the log with too many warnings. Also, GCC wrongly warns for initializations of
char arrays.
git-svn-id: https://svn.eduke32.com/eduke32@2796 1a8010ca-5511-0410-912e-c29ae57300e0
Also, correct the loadboard() return value checks in premap.c to be
aware of a returned -2 ("wrong map version").
git-svn-id: https://svn.eduke32.com/eduke32@2694 1a8010ca-5511-0410-912e-c29ae57300e0
The primary reason for doing this is that handing of moving sectors is
significantly simplified. Because moving sectors usually don't move containing
SEs/effector-statnum sprites, no special handing code is needed to move light
SEs with them. Thus, this commit sets light SEs to a new statnum when they're
spawned *from premap*, and a new G_Move*-like function (called G_DoPolymerLights)
is added to process every sprite in that status list.
This should "fix" light SEs moving together with a variety of moving sectors,
but CON programs expecting the old behavior may break, therefore this commit is
marked as experimental.
Additionally, a problem with the old implementation is identified: it seems like
the correct functioning is dependent upon the order of processing between the
sector movement effector and the light SE, so this makes it another good reason
for the change. (A third one is that all lights can be processed with a per-
statnum loop, but CON coders should not do this until the change is considered
final).
git-svn-id: https://svn.eduke32.com/eduke32@2646 1a8010ca-5511-0410-912e-c29ae57300e0
This is so that when hud_bgstretch is disabled (i.e. background pictures are
not stretched to the whole screen), the frame buffer has no leftover contents
from previous frames on the sides of the screen. This was particularly noticable
when using the console.
The "places" are the following:
- before drawing an anim frame
- before drawing a "full-screen" background
- while displaying logo, titlescreen, loadscreen
(this leaves a couple others which I didn't test, and didn't tweak)
git-svn-id: https://svn.eduke32.com/eduke32@2584 1a8010ca-5511-0410-912e-c29ae57300e0
The primary change is that things have been made memory-clean. Some of these
pointers may point to wildly different places during the course of the program
such as statically or dynamically allocated storage, the buffer returned by
getenv() (which must not be modified according to the docs), or an element of
argv[]. Consequently, we need to strdup, or better, dup_filename them if they
are ever to be passed to a function that modifies their pointed-to data.
Specifically:
- added statics or consts according to usage
- 3 new functions clear{Grp,Def,Script}NamePtr, only 'Def' one extern for now
- in G_CheckCommandLine, don't strip 'const'; use Bstrncpyz where appropriate
- remove multiple declarations
Also, warn if an application parameter has been ignored (not matched).
git-svn-id: https://svn.eduke32.com/eduke32@2561 1a8010ca-5511-0410-912e-c29ae57300e0
- Help window text cleaned and made more consistent between game and editor
- Added help entry for "-clipmap"
- Log text for using CON, DEF, and RTS files has been made consistent
- All instances of '%s' have been replaced with \"%s\" because ' is a valid filename character. (At least on Windows.)
git-svn-id: https://svn.eduke32.com/eduke32@2538 1a8010ca-5511-0410-912e-c29ae57300e0
This plays more nicely with automatic formatters. Also indent accordingly.
git-svn-id: https://svn.eduke32.com/eduke32@2379 1a8010ca-5511-0410-912e-c29ae57300e0
- guard cansee() against negative sectnums (return 0 immediately), since
it's often called with the player sectnum as one argument
- in resetpspritevars(), don't inset APLAYER sprite if sectnum < 0, which
can happen if a map is started in void space accidentally (e.g. from
the editor)
- two checks before accessing sector[] with a player sectnum
git-svn-id: https://svn.eduke32.com/eduke32@2342 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
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
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
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
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
First, if we're in Polymer, don't precache tinted tiles that have a highpal
for that certain pal. Second, don't precache tiles for palnum 251 (the last
non-reserved one, which is used as a crosshair pal). Assuming that there are
no other tints, this cuts the initial precache time and cache size on disk in
half.
git-svn-id: https://svn.eduke32.com/eduke32@2045 1a8010ca-5511-0410-912e-c29ae57300e0
in any renderer because it's drawn with the software one...
Also add a hack to make Polymer realize that viewscreen tiles can change
each tic so that they don't show a static image anymore.
git-svn-id: https://svn.eduke32.com/eduke32@2021 1a8010ca-5511-0410-912e-c29ae57300e0
- fix an earlier 'oops': make highpals load correctly again
- maphack lights shouldn't be double-loaded now
- slight tweak to the loading screen fadein/out timing
- two bound checks
- make some variables static in engine.c
git-svn-id: https://svn.eduke32.com/eduke32@1969 1a8010ca-5511-0410-912e-c29ae57300e0
which switches have been hidden in the original and user maps. One is to make
it face a wall, and another is to 'embed' it in e.g. the floor, like the
monitor with the burning fuse in E4L1. Both kinds show up when the switches
are rendered as models, revealing the secrets that the mapper sought to hide.
My proposal, implemented in this commit, is to apply a heuristic for such
switches at premap and make them invisible (set cstat bit 32768). The
conditions are re-checked during the game in case there is a switch coming
out of the floor, for example. A new spriteext bit is used for this feature.
git-svn-id: https://svn.eduke32.com/eduke32@1968 1a8010ca-5511-0410-912e-c29ae57300e0
* When dragging highlighted sprites, do a setsprite() after each position update. This way, they won't end up on the wrong level
* TROR support for SE 31 and 32 in-game, example provided in test map
* some uncommited stuff for TROR: SE 6/14
git-svn-id: https://svn.eduke32.com/eduke32@1924 1a8010ca-5511-0410-912e-c29ae57300e0
Implementation note: the so instrumented sprites use actor[].t_data[7] to hold a magic number (0x18190000 + pivot spr idx), and t_data[8] and [9] for the initial coords relative to the pivot point.
git-svn-id: https://svn.eduke32.com/eduke32@1913 1a8010ca-5511-0410-912e-c29ae57300e0
* more useful auto-red wall feature: if no structure-changing operations have been applied after highlighting and duplicating, now also paste 'visual' fields of outer walls (this is one example of the use of a system that temporarily keeps track of nextwalls for former red lines)
* multi-pkies now have individual parallaxyscale
git-svn-id: https://svn.eduke32.com/eduke32@1886 1a8010ca-5511-0410-912e-c29ae57300e0
* Sprite cstat 2048 ('use own shade', [N]) now works more or less. (Issues may arise when combined with sector light effects.)
* Begin work on 'smart' tag labeling system for Mapster32. Right now, it only displays a '+' after tags with linking semantics.
*
git-svn-id: https://svn.eduke32.com/eduke32@1866 1a8010ca-5511-0410-912e-c29ae57300e0
* Consolidate the various, slightly different, methods of bounding a sprite between a sector's ceiling and floor into one common function
* Fixes for accumulated bugs: shade preview, r_shadescale_unbounded, and a couple of unreported ones
* Yaks, gnus, and bisons...
git-svn-id: https://svn.eduke32.com/eduke32@1854 1a8010ca-5511-0410-912e-c29ae57300e0
