Note: You may encounter a crash if you try to test your map and Mapster32 is running fullscreen.
git-svn-id: https://svn.eduke32.com/eduke32@2684 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
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
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
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
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
