- 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
The original patch was communicated to me by Hendricks, but since it didn't
apply cleanly (it's based on r2182) I took the liberty of slightly messing
with it for inclusion into EDuke32.
Info: http://wiibrew.org/wiki/User:Tueidj/Duke3D
This first part (which wasn't changed from the original patch) implements
scaling arithmetic and miscellaneous pragmas, some in PPC assembly and a part
of them in C. Of some interest is the fact that the Wii processor apparently
lacks support for 64-bit integers, so divscale() uses floating-point math.
git-svn-id: https://svn.eduke32.com/eduke32@2621 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
That is, have a second loop over all models run for each deleted tex and
null the texname. This is ugly, sure, but it's better than calling
glDeleteTextures on stale names.
git-svn-id: https://svn.eduke32.com/eduke32@2619 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
Specifically, it was in the "determine searchwall when aiming at floor or
ceiling" part. Now, if prsectors[]->ceil.plane (or ->floor.plane) is NULL,
we set the searchwall to the sector's firstwall and return.
git-svn-id: https://svn.eduke32.com/eduke32@2610 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
Previously, we only set the viewingrange according to the physical screen's
dimensions, but didn't correct yxaspect for a potential non-square pixel
ratio.
git-svn-id: https://svn.eduke32.com/eduke32@2603 1a8010ca-5511-0410-912e-c29ae57300e0
Consequently, it's not saved as a setting in either the game or editor
config files. We do this by calling "GetSystemMetrics(SM_CXSCREEN)"
(accordingly for y) and calculating the cvar by dividing common factors,
since it has to be in the form WWHH. This may fail for _really_ strange
screen dimensions, so a log message is printed at the very beginning.
git-svn-id: https://svn.eduke32.com/eduke32@2601 1a8010ca-5511-0410-912e-c29ae57300e0
Because this doesn't even seem to work on XP, we're being spammed with
DDERR_SURFACELOST messages...
git-svn-id: https://svn.eduke32.com/eduke32@2600 1a8010ca-5511-0410-912e-c29ae57300e0
Previously, it was possible to leave a sector with less than three walls if
a point got deleted transitively by a TROR link. Now, a proper check is done
for all deletion candidates and a message stating which wall and sector is
problematic is printed. Thanks for Diaz for pointing out the brokenness.
git-svn-id: https://svn.eduke32.com/eduke32@2599 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
Allow all drivers for now; if anything, we should start maintaining a
blacklist now that most Intel chips have decent enough support to be
able to run stuff satisfactorily.
git-svn-id: https://svn.eduke32.com/eduke32@2580 1a8010ca-5511-0410-912e-c29ae57300e0
