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
- Make MAXXDIM and MAXYDIM macros be 860 and 490, respectively. tueidj says
max. screen size is 848x480, but there are oob access bugs in the classic
renderer when running with the maximum possible resolution
- don't allocate additional sector/wall storage for Mapster (saves ~16k)
- Add ud.config.UseJoystick = 1 in config.c, but make it conditional on Wii
- remove one comment I no longer believe true, add one TODO comment
git-svn-id: https://svn.eduke32.com/eduke32@2645 1a8010ca-5511-0410-912e-c29ae57300e0
This is so that it may be intercepted in the future.
The only code that's not replaced by the function call is with the CON
interface to g_player[].ps->pals via player[].pals X and .pals_time.
Also, comment out one instance because it's overwritten by a succeeding one.
git-svn-id: https://svn.eduke32.com/eduke32@2643 1a8010ca-5511-0410-912e-c29ae57300e0
Besides being the compiler's job nowadays, they significantly inflate
the size of the debugging builds.
git-svn-id: https://svn.eduke32.com/eduke32@2640 1a8010ca-5511-0410-912e-c29ae57300e0
Among other things, comment out very seldomly (or not at all)
used sprite member macros: SV, ZV, RX, RY, CX, CY, CD, PL.
git-svn-id: https://svn.eduke32.com/eduke32@2639 1a8010ca-5511-0410-912e-c29ae57300e0
(I.e. also restore r2232 again.)
The first one is the palette restore logic in G_DisplayRest, the second
is CON setgamepalette, to which the "don't gltexinvalidateall()" bit is
added to mimic the first. Hightile invalidations aren't really useful for
anything other than reloading them after a video mode change, IMO.
These changes mean that
1) active full screen tints should (almost) always be kept with a basepal
change. The only exceptions to this are when tints really have to be
cleared, e.g. when changing the player view in co-op play.
2) there should be no performance issues with simultaneously changing
basepals while a tint is applied
git-svn-id: https://svn.eduke32.com/eduke32@2637 1a8010ca-5511-0410-912e-c29ae57300e0
The sliders themselves still permit changing values, but are drawn with a
'disabled' shade because they're non-functional with software gamma.
git-svn-id: https://svn.eduke32.com/eduke32@2635 1a8010ca-5511-0410-912e-c29ae57300e0
- in actors.c, make a static array const (the original patch removed the
staticness)
- remove one comment and change some compiled-out code
- remove commented out pre-Makefile.common stuff
Some changes were not adopted from tueidj's patch:
- whitespace cleanup
- ud.config.UseJoystick = 1 in config.c
- Makefile.common, as mentioned before
- proper read-in of g_numRealPalettes, because it was done with r2503
git-svn-id: https://svn.eduke32.com/eduke32@2632 1a8010ca-5511-0410-912e-c29ae57300e0
- BIGX -> BIGX_, likely again because of a name clash
- make a loop in animlib.c iterate in forward direction
git-svn-id: https://svn.eduke32.com/eduke32@2631 1a8010ca-5511-0410-912e-c29ae57300e0
This part is a mixture of the original patch and my changes. It seems like
tueidj had some trouble
1) getting OGG to work, which is why it's conditionally compiled out
2) struggling with endianness with the mixing routines? This may be also
due to him missing to define two others BIGENDIAN macros (our code is
in need of cleanup there). Note the change in jaudiolib/src/mix.c!
Because I added my share to this part, I might have actually broken sound
mixing on big-endian platforms.
git-svn-id: https://svn.eduke32.com/eduke32@2630 1a8010ca-5511-0410-912e-c29ae57300e0
- conditionally compiles out some code intended for the PC platforms
- compat.c: get home directory routine, access() implementation
- game.c: don't use ioctl(), lower cache1d size to 8 MiB, Wii-specific
initialization code and application directory ("apps/eduke32")
git-svn-id: https://svn.eduke32.com/eduke32@2628 1a8010ca-5511-0410-912e-c29ae57300e0
This simply macro-defines various low-level networking functions.
git-svn-id: https://svn.eduke32.com/eduke32@2627 1a8010ca-5511-0410-912e-c29ae57300e0
- the crosshair is displayed at the position read from the absolute pointing
device
- in the menus, use the hat input (that was mapped to mouse buttons in part 4)
for navigation
git-svn-id: https://svn.eduke32.com/eduke32@2625 1a8010ca-5511-0410-912e-c29ae57300e0
- sdlayer.c: custom "get joystick button names" routine
- jmact/mouse.c: packs some joystick events into the value returned by
MOUSE_GetButtons(): bits used are 256, 512, 4096, 8192
- MOUSE_Init() --> Mouse_Init(), presumably because of a name clash?
- comments out right-shift of joystick analog values by 5, maybe this fixes
the scale problems with the joystick on the PC too?
git-svn-id: https://svn.eduke32.com/eduke32@2624 1a8010ca-5511-0410-912e-c29ae57300e0
I didn't add Makefile.common, because it needs to be made conditional.
git-svn-id: https://svn.eduke32.com/eduke32@2622 1a8010ca-5511-0410-912e-c29ae57300e0
Because gltexinvalidate*() could be called too often when setgamepalette is used
while having a tint overlaid else. Pending thorough analysis/reworking of the
32-bit mode base palette handling / texture invalidation.
git-svn-id: https://svn.eduke32.com/eduke32@2620 1a8010ca-5511-0410-912e-c29ae57300e0
- bump lpeg stack limit to 1024 (hack) for long if/if/if...else chains
- lexical: newline, EOF and whitespace; "bad" identifiers; hex literals,
newline terminated strings (allow empty string)
- syntax: allow nesting of array expressions, it's easier than special-casing;
handle issues with structs expecting parm2 (hackish); userdef;
switch/case/default
- fix parsing some commands; mind prefixes!
- frontend: if failing match, print last keyword and its position; warn on
"bad" identifiers (one per such); batch processing from command line
- Files that locate finds from my linux box now pass (except where there are
really syntax errors).
git-svn-id: https://svn.eduke32.com/eduke32@2616 1a8010ca-5511-0410-912e-c29ae57300e0
- 4 instances -> HandleSE31
- 4 instances -> MaybeTrainKillPlayer
- 2 instances -> MaybeTrainKillEnemies
- move a couple of variables into inner blocks and add 'const' for easier reading
In passing, fix a minor glitch where the squishing sound of an enemy that got
run over by an SE 6 or 14 car would appear to originate from the SE instead
of the enemy's last position.
git-svn-id: https://svn.eduke32.com/eduke32@2607 1a8010ca-5511-0410-912e-c29ae57300e0
Of course, it's just for the heck of it, since this setting is not saved into
MAP files. I kinda like the cylindrical projection...
git-svn-id: https://svn.eduke32.com/eduke32@2605 1a8010ca-5511-0410-912e-c29ae57300e0
This has been there since searchbottomwall introduction in r1466.
git-svn-id: https://svn.eduke32.com/eduke32@2604 1a8010ca-5511-0410-912e-c29ae57300e0
Currently syntax only. Parses the original scandcode 0x1d files, which is
harder than you'd imagine given the relatively simple structure. Chokes on
new-gen custom stuff.
git-svn-id: https://svn.eduke32.com/eduke32@2594 1a8010ca-5511-0410-912e-c29ae57300e0
If one next instruction happened to be interpreted, madness would ensue,
because the pointer wouldn't be aligned on the "opcode" part anymore.
Also, with "seti", set current sprite index only after a successful validation.
git-svn-id: https://svn.eduke32.com/eduke32@2591 1a8010ca-5511-0410-912e-c29ae57300e0
This get into the writable variable the "linking type" of the sprite with index
<spritenum>. The result is a bit field of ORed values:
1: lotag has linking semantics
2: hitag
4: extra, 8: xvel, 16: yvel, 32: zvel, 64: owner (custom only)
Custom setting about which sprites have what kind of linking can be programmed
via EVENT_LINKTAGS: it receives a sprite index as the 'current sprite' and is
supposed to return the bit field in RETURN.
An example which lists sprites and their linking hi- and lotags is provided in
the state 'listusedtags' in a.m32.
git-svn-id: https://svn.eduke32.com/eduke32@2590 1a8010ca-5511-0410-912e-c29ae57300e0
- factor out many identical checks in a convenient function; some messages
may read slightly differently now and tile ranges may be handled more strictly
(error out if one of the limits is invalid)
- factor out two instances of identical (up to one arg) code into
tile_from_truecolpic
- factor out setting picsiz[] and stuff into set_picsizanm
- some checks
- Make "undefmodelof" non-functional and warn.
- in "animtilerange", if the tile difference is >= 64, error out since we
can't store it in picanm[]
git-svn-id: https://svn.eduke32.com/eduke32@2588 1a8010ca-5511-0410-912e-c29ae57300e0
This was more or less done by trial and error rather than understanding what
exactly is going on there. In any case, the code for all the different ending
scenes ought to be factored out instead of being duplicated with subtle
differences every time.
git-svn-id: https://svn.eduke32.com/eduke32@2585 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
Also, do a setpalettefade(..., end) when breaking fadepaltile now, too.
git-svn-id: https://svn.eduke32.com/eduke32@2583 1a8010ca-5511-0410-912e-c29ae57300e0
When requesting an increasing ramp, the upper limit is taken to be exclusive.
When it is passed to G_FadePalette, only the lowest 6 bits are passed further
to setpalettefade, which means that a limit of 64 is incorrectly set as 0.
Also, when breaking from the fade loop, set the fade value to the end one for
fadepal!
git-svn-id: https://svn.eduke32.com/eduke32@2582 1a8010ca-5511-0410-912e-c29ae57300e0
This requires one tweak in drawrooms' umost/dmost setup to prevent oob access.
Specifically, a coordinate difference of 0 is allowed. In the classic renderer,
this would mean a one-pixel (real screen coords) height or width. In Polymost,
it would currently mean a one-pixel height and zero-pixel width, but this might
be subject to change.
git-svn-id: https://svn.eduke32.com/eduke32@2574 1a8010ca-5511-0410-912e-c29ae57300e0
The showview command transforms the 320-based screen bound coordinates to the real
screen bounds like xreal = (x*xdim)/320, which shows a bias towards zero: for
example, for a 1680 screen width, the maximum permissible value 319 is mapped to
round_to_zero((319*1680)/320) == 1674. (The rounding is implicit in the integer
division). This makes it impossible for a view to cover the whole screen with any
other resolution than 320x200. The new command transforms the bounds like
xreal = (x*(xdim-1))/319, which would map 319 to 1679 in the preceding example.
git-svn-id: https://svn.eduke32.com/eduke32@2573 1a8010ca-5511-0410-912e-c29ae57300e0
