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
