- Clang's optional runtime array bounds checking doesn't understand when we
intentionally "overflow" by doing this:
RGB32k[0][0][colorval]
It will warn that it was accessed at an index will past the bounds
of type 'BYTE [32]', which makes it less than useful for catching real
array bounds overflows. So now do this:
RGB32k.All[colorval]
And if you want this:
RGB32k[r][g][b]
Now do this:
RGB32k.RGB[r][g][b]
Conflicts:
src/CMakeLists.txt
src/b_think.cpp
src/g_doom/a_doomweaps.cpp
src/g_hexen/a_clericstaff.cpp
src/g_hexen/a_fighterplayer.cpp
src/namedef.h
src/p_enemy.cpp
src/p_local.h
src/p_mobj.cpp
src/p_teleport.cpp
src/sc_man_tokens.h
src/thingdef/thingdef_codeptr.cpp
src/thingdef/thingdef_function.cpp
src/thingdef/thingdef_parse.cpp
wadsrc/static/actors/actor.txt
wadsrc/static/actors/constants.txt
wadsrc/static/actors/shared/inventory.txt
- Added register reuse to VMFunctionBuilder for FxPick's code emitter.
- Note to self: Need to reimplement IsPointerEqual and CheckClass, which
were added to thingdef_function.cpp over the past year, as this file no
longer exists in this branch.
because they're kind of a pain to type when all uppercase.
- Also, make its sx1 and sx2 members shorts, so it takes less space, since
it's getting crammed into a vissprite now.
- This still doesn't use all the sprite properties correctly. It also
looks like they're going to need different code to build the clipping
arrays. But at least wall sprites are drawn at the proper angle now!
about this now. I spent three days trying to figure out why the VC++ debug version was so slow.
It turns out I had a conditional breakpoint set in a high-traffic area. D'oh!
The rest of this stuff should get merged into trunk:
- Fixed: Writing to debugfile uses the standard fprintf, which does not understand %td on VC++.
- Fixed: Instead of crashing when a sprite has been scaled to 0, just don't draw it.
SVN r3896 (scripting)
Includes:
- Made the move tried from checking missile spawns ignore drop off height. This solves the Voodoo Gun ghostly civilian issue.
- Fixed: the NOTELEPORT flag is removed from Dehacked missiles which lose the MISSILE flag. This caused problems with certain special effects based on dehacked spawn cubes.
- Fixed: all Boom silent teleporters preserve relative height.
- support for palette independent particle colors if the renderer can handle them.
SVN r3329 (trunk)
- FCoverageBuffer is only used in r_things.cpp, so its declaration does not need to be in a global header that's included everywhere.
SVN r3258 (trunk)
(e.g. invulnerability). This should only be necessary for SM1.4 cards with buggy drivers. I
doubt the problem is very widespread. The one piece of SM1.4 hardware I obtained specifically
for testing purposes has no problems using shaders for these effects.
SVN r3200 (trunk)
* Added new cvar, r_3dfloors for testing, so for example, you can see the FPS difference.
* ds_p->bkup is not always allocated.
* Fixed particles visible through 3D floors.
* Fixed FAKE3D flag names.
SVN r3178 (trunk)
- allow setting 'Shadow' as default fuzz effect
- changed CVAR conversion that strings 'false' and 'true' get evaluated as integers 0 and 1 respectively so that changing boolean CVARs to int does not destroy their values.
SVN r3076 (trunk)
- Initialize the alt HUD explicitly in D_DoomMain.
- don't let S_UnloadReverbDef leave a broken list of sound environments behind.
- Added more code to explicitly delete data before initializing it.
SVN r3039 (trunk)
- move D_LoadWadSettings to keysections.cpp.
- made some more data reloadable.
- data structures filled by P_SetupLevel should be cleared before loading the level. They can remain non-empty in case of an error. There's probably more to fix here...
- fixed: MidiDevices and MusicAliases were not cleared before reloading local SNDINFOs.
- fixed signed/unsigned warnings in AddSwitchPair for real (GCC really allows -1u? MSVC prints a warning for that.)
SVN r3036 (trunk)
- added compatibility option to invert sprite sorting. Apparently Doom.exe
originally sorted them differently than most source port and on some maps
which depends on this it doesn't look right (e.g. Strain MAP13)
SVN r2031 (trunk)
player sprites will retain the same precision they had when they were
rendered as part of the 3D view. (needed for propery alignment of flashes
on top of weapon sprites) It worked just fine for D3D, but software
rendering was another matter. I consequently did battle with imprecisions
in the whole masked texture drawing routines that had previously been
partially masked by only drawing on whole pixel boundaries. Particularly,
the tops of posts are calculated by multiplying by spryscale, and the
texture mapping coordinates are calculated by multiplying by dc_iscale
(where dc_iscale = 1 / spryscale). Since these are both 16.16 fixed point
values, there is a significant variance. For best results, the drawing
routines should only use one of these values, but that would mean
introducing division into the inner loop. If the division removed the
necessity for the fudge code in R_DrawMaskedColumn(), would it be worth it?
Or would the divide be slower than the fudging? Or would I be better off
doing it like Build and using transparent pixel checks instead, not
bothering with skipping transparent areas? For now, I chop off the
fractional part of the top coordinate for software drawing, since it was
the easiest thing to do (even if it wasn't the most correct thing to do).
SVN r1955 (trunk)
which could cause crashes.
- Added custom special colormaps to DECORATE.
- Cleaned up special colormap code and removed lots of dependencies on the
knowledge of the tables' contents.
SVN r1860 (trunk)
completely ignore them, either).
- Separated light level fixing out of player_t's fixedcolormap parameter.
Using a fixed light level (e.g. PowerTorch) will no longer wipe out
colored lighting.
- Moved the blending rectangle drawing into a separate discrete stage, since
doing it while copying the 3D view window to the display now blends
underneath the weapon instead of on top of it.
- Consolidated the special colormaps into a single 2D table.
- Tweaked the special colormaps slightly to make the true color results more
closely match the paletted approximations.
- fb_d3d9_shaders.h was getting unwieldy, so I moved the shaders out of the
executable and into zdoom.pk3. Shaders are still precompiled so I don't need
to pull in a dependancy on D3DX.
- Added a few more shaders to accomodate drawing weapons with all the in-game
lighting models. These are accessed with the new DrawTexture tags
DTA_SpecialColormap and DTA_ColormapStyle.
- Player weapon sprites are now drawn using Direct3D and receive all the
benefits thereof.
SVN r1858 (trunk)
issues that caused its inclusion. Is an optimized GCC build any faster
for being able to use strict aliasing rules? I dunno. It's still slower
than a VC++ build.
I did run into two cases where TAutoSegIterator caused intractable problems
with breaking strict aliasing rules, so I removed the templating from it,
and the caller is now responsible for casting the probe value from void *.
- Removed #include "autosegs.h" from several files that did not need it
(in particular, dobject.h when not compiling with VC++).
SVN r1743 (trunk)
- Removed #pragma warnings from cmdlib.h and fixed the places where they were
still triggered.
These #pragmas were responsible for >90% of the GCC warnings that were not
listed in VC++.
- Fixed one bug in the process: DSeqNode::m_Atten was never adjusted when the
parameter handling of the sound functions for attenuation was changed.
Changed m_Atten to a float and fixed the SNDSEQ parser to set proper values.
Also added the option to specify attenuation with direct values in addition
to the predefined names.
SVN r1583 (trunk)
code depends on the original indices.
- Fixed: P_StartConversation set the global dialog node variable for all
players, not just the consoleplayer.
- Fixed: AWeapon::PickupForAmmo assumed that any weapon having a secondary
ammo type also has a primary one.
SVN r1431 (trunk)
replaced it did the check at the center of the area intersected by the
sprite and the drawseg, whereas 2.0.63 only did the check at the location
of the sprite on the map.
SVN r1411 (trunk)
