This introduces a Makefile variable EDUKE32_MY_DEVELOPER_ID, which is
expected to come from the environment, so that minor disagreements/
preferences can be handled -- don't let it go overboard though! -- to keep
the working directory clean of stuff that one doesn't actually work on.
My ID is 805120924, i.e. "helix".
git-svn-id: https://svn.eduke32.com/eduke32@2718 1a8010ca-5511-0410-912e-c29ae57300e0
Usage is from 3D mode only. When a sector (or wall) is committed to the
clipboard, it (or the wall's sector) is saved, and is subsequently used
when auto-aligning [;-ENTER] another sector's ceiling or floor against the
reference one's. This temp. sector is reset on any structurally modifying
operation except setting first walls; also, aligning extended ceilings or
floors is impossible as they use .*xrepeat internally.
The auto-alignment does not change picnums (this can be accomplished with
the ['+ENTER] combination), but copies the orientation bits 2^{2..6} to the
alignee. Afterwards, if the reference is relative-aligned, it tweaks them,
so that every case where the two firstwalls are either parallel or perpendi-
cular is handled correctly.
It does not yet calculate the panning values.
git-svn-id: https://svn.eduke32.com/eduke32@2715 1a8010ca-5511-0410-912e-c29ae57300e0
vbit was being accessed with an int32 e.g. at address 3200 when only 3203 were
allocated. We simply alloc +1 byte.
git-svn-id: https://svn.eduke32.com/eduke32@2705 1a8010ca-5511-0410-912e-c29ae57300e0
The first means that the expensive (~0.5 ms) SHGetFileInfo() calls won't inter-
fere with smooth gameplay, but files that are opened only at game-time like
sounds won't be checked. The second means that there are now less false
positives, i.e. warnings about files that would be found due to the
check-all-{upper,lower} hack.
git-svn-id: https://svn.eduke32.com/eduke32@2702 1a8010ca-5511-0410-912e-c29ae57300e0
Also, correct the loadboard() return value checks in premap.c to be
aware of a returned -2 ("wrong map version").
git-svn-id: https://svn.eduke32.com/eduke32@2694 1a8010ca-5511-0410-912e-c29ae57300e0
Most of the time, Windows file name lookup is case-insensitive. Reading the
docs (see MSDN's CreateFile help, for example), it seems like case-sensitivity
can be controlled on a per-file basis where applicable (NTFS), but people
should be concerned about matching case in the DEFs/on disk *especially* in
that case.
Also, note that this hack will not always help on systems with case-sensitive
lookup.
git-svn-id: https://svn.eduke32.com/eduke32@2693 1a8010ca-5511-0410-912e-c29ae57300e0
When a file from the local file system is opened, its real file name is gotten
with SHGetFileInfo() and compared against the one that was passed. In the case
they're not identical, a warning is issued.
This is one step towards eliminating mismatched file names in DEFs etc., which
cause trouble on systems that look them up case-sensitively. However, it's not
perfect because the issue is trickier than it appears on first sight.
For one thing, this will only check the last (i.e. file) part in the path,
falsely accepting mismatched directory names. However for these, it reports
them ruthlessly, even for those names where the try-other-case hack (try all
uppercase, all lowercase) would find the correctly-cased file.
git-svn-id: https://svn.eduke32.com/eduke32@2692 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
- 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
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
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
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
This part is a mixture of the original patch and my changes. It seems like
tueidj had some trouble
1) getting OGG to work, which is why it's conditionally compiled out
2) struggling with endianness with the mixing routines? This may be also
due to him missing to define two others BIGENDIAN macros (our code is
in need of cleanup there). Note the change in jaudiolib/src/mix.c!
Because I added my share to this part, I might have actually broken sound
mixing on big-endian platforms.
git-svn-id: https://svn.eduke32.com/eduke32@2630 1a8010ca-5511-0410-912e-c29ae57300e0
- conditionally compiles out some code intended for the PC platforms
- compat.c: get home directory routine, access() implementation
- game.c: don't use ioctl(), lower cache1d size to 8 MiB, Wii-specific
initialization code and application directory ("apps/eduke32")
git-svn-id: https://svn.eduke32.com/eduke32@2628 1a8010ca-5511-0410-912e-c29ae57300e0
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
- 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
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
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
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
- 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
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
(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
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
- 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
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
- 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
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
- 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
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
