- alloc_multimapstate() helper
- make g_netMapRevision a uint32 and store save->revision in sequence order
(without &(NET_REVISIONS-1))
- one assert, one XXX comment, stylistic changes
git-svn-id: https://svn.eduke32.com/eduke32@2674 1a8010ca-5511-0410-912e-c29ae57300e0
This should be more correct, since previously, the saved PNGs were way too
contrasty when looked from within a browser. Now, they'll always be
slightly darker than in-game (assuming one has a gamma greater than 1).
git-svn-id: https://svn.eduke32.com/eduke32@2673 1a8010ca-5511-0410-912e-c29ae57300e0
For Lunatic, we'll want to get rid of the t_data --> script indirections, since
the latter will be no more. Thus, all parameters are saved in t_data directly.
For the normal build, there are no changes, only stylistic tweaks.
git-svn-id: https://svn.eduke32.com/eduke32@2669 1a8010ca-5511-0410-912e-c29ae57300e0
EVENT_SOUND: triggered upon playback of any sound, this allows the "hard coded" sounds to be altered in a context-aware fashion instead of having to resort to clunky hacks like replacing them with a blank sound effect. RETURN var
iable is set to the sound effect # of the sound to be played, or -1 to cancel playback.
EVENT_CHECKTOUCHDAMAGE: triggered in P_CheckTouchDamage() whenever the player collides with anything. Value of RET
URN is set to the result provided by clipmove() and so can be decoded in the same way. Value of RETURN when the event is over can also be manipulated to control some of the hard coded damage effects.
EVENT_CHECKFLOORDAMAGE: triggered in P_CheckFloorDamage(), RETURN is simply the picnum of the floor of the sector t
he player is in. Can be used to cancel hard coded floor damage effects or to make other tiles exhibit the same eff
ects
Other misc fixes and cleanups, including a possible workaround for Duke Plus SECTOREFFECTOR light issues wherein all SE49 and SE50 that have a statnum of STAT_EFFECTOR are simply changed to STAT_LIGHT during the STAT_EFFECTOR loop
now.
git-svn-id: https://svn.eduke32.com/eduke32@2652 1a8010ca-5511-0410-912e-c29ae57300e0
The remaining checks now "continue;" when an oob tilenum is found where
an oob access would ensue else. Also, it's now checked for negative
numbers (the message remains the same though).
git-svn-id: https://svn.eduke32.com/eduke32@2651 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
- 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
Previously, we checked whether the faded palette has changed (by way of CRC)
and invalidated the textures then unless the preserve flags were set. This
however could lead to wrongly invalidating them under unfortunate circumstances,
e.g. basepal change from CON + tints at the same time before r2620 which
reverted r2232.
Now, only invalidate them if the corresponding preserve flags are clear AND
* the base palette has really changed OR
* the palette CRC changed and we were running on software gamma
The latter means that performance-killing invalidations may still happen on
GL platforms lacking HW gamma (for ATI, it's currently only disabled in 8-bit
fullscreen).
Also have a new global 'basepalreset' to fake a basepal change for
setbrightness(), currently used when changing renderers so that going from
Polymer to Polymost and back again will invalidate the Polymer textures
on the second change, potentially re-applying a basepal highpal. (Still
with me?)
git-svn-id: https://svn.eduke32.com/eduke32@2636 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
This was fixed with the preceding change; software mode will now always use
software gamma if an ATI/AMD card is detected.
git-svn-id: https://svn.eduke32.com/eduke32@2634 1a8010ca-5511-0410-912e-c29ae57300e0
Previously, I knew no way of querying for graphics adapter vendors/names from
anything other than OpenGL. Googling revealed a way to do this with the
Windows API.
git-svn-id: https://svn.eduke32.com/eduke32@2633 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
On the Wii, V7 (i.e. original) map limits are used and the maximum screen size
is 1600x1200.
git-svn-id: https://svn.eduke32.com/eduke32@2629 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
For the Wii, SDL's mutex functionality is used. The implementation in the
original patch was wrong though, so this part required non-trivial changes.
git-svn-id: https://svn.eduke32.com/eduke32@2626 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
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
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
(That is, the base shade table.) Before, we allocated each palookup buffer.
For a vanilla setup, this means that we're now saving 224*32*256 ~= 1.8 megs,
which might be interesting for low-memory gadgets.
git-svn-id: https://svn.eduke32.com/eduke32@2571 1a8010ca-5511-0410-912e-c29ae57300e0
First, it's unlikely in our day and age. Second, they're always free'd at the end,
so allocache'ing them is incorrect.
git-svn-id: https://svn.eduke32.com/eduke32@2570 1a8010ca-5511-0410-912e-c29ae57300e0
Also,
- use this in game.c and astub.c palookup loading code
- when makepalookup() is passed a 0 palnum, return early. This means that
'fogpal' will silently fail when attempting to change pal 0.
- in 'makepalookup' DEF command, error out if passed a pal of 0.
git-svn-id: https://svn.eduke32.com/eduke32@2569 1a8010ca-5511-0410-912e-c29ae57300e0
The syntax is as follows:
makepalookup { <token-list...> }
where valid tokens are
* pal <palnum>: the palette number, 1 .. 250
* red <num>, green, blue (or r, g, b): the fog color components on a 0 to 63 scale.
Components that are not present are assumed to be 0.
* remappal <palnum>: the palette number to take the index remapping from, i.e. 21
for blue -> red. When absent, defaults to 0.
* remapself: when present, specifies that the remappal is the same as the 'pal'.
This is to prevent textual redundancy when overwriting existing palookups.
Examples (best tested with tile #251):
1) makepalookup { pal 200 red 30 remappal 23 }
This creates palookup 200 with a fog of (30,0,0) and a blue-to-yellow remapping
(assuming it has not been changed before)
2) makepalookup { pal 21 red 30 remapself }
This 'fogifies' palookup 21 with a red fog.
3) makepalookup { pal 21 red 30 }
This overwrites palookup 21 with a red fog, but clears the blue-to-red remapping.
The fog aspect of this command affects the GL modes just like 'fogpal', but the
remapping has no effect for hightiles.
- Also, silently clamp 'fogpal' r,g,b values to the range 0 .. 63.
git-svn-id: https://svn.eduke32.com/eduke32@2568 1a8010ca-5511-0410-912e-c29ae57300e0
Instead of drawing the rooms and masks with the classic renderer once.
The captured scene is transformed to use the base palette, so that the
screenshot will also show up in classic. No aspect correction is done.
git-svn-id: https://svn.eduke32.com/eduke32@2567 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
It allocates a buffer of size BMAX_PATH and copies the passed string into it.
git-svn-id: https://svn.eduke32.com/eduke32@2560 1a8010ca-5511-0410-912e-c29ae57300e0
This additionally fixes leaks that were caused by traversing the file name
list with the 'findfiles' pointer and not clearing them afterwards (even if
there was a handle to the list head via 'findfileshigh').
git-svn-id: https://svn.eduke32.com/eduke32@2557 1a8010ca-5511-0410-912e-c29ae57300e0
Don't actually replace the instances in the code now.
Additions in common.h:
- fnlist_t, which combines CACHE1D_FIND_REC *finddirs, *findfiles and
int32_t numdirs, numfiles
- the FNLIST_INITIALIZER macro, which MUST be used for automatic variables
- fnlist_clearnames, fnlist_getnames functions
- G_LoadGroupsInDir, G_DoAutoload, two often-occurring uses of these
git-svn-id: https://svn.eduke32.com/eduke32@2555 1a8010ca-5511-0410-912e-c29ae57300e0
Alongside, these make into into the header:
- the 'tokenlist' type (a typedef'd struct)
- the T_EOF and T_ERROR enumeration values
git-svn-id: https://svn.eduke32.com/eduke32@2549 1a8010ca-5511-0410-912e-c29ae57300e0
These are for LLVM bitcode, I think. In any case, they're giving me errors.
git-svn-id: https://svn.eduke32.com/eduke32@2544 1a8010ca-5511-0410-912e-c29ae57300e0
As inauguration, move G_AddGroup, G_AddPath and struct strllist there.
The header is located in build/include, because in the future, code that resides
closer to (but is not strictly part of) the engine might need to be factored
into here. The source file, however, is in the source/ directory.
git-svn-id: https://svn.eduke32.com/eduke32@2542 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 was broken ever since updatesprite() had been forked off drawsprite() and
would cause static lights to never hit static sprites until one or the other
changed, after which the light would always get culled against outdated sprite
geometry.
git-svn-id: https://svn.eduke32.com/eduke32@2536 1a8010ca-5511-0410-912e-c29ae57300e0
Since updatesprite() only happens once for static sprites, avoiding
light culling if we hit it in a shadow pass means that sprite will
never be lit as long as that happens.
git-svn-id: https://svn.eduke32.com/eduke32@2535 1a8010ca-5511-0410-912e-c29ae57300e0
There are instances where oob picnums may propagate to that function, so
protect it. The digitanumber[z] bound check is actually made more permissive,
but could also just as well be removed now.
git-svn-id: https://svn.eduke32.com/eduke32@2533 1a8010ca-5511-0410-912e-c29ae57300e0
The code in the editor was potentially doing a strcat on a strdup'd string.
Also, rename AddGamePath to G_AddPath in astub.c and add CODEDUP markers
because shared stuff like this ought to be factored out into a separate
source file some time.
git-svn-id: https://svn.eduke32.com/eduke32@2531 1a8010ca-5511-0410-912e-c29ae57300e0
Skill names are defined via 'defineskillname' as before, but the index
of the last non-empty skill name (plus one) is taken as the skill count.
So, if you only define the 6th, there will be no effect.
Note that currently, there is no way to specify less than four skills
because the CON parser doesn't allow the empty string for the name (it'll
go beyond the line) and because the default skill names are initialized in
EDuke32 too, in addition to the CONs.
git-svn-id: https://svn.eduke32.com/eduke32@2530 1a8010ca-5511-0410-912e-c29ae57300e0
This makes the differences in these codes stand out much more clearly.
git-svn-id: https://svn.eduke32.com/eduke32@2526 1a8010ca-5511-0410-912e-c29ae57300e0
The nofloorpalrange beginning and end indices are silently clamped to 1 .. 255.
git-svn-id: https://svn.eduke32.com/eduke32@2524 1a8010ca-5511-0410-912e-c29ae57300e0
- Fix typo, correctly adding SDL libs to the tools on OS X so that makesdlkeytrans builds.
- Move all mention of $(LIBS) out of build/Makefile into build/Makefile.shared because no linking takes place in the engine itself so LIBS additions were lost. This should fix USE_LIBPNG=1 on Windows at least.
- Other assorted cleanup.
git-svn-id: https://svn.eduke32.com/eduke32@2523 1a8010ca-5511-0410-912e-c29ae57300e0
- Fix up and add building instructions for kmd2tool, getdxdidf, and makesdlkeytrans.
- Add kmd2tool to "utils" build job.
- Fix warning in and cross-platform building of generateicon.
- Source and text cleanup!
git-svn-id: https://svn.eduke32.com/eduke32@2521 1a8010ca-5511-0410-912e-c29ae57300e0
- Properly handle the architecture definition when BUILD32_ON_64=1
- Add proper $(*LDFLAGS) to which LTO and ARCH are correctly passed.
- Cleanup of compiler flag variables.
This should fix to some degree building of the Build tools on OS X, and it may possibly fix the crashing of the OS X x86 32-bit build.
git-svn-id: https://svn.eduke32.com/eduke32@2520 1a8010ca-5511-0410-912e-c29ae57300e0
It has always annoyed me how floors with "shirt-color" type palookups like 21
affected the color of its containing sprites and HUD-drawn stuff. This commit
allows one to specify an inclusive range of pals for which this should be
disabled for sprites (but not for HUD stuff, yet).
git-svn-id: https://svn.eduke32.com/eduke32@2517 1a8010ca-5511-0410-912e-c29ae57300e0
An effect is only really seen in the buildtools written in C++, currently just arttool.
This is mainly of interest to distributors of the buildtools to avoid missing DLL errors.
git-svn-id: https://svn.eduke32.com/eduke32@2507 1a8010ca-5511-0410-912e-c29ae57300e0
We shouldn't assume a particular bytes-per-line value and use ylookup[] instead.
Specifically, windowed modes on Windows use a frame buffer that always has odd
x dimension.
git-svn-id: https://svn.eduke32.com/eduke32@2505 1a8010ca-5511-0410-912e-c29ae57300e0
- replace bit tweaking for big endian archs with clear code
- allow palette lookups >= 128, previously we read into a signed byte
git-svn-id: https://svn.eduke32.com/eduke32@2503 1a8010ca-5511-0410-912e-c29ae57300e0
- in Mapster, pre-form the default 10 clip map names before returning from
G_CheckCommandLine() so it gets loaded even if we passed no cmdline args.
- malloc + strlen + strcpy --> strdup
- don't need to spank dead variables ;)
- we may call calloc with zero size, which isn't bad by itself, but asserting
for non-null afterwards is. Allocs of 0 are implementation-defined, and may
well return a null pointer (C99 7.20.3).
git-svn-id: https://svn.eduke32.com/eduke32@2502 1a8010ca-5511-0410-912e-c29ae57300e0
Gives a couple more fps for scenes where much screen estate is covered by
stuff, like when holding the devastator.
git-svn-id: https://svn.eduke32.com/eduke32@2499 1a8010ca-5511-0410-912e-c29ae57300e0
With the same setup as before, a screen-filling translucent wall (with nothing
drawn behind it) renders at about 7 fps faster (from 60-something fps initially)
git-svn-id: https://svn.eduke32.com/eduke32@2498 1a8010ca-5511-0410-912e-c29ae57300e0
These two functions draw a vertical line 4 neighboring pixels at a time.
This gives a significant speed boost for a full screen solid and masked wall
scene for x86_64 (where we have plenty of registers), about 60 --> 76 fps.
git-svn-id: https://svn.eduke32.com/eduke32@2497 1a8010ca-5511-0410-912e-c29ae57300e0
Also, a very minor change in the con/def module code. (int --> int32_t)
git-svn-id: https://svn.eduke32.com/eduke32@2495 1a8010ca-5511-0410-912e-c29ae57300e0
A run of consecutive mapstates may share sector/wall/sprite blocks, but
the code was deciding whether to free them solely on local properties.
Now, save a reference count at the beginning of each such allocated block
and free it only if it reaches zero.
git-svn-id: https://svn.eduke32.com/eduke32@2492 1a8010ca-5511-0410-912e-c29ae57300e0
Also, always print at least level 5 corruptions (that is, have no instances
of completely silent corruptcheck).
git-svn-id: https://svn.eduke32.com/eduke32@2490 1a8010ca-5511-0410-912e-c29ae57300e0
This checks for about every possible type of sprite list corruption and
reports back with a corruption level 5 if one of the 14 validations fail.
git-svn-id: https://svn.eduke32.com/eduke32@2489 1a8010ca-5511-0410-912e-c29ae57300e0
- start scrolling from about half of the visible page
- PGUP/DGDN moves the cursor by 1/4 of the page
- code cleanup (we only need one displine[80], use clearkeys())
git-svn-id: https://svn.eduke32.com/eduke32@2488 1a8010ca-5511-0410-912e-c29ae57300e0
- Make all arguments explicit toggles (except for onlyzip).
- Disable PowerPC builds by default on Snow Leopard in addition to Lion.
- Enable Darwin 9 compatibility for all builds whenever PowerPC is enabled.
git-svn-id: https://svn.eduke32.com/eduke32@2487 1a8010ca-5511-0410-912e-c29ae57300e0
Note the capitalization. I hope that this makes clashes with user variable
names less likely.
git-svn-id: https://svn.eduke32.com/eduke32@2484 1a8010ca-5511-0410-912e-c29ae57300e0
Also include one comment about a currently failing assertion there.
git-svn-id: https://svn.eduke32.com/eduke32@2482 1a8010ca-5511-0410-912e-c29ae57300e0
Previously, if the sprite turned really out to be in void space, either freelist
inconsistency (before the list rewrite) or oob access (now) would happen.
Also add an bound-checking assert() for insertsprite's sectnum argument (it's not
a bound check!)
git-svn-id: https://svn.eduke32.com/eduke32@2480 1a8010ca-5511-0410-912e-c29ae57300e0
New engine variable 'int32_t Numsprites', not yet saved into savegames
or mapstates. (The capitalization is to distinguish it from the often-used
'numsprites' locals or structure member names.
In the editor, get rid of updatenumsprites().
git-svn-id: https://svn.eduke32.com/eduke32@2478 1a8010ca-5511-0410-912e-c29ae57300e0
Previously, the lists starting at headspritestat[MAXSTATUS] and
headspritesect[MAXSECTORS] were both used as sprite freelists and were always
in complete synchrony. Now, make only the statnum list keep the free sprites.
This way, it has no CON compatibility implications because
headspritesect[MAXSECTORS] is inaccessible there. Leave the array at its
original size for now.
git-svn-id: https://svn.eduke32.com/eduke32@2477 1a8010ca-5511-0410-912e-c29ae57300e0
Makefiles: new features to facilitate above:
- buildtools: "make printutils" is a phony which simply lists all the tools
- $(EXESUFFIX_OVERRIDE)
git-svn-id: https://svn.eduke32.com/eduke32@2476 1a8010ca-5511-0410-912e-c29ae57300e0
The major outside-visible change is that this fixes the sound cutoff bugs that
happened because newly-spawned sprites took the place of those whose sounds
had not yet finished playing.
Besides, there are these changes:
- remove deletesprite{sect,stat}
- we have a new engine variable 'tailspritefree' that keeps track of the
sprite freelist tail
- we need to store it in savegames and mapstates, so bump the savegame
minor version
git-svn-id: https://svn.eduke32.com/eduke32@2470 1a8010ca-5511-0410-912e-c29ae57300e0
This is simply done by using the two list helper functions defined earlier
instead of a deletespriteX/insertspriteX pair.
git-svn-id: https://svn.eduke32.com/eduke32@2469 1a8010ca-5511-0410-912e-c29ae57300e0
Factor out two helper functions, do_deletesprite{sect,stat}
and do_insertsprite_at_headof{sect,stat}.
git-svn-id: https://svn.eduke32.com/eduke32@2466 1a8010ca-5511-0410-912e-c29ae57300e0
These operations aren't executed THAT often to warrant exposing four internal
functions. Besides, I'll be hacking on them and need everything laid out
cleanly. Should somebody complain, they can go change them to __fastcall or
something.
git-svn-id: https://svn.eduke32.com/eduke32@2465 1a8010ca-5511-0410-912e-c29ae57300e0
In changesprite{stat,sect}, don't check for deletesprite{stat,sect} failure,
because the only way it can fail was already checked for above. So, this is
essentially dead code elimination.
git-svn-id: https://svn.eduke32.com/eduke32@2462 1a8010ca-5511-0410-912e-c29ae57300e0
- JFBuild ports: arttool, givedepth, and mkpalette
- All viable tools are now built when 'make utils' is invoked, not just some
- Revert "initprintf" hack of previous commit and replace it with "compat_tools.c"
- Move Bstrtolower from baselayer.c to compat.c
- Makefiles: Add start and finish messages for the tools
- Makefiles: To prevent "-Wimplicit" from being passed to the C++ compiler, create $(*CONLYFLAGS)
git-svn-id: https://svn.eduke32.com/eduke32@2458 1a8010ca-5511-0410-912e-c29ae57300e0
- Adding $(EXESUFFIX) where it belongs in the Makefile.
- Eliminating a call to initprintf() from compat.c. This may not be ideal.
git-svn-id: https://svn.eduke32.com/eduke32@2457 1a8010ca-5511-0410-912e-c29ae57300e0
- Generate changelog and add to zip.
- Increase minimum version to Leopard 10.5.
- Fix typo in usage printout.
git-svn-id: https://svn.eduke32.com/eduke32@2455 1a8010ca-5511-0410-912e-c29ae57300e0
This might now be even more confusing for users reading both the source
and CON code (where the access is necessarily still via '.clipping'),
but at least reading the source now makes sense :P
git-svn-id: https://svn.eduke32.com/eduke32@2454 1a8010ca-5511-0410-912e-c29ae57300e0
This is so that in the event of a crash, no CON dump will be printed if no
(actor or loadactor) CON code was actually executing at the time of the
crash, confusing the users. Note: doesn't apply for event code.
git-svn-id: https://svn.eduke32.com/eduke32@2453 1a8010ca-5511-0410-912e-c29ae57300e0
We've been running with same-sized actor_t for a while without problems now.
In the unlikely event (famous last words) that an issue should pop up later,
this revision should be consulted for the differences between the two versions.
git-svn-id: https://svn.eduke32.com/eduke32@2451 1a8010ca-5511-0410-912e-c29ae57300e0
- forgot a glogy --> logy in a-c.c
- comment out stretchhline and slopevlin2 in a.nasm, the former also in a-c.c
- make transmaskvline2 use a uintptr_t where appropriate
git-svn-id: https://svn.eduke32.com/eduke32@2448 1a8010ca-5511-0410-912e-c29ae57300e0
With VBOs enabled, the virtual pointer to the geometry of frame 0 of a model
is always NULL. This was confusing the polymer code responsible for deciding
whether to enable smooth animations or not, which meant that any animation
that would loop to frame 0 would do it as if animation interpolation was
disabled, which looks very choppy.
git-svn-id: https://svn.eduke32.com/eduke32@2443 1a8010ca-5511-0410-912e-c29ae57300e0
The format is
snd #<sound number>
inst <instance of that sound>:
voice <internal voice handle>,
ow <owner's sprite ID/-1> (this is the interesting part)
git-svn-id: https://svn.eduke32.com/eduke32@2441 1a8010ca-5511-0410-912e-c29ae57300e0
- make a couple variables static in sounds_mapster32.c
- KHz --> Hz in initialization text
git-svn-id: https://svn.eduke32.com/eduke32@2439 1a8010ca-5511-0410-912e-c29ae57300e0
- make some variables static
- conditionally compile out some code with DEBUG_ALLOCACHE_AS_MALLOC
- exit(1) on failure (instead of exit(0))
- some formatting
git-svn-id: https://svn.eduke32.com/eduke32@2438 1a8010ca-5511-0410-912e-c29ae57300e0
- Conditional disabling of the build for each architecture
- Conditional enabling of debug building
- Detection of the OS X version, disabling incompatible builds and establishing a minimum version
- Fail-safe assembly of fat binaries and the archive (each item is checked first)
- Lovely factored 'for' loops and parameter expansion
git-svn-id: https://svn.eduke32.com/eduke32@2437 1a8010ca-5511-0410-912e-c29ae57300e0
Note: I'm not really sure whether I'm initializing it in the right places.
git-svn-id: https://svn.eduke32.com/eduke32@2429 1a8010ca-5511-0410-912e-c29ae57300e0
When drawing from inside the mirror, there may be no 'bunches' (BUILD lingo,
not TROR ones) collected, but following code used the first one unconditionally.
git-svn-id: https://svn.eduke32.com/eduke32@2427 1a8010ca-5511-0410-912e-c29ae57300e0
Hlines for masked and translucent masked ceiling/floor (sprites).
- apply the --> 'do { ... } while (--cnt)' transformation, making these
functions iterate cnt+1 times like the asm version. This also fixes an
off-by-one issue where sprites or masked ceilings/floors had a one-pixel
non-drawn line to the right.
- This time, only declare-as-local two 'extern' globals (asm1 and asm2).
It seems that I was too eager with "localing" all file-scoped vars earlier.
GCC is able to remove the loads from memory inside the loop by itself, whereas
clang is not. This is not trivial, since it has to prove that the 'screen'
pointer passed to the functions will never alias these globals.
git-svn-id: https://svn.eduke32.com/eduke32@2424 1a8010ca-5511-0410-912e-c29ae57300e0
The apparent horizon (in units proportional to pixels by a constant factor)
was being calculated without normalizing to viewingrange, resulting a
discrepancy between the drawn and actual up/down angle with non-default
viewingranges (e.g. with r_usenewaspect=1, or when setting it from setaspect).
This also means that the center-of-aim will now be the same regardless of
the aspect.
This fixes many derived bugs:
* inconsistency w/ crosshair when shooting a gun and aiming up/down (obviously)
* bugs resulting from being able to look up/down too far (garbage non-slope
texture-mapping and viewing BIGORBIT skies above the borders in classic).
Note: mods that had workaround logic for this bug will have to remove it...
git-svn-id: https://svn.eduke32.com/eduke32@2414 1a8010ca-5511-0410-912e-c29ae57300e0
added: sector extra; viewingrange and yxaspect before the main drawrooms call
removed: randomseed
git-svn-id: https://svn.eduke32.com/eduke32@2413 1a8010ca-5511-0410-912e-c29ae57300e0
This has no measureable difference. Oh well, maybe it benefits weaker
machines, since the generated loop code should definitely be prettier.
git-svn-id: https://svn.eduke32.com/eduke32@2408 1a8010ca-5511-0410-912e-c29ae57300e0
This doesn't give much, maybe 0.5 fps more, probably because the
loop body is pretty long.
git-svn-id: https://svn.eduke32.com/eduke32@2406 1a8010ca-5511-0410-912e-c29ae57300e0
Affected functions: hlineasm4, vlineasm1, mvlineasm1, tvlineasm1.
Optimizations:
- declare all used variables as possibly const-qualified locals in each
function. This removes unnecessary loads from memory in the loops.
- rewrite "for (; cnt>=0; cnt--) {...}" to "cnt++; do {...} while (--cnt);"
in the three last ones (yes, these function iterate cnt+1 times). This
makes them functionally equivalent to the asm versions (madness ensues for
cnt < 0) and allows the compiler to remove one 'test' instruction at the
end of each loop.
- in the translucence function, replace addition by ORing
Observations (system: Core2 Duo Linux x86_64):
With a 1680x1050 window fully covered by the respective type of wall (simple,
masked, trans. masked), fps increases by 3-4 from the baseline of approx. 60.
git-svn-id: https://svn.eduke32.com/eduke32@2405 1a8010ca-5511-0410-912e-c29ae57300e0
- remove the objects too on 'clean'
- fix warning with 'transpal' on x64
(generates translucency and shade tables)
git-svn-id: https://svn.eduke32.com/eduke32@2404 1a8010ca-5511-0410-912e-c29ae57300e0
- print compilation status for building the final executable
- add 'cleanutils' target in build/Makefile
- don't link against pthread, seems unnecessary
- don't build nedmalloc.o when not requested in Makefile.common
git-svn-id: https://svn.eduke32.com/eduke32@2403 1a8010ca-5511-0410-912e-c29ae57300e0
- Exclude "Apple/lib" rather than "Apple" so that required files are not left out of the tarball.
- Add one to $lastrevision before generating the ChangeLog so that it only includes what is new to an update.
osxbuild.sh:
- Add stronger detection of the SVN revision by adding support for 1.7 (no longer relying on an ".svn" directory) and having a specific fallback in case the build location is neither svn nor git.
- Echo the SVN revision to source/rev.h before the build processes and revert it afterwards.
git-svn-id: https://svn.eduke32.com/eduke32@2402 1a8010ca-5511-0410-912e-c29ae57300e0
It needs to have the sound quality box removed and the Game directory box added, possibly among other things.
git-svn-id: https://svn.eduke32.com/eduke32@2396 1a8010ca-5511-0410-912e-c29ae57300e0
The replacement of atoi with strtol in r2374 had the side-effect that numbers
out of the range of a 32-bit integer were being returned as LONG_MAX/LONG_MIN
instead of being converted by taking the bits and re-interpreting them (note
that it was a coincidence that atoi behaved that way; to be strict, the
behavior was undefined and there is no regression).
Now, we implement parsing decimal integers using strtoll (with assuming
"long long" being the same as int64_t) and check in which range the number
falls. If it's in the range (INT32_MAX <= x <= UINT32_MAX), issue a warning;
if it's not in (INT32_MIN <= x <= UINT32_MAX), warn too (though this better
ought to be an error?). In each case, the bit representation is converted to
the CON number type (int32 to assume maximum portability) by re-interpreting
the bits [this is the same as an int/int cast, with GCC at least; more
generally, it's implementation-defined per C99].
git-svn-id: https://svn.eduke32.com/eduke32@2392 1a8010ca-5511-0410-912e-c29ae57300e0
(Classic renderer). We don't need 64-bit integers; also use the nice
asm version of divscale32() if possible.
git-svn-id: https://svn.eduke32.com/eduke32@2390 1a8010ca-5511-0410-912e-c29ae57300e0
This fixes mirrors consisting of more than one walls not drawing when the
first assigned mirror wall breaks. It still does not let you have more
than one mirror (i.e. mirror sectors) showing up at the same time in
the scene. Affects classic and Polymost only.
git-svn-id: https://svn.eduke32.com/eduke32@2387 1a8010ca-5511-0410-912e-c29ae57300e0
* update Windows icons to include 64x64, 128x128, and 256x256 sizes
* add "orange_icon.ico" (unused; classic orange color of logo)
* remove unused 32x32 "build_icon.bmp" file
git-svn-id: https://svn.eduke32.com/eduke32@2382 1a8010ca-5511-0410-912e-c29ae57300e0
This was causing oob sector accesses with code like this:
getwall[hitwall].nextsector temp
ifvarvare sector[temp].floorz sector[temp].ceilingz setvar tempb 1
(from DT's HYPERCORE).
Also validate quote indices passed to CON's quote and userquote commands at
runtime.
git-svn-id: https://svn.eduke32.com/eduke32@2381 1a8010ca-5511-0410-912e-c29ae57300e0
Such game text was shown starting from about the center of the screen.
The reason for the bug was this code:
t += 1 + isdigit(*(t+2));
The sequence points here are at the beginning and end of this assignment
expression, and the updating of t may happen anywhere between these (C99
6.5.16 #3). Please don't write such code. When in doubt, and assignment
and reference to the same object should be split!
git-svn-id: https://svn.eduke32.com/eduke32@2380 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
Because: 1) It used to be like this; 2) guard against bad CON input.
git-svn-id: https://svn.eduke32.com/eduke32@2378 1a8010ca-5511-0410-912e-c29ae57300e0
Encountered with Scent.map. Since the SE21 are deleted after they have
been used, the search for them in the ST28 code in sector.c may come up
empty, in which case sector[-1] would be accessed.
git-svn-id: https://svn.eduke32.com/eduke32@2377 1a8010ca-5511-0410-912e-c29ae57300e0
This was discovered because viewscreens (TILE_VIEWSCR) ceased being drawn
with the MAXTILES increase (reported by Hank, who also did the bisect).
git-svn-id: https://svn.eduke32.com/eduke32@2376 1a8010ca-5511-0410-912e-c29ae57300e0
That is, everyplace a user input is to be converted. The only remaining
instance of atoi() is now atoi(s_buildDate).
git-svn-id: https://svn.eduke32.com/eduke32@2374 1a8010ca-5511-0410-912e-c29ae57300e0
Internally, the last argument to neartag is now a pointer to a function
int32_t (*blacklist_sprite_func)(int32_t i),
which is supposed to return 1 if sprite[i] should NOT be considered for hitting.
This is now used in the hard-coded neartag() calls in sector.c, but not in any
way in CON (there's neither a C blacklist function provided, nor is there a
possibility to define one in CON). There, all sprites with picnums >=1 and <=10
(i.e. the effectors) will be blacklisted. This remedies problems where such
sprites would get in the way of switches.
Note that a whitelist approach (only consider a predefined set, namely those
picnums which will be checked afterwards) has back-compatibility implications
since people may have used e.g. lotagged window sprites to cover a switch.
Also, the >=1 to <=10 range is [sic] (the static, not dynamic values are used),
since anyone redefining effector picnums is clearly out of their mind.
git-svn-id: https://svn.eduke32.com/eduke32@2373 1a8010ca-5511-0410-912e-c29ae57300e0
lzwcompress can access one byte after lzwrawbuf[LZWSIZE] when provided with
an uncompleng of LZWSIZE, so we increase that array's size by one.
git-svn-id: https://svn.eduke32.com/eduke32@2369 1a8010ca-5511-0410-912e-c29ae57300e0
Remove dfread and kdfwrite, only leave a recipe how to get their
source from the respective used functions.
git-svn-id: https://svn.eduke32.com/eduke32@2368 1a8010ca-5511-0410-912e-c29ae57300e0
I'm not getting this warning (synthesis is) but I think it's justified because
the VOC block parsing code isn't terribly validating...
git-svn-id: https://svn.eduke32.com/eduke32@2364 1a8010ca-5511-0410-912e-c29ae57300e0
The following functions have const qualifiers attached for the 'destination'
arguments: kdfwrite, dfwrite in cache1d.c and copybuf{byte,reverse,} in the
pragmas source or headers. A couple uses of the latter ones were replaced
with calls to standard library functions.
git-svn-id: https://svn.eduke32.com/eduke32@2361 1a8010ca-5511-0410-912e-c29ae57300e0
This is useful to debug out-of-bound violations for memory allocated
with that function.
git-svn-id: https://svn.eduke32.com/eduke32@2360 1a8010ca-5511-0410-912e-c29ae57300e0
- RENDERER SETUP is now also accessible from classic, with only 2 options:
'aspect ratio' and 'ambient light level'
- remove the latter option from the VIDEO SETUP menu
- When compiled with OpenGL, the aspect ratio option cycles between 3 states:
r_usenewaspect=1 (the modern way), and r_usenewaspect=0 but r_widescreen=0/1.
In non-GL builds, there are only 2 states.
- don't display black translucent overlay in COLOR CORRECTION menu
git-svn-id: https://svn.eduke32.com/eduke32@2358 1a8010ca-5511-0410-912e-c29ae57300e0
This makes more sense because the game selector draws the names with uppercase
letters and the hotkeys to jump to a map starting with a particualar letter
aren't case sensitive, either. Mapster32's selector will still display maps
starting with upper case first.
git-svn-id: https://svn.eduke32.com/eduke32@2356 1a8010ca-5511-0410-912e-c29ae57300e0
The bulk are whitespace changes; the only exception is a
"if (expr) { stmt; }" --> "if (expr) stmt;"
git-svn-id: https://svn.eduke32.com/eduke32@2353 1a8010ca-5511-0410-912e-c29ae57300e0
Also, there's a "ladder" that passes through a TROR portal, and the mirror
in that map has been fixed for the classic renderer.
git-svn-id: https://svn.eduke32.com/eduke32@2351 1a8010ca-5511-0410-912e-c29ae57300e0
The reason was that drawmasks(), which was where the resetting of the fake
RoR textures happened under Polymer, can be called from polymer_displayrooms()
when mirrors are present. I was assuming that drawmasks() was only ever called
after the 'main' drawrooms and that hence the sequence of fake RoR tile tweaking
was set, reset, set, reset, ... which it was not.
Now, do the resetting explicitly after every drawmasks() in the editor.
git-svn-id: https://svn.eduke32.com/eduke32@2350 1a8010ca-5511-0410-912e-c29ae57300e0
I find this cleaner for two reasons. First, lotags won't get in the way of
neartag(), so that doors and switches near constrained TROR walls can be
pushed. Second, this removes the information leak so that CON coders aren't
tempted to read that values directly before a proper API for that comes along.
When writing out a map in-game (e.g. with dndebug), restore the respective
members so that it can be loaded in the editor again.
git-svn-id: https://svn.eduke32.com/eduke32@2349 1a8010ca-5511-0410-912e-c29ae57300e0
getzrange() returns the floor rather than the sprite if their heights are
equal. Now, make an exception for extended floors (analogously, ceilings).
git-svn-id: https://svn.eduke32.com/eduke32@2347 1a8010ca-5511-0410-912e-c29ae57300e0
- Maintain a position relative to the start of the data. VOC doesn't
mandate an EOF marker (blocktype 0). If we go over the end, fake
that marker, so as to restart a looping sound or stop a one-shot one.
This fixes an uninitialized mem access with the corrupt SNAKRM.VOC.
- When encountering the EOF marker, don't read the 3 bytes of block size,
since they may not be there.
- Read blocksize by ORing and shifting the 3 bytes, not with *(int32_t *)...
git-svn-id: https://svn.eduke32.com/eduke32@2346 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
This fixes updateanimation picking up foreign (and thus potentially oob)
frame numbers at "3: c > n".
git-svn-id: https://svn.eduke32.com/eduke32@2339 1a8010ca-5511-0410-912e-c29ae57300e0
Uncomment #define DEBUG_VALGRIND_NO_SMC in duke3d.h to be able to
valgrind --smc-check=none (or the default stack-only)
with Polymost and Polymer renderers.
git-svn-id: https://svn.eduke32.com/eduke32@2337 1a8010ca-5511-0410-912e-c29ae57300e0
It was causing update issues when many tints were applied simultaneously,
like being shot and spit at by enforcers while being on rails barefeet.
Also, the GL modes were calling gltexinvalidate8() when picking up goodies
or being hurt with that change, so it needs much more thought.
git-svn-id: https://svn.eduke32.com/eduke32@2322 1a8010ca-5511-0410-912e-c29ae57300e0
This fixes a bug in passing: 'int32_t j' was assigned to as a temporary inside
one instance of the code, but used as if it were the previous sprite index
further on. Would only happen with projectiles that "work like" both SPIT
and RPG_IMPACT.
git-svn-id: https://svn.eduke32.com/eduke32@2321 1a8010ca-5511-0410-912e-c29ae57300e0
- make PGUP/PGDN and HOME/END behave as expected across all menus
- in keyboard/mouse button mapping menu, draw function names that have been given
custom names via CON with pal 8 for easier recognition
- fix tinting of function names in mouse button mapping menu
git-svn-id: https://svn.eduke32.com/eduke32@2313 1a8010ca-5511-0410-912e-c29ae57300e0
Internally, there's a new function fade_screen_black() that implements the
fading more efficiently than calling rotatesprite for classic, and uses
tile 0 (assumed to have at least 64x32 size) in the GL modes.
The black background of the user map selector is still done with rotatesprite
and tile BLANK in every renderer.
git-svn-id: https://svn.eduke32.com/eduke32@2312 1a8010ca-5511-0410-912e-c29ae57300e0
So that the game won't exit if you write 'vidmode 4' when intending
'setrendermode 4'.
git-svn-id: https://svn.eduke32.com/eduke32@2311 1a8010ca-5511-0410-912e-c29ae57300e0
The problems still remains that rotatesprite behaves differently in classic and
OpenGL modes with clipping boundaries specified (and maybe in some other cases)
git-svn-id: https://svn.eduke32.com/eduke32@2304 1a8010ca-5511-0410-912e-c29ae57300e0
This means that when e.g. emerging from water hurt will change the
palette instantly, but because bit 16 is added to the P_SetGamePalette
call, the tinting is retained.
git-svn-id: https://svn.eduke32.com/eduke32@2303 1a8010ca-5511-0410-912e-c29ae57300e0
The implementation uses the recently introduced updatesector_onlynextwall when
setspritez fails.
git-svn-id: https://svn.eduke32.com/eduke32@2302 1a8010ca-5511-0410-912e-c29ae57300e0
Of course, only when the mod/TC in question doesn't use that feature.
git-svn-id: https://svn.eduke32.com/eduke32@2301 1a8010ca-5511-0410-912e-c29ae57300e0
led out or not. Removing features that certain mods may depend on to operate correctly without throwing any kind of
error or warning at startup other than a logged message is bad.
git-svn-id: https://svn.eduke32.com/eduke32@2300 1a8010ca-5511-0410-912e-c29ae57300e0
for an assertion failure with clang. Really ought to file a bug report instead.
git-svn-id: https://svn.eduke32.com/eduke32@2292 1a8010ca-5511-0410-912e-c29ae57300e0
It looks like GCC doesn't honor the 'used' attribute with LTO. This is
"fixed" by declaring the variables in question with external linkage
(i.e. removing the 'static'). I consider such behavior a GCC bug, though.
git-svn-id: https://svn.eduke32.com/eduke32@2286 1a8010ca-5511-0410-912e-c29ae57300e0
The "double-click button4" had to make way for MOUSE5 in the button binds menu,
but I don't think anyone cares. Savegame compatibility was actually silently
broken with the MAXTILES update earlier, but I forgot updating the version...
git-svn-id: https://svn.eduke32.com/eduke32@2284 1a8010ca-5511-0410-912e-c29ae57300e0
Also a couple of other cleanup lines... might need more though, I'm not sure
it's all good there.
git-svn-id: https://svn.eduke32.com/eduke32@2278 1a8010ca-5511-0410-912e-c29ae57300e0
Internally, updateanimation() now takes a third parameter 'lpal'.
git-svn-id: https://svn.eduke32.com/eduke32@2277 1a8010ca-5511-0410-912e-c29ae57300e0
This may fix compilation for optimized builds with GCC or clang where
the compiler would otherwise decide that those symbols are unused.
git-svn-id: https://svn.eduke32.com/eduke32@2271 1a8010ca-5511-0410-912e-c29ae57300e0
If enabled, this makes the following arrays be allocated statically:
spriteext, spritesmooth, sector, wall, sprite, tsprite, while
necessarily disabling the clipshape feature (because it relies on
setting sector/wall to different malloc'd block temporarily).
To compile, pass DEBUGANYWAY=1 in addition to RELEASE=0 to 'make',
and it's really only useful with CC=clang, of course.
git-svn-id: https://svn.eduke32.com/eduke32@2270 1a8010ca-5511-0410-912e-c29ae57300e0
Ideally, we would also warn when setting WEAPONx_SHOOTS to negative values, but
we'd have to intercept CON's setvar's and it wouldn't be pretty.
git-svn-id: https://svn.eduke32.com/eduke32@2268 1a8010ca-5511-0410-912e-c29ae57300e0
I'm decreasing EXTRATILES because I feel that it's way overcommitted. It's the
max number of model-tiles that have their own skin for a certain palette,
like the slimer egg in the HRP.
git-svn-id: https://svn.eduke32.com/eduke32@2267 1a8010ca-5511-0410-912e-c29ae57300e0
- fix one bound-checking line
- rewrite two lines in astub.c to potentially not overflow an int16
- make tiletovox[] an array of int16's
git-svn-id: https://svn.eduke32.com/eduke32@2266 1a8010ca-5511-0410-912e-c29ae57300e0
Always malloc that buffer. This allows us to remove suckcache() from
cache1d.c, which I believe to be buggy (see comments in the source).
git-svn-id: https://svn.eduke32.com/eduke32@2261 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
It is likely that this is the value it used to have at some point, because
the MAXTILEFILES macro equals 256 and is as old as the Duke3D source.
loadpics() now refuses to load an ART file with localtilestart or localtileend
out of bounds, or if localtileend<=localtilestart (i.e. no tiles in ART file, or
nonsense). Also, on 'invalid art file version', continue instead of returning.
Note: this does not increase the maximum number of tiles, which is still 15360,
it only gives a bit more freedom to arrange them (well, into more art files).
Also, I don't see what anyone keeps off from packing any number of tiles (from
1 to 15360) into an art file. Old EDITART limits?
git-svn-id: https://svn.eduke32.com/eduke32@2259 1a8010ca-5511-0410-912e-c29ae57300e0
The cause was a combination of many factors. First, Polymer requires the
start-drawing position to be inside the sector to draw (deviations lead to
incorrect drawing). This was violated by the game, because it interpolated
the current and next tic position without updating the sectnum, leading to
inconsistencies especially when passing through narrow sectors. Polymer
worked around it by doing an updatesector() each frame, however this works
poorly for maps with overlapping geometry such as SoS or RoR.
The solution to this is to add a new engine function,
updatesector_onlynextwalls(), which searches the sectors (via nextsector)
in breadth-first fashion instead of from 0 to numsectors-1, like updatesector
does when it fails for the *immediate* nextwall neighbors.
Internally, the breadt-first search helpers are moved into the engine.
git-svn-id: https://svn.eduke32.com/eduke32@2256 1a8010ca-5511-0410-912e-c29ae57300e0
so try and steal it back"), prevent calling IDirectDrawSurface_SetPalette()
with NULL arguments, causing a crash. It's happened for me on Vista, when
initially changing from 8-bit to 32-bit mode.
git-svn-id: https://svn.eduke32.com/eduke32@2255 1a8010ca-5511-0410-912e-c29ae57300e0
I didn't have much success in finding bugs using it, but it works
out-of-the-box on my setup, so it may be useful in the future.
git-svn-id: https://svn.eduke32.com/eduke32@2254 1a8010ca-5511-0410-912e-c29ae57300e0
The second one is passed to the 'mouseb' variable, but the game currently
can't map it since ud.config.MouseFunctions[] would have to be enlarged,
breaking savegame compatibility.
Works both for the Windows and SDL layers. For the latter, instead of using
the SDL_BUTTON_X1/X2 macro constants, I'm using 8 and 9, since that is what
SDL (and incidentally or not, xev) gives me for those buttons.
git-svn-id: https://svn.eduke32.com/eduke32@2252 1a8010ca-5511-0410-912e-c29ae57300e0
It turns out that with model interpolation, out-of-bounds frame numbers may
be generated with thinned out models, so disable it until I can sort out
what's wrong with it.
Also, minor code cleanup.
git-svn-id: https://svn.eduke32.com/eduke32@2251 1a8010ca-5511-0410-912e-c29ae57300e0
Also, for debugging builds, show this message from verbosity level 1 on.
git-svn-id: https://svn.eduke32.com/eduke32@2250 1a8010ca-5511-0410-912e-c29ae57300e0
Since the original source code release of Duke3D, there was a potentially
dangerous hack where actor[].dispicnum was set to -4 to signal "this actor
should not have a floor shadow for this moment" (it doesn't really work,
if you ask me).
Now, use another bit of actor[].flags for that purpose because setting
any picnum members to negative values asks for trouble.
git-svn-id: https://svn.eduke32.com/eduke32@2249 1a8010ca-5511-0410-912e-c29ae57300e0
the only visible change is that polymost_trytexcache (formerly two
instances of nearly duplicate code) now prints a diagnostic after
a cache miss. The one that one is most likely to encounter is
"r_downsize doesn't match", meaning that this setting likely differs
between Mapster and the game.
git-svn-id: https://svn.eduke32.com/eduke32@2248 1a8010ca-5511-0410-912e-c29ae57300e0
E.g. this should work correctly now:
// FLY_BY, PIPEBOMB_EXPLODE, OCTA_DYING
animsounds logo { 1 244 64 14 64 144 }
git-svn-id: https://svn.eduke32.com/eduke32@2243 1a8010ca-5511-0410-912e-c29ae57300e0
The syntax is as follows:
animsounds <anim> { frame1 sound1 frame2 sound2 ... }
<anim> has to be one of the tokens: cineov2, cineov3, RADLOGO, DUKETEAM,
logo, vol41a, vol42a, vol4e1, vol43a, vol4e2, or vol4e3, corresponding
to hard-coded Duke3D anims.
The frameN's (1-based frame numbers) have to be in ascending order (but not
necessarily strictly ascending, so that a frame may have more than one sound).
Example: for Duke3D's XBLA nuke logo animation (IVF extracted from nuke.webm),
the following definition overlays the video with a sound sequence similar
(identical save for timing) to the original nuke animation:
// frame 1: FLY_BY, frame 64: PIPEBOMB_EXPLODE
animsounds logo { 1 244 64 14 }
git-svn-id: https://svn.eduke32.com/eduke32@2242 1a8010ca-5511-0410-912e-c29ae57300e0
the loop. For the release build and the test animation, this lowers the time
to 3-4 ms per conversion of one frame on my desktop machine.
git-svn-id: https://svn.eduke32.com/eduke32@2241 1a8010ca-5511-0410-912e-c29ae57300e0
let it hang around causing trouble later on; delete it right now and inform
the user.
Add a couple of 'static's to some functions and file scope data in mdsprite.c
git-svn-id: https://svn.eduke32.com/eduke32@2237 1a8010ca-5511-0410-912e-c29ae57300e0
the SE ones douple, triple, ... after each save. Maphack lights are reloaded
with polymer_resetlights() (though I've had them disappearing after load, I
couldn't reproduce it afterwards).
- in debugging builds, print a message when polymer_resetlight is called on a
nonexistent one. The problem is not so much the call itself (it's guarded),
but the fact that resources on the caller side may not have been freed if it
thinks that those lights do in fact exist. Right now, it's not the case though.
- add 'loaded map hack' messages after some other successful loadmaphack calls
git-svn-id: https://svn.eduke32.com/eduke32@2236 1a8010ca-5511-0410-912e-c29ae57300e0
crashes.
Usually, after loading a game, some wall tiles are tweaked depending on whether
adult mode is enabled or not. If it's not, those wall picnums are replaced
with blank or broken screens. If it is, they are restored from the wall's
.extra member. Apparently though, Mapster32 leaves some .extra members
floating around even after deleting a TROR nextwall link (it's used as the
'lower wall index'). Because MAXWALLS is greater than MAXTILES, this may
produce out-of-bounds accesses and corrupt memory (besides setting wall
tilenums to nonsensical values) later in the game.
Other than that, the change only affects loading savegames created with adult
mode OFF. Kinky TV screenies simply won't be restored then.
git-svn-id: https://svn.eduke32.com/eduke32@2235 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
'frequently' isn't such a good idea. Assume an actor constantly changes the
palette to some value and you're attacked by a newbeast at the same time. Then
the pain tinting would be reset each time the actor's code is run. This commit
adds a new flag 16 to setbrightness(), meaning "don't reset the fade tinting".
Its only use right now is from CON's setgamepalette command (and there, always).
The change is done in the engine and thus affects all platforms.
git-svn-id: https://svn.eduke32.com/eduke32@2225 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
This is in the similar vein as the set-palette deferring and it's this
that fixes the low FPS in the radioactively contaminated area in AMC TC:
Megabase (since setgamma() is called from setbrightness()).
Again, update issues might be expected, but changing focus between EDuke32
and the desktop and back seems to restore the gamma settings properly on
Kubuntu. Looks like X (or whatever above handles this stuff) maintains it
on a per-application basis.
git-svn-id: https://svn.eduke32.com/eduke32@2222 1a8010ca-5511-0410-912e-c29ae57300e0
CON code sometimes uses 'setgamepalette' from withing actors, which is a bit too
frequent. Deferring the actual palette updating means that multiple requests in
between two screen redraws are coalesced into one, which is desirable for
performance reasons and for the reduction of 'tearing' artefacts (but not
prevention, since the drawing isn't synced to the screen refresh rate with
vsync off).
(Did-not-)update issues might be introduced.
Windows isn't touched because
- I expect it to be more brittle, especially in light of the ATI HW gamma
problems.
- I haven't tested whether the particular performance penalty that lead to this
change ('gas' in AMC TC) exists there too
git-svn-id: https://svn.eduke32.com/eduke32@2221 1a8010ca-5511-0410-912e-c29ae57300e0
color-inversed shots. For both PNG and TGA, change the way they're
done in 8-bit mode: instead of XORing every byte with 15, save the
inverse palette (each component taken 255-x).
git-svn-id: https://svn.eduke32.com/eduke32@2219 1a8010ca-5511-0410-912e-c29ae57300e0
instead of shorts. This fixes their values' overflow in AMC TC megabase and
probably a couple of other large maps.
git-svn-id: https://svn.eduke32.com/eduke32@2216 1a8010ca-5511-0410-912e-c29ae57300e0
the constants 0 and 1, and moveptrs may reference the script up to index 2
then (though I'm not sure whether the code is reachable with moveofs either
0 or 1), so make sure it's nulled instead of whatever happened to compile at
the first two positions. Move 1 is only used once in the original cons,
when frozen and being shattered.
git-svn-id: https://svn.eduke32.com/eduke32@2211 1a8010ca-5511-0410-912e-c29ae57300e0
Now we don't need to worry about the numbers running out soon.
Bump BYTEVERSION by three to celebrate this, too.
git-svn-id: https://svn.eduke32.com/eduke32@2209 1a8010ca-5511-0410-912e-c29ae57300e0
This makes savegames practically the same as the initial snapshot of a demo.
Saves are now named 'dukesavX.esv' (demos: 'edemoX.edm').
Additionally, many changes that couldn't/needn't be cleanly separated are added
with this commit:
- make spriteext_t have the same size across 32/64 bit platforms (actor_t partially)
- prevent saving/loading in MP games (it certainly didn't work and still doesn't)
- it's time we start using assertions! Define NDEBUG for releasse builds.
- reset savegame major and minor versions (we have a new magic string, so no conflict)
git-svn-id: https://svn.eduke32.com/eduke32@2207 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
Bmemset(..., 0, sizeof(...)) instead of clearbuf(..., MAX..., 0),
because the latter would clear only half of the data on 64-bit platforms.
git-svn-id: https://svn.eduke32.com/eduke32@2189 1a8010ca-5511-0410-912e-c29ae57300e0
some information about it instead of simply omitting it.
Internally, struct savegame --> struct savegame_ for easier grepping.
git-svn-id: https://svn.eduke32.com/eduke32@2188 1a8010ca-5511-0410-912e-c29ae57300e0
32- and 64-bit platforms. Also, make struct type actor_t also have a common
size of 128 bytes. New code currently disabled and #ifdef'd for comparison.
This requires certain t_data[] entries ([1]: move ptr, [4]: action ptr and
[5]: ai ptr with actors) to be converted to script offsets instead of pointers,
breaking savegame and net packet compatibility (we could in theory try hard not
to, but it would be too much trouble).
git-svn-id: https://svn.eduke32.com/eduke32@2185 1a8010ca-5511-0410-912e-c29ae57300e0
Actors are always moved such that _they_ clip against blocking sprites, even
if their blocking bit is clear. Setting the new bit make them not clip against
anything. The promary use of this is for decorative moving sprites that are
spawned in masses, such as rain or snow.
git-svn-id: https://svn.eduke32.com/eduke32@2184 1a8010ca-5511-0410-912e-c29ae57300e0
already have MAXSPRITESONSCREEN of them, return 1 to signal that the caller
should break out of the loop.
git-svn-id: https://svn.eduke32.com/eduke32@2183 1a8010ca-5511-0410-912e-c29ae57300e0
to negative numbers. Previously, only checks for being zero were performed,
but CON code in the wild also has WEAPONx_SPAWN -1, which would propagate to
the sprite picnum...
git-svn-id: https://svn.eduke32.com/eduke32@2180 1a8010ca-5511-0410-912e-c29ae57300e0
Usage: press the ['] (quote) modifier together with the PERIOD key.
Aligns only the immediate upper and lower neighbors of each wall that got
aligned by following point2s or nextwalls. Doesn't play well with Alt
(carry over xrepeat) yet, might need two subsequent alignment passes.
git-svn-id: https://svn.eduke32.com/eduke32@2178 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
(getzrange, hitscan, clipmove, drawmapview).
They're reproducible with DNE1.3D; Since these angle values most likely come
from CON code, my suggestion would be to bit-and all values representing angles
with 2047 when setting the from CON, but I'd have to think about potential
side-effects of doing this.
git-svn-id: https://svn.eduke32.com/eduke32@2170 1a8010ca-5511-0410-912e-c29ae57300e0
callback 'G_Polymer_UnInit'.
- In astub.c, reset spritelightid to -1 when nulling the spritelightptr of
a sprite (no crashes observed, just precaution)
- In sdlayer.c, catch SIGILLs with our signal handler too, since illegal
instructions are what the instrumented debug builds will execute when
attempting to carry out an undefined (per C) operation.
git-svn-id: https://svn.eduke32.com/eduke32@2169 1a8010ca-5511-0410-912e-c29ae57300e0
How in the name of hell this could pass undetected for so long is a
mystery to me.
git-svn-id: https://svn.eduke32.com/eduke32@2163 1a8010ca-5511-0410-912e-c29ae57300e0
values; check the color index that is potentially gotten from the string to
be printed.
git-svn-id: https://svn.eduke32.com/eduke32@2162 1a8010ca-5511-0410-912e-c29ae57300e0
menu. If some sectors are highlighted, save their indices. The highlighting
of those particular sectors can then be restored at a later time (but careful
across structural modifications that tweak sector indices) by running the same
function. Shares a 'gamearray' with function 'collect_teleporting_sectors',
so the latter will reset this one when run.
git-svn-id: https://svn.eduke32.com/eduke32@2155 1a8010ca-5511-0410-912e-c29ae57300e0
one sector was filled and the 'clear bunch' message was displayed even if the
operation was canceled.
git-svn-id: https://svn.eduke32.com/eduke32@2153 1a8010ca-5511-0410-912e-c29ae57300e0
represents a pointer into the script for label types other than LABEL_DEFINE
instead of checking inclusion of the value in the script bounds. This
assertion was tested with WGR2 SVN.
git-svn-id: https://svn.eduke32.com/eduke32@2150 1a8010ca-5511-0410-912e-c29ae57300e0
them has a different height, print the sectnums of two differing sectors
to so that the mapper can find and examine them with Ctrl-J.
git-svn-id: https://svn.eduke32.com/eduke32@2146 1a8010ca-5511-0410-912e-c29ae57300e0
The texture warping mode will need to be set depending on whether we're
actually drawing a parallaxed sky or not.
git-svn-id: https://svn.eduke32.com/eduke32@2142 1a8010ca-5511-0410-912e-c29ae57300e0
This fixes the vertical (~1 texel wide) stripes that are especially
noticable with tiled art skies and Polymost with r_parallaxskyclamp=1
or Polymer (which always uploads skies with repeating s and t coords).
What constitutes a sky tile is currently hardcoded to be >=78 and <=99.
git-svn-id: https://svn.eduke32.com/eduke32@2141 1a8010ca-5511-0410-912e-c29ae57300e0
and restore_highlighted_sector functions. What this means is that TROR bunches
are now correctly duplicated too (only if all sectors of a given bunch are
highlighted).
git-svn-id: https://svn.eduke32.com/eduke32@2138 1a8010ca-5511-0410-912e-c29ae57300e0
(i.e. first press RAlt, then hold RShift to make it active), consider all
sectors, even the grayed out ones.
This makes 6 modifier keys in 4 categories for RAlt. Can you name them all?
Also spell out the labels that get drawn near the reticle when applying
some of the modifiers and make them not show when not actually selecting
(e.g. pressed RShift alone, but have highlighted sectors)
git-svn-id: https://svn.eduke32.com/eduke32@2137 1a8010ca-5511-0410-912e-c29ae57300e0
that bunches and nextwall links are restores, too. Now, to coalesce two
TROR maps (e.g. for a CBP), one could
do for i allsectors, sethighlightsector i 1
on the console, and then load the 'other' map to copy over the contents
of the first, including all TROR stuff. Note that neither selecting
all sectors with RAlt, nor duplicating them with Insert would lead to
the desired effect (yet).
Internally,
- yax_setbunch() now has different behavior for bunchnums -1, -2 and -3
(it either clears the nextwalls or not)
- build.c has a helper function free_n_ptrs(). This could be handy in
other situations where many blocks of memory must be allocated
consecutively and freed in case of failure
git-svn-id: https://svn.eduke32.com/eduke32@2136 1a8010ca-5511-0410-912e-c29ae57300e0
suboptimal, but at least 'correct' and won't produce the aforementioned
corruptions anymore.
git-svn-id: https://svn.eduke32.com/eduke32@2135 1a8010ca-5511-0410-912e-c29ae57300e0
can be caused by copying map parts from one map to another (or a new one).
The copying system is slightly broken right now....
git-svn-id: https://svn.eduke32.com/eduke32@2133 1a8010ca-5511-0410-912e-c29ae57300e0
next{wall,sector} indices instead of using checksectorpointer() so
that the nextwalls will be restored exactly as they were (provided
that they are copied). Also fix tweaking the sectnums of sprites.
git-svn-id: https://svn.eduke32.com/eduke32@2132 1a8010ca-5511-0410-912e-c29ae57300e0
Called 'loop punching'. In addition to duplicating the loop, the inner
portions of the original and cloned loop are made into a new bunch, and
the loop walls are made to be neighbors, linking their movement to each
other. This gives a way to create island sectors with a differing
bunchnum in the midst of an already extended area.
Usage:
For an extended sector containing a CCW inner loop, select its points
using Ctrl+Shift. Press Ctrl-E to be queried whether to duplicate the
points into the upper or lower extension (even if it's unambiguous).
A number of conditions must be met for a successful 'punch', which
should hopefully be more or less obvious. Among them:
- loop walls should all be red
- the starting wall is only considered among the non-grayed-out ones
- the neighboring sector must not contain points inside or at the loop
git-svn-id: https://svn.eduke32.com/eduke32@2130 1a8010ca-5511-0410-912e-c29ae57300e0
would break out of the 2D mode loop when splitting a sector would exceed
limits.
git-svn-id: https://svn.eduke32.com/eduke32@2129 1a8010ca-5511-0410-912e-c29ae57300e0
- Don't crash when sector joining fails under certain circumstances.
- Increase the point lock (Manhattan) distance from 1/16th to 1/8th
of the grid square length, making it easier to snap to vertices not
lying at the grid points with grid lock on
- When drawing walls, don't snap to any of them except the first drawn
git-svn-id: https://svn.eduke32.com/eduke32@2126 1a8010ca-5511-0410-912e-c29ae57300e0
When having drawn N new points (and having one 'free') and pressing
ENTER, the N line segments between the new points are checked one by
one for intersection with every non-grayed-out wall and a wall vertex
is inserted at every intersecting point. This may be viewed as a
prerequisite for a 'cutter' style tool.
git-svn-id: https://svn.eduke32.com/eduke32@2125 1a8010ca-5511-0410-912e-c29ae57300e0
This function only handles the actual insertion, also taking care of
constrained TROR walls. Anything around the inserting such as backing up
drawn walls or snapping the x/y position to the grid is handled outside.
git-svn-id: https://svn.eduke32.com/eduke32@2123 1a8010ca-5511-0410-912e-c29ae57300e0
The main change consist of adding a key press (and release) callback
whose only purpose is to be used from m32script as EVENT_KEYPRESS.
When entering that event, the RETURN variable will be set to the
keystatus code of the key, and whether it was pressed or released can
be checked by looking at keystatus[] at that code (ifholdkey and
ifhitkey do this). The purpose of this, then, is to be able to remap
keys in a more general (and complicated) fashion than is possible with
the mapster32.cfg 'remap' option. Various other additions build around
this central one:
- add an example EVENT_KEYPRESS to a.m32, among other things emulating
the keypad arrows with Alt-<normal arrows> for notebook convenience;
disabled initially
- a.m32: set 'owner' with Alt-KP2: now Alt-Shift-KP2, because of
collision with the above
- new m32script command: setkey <keycode>, setting keystatus[<keycode>]
to 1 (note: may be restricted to use in EVENT_KEYPRESS only in the
future)
- fix indexing an m32script array with a defined label, there used to
be a 'not a gamevar' error instead
- add the following constant labels for some key codes:
KEY_SCROLL, KEY_F1 .. KEY_F12
git-svn-id: https://svn.eduke32.com/eduke32@2122 1a8010ca-5511-0410-912e-c29ae57300e0
with no highlighted sectors; and when entering 3D mode, even if there are
highlighted sectors. This should have almost no effect, but I find it cleaner
that way.
- Check map for corruption every time an editing change is done. This was
accidentally disabled when commenting out the undo code (which I've yet
to debug).
git-svn-id: https://svn.eduke32.com/eduke32@2121 1a8010ca-5511-0410-912e-c29ae57300e0
of SPACE and C when in side-view mode. Now, this is accomplished by checking
directly in the overheadeditor code.
git-svn-id: https://svn.eduke32.com/eduke32@2119 1a8010ca-5511-0410-912e-c29ae57300e0
selector. This could lead to a crash when OpenGL wasn't initialized before.
git-svn-id: https://svn.eduke32.com/eduke32@2117 1a8010ca-5511-0410-912e-c29ae57300e0
(lazy_tileselector=1 in mapster32.cfg). We're drawing tiles one by one,
so glDrawBuffer(GL_FRONT_AND_BACK) is our friend.
git-svn-id: https://svn.eduke32.com/eduke32@2115 1a8010ca-5511-0410-912e-c29ae57300e0
sector c/f and moving one of them would go beyond the other side (ceilingz >
floorz), don't move any sector c/f at all. When moving only one sector in that
case, move so that ceilingz == floorz.
git-svn-id: https://svn.eduke32.com/eduke32@2112 1a8010ca-5511-0410-912e-c29ae57300e0
Now, if more than one sectors are affected, always move them by the same
amount. That is, if one of them would be sticking against the other side,
don't move the rest. Another change consists of determining the z delta
first, and only then moving the sprites by that amount. This fixes the
problem where you'd e.g. raise a 'floor door' against the ceiling, and the
effector sprites would be raised one time too much, preventing them from
being lowered the next time.
git-svn-id: https://svn.eduke32.com/eduke32@2111 1a8010ca-5511-0410-912e-c29ae57300e0
- new mapster32.cfg and OSD variable 'fixmaponsave_sprites', telling the
editor whether to 'fix' the sprite sectnums on saving and entering 3D
mode. Note that a) sprite sectnums are never fixed when 'script_expertmode'
is enabled, as before, and b) sprites that have out-of-bounds sectnums
are still fixed if a proper sector is found
- if saving and some sprite sectnums have thus been tweaked, inform the
mapper on the status line and print the changes in the OSD
- fix update issue similar to an earlier one: when 'saving as', the astub.c-
based file name is now updated too, so saving with Ctrl-S now saves into
the one save with 'save as' (and not the old one)
- don't attempt to recheck wall pointers from scratch (when saving and running
with -check) if it's a TROR map
git-svn-id: https://svn.eduke32.com/eduke32@2110 1a8010ca-5511-0410-912e-c29ae57300e0
Hopefully this fixes the periodic pausing/unpausing that a few people
have been experiencing.
Also fix build with GCC 3.
git-svn-id: https://svn.eduke32.com/eduke32@2108 1a8010ca-5511-0410-912e-c29ae57300e0
with RAND_MAX > 32767 (everything except Windows?). The 'displayrand' command
now returns values from 0 to 32767 inclusive, across all platforms.
git-svn-id: https://svn.eduke32.com/eduke32@2105 1a8010ca-5511-0410-912e-c29ae57300e0
setactorsoundpitch <actor#> <sound#> <pitchoffset>
which can be used to change the pitch of a playing sound.
The pitch offset has the same meaning as the definesound pitch range endpoints,
i.e. the units are 1/100th of a seminote. Note that just like the random pitch
offset, increasing the pitch makes the sound duration shorter (and vice versa).
git-svn-id: https://svn.eduke32.com/eduke32@2104 1a8010ca-5511-0410-912e-c29ae57300e0
member, so maybe not *that* bad) and an invalid memory access when trying to
access a per-player gamevar in a player-less context (e.g. WGR2 SVN r25
WGR2GAME.CON line 10448).
git-svn-id: https://svn.eduke32.com/eduke32@2102 1a8010ca-5511-0410-912e-c29ae57300e0
playback functions. Without these, there would be an uninitialized access
in line 444 of multivoc.c (if the memory in question was allocated with malloc,
but still...)
git-svn-id: https://svn.eduke32.com/eduke32@2101 1a8010ca-5511-0410-912e-c29ae57300e0
and some VoiceNode struct members with a const, commit forgotten vorbis.c
changes.
git-svn-id: https://svn.eduke32.com/eduke32@2100 1a8010ca-5511-0410-912e-c29ae57300e0
last one + this one:
A couple of tweaks against accidental overwriting of maps.
- first, fix a bug where the map name wasn't reset to 'newboard.map' when starting a
new map
- When saving with Ctrl-S, query the user for confirmation and also show the file name
where the map will be written
- when going into the ESC-menu, print the file name where the map will be written
on pressing 'S' above the '(S)ave' text
git-svn-id: https://svn.eduke32.com/eduke32@2096 1a8010ca-5511-0410-912e-c29ae57300e0
Keep in mind that MUSICANDSFXs with ambient sounds must still have lotags
less than 999 because values >=1000 are used for the amount of reverb.
(999 can't be used because the original code reads '< 999' and I'm not
sure whether it has any special significance... probably not though)
git-svn-id: https://svn.eduke32.com/eduke32@2093 1a8010ca-5511-0410-912e-c29ae57300e0
cursor, query the mapper to pick one. The joining can still fail afterwards,
which makes it only a semi-automatic helper feature.
git-svn-id: https://svn.eduke32.com/eduke32@2092 1a8010ca-5511-0410-912e-c29ae57300e0
allowed circle-walls started on the unconstrained _other_ side of a constrained
wall. Also fix a potential invalid wall access when inserting a point (pretty
serious, that!)
git-svn-id: https://svn.eduke32.com/eduke32@2091 1a8010ca-5511-0410-912e-c29ae57300e0
also for make-circle (C, SPACE). There's still a TROR corruption happening
probably when inserting on constrained walls, but I've yet to get behind the
real cause.
git-svn-id: https://svn.eduke32.com/eduke32@2090 1a8010ca-5511-0410-912e-c29ae57300e0
some wall drawing state is ripped out from overheadeditor() into a
a file-scope struct (even if we don't yet need it there). If the deleting
touches the first drawn point, the walls drawn so far are cleared.
git-svn-id: https://svn.eduke32.com/eduke32@2089 1a8010ca-5511-0410-912e-c29ae57300e0
overheadeditor() by allocating temp variables in the blocks where they
are needed.
git-svn-id: https://svn.eduke32.com/eduke32@2088 1a8010ca-5511-0410-912e-c29ae57300e0
- fix arg checking in checkdefs.sh
- some tilenum and quote ID validation in the CON interpreter
- G_DrawDigiNum and friends: eliminate redundant strlen calls
git-svn-id: https://svn.eduke32.com/eduke32@2086 1a8010ca-5511-0410-912e-c29ae57300e0
ATI cards.
From the time of OpenGL initialization, gamma lookup in classic/fullscreen
will be done in software. Before that, always do a setgamma() after setting the
palette, since this is what resets the HW gamma. However, this may lead to
unappealing artifacts with portions of the scene being sent to the screen with
different gammas.
git-svn-id: https://svn.eduke32.com/eduke32@2085 1a8010ca-5511-0410-912e-c29ae57300e0
add it to the 'all' target instead
source/midi.c: eliminate one 'variable set but not used' warning
git-svn-id: https://svn.eduke32.com/eduke32@2084 1a8010ca-5511-0410-912e-c29ae57300e0
maybe replace them with the proper names.
Usage:
checkdefs.sh <some.def> [[<some_dir>] -patch]
<some_dir> is taken to be the base directory of the search path.
-patch uses 'sed -i' to replace the offending findings
git-svn-id: https://svn.eduke32.com/eduke32@2081 1a8010ca-5511-0410-912e-c29ae57300e0
We pack our own copy of glext.h to avoid build breakages on older environments,
and having gl.h include its own was defeating all that.
git-svn-id: https://svn.eduke32.com/eduke32@2080 1a8010ca-5511-0410-912e-c29ae57300e0
fashion. Among other things, this makes the FOV widening when shrunk
work. User CON code should always check the initial viewingrange value
when attempting to do FOV effects like zoom, because it is not guaranteed
to be 65536 due to different screen aspect ratios etc.
git-svn-id: https://svn.eduke32.com/eduke32@2078 1a8010ca-5511-0410-912e-c29ae57300e0
First, when pressing 'S on signed members (like the shade), display
the real signed value instead of the value cast to an unsigned type.
Second, when aiming at an overwall and pressing G, affect the overwall
instead of the wall. Maybe these changes affect a few other queries too...
git-svn-id: https://svn.eduke32.com/eduke32@2077 1a8010ca-5511-0410-912e-c29ae57300e0
ceilings or floors. In such cases, you're not squished unconditionally (instead
of fetching the ceiling or floor height of the neighbor sector), but TROR isn't
meant for small-scale RoR anyway.
git-svn-id: https://svn.eduke32.com/eduke32@2071 1a8010ca-5511-0410-912e-c29ae57300e0
polymer_addlight(). I have no idea whether it's the 'right' thing,
but it fixes this:
Conditional jump or move depends on uninitialised value(s)
at polymer_updatelights (polymer.c:5090)
by polymer_drawrooms (polymer.c:938)
. . .
Uninitialised value was created by a stack allocation
at loadmaphack (engine.c:9482)
Fix another uninitialized access when rendering jpegs.
git-svn-id: https://svn.eduke32.com/eduke32@2069 1a8010ca-5511-0410-912e-c29ae57300e0
This fixes a crash when loading a map afterwards.
Tweak a few debugging messages and some whitespace.
git-svn-id: https://svn.eduke32.com/eduke32@2068 1a8010ca-5511-0410-912e-c29ae57300e0
Also move a 'int16_t editstatus' declaration from polymost.c to engine_priv.h.
git-svn-id: https://svn.eduke32.com/eduke32@2066 1a8010ca-5511-0410-912e-c29ae57300e0
My choice of solution is simply to add an extra set of values duplicating the previous five because doing so would definitely show the user no changes. I could have tinkered with the messy loop where the out-of-bounds references are made but there is no guarantee I could have succeeded or kept compatibility.
git-svn-id: https://svn.eduke32.com/eduke32@2061 1a8010ca-5511-0410-912e-c29ae57300e0
Getting the texture handles without requiring invalidation means we can
handle ART-animating tilenums without impacting performance too much.
git-svn-id: https://svn.eduke32.com/eduke32@2058 1a8010ca-5511-0410-912e-c29ae57300e0
Polymer has a hack that snaps horiz values of spotlights between 90 and 110
to 90 and 110 to avoid triggering aliasing artifacts with perfectly horizontal
spotlights. Propagate that change all the way to the spotlight SE sprite so
that the code won't think that the horiz is always different from the light
and mark it invalid each frame.
git-svn-id: https://svn.eduke32.com/eduke32@2057 1a8010ca-5511-0410-912e-c29ae57300e0
This won't actually do anything until the a debug bit is added when
creating the context, but that requires support for GLX_create_context
which SDL doesn't support. I'll add support for WGL_create_context to
winlayer in a bit as a stopgap.
Also updates our local copy of glext.h with a fresh one from the
Khronos registry.
git-svn-id: https://svn.eduke32.com/eduke32@2056 1a8010ca-5511-0410-912e-c29ae57300e0
We need to Y-invert the projection texcoords when sampling
from the lightmap.
git-svn-id: https://svn.eduke32.com/eduke32@2055 1a8010ca-5511-0410-912e-c29ae57300e0
Sprites would stick with their old material on global palette change.
This goes through all prsprites and clobbers their CRCs so that an
alternate skin / tint / highpal can be applied accordingly.
git-svn-id: https://svn.eduke32.com/eduke32@2053 1a8010ca-5511-0410-912e-c29ae57300e0
The winding order of faces is different if only flipping about X or Y,
and we were unconditionally culling CW faces.
git-svn-id: https://svn.eduke32.com/eduke32@2052 1a8010ca-5511-0410-912e-c29ae57300e0
the nextwall pointers correctly; Add some 'asksave=1' and 'make old-nextwalls
invalid'.
git-svn-id: https://svn.eduke32.com/eduke32@2048 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
of the picnums of all sprites, omit the newly inserted sprite itself!
git-svn-id: https://svn.eduke32.com/eduke32@2043 1a8010ca-5511-0410-912e-c29ae57300e0
three individual loops and compile the enclosing function at -O3 (-O1 for
debugging builds). Now, the time for this conversion ranges from 7 to 18
ms per frame across various tested machines, a clear improvement.
git-svn-id: https://svn.eduke32.com/eduke32@2042 1a8010ca-5511-0410-912e-c29ae57300e0
This way, crashlogs will really be appended. Additionally, print a time
at the end of each backtrace.
winlayer.c: load ebacktrace1.dll instead of the old one
Makefile.common: when building with DEBUGANYWAY=1, don't omit frame pointers
This will let us get a stack trace for crashes with the release build code.
git-svn-id: https://svn.eduke32.com/eduke32@2040 1a8010ca-5511-0410-912e-c29ae57300e0
and build our own DLL, now called ebacktrace1.dll. The change consists of
breaking the link to the libintl lib and its dependencies, so the backtrace dll
is now the only one required.
git-svn-id: https://svn.eduke32.com/eduke32@2037 1a8010ca-5511-0410-912e-c29ae57300e0
./configure --disable-vp8-encoder --disable-multithread
Also add VPX/VP8 headers for an easy build on Windows. Throw in the
necessary lines into the Makefile but do not enable VPX support yet.
git-svn-id: https://svn.eduke32.com/eduke32@2036 1a8010ca-5511-0410-912e-c29ae57300e0
- when pasting to walls or maskwalls, the following user bits are kept now:
4 (top/bottom alignment [O])
1+64 (blocking, hitscan)
8+256 (x/y-flip)
- print '(one-sided)' when pressing Shift + ([B] or [H]) on a wall
git-svn-id: https://svn.eduke32.com/eduke32@2033 1a8010ca-5511-0410-912e-c29ae57300e0
Keep track of which side is getting culled, swap around mirrors, swap
around model drawing.
git-svn-id: https://svn.eduke32.com/eduke32@2032 1a8010ca-5511-0410-912e-c29ae57300e0
is picked" but still not perfect. In particular, sometimes a wrong wall is
selected, and sprites don't get picked through portals. As a rule of thumb,
don't be too far away from the objects you're modifying in 3D mode.
git-svn-id: https://svn.eduke32.com/eduke32@2030 1a8010ca-5511-0410-912e-c29ae57300e0
before, and additionally a mode that doesn't clip against masked walls
and sprites.
git-svn-id: https://svn.eduke32.com/eduke32@2028 1a8010ca-5511-0410-912e-c29ae57300e0
uint64_t gethiticks() and gethitickspersec(). For SDL 1.2, the timer
has the same resolution as getticks (1000 Hz). For Windows and SDL 1.3,
the resolution of the underlying perf-timers is used. The only user of
these functions right now is some TROR on-screen debugging code.
Revert an earlier change regarding r_preview_mouseaim. We can't do the
check because editstatus is set later.
git-svn-id: https://svn.eduke32.com/eduke32@2026 1a8010ca-5511-0410-912e-c29ae57300e0
the additional rendering pass
- Remove r_preview_mouseaim cvar from the game, since it's only for Mapster
- sdlmusic.c: (Failed) attempt to fix a call of waitpid() with a non-existent
process ID in the external MIDI playing code. I think there's a race there...
git-svn-id: https://svn.eduke32.com/eduke32@2025 1a8010ca-5511-0410-912e-c29ae57300e0
functionality, Polymost).
The new feature can be enabled/disabled with the 'r_tror_nomaskpass' cvar.
The basic idea is that when drawing lower or upper levels, a first pass
is performed that ignores all red walls for which the TROR nextwall link
'towards' the viewer arrives at a red wall. Thus, in the worst case, there
can be up to twice as many rendering passes now (when it is discovered that
the no-mask-pass isn't different that what would be drawn with the ordinary
one, the latter is skipped, since we've already drawn all needed geometry).
Hovever, this kind of multi-pass splitting is only suitable for simple scenes,
like the upper subway in the TROR test map. In particular, multiple islands
shouldn't 'see' each other.
Two issues are worth mentioning: first, care needs to be taken for translucent
ceilings or floors, since drawing them twice isn't the same as drawing them
once. This is done for classic, but not for Polymost. Second, sprites (which
are always drawn _after_ the geometry for a given pass) are still clipped to
the geometry of the ordinary pass, resulting in their disappearance from
certain angles.
--
Additionaly, a change made it into this commit that fixes redundant collection
of sprites in TROR:classic/Polymost.
git-svn-id: https://svn.eduke32.com/eduke32@2024 1a8010ca-5511-0410-912e-c29ae57300e0
- remove 'imageSize' global which was always yres*bytesperline and only used once
- some clearbuf() -> Bmemset() because I find the latter easier to read
- remove some clearbufs to 0 of some global arrays on init
git-svn-id: https://svn.eduke32.com/eduke32@2023 1a8010ca-5511-0410-912e-c29ae57300e0
always like this now:
ExtUninit -> (writesetup, misc.)
uninitengine -> (uninitsystem -> (uninit timers, mouse, ...))
exit()
Some paths still lead to a plain exit(), like failures in cache1d.c or mdsprite.c
git-svn-id: https://svn.eduke32.com/eduke32@2022 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
with other than base levels, since the y*most arrays are copied there later.
git-svn-id: https://svn.eduke32.com/eduke32@2020 1a8010ca-5511-0410-912e-c29ae57300e0
handled could lead to a bunch whose floors and ceilings covered different
areas. A fix for the reduced functionality arising from this change is
underway.
- Rewrite a small portion of code using yax_vnextsec() in game.c.
git-svn-id: https://svn.eduke32.com/eduke32@2019 1a8010ca-5511-0410-912e-c29ae57300e0
dealing with sectors on the two sides of a bunch. Make yax_globallev and
yax_globalbunch variables non-static.
Rewrite a TROR-related bit in the engine code using the new function.
git-svn-id: https://svn.eduke32.com/eduke32@2018 1a8010ca-5511-0410-912e-c29ae57300e0
palette changed from the last one (either globally or within the last call of
one of the function). This fixes the ugly OSD flickering in 8-bit mode when
a screen tint effect is in action (such as when being hurt or snotted on).
git-svn-id: https://svn.eduke32.com/eduke32@2015 1a8010ca-5511-0410-912e-c29ae57300e0
This will prevent it from calling gltexinvalidateall() when e.g. submerging
and resurfacing, mimicking the behavior of the game, where only
gltexinvalidate8() is called in such situations.
git-svn-id: https://svn.eduke32.com/eduke32@2013 1a8010ca-5511-0410-912e-c29ae57300e0
with 'corruptcheck now', but still print each corrected one on tryfix.
git-svn-id: https://svn.eduke32.com/eduke32@2012 1a8010ca-5511-0410-912e-c29ae57300e0
effects:
1) Mouse turning works with SDL 1.3
2) The mouse pointer can't leave the window area with the console up, so that
focus always stays with the application
3) Menu selection using the mouse doesn't work. Not dramatic IMO.
git-svn-id: https://svn.eduke32.com/eduke32@2011 1a8010ca-5511-0410-912e-c29ae57300e0
is present (like in E4L1). Also sneak in a trivial change in cache1d.c
git-svn-id: https://svn.eduke32.com/eduke32@2010 1a8010ca-5511-0410-912e-c29ae57300e0
fix two issues with signed integer overflow. One is related to clipping
and the other to Polymost mouse-picking for overlong walls. Many more
remain especially in the 8-bit rendering code, but I expect many of
them to be intended.
git-svn-id: https://svn.eduke32.com/eduke32@2009 1a8010ca-5511-0410-912e-c29ae57300e0
is to remove a couple of 'inline's for functions with external linkage, which
seems to be a GCC convenience.
git-svn-id: https://svn.eduke32.com/eduke32@2008 1a8010ca-5511-0410-912e-c29ae57300e0
name into m->head.nam after loading (but before preprocessing for Polymer)
git-svn-id: https://svn.eduke32.com/eduke32@2007 1a8010ca-5511-0410-912e-c29ae57300e0
whenever we change to another renderer etc. and define it for the game and
editor. The purpose of the function is to clean up references to Polymer
resources like lights.
This fixes 1) all lights becoming spot lights in the game and 2)
an issue with maphack lights in the editor (can't recall which exactly).
git-svn-id: https://svn.eduke32.com/eduke32@2006 1a8010ca-5511-0410-912e-c29ae57300e0
Specifically, now also consider the sprite tile's yoffset, and fix an
issue when a tsprite got duplicated 'toward' the viewer. Also add a
couple of tests in trueror1.map.
git-svn-id: https://svn.eduke32.com/eduke32@2004 1a8010ca-5511-0410-912e-c29ae57300e0
This makes the latter also correct when testing a map from the editor.
git-svn-id: https://svn.eduke32.com/eduke32@2001 1a8010ca-5511-0410-912e-c29ae57300e0
With script_expertmode enabled, SHIFT-BACKSPACE clears the upwall link and CTRL-
BACKSPACE the downwall link. These functions are useful because the automatic
nextwall determination code sometimes gets it wrong (not corrupting anything) or
if you want to vertically displace a sector attached to a higher or lower level.
Also add the exploding ceiling example to the TROR test map.
git-svn-id: https://svn.eduke32.com/eduke32@1997 1a8010ca-5511-0410-912e-c29ae57300e0
TROR portals that works with a little help from updatesectorz() (change not visible
from CON code). Relies only on the presence of an extension whose portal isn't
blocked and also plays nicely with corner cases like being shrunk and enabling
the jetpack. This should fix the upward moving platforms in WGR2.
git-svn-id: https://svn.eduke32.com/eduke32@1996 1a8010ca-5511-0410-912e-c29ae57300e0
on the command-line isn't found (instead of saying nothing)
* editor: Move inconsistent (stat&2)/heinum detection into the corruption
checker. This makes a lot of original maps spew countless 'errors', but
it's preferable for new maps since such floors and ceilings could behave
strangely with TROR.
git-svn-id: https://svn.eduke32.com/eduke32@1995 1a8010ca-5511-0410-912e-c29ae57300e0
In cases where performing occlusion queries for multiple red walls
leading to the same sector, we would sometimes leak a number of
query objects. This was apparently harmless on NVIDIA drivers, but
would leak tons of memory on ATI.
git-svn-id: https://svn.eduke32.com/eduke32@1993 1a8010ca-5511-0410-912e-c29ae57300e0
The code was using the Polymer-cached version of the sector cstat to
determine the translucency of its diffuse material, meaning it would
never get it right on the first try; that's what you get for having
completely different variables named 's' and 'sec'.
git-svn-id: https://svn.eduke32.com/eduke32@1991 1a8010ca-5511-0410-912e-c29ae57300e0
We normally enable backface culling always, but turn it off for
two-sided sprites; we need to make sure it's re-enabled after that
as sector masks are drawn after.
git-svn-id: https://svn.eduke32.com/eduke32@1990 1a8010ca-5511-0410-912e-c29ae57300e0
Some of the ROR code was operating under the assumption that drawasks
always correspond to one call of polymer_displarooms(), but that's not
necessarily the case; external view draws all sectors from the top
polymer_drawrooms(), which was causing crashes. Just ignore the sector
mask queues in external view mode, we already don't draw masked walls.
git-svn-id: https://svn.eduke32.com/eduke32@1982 1a8010ca-5511-0410-912e-c29ae57300e0
Check all the bunch siblings if we get a floor/ceiling hit and walk
them if their own planes hit.
git-svn-id: https://svn.eduke32.com/eduke32@1981 1a8010ca-5511-0410-912e-c29ae57300e0
When walking the sectors in displayrooms, detect floor/sector masks to
place them in a mask queue. The queues are allocated on the heap, but
a stack pointer is maintained by the displayrooms to allow it to play
nice with mirror recursion.
Right now the masks are drawn after all of drawmasks is finished; that
means you can see sprites and wall masks through sector masks, but not
the opposite. There is a slight attempt at blending far to near, but
nothing too conclusive yet; that means that in some cases some sector
masks won't be visible through other sector masks, but it should work
for trivial cases.
The next step would be to copy all the drawmasks logic into Polymer
and have it (attempt to) properly interleave sector masks where they
belong in the blending order.
git-svn-id: https://svn.eduke32.com/eduke32@1980 1a8010ca-5511-0410-912e-c29ae57300e0
