Most often, this had happened when casting comparison functions for qsort()
like these: "int yax_cmpbunches(const int16_t *b1, const int16_t *b2)"
to a function pointer type expecting "const void *". Alas, this is undefined
behavior: see
http://blog.frama-c.com/index.php?post/2013/08/24/Function-pointers-in-C
and posts linked from it.
At least two cases have not been fixed:
- The savegame system maintains pointers which are either to data or a function in
the generic "void *". This ought to be made into a union.
- Probably also:
#define OSD_ALIAS (int32_t (*)(const osdfuncparm_t*))0x1337
git-svn-id: https://svn.eduke32.com/eduke32@4068 1a8010ca-5511-0410-912e-c29ae57300e0
- Currently: only tvlineasm1 and tvlineasm2, but incomplete (no reverse
translucency, nonpow2 textures will crash)
- For System V AMD64 calling conventions; requires YASM
git-svn-id: https://svn.eduke32.com/eduke32@4066 1a8010ca-5511-0410-912e-c29ae57300e0
This reverts commit c7e51147f1869d42fc8365f748bb8f6bd4c6fc2f. [r3835]
Conflicts:
eduke32/build/src/defs.c
[Dunno what caused this, but I cleaned this out. Also, the change from
build.c was not reverted.]
git-svn-id: https://svn.eduke32.com/eduke32@4061 1a8010ca-5511-0410-912e-c29ae57300e0
This reduces the proportion of time the trig calculations take of the whole
preprocessing from 50% to about 13%.
git-svn-id: https://svn.eduke32.com/eduke32@4060 1a8010ca-5511-0410-912e-c29ae57300e0
The offsets (that will translate the axes for .pitch/.roll rotation) were
calculated improperly with screen sizes other than 1280 x 1024 and were
dependent on other related variables. The fix proceeded empirically, i.e. mostly
trial, error, and some educated guesswork. (It's telling that the magic constant
1280 is needed.) A test for Lunatic is added to test.lua that will rotate
SEENINES.
Bug pointed out by Mblackwell.
git-svn-id: https://svn.eduke32.com/eduke32@4058 1a8010ca-5511-0410-912e-c29ae57300e0
- engine.c: comment out some unused decls with RELEASE=0 DEBUGANYWAY=1
- Lunatic: update dump.lua and v.lua
- Lunatic: test/test_geom.lua: note a perf regression (wrt older LuaJIT,
or I mis-configured / built something wrong)
git-svn-id: https://svn.eduke32.com/eduke32@4048 1a8010ca-5511-0410-912e-c29ae57300e0
(Auto-insertion of an inner sector from a loop happens either because the loop
is created in an extended sector, or because it has been punched through a
ceiling/floor into the upper/lower neighbor sector.)
git-svn-id: https://svn.eduke32.com/eduke32@4033 1a8010ca-5511-0410-912e-c29ae57300e0
Note: the wall line will not light up periodically, but point insertion will
be possible nontheless. A bit inconsistent, but I didn't want to do a full
analysis of which side effects allowing a sprite highlight and a line highlight
to coexist at the same time would have.
git-svn-id: https://svn.eduke32.com/eduke32@4026 1a8010ca-5511-0410-912e-c29ae57300e0
Redundant for the same reason as the preceding one: the pointer has already
been dereferenced at the point the check is made. Also, all 5 calls of that
function pass a valid pointer (provided the pointers from which the expressions
are derived are valid). Reported by Stack, too.
git-svn-id: https://svn.eduke32.com/eduke32@4017 1a8010ca-5511-0410-912e-c29ae57300e0
Again, in case a bunch is discarded. The tags would appear as really tagging
the walls instead of being "hidden".
git-svn-id: https://svn.eduke32.com/eduke32@4012 1a8010ca-5511-0410-912e-c29ae57300e0
That is, if a bunch is discarded when copying a sector to the clipboard.
(This happens if not all sectors that are part of the bunch are copied.)
git-svn-id: https://svn.eduke32.com/eduke32@4011 1a8010ca-5511-0410-912e-c29ae57300e0
Don't touch TerminX's r_usetileshades==1 or it being the default.
git-svn-id: https://svn.eduke32.com/eduke32@4010 1a8010ca-5511-0410-912e-c29ae57300e0
- For setting 1, don't draw them for red walls whose sector floors have equal
height.
- Make setting 1 the default, because I consider drawing them for such walls
(and white walls) noise (as opposed to information). The "verbose" setting 2
is still available.
git-svn-id: https://svn.eduke32.com/eduke32@4007 1a8010ca-5511-0410-912e-c29ae57300e0
DONT_BUILD, because there have been no significant changes of the non-Lua build.
git-svn-id: https://svn.eduke32.com/eduke32@4006 1a8010ca-5511-0410-912e-c29ae57300e0
- libs and headers are expected in platform/Windows/* (not there yet)
- prefix Lua #includes with luajit-2.0/
- build bytecode objects with absolute path name (used for debug info)
git-svn-id: https://svn.eduke32.com/eduke32@4000 1a8010ca-5511-0410-912e-c29ae57300e0
- Use the proper tile sequence when multiple pskies are present in a map.
However, there's still only *one* psky chosen at map load time.
- Handle three horizfrac cases:
* 0, psky always at same level wrt screen
* 65536, psky horiz follows camera horiz (e.g. E4L9)
* otherwise, fall back to default hard-coded parallax implemented as an
angle fraction
git-svn-id: https://svn.eduke32.com/eduke32@3977 1a8010ca-5511-0410-912e-c29ae57300e0
- Rename sky_t members: yscale -> horizfrac, bits -> lognumtiles.
- Add default sky (8 tiles, horizfrac=32768 (i.e. 1/2 the scene horiz), offsets
all zero) and CLOUDYOCEAN sky (8 tiles, horizfrac=65536, offsets all zero)
to multipsky[].
- Get rid of "psky_t g_psky", merely maintaining a g_pskyidx instead. Set it up
at map load time so as to keep the behavior of the legacy per-map psky:
the last sector index with a matching psky ceiling wins.
- In mapstate_t, save g_pskyidx too, not (former) pskybits and pskyoffs[].
- Make on-map-load global psky setup consistent for the game and editor by
factoring it out into common.c: G_SetupGlobalPsky().
- Remove a couple of useless initializations, add some static assertions.
This commit is more likely to introduce subtle differences in behavior.
Specifically, getpsky() now always returns the default sky properties instead of
the global sky ones (but with all-zero offsets) when no match for a suiting
multi-psky is found. This is only likely to affect the yscale/horizfrac of
non-multi-pskies when a global non-default multi-psky has been set up.
Bump BYTEVERSION again.
git-svn-id: https://svn.eduke32.com/eduke32@3976 1a8010ca-5511-0410-912e-c29ae57300e0
- Consolidate psky* arrays into a "typedef struct psky_t" "g_psky" and
"multipsky[]".
- Factor out getting parallaxed sky properties into getpsky().
- Condense initial multi-psky setup by memcpy'ing from multipsky[].
- New function: MultiPsky_TileToIdx().
- Add new define PSKYOFF_MAX and related consistency-checking assertions.
- Lower MAXPSKYTILES to 8 to reflect current usage (was 256).
- Game: make multi-pskies consider dynamically-remapped MOONSKY1, BIGORBIT1
and LA. (Not very useful as the editor will still only act for the static
values -- 80, 84 and 89, respectively.)
An attempt has been made to preserve behavior even in strange cases, so this
commit is unlikely to introduce regressions. Because of point 6, BYTEVERSION
had to be bumped.
git-svn-id: https://svn.eduke32.com/eduke32@3975 1a8010ca-5511-0410-912e-c29ae57300e0
- Allow xoffset and yoffset to modified independently of a tile definition, much like texhitscan and nofullbright.
(Both still default to zero when a tile is specified, to keep current behavior, and because it makes sense.)
- Add actual detection of the "nofullbright" keyword, which appears to have been overlooked in r3230.
- Internal: Eliminate the need for one int32_t by condensing two variables into "flags".
git-svn-id: https://svn.eduke32.com/eduke32@3973 1a8010ca-5511-0410-912e-c29ae57300e0
Also, very slightly tweak a factor toward a "brighter" (farther visible)
scene overall to account for the "circular" nature of the fragment distance
(as opposed to an "ortho" distance in Build).
git-svn-id: https://svn.eduke32.com/eduke32@3962 1a8010ca-5511-0410-912e-c29ae57300e0
So there's no "jump" from vis!=0 to vis=0 making the texture appear brighter.
git-svn-id: https://svn.eduke32.com/eduke32@3959 1a8010ca-5511-0410-912e-c29ae57300e0
That is, for shade of objects, use shade tables. For visibility, use GL fog.
Mixing these two does not produce satisfactory results in areas where both
shade and visibility darkening are high, such as around the E1L1 restroom.
git-svn-id: https://svn.eduke32.com/eduke32@3941 1a8010ca-5511-0410-912e-c29ae57300e0
Having to tag these few variables and functions as ATTRIBUTE((used))
seems sensible, but what follows is just strange. OSD_Printf? headspritesect?
git-svn-id: https://svn.eduke32.com/eduke32@3932 1a8010ca-5511-0410-912e-c29ae57300e0
Also, get rid of the strange filename[len]=255 hack in loadboard()
and make its file name arg const char* at last.
git-svn-id: https://svn.eduke32.com/eduke32@3913 1a8010ca-5511-0410-912e-c29ae57300e0
Also, clean up the saving/loading logic a bit:
- On load failure, display message with purple color.
- Take over the current file name ('boardfilename') only on success.
- Check SaveBoard() return values in various places.
git-svn-id: https://svn.eduke32.com/eduke32@3911 1a8010ca-5511-0410-912e-c29ae57300e0
In other words, for a test rectangular sector, a sprite would be inside the
sector in on all 4 edges and all 4 corners. Previously, it would have been
the lower right portion only (*excluding* LL and UR corners), which led to
map editing issues.
git-svn-id: https://svn.eduke32.com/eduke32@3898 1a8010ca-5511-0410-912e-c29ae57300e0
The main thing to note is the "half-open" nature of the x/y range checks.
git-svn-id: https://svn.eduke32.com/eduke32@3897 1a8010ca-5511-0410-912e-c29ae57300e0
It's hard to call this a fix, since ideally, buffer sizes like these would be
only as large as needed in the worst case.
git-svn-id: https://svn.eduke32.com/eduke32@3880 1a8010ca-5511-0410-912e-c29ae57300e0
Interestingly, that test case then appears to be drawn fully. Heh.
Also, move one clamp from r1874 one up in the data flow chain.
Doesn't seem to break textured overhead map view with Last Pissed Time.
git-svn-id: https://svn.eduke32.com/eduke32@3878 1a8010ca-5511-0410-912e-c29ae57300e0
Also add an assertion that currently sometimes fails when zooming in too much
in Mapster32 textured 2D mode. Example: DNF's LADYKILLR.MAP at (46000,-14000).
git-svn-id: https://svn.eduke32.com/eduke32@3877 1a8010ca-5511-0410-912e-c29ae57300e0
The latter checked with #defined HAVE_GTK2, which is probably not correct
for every platform.
In builds without a startup window, the periods get mingled with stdout
output otherwise.
git-svn-id: https://svn.eduke32.com/eduke32@3827 1a8010ca-5511-0410-912e-c29ae57300e0
In 3D mode, Alt+F now only attempts to set the first wall of the aimed at
wall, not collecting upper/lower neighbors. For this, press Shift+Alt+F.
In 2D mode, they are always collected.
git-svn-id: https://svn.eduke32.com/eduke32@3825 1a8010ca-5511-0410-912e-c29ae57300e0
Analogously for the negation; remove a couple of redundant decls of "qsetmode".
git-svn-id: https://svn.eduke32.com/eduke32@3823 1a8010ca-5511-0410-912e-c29ae57300e0
The 'x' is for "extended", since its last arg is a switch of whether to disable
sliding. Use that from gameexec.c.
git-svn-id: https://svn.eduke32.com/eduke32@3811 1a8010ca-5511-0410-912e-c29ae57300e0
Also, update test_tileoffsets.map with a new 'dimension': cstat 128
(sprite centering). It has an issue in Polymer marked with a silver D.
git-svn-id: https://svn.eduke32.com/eduke32@3777 1a8010ca-5511-0410-912e-c29ae57300e0
This fixes the case marked with the silver letter C in test_tileoffsets.map.
The orientation of the sprites is correct (matches classic) as far as I can
see, there are now only problems with translation.
git-svn-id: https://svn.eduke32.com/eduke32@3776 1a8010ca-5511-0410-912e-c29ae57300e0
Also, add some defines for sprite cstats to build.h (SPR_*) and use them.
git-svn-id: https://svn.eduke32.com/eduke32@3775 1a8010ca-5511-0410-912e-c29ae57300e0
Among other things, rotatesprite doesn't cope well with large zoom values.
Two assertions are added that guard qinterpolatedown16short() calls: in
the failing case, they would write outside the destination arrays.
Another (existing) assertion is commented a little and like for the first,
instructions are given how to reproduce its failure.
git-svn-id: https://svn.eduke32.com/eduke32@3754 1a8010ca-5511-0410-912e-c29ae57300e0
- factored out: tweak_sboardfilename(), menuselect_try_findlast()
- quickloading a map now doesn't require loading one first
- the usual
git-svn-id: https://svn.eduke32.com/eduke32@3749 1a8010ca-5511-0410-912e-c29ae57300e0
... in the auto-correction. Also,
- make two similar corruptions level 5 (wallptr oob, wallptr+wallnum oob).
- in drawscreen_drawwall(), do a more strict bound check, not only >=0.
git-svn-id: https://svn.eduke32.com/eduke32@3745 1a8010ca-5511-0410-912e-c29ae57300e0
The visibility calculation relies on the distance, which might not be entirely
accurate in rotatesprite, so maybe it'll be too dark in some cases.
git-svn-id: https://svn.eduke32.com/eduke32@3741 1a8010ca-5511-0410-912e-c29ae57300e0
TODO: figure out wtf is wrong with rotatesprite, linear filtering.
git-svn-id: https://svn.eduke32.com/eduke32@3737 1a8010ca-5511-0410-912e-c29ae57300e0
In the mirror reversing code, get rid of the padding. This may produce
seams, but they appear to be extremely transient and shouldn't be
noticeable.
In game.c, add a debugging compilation switch DEBUG_MIRRORS_ONLY.
git-svn-id: https://svn.eduke32.com/eduke32@3726 1a8010ca-5511-0410-912e-c29ae57300e0
No functional changes, but a (commented out) debug line for an oob read of the
frame buffer when the mirror covers the whole screen is inserted.
git-svn-id: https://svn.eduke32.com/eduke32@3719 1a8010ca-5511-0410-912e-c29ae57300e0
- Return early from drawsprite_classic() if tspr->owner if oob.
Commonize that check between renderers into bad_tspr().
- Make the BIT() macro a left-shift of the *unsigned* number 1,
preventing expansion to (1<<31).
git-svn-id: https://svn.eduke32.com/eduke32@3717 1a8010ca-5511-0410-912e-c29ae57300e0
LameDuke's shade table has 32 gradients of shade, like Duke3D.
For the translucency table though, only the diagonal + one half is stored
because it's symmetric (50/50 translucency).
git-svn-id: https://svn.eduke32.com/eduke32@3709 1a8010ca-5511-0410-912e-c29ae57300e0
- colorize the trailing part if there is corruption or (new) if sprites were
removed
- also corrupt-check when loading <V7 map
- move start{pos,ang,sectnum} to build.c
- remove pointless ...[].extra = -1 before loading map, scantoasc*[] comment
git-svn-id: https://svn.eduke32.com/eduke32@3697 1a8010ca-5511-0410-912e-c29ae57300e0
Sprites are now considered to have out of bounds sector numbers if it is
< 0 or >= numsectors (not merely >= MAXSECTORS). If such a sprite is now
encountered during post-load, an attempt is made first to assign it a sector
number (using updatesector()). If that fails, the sprite is removed from the
map. The background is that a dozen of maps do come with such sprites and
could previously corrupt the sprite list when loaded.
git-svn-id: https://svn.eduke32.com/eduke32@3696 1a8010ca-5511-0410-912e-c29ae57300e0
Specifically, in GL modes, and if the CHAINGUN is not replaced by a model,
- draw the upper part twice: first, two screen pixels * weapon scale lower,
then at the original position
- reverse the previous order: draw the upper part first, then the lower part
This is much preferable to the previous engine-side hack, and to my eye,
it looks perfect now.
git-svn-id: https://svn.eduke32.com/eduke32@3695 1a8010ca-5511-0410-912e-c29ae57300e0
- Rewrite some sprites-of-{stat,sector} loops using the SPRITES_OF,
SPRITES_OF_SECT and new SPRITES_OF_SECT_SAFE macros.
- In passing, identify some problems and mark them with 'XXX', but don't
attempt to fix them yet.
- The usual readability improvements...
git-svn-id: https://svn.eduke32.com/eduke32@3679 1a8010ca-5511-0410-912e-c29ae57300e0
(Note: We are still vulnerable to crashes here (and likely in other places), but you have (4096-16) extra characters to work with. We should consider replacing many uses of Bsprintf with Bsnprintf.)
git-svn-id: https://svn.eduke32.com/eduke32@3669 1a8010ca-5511-0410-912e-c29ae57300e0
This fixes liztroops not passing TROR layers when on the jetpack, as well as
other enemies capable of moving upward, and also COMMANDER and DRONE (for which
the code is special-cased).
git-svn-id: https://svn.eduke32.com/eduke32@3666 1a8010ca-5511-0410-912e-c29ae57300e0
... like was done with clipmove() previously.
Also, do some code clean up. There are no changes of functionality.
git-svn-id: https://svn.eduke32.com/eduke32@3662 1a8010ca-5511-0410-912e-c29ae57300e0
The Lunatic build compiles with new structures for sector and wall types.
They have separate members for TROR {up,down}{bunch,nextwall}, so there are
no conflicts with other uses of members into which they were previously
shoehorned. Also, the maximum bunch limit is bumped to 512 in that build.
Currently, loading from V7/8/9 and saving to V7 and V8 are supported.
git-svn-id: https://svn.eduke32.com/eduke32@3658 1a8010ca-5511-0410-912e-c29ae57300e0
Toggled with Ctrl+Shift+[KP-]. Variable 'headlight_range' controls its range.
For the implementation, a new event EVENT_PREDRAW3DSCREEN was added.
git-svn-id: https://svn.eduke32.com/eduke32@3648 1a8010ca-5511-0410-912e-c29ae57300e0
- Don't attempt to play an ANM file if it is empty (warn) or too short (error).
- If failing to read IVF file header or initializing VPX codec, don't play ANM.
- Return early from gltexapplyprops() if not in GL modes.
git-svn-id: https://svn.eduke32.com/eduke32@3628 1a8010ca-5511-0410-912e-c29ae57300e0
Previously, only the <0 condition was checked. However, the passed sectnums
could be >= MAXSECTORS (at least in C-CON), for example when issuing 'canseespr'
on a sprite not in the game world.
git-svn-id: https://svn.eduke32.com/eduke32@3603 1a8010ca-5511-0410-912e-c29ae57300e0
... into a macro MFLAGS_NOCONV(m). Since it currently expands to (0), some dead
code will be eliminated.
Introduce a "compilation option" macro DO_MD2_MD3_CONV in mdsprite.c.
git-svn-id: https://svn.eduke32.com/eduke32@3588 1a8010ca-5511-0410-912e-c29ae57300e0
This enables ART animations to take effect on voxels in classic, voxels and models in Polymost, and models in Polymer.
git-svn-id: https://svn.eduke32.com/eduke32@3580 1a8010ca-5511-0410-912e-c29ae57300e0
- Make _buildargv[_buildargc] NULL.
- With SDL layer, pass argv and argc directly and get rid of _build* ones.
- Add tilesiz* to dynsymlists.
git-svn-id: https://svn.eduke32.com/eduke32@3573 1a8010ca-5511-0410-912e-c29ae57300e0
This fixes an update issue: start EDuke32 without warping to a map in Polymost,
change to classic, and change to Polymost again. The OSD background will be
displaced.
git-svn-id: https://svn.eduke32.com/eduke32@3525 1a8010ca-5511-0410-912e-c29ae57300e0
If m32script gamevar "move_by_one" is nonzero, the some keys move the
"player arrow" by increments of 1:
- Without SHIFT: LEFT/RIGHT absolute x, DOWN/UP absolute y, A/Z absolute z.
- With SHIFT: DOWN/UP (unbounded!) horiz, LEFT/RIGHT angle.
This can be useful to debug renderer bugs that show a high sensitivity to the
exact location ("are transient in space").
git-svn-id: https://svn.eduke32.com/eduke32@3509 1a8010ca-5511-0410-912e-c29ae57300e0
Face- and wall-aligned sprites are drawn using the wall routines in BUILD.
However, the per-x-screen-coordinate distance (swall[]) is calculated in a way
that potentially incurs great precision loss (for example 5 bits for
xdimen=1280, yxaspect=65536). This leads to the starting (top) vertical texture
coordinate possibly wrapping to large values, leaving an unsightly "stray line"
on top of the sprite from certain viewing angles/horiz values.
The approach to fix it has two parts: first, the distance is calculated using
float values, preventing the precision loss. Because this doesn't fully prevent
the unwanted lines, the texture coords are clamped to the mininum and maximum
(0 and UINT32_MAX respectively) when calculating them for sprites.
Note that stray lines may still appear at the *bottom* of sprites under certain
circumstances, for example when viewing at a y-flipped sprite from above.
These should be less noticable in real-world usage though.
The feature is guarded by a macro HIGH_PRECISION_SPRITE in case using floating
point or 64-bit integers is undesirable/impossible on some platforms.
git-svn-id: https://svn.eduke32.com/eduke32@3483 1a8010ca-5511-0410-912e-c29ae57300e0
That is, first check if the sprite is in the game world and then if it
already has the desired sector or status number. This doesn't change anything
in our codebase, since the return values of these functions are never examined.
git-svn-id: https://svn.eduke32.com/eduke32@3474 1a8010ca-5511-0410-912e-c29ae57300e0
The usual: declare locals more tightly, const-qualify them where it helps
readability, remove dead code...
git-svn-id: https://svn.eduke32.com/eduke32@3470 1a8010ca-5511-0410-912e-c29ae57300e0
Its only use is to have a actor -> tsprite mapping for the EVENT_ANIMATESPRITE
event and .tspr will be set before it is run.
git-svn-id: https://svn.eduke32.com/eduke32@3448 1a8010ca-5511-0410-912e-c29ae57300e0
Whether a sprite is considered for texel-hitscan is determined on the base
tile number, not the individual animated tile numbers.
git-svn-id: https://svn.eduke32.com/eduke32@3404 1a8010ca-5511-0410-912e-c29ae57300e0
One use was in determining the ray vector for the mouse-aiming hitscan
in the editor. Unfortunately, the change doesn't make it any less broken
in Polymost, even if the two instances were out of sync.
git-svn-id: https://svn.eduke32.com/eduke32@3401 1a8010ca-5511-0410-912e-c29ae57300e0
If enabled, dragging wall vertices will correct the xrepeat after the
mouse button is released, so that the pre-drag absolute stretching is
restored.
git-svn-id: https://svn.eduke32.com/eduke32@3398 1a8010ca-5511-0410-912e-c29ae57300e0
- Run it twice, since the first one is wrong.
- Warn when attempting to align based on a top-oriented wall. When the
sequence of walls to align has "windows", only the bottom parts will
be correct.
- Make the modifiers actually useful:
* Pressing SHIFT aligns at most one wall, remove the old CTRL modifier.
* The rest is as before: ALT makes the walls have (approximately) equal
texture stretching, ['] (quote) aligns the immediate TROR-nextwalls.
git-svn-id: https://svn.eduke32.com/eduke32@3396 1a8010ca-5511-0410-912e-c29ae57300e0
Also, factor out 2x dup'd code of insertsprite() into do_insertsprite()
and add searchwall-displaying code into package/samples/a.m32.
git-svn-id: https://svn.eduke32.com/eduke32@3395 1a8010ca-5511-0410-912e-c29ae57300e0
Also, add another flag, signifying that from the editor, also the
"lastwall"s (i.e. the CCW-linked points) should get collected. This is
to signal the editor that their wall lengths should be displayed, too.
git-svn-id: https://svn.eduke32.com/eduke32@3394 1a8010ca-5511-0410-912e-c29ae57300e0
Also, rewrite comparison to the non-tint in astub.c to be even less hackish.
git-svn-id: https://svn.eduke32.com/eduke32@3387 1a8010ca-5511-0410-912e-c29ae57300e0
- Stop using memcache on some other failure paths, particularly when
failing to read from the on-disk texcache.
- Factor out cache reading code (3x).
- Fix endianness issues affecting big-enadian systems (one introduced by
r3382, one existing before). Comment each B_LITTLE32 with whether we're
converting from native to on-disk (little) endianness or back.
git-svn-id: https://svn.eduke32.com/eduke32@3386 1a8010ca-5511-0410-912e-c29ae57300e0
The SDL and Windows layers had slightly different code: the latter would
dereference a NULL pointer if stdout.txt failed being write-opened.
git-svn-id: https://svn.eduke32.com/eduke32@3377 1a8010ca-5511-0410-912e-c29ae57300e0
When reaching wall limits, it is possible that only some circle points will
be inserted and the result is left unfinished.
git-svn-id: https://svn.eduke32.com/eduke32@3376 1a8010ca-5511-0410-912e-c29ae57300e0
Reproduced as follows (assuming all tiles have texel-hitscan for simplicity):
In E2L5, shoot the opening switch with the shotgun, aiming for the border.
The crash occurs because the *other*, depressed switch tile isn't yet loaded
when we index into its tile storage. Dereferencing 0+small number == BAD!
git-svn-id: https://svn.eduke32.com/eduke32@3364 1a8010ca-5511-0410-912e-c29ae57300e0
Preventing a continuously growing stack top and inevitable program termination.
Also, commonize the error handling to live on the engine side.
git-svn-id: https://svn.eduke32.com/eduke32@3352 1a8010ca-5511-0410-912e-c29ae57300e0
* Renamed source/jaudiolib/third-party/mingw32 to source/jaudiolib/third-party/Windows.
* Moved source/jaudiolib/third-party/Windows/include to source/jaudiolib/third-party/common/include to use both on Windows and Apple.
* Deleted Apple/lib/include/{ogg,vorbis}/, see previous point.
* Deleted Apple/lib/libvorbisenc.a, 6MB saved.
* Moved Apple/lib/lib{ogg,vorbis,vorbisfile}.a to source/jaudiolib/third-party/Apple/lib, where they belong.
* Moved source files in Apple/ to source/, where they belong. (SDLMain.[mh] stay.)
* Deleted source/jaudiolib/third-party/{ogg,vorbis}.framework, not used any more.
* Renamed "StartupWinController*" to "startosx*".
git-svn-id: https://svn.eduke32.com/eduke32@3334 1a8010ca-5511-0410-912e-c29ae57300e0
- Rewrite the "clear background" routine in a no-brainer way instead of
juggling around with rotatesprite(). Make it common to game+editor.
Expose glRectd to glbuild.
- Don't stop OSD text line drawing when encountering a non-printable char.
Instead, treat it as space.
- In OSD_SetTextMode(), don't use swaplong (which really swaps 32-bit ints)
to swap pointers. Write an analogous "swapptr" instead.
- When changing from/to OSD, don't inject a pause key. This *might* have been
the cause of the reported pausing problems.
- clean up the code...
(Yes, this commit throws together too much stuff. I suck sometimes. :P)
git-svn-id: https://svn.eduke32.com/eduke32@3321 1a8010ca-5511-0410-912e-c29ae57300e0
Unconditionally enabled, but useful for comparing the behavior of the 1-column
vline functions against the 2- or 4-column ones.
git-svn-id: https://svn.eduke32.com/eduke32@3311 1a8010ca-5511-0410-912e-c29ae57300e0
The former is really only a workaround. Walls/vertical sprites/pskies with
ysize 512 (and presumably greater, but this was not tested) are rendered
with one shade higher at the borders (1 pixel vlines) because of a certain
assumption in the ASM (see comments there). With very dark shades, the
palookup[] buffer is accessed oob. We simply allocate 256 bytes more at the
end for each.
The latter is only for CLASSIC_NONPOW2_YSIZE_WALLS builds, which is not enabled
yet. It seems to matter only for the uncommon case where the such pskies repeat
in the height. A 1680x1050 window fully covered with such a sky is then rendered
at about 60/85 the FPS for me (mostly due to not using the 4 pixel vline
routines), so it may be leaning a bit too much on the side of correctness.
A compilation switch DEBUG_TILESIZY_512 is introduced in engine.c for
demonstration purposes.
git-svn-id: https://svn.eduke32.com/eduke32@3310 1a8010ca-5511-0410-912e-c29ae57300e0
- If aiming at a swapped bottom wall, display "Wall <wallnum> -> <otherwallnum>"
- highlight pic, shade, pal, cstat in yellow then
- in printext256, accept at most 3 digits for the color format string (e.g. ^123)
git-svn-id: https://svn.eduke32.com/eduke32@3308 1a8010ca-5511-0410-912e-c29ae57300e0
Implemented using GL_LINEAR fog. The only source of difference (besides the
obvious indexed vs. true color) should now be the distance constant, which
still had to be determined experimentally. Polymer implements this mode in
its fog fragment program part.
Parallaxed skies are always drawn with full visibility, I'm not sure if there
are any maps that expect otherwise.
Also, accidentally committed: factor out initialization code from
polymost_printext256() into gen_font_glyph_tex(), small game.c changes.
git-svn-id: https://svn.eduke32.com/eduke32@3301 1a8010ca-5511-0410-912e-c29ae57300e0
It was caused by the definition of c_dfDIJoystick using literal 24 and 16 values in place of sizeof(DIDATAFORMAT) and sizeof(DIOBJECTDATAFORMAT), which include pointers. On 64-bit, the values end up being 32 and 24, causing a discrepancy in which DIERR_INVALIDPARAM was thrown.
1b1e05db06/diffs
git-svn-id: https://svn.eduke32.com/eduke32@3300 1a8010ca-5511-0410-912e-c29ae57300e0
This also means that the "r_shadescale_unbounded 0" option will work
in Polymer (except on models).
git-svn-id: https://svn.eduke32.com/eduke32@3286 1a8010ca-5511-0410-912e-c29ae57300e0
This global option will set bit 1024 and clear bits 256 and 512 for all
rotatesprite calls, fixing complex HUD drawing code relying on precise
alignment of individual elements (widescreen rotatesprite is entirely
unsuitable for this purpose).
git-svn-id: https://svn.eduke32.com/eduke32@3284 1a8010ca-5511-0410-912e-c29ae57300e0
This includes a complete Windows header and library refresh, including the addition of 64-bit compiled libs:
*libogg 1.3.0
*libvorbis 1.3.3
*zlib 1.2.7
*libpng 1.5.13
*libvpx 9a3de881c0e681ba1a79a166a86308bbc84b4acd
*SDL_mixer 1.2.12 (for RENDERTYPE=SDL)
*DirectX import libraries: dsound and dxguid (now included)
To build in 64-bit, you essentially need MinGW's MSYS (but not MinGW itself) and MinGW-w64 at the top of your PATH. The target is automatically detected using `$(CC) -dumpmachine`. The EDukeWiki will get detailed instrucitons.
All compiler and linker warnings when building in 64-bit mode have been fixed.
Remaining 64-bit to-do:
- The ebacktrace dll does not build under 64-bit. It uses code specific to the format of 32-bit executables and will have to be ported to work with 64-bit executables. A future 64-bit version will be named ebacktrace1-64.dll.
- RENDERTYPE=SDL crashes in SDL_mixer's Mix_Linked_Version().
- DirectInput gives an error and does not function. This only affects joysticks, and the error never happens without any plugged in.
- Port the classic renderer ASM to 64-bit. (Just kidding, this is way out of my league.)
This commit includes a fair bit of Makefile development spanning all platforms, including simplifying the SDLCONFIG code, fixing build on Mac OS X (thanks rhoenie!), globally factoring Apple brew/port inclusion, enforcing that all -L come before all -l, and ensuring that $(shell ) is always :='d.
In addition, I have resurrected the old GCC_MAJOR and GCC_MINOR detection using `$(CC) -dumpversion`, but I have made it failsafe in case the command fails or the version is manually specified. I have applied this new fine-grained detection where applicable, including allowing LTO, and restraining -W's to versions that support them.
git-svn-id: https://svn.eduke32.com/eduke32@3278 1a8010ca-5511-0410-912e-c29ae57300e0
The attribute is set per tile from DEF: either
nofullbrightrange <begintile> <endtile>
or
tilefromtexture <tile> { ... nofullbright ... }
As a special case, the list may only contain "nofullbright", in which case the
texture is not changed. (This is analogous to "texhitscan".)
Example:
// make piggy's eyes fullbright red only when it fires the shotgun
nofullbrightrange 2000 2034
nofullbrightrange 2040 2049
nofullbrightrange 2055 2061
git-svn-id: https://svn.eduke32.com/eduke32@3230 1a8010ca-5511-0410-912e-c29ae57300e0
The two uses are from hitscan and neartag. The functionality is reproduced
exactly (assuming I made no mistake), down to different distance checking
(<= vs. <).
git-svn-id: https://svn.eduke32.com/eduke32@3228 1a8010ca-5511-0410-912e-c29ae57300e0
This introduces winbits.[ch] in the engine, containing layer-independent code migrated from winlayer, including nedmalloc, ebacktrace1, OS version detection, and high-resolution profiling timers.
sdlayer has been expanded to include the code from winbits under _WIN32.
All uses of RENDERTYPEWIN in the source have been examined and changed to _WIN32 (or removed) where the block in question is layer-independent.
git-svn-id: https://svn.eduke32.com/eduke32@3221 1a8010ca-5511-0410-912e-c29ae57300e0
This needs improvements to bring it up to par with winlayer, but it is functional. In particular, a good amount of code from winlayer could be used for both layers, including the profiling timers, the version printing code, and the hInstance and hModule sharing.
Known problems: the mouse cursor is not trapped, and the game starts before the startup window shows options.
git-svn-id: https://svn.eduke32.com/eduke32@3219 1a8010ca-5511-0410-912e-c29ae57300e0
This function also changed: it doesn't handle floor-aligned sprites now,
and the z offset is returned instead of set by pointer.
git-svn-id: https://svn.eduke32.com/eduke32@3205 1a8010ca-5511-0410-912e-c29ae57300e0
The size of that struct is currently 4, and its layout almost the same as
what is read in with loadpics(). The number of tiles in an animation is
bumped to 256, so that the max. tile difference in DEF's animtilerange is
255. (There's no way to have such animations from ART.)
git-svn-id: https://svn.eduke32.com/eduke32@3202 1a8010ca-5511-0410-912e-c29ae57300e0
Notes:
- Atomic Edition (Censored) -> Plutonium Pak in grpscan.c
- "scale" in astub.c:drawtileinfo() is incorrect, I think.
- in demo.c, the gethitickms() value should be returned to a double.
git-svn-id: https://svn.eduke32.com/eduke32@3178 1a8010ca-5511-0410-912e-c29ae57300e0
NOTE: changes such as these are best viewed with something like
git diff (...) --color-words='[a-zA-Z0-9_]+|[^[:space:]]'
git-svn-id: https://svn.eduke32.com/eduke32@3176 1a8010ca-5511-0410-912e-c29ae57300e0
Note the type change of vplce[] in engine.c: int32_t -> uint32_t.
git-svn-id: https://svn.eduke32.com/eduke32@3172 1a8010ca-5511-0410-912e-c29ae57300e0
This reverts r3159..r3161.
Conflicts:
eduke32/build/include/compat.h
(Handled so that r3163's changes are kept applied.)
git-svn-id: https://svn.eduke32.com/eduke32@3165 1a8010ca-5511-0410-912e-c29ae57300e0
- Eliminate use of the C++ standard library from arttool. I improved some of the program's workings but it continues to corrupt my art files in certain circumstances. (Note: Not a regression; it happens with previous revisions.)
- Construct "make utils" for the game side following the pattern of the engine.
- Move ivfrate to this new distinction.
- Minor Makefile cleanup and tweaks, mainly to facilitate CLANG=1 and to formalize text output in special cases.
git-svn-id: https://svn.eduke32.com/eduke32@3163 1a8010ca-5511-0410-912e-c29ae57300e0
I think there's also a fix for the CON precache system breakage in here (lost it in my local tree when I started getting the C++ build working in MSVC, sorry!)
git-svn-id: https://svn.eduke32.com/eduke32@3159 1a8010ca-5511-0410-912e-c29ae57300e0
Specifically, if the first wall of the sector-to-split is to the left or right
of the *start* of the splitting line AND the sector has no TROR extensions,
make these two the new nextwalls of the respective split sectors.
git-svn-id: https://svn.eduke32.com/eduke32@3157 1a8010ca-5511-0410-912e-c29ae57300e0
Exporting only (de)compression functions. Also, different reader/writer
functions can be set.
git-svn-id: https://svn.eduke32.com/eduke32@3153 1a8010ca-5511-0410-912e-c29ae57300e0
On the engine side (functions starting with L_), there are now the basic
parts like state creation and running code from strings and files.
The game and editor can add to that by e.g. loading whatever they please
into the state. Their functions start with El_ and Em_, respectively.
The Lua scripts still reside in source/lunatic, even for the common ones.
This is because they will be embedded into the binaries as bytecode or
compressed source eventually, so their location on disk will be irrelevant.
git-svn-id: https://svn.eduke32.com/eduke32@3148 1a8010ca-5511-0410-912e-c29ae57300e0
Also, enable showing sprites in Mapster32's overhead view again, since that
was one (the only?) use of that code path. The uninitialized read was
introduced in r2927.
git-svn-id: https://svn.eduke32.com/eduke32@3144 1a8010ca-5511-0410-912e-c29ae57300e0
arrays; any write access to them will run the corresponding hook and write
to the [sector/wall/sprite/tsprite]clean array.
Note: tsprite and sprite use the same hook and require running a few more
instructions per access in order to disambiguiate; this could be made more
optimal (like the other arrays) by clearly separating the types in the game
code.
Note #2: taking a member's address currently marks it dirty because of tons
of helper functions across the editor code. I don't know how many read-only
accesses we have after taking a member address, but it could also be fixed
with some finessing of the code.
git-svn-id: https://svn.eduke32.com/eduke32@3138 1a8010ca-5511-0410-912e-c29ae57300e0
Credit to Plagman for the idea and doing the work on the game side, which is included in this commit.
(Building as C++ will give us features with which we can make improvements and optimizations on the multiplayer code and Polymer.)
git-svn-id: https://svn.eduke32.com/eduke32@3116 1a8010ca-5511-0410-912e-c29ae57300e0
This is done by pressing LShift and
- holding down the left mouse button for scaling, or
- the right mouse button for rotating the highlighted walls/sprites
with respect to a pivot point determined as the center of the bounding box of
all highlighted points.
Note that scaling sectors isn't that easy and the current functionality is very
rudimentary: there's no z scaling, no xrepeat correction, and sprites aren't
touched expect for their position. The user is responsible to maintain map
consistency, for example to prevent wall-lines of the same sector crossing
each other.
git-svn-id: https://svn.eduke32.com/eduke32@3113 1a8010ca-5511-0410-912e-c29ae57300e0
