- The old algorithm is something I threw together that produced decent,
but not spectacular results since it had a tendency to waste space by
forcing everything onto "shelves".
The new packer is the Skyline-MinWaste-WasteMap-BestFirstFit algorithm
described by Jukka Jylanki in his paper *A Thousand Ways to Pack the Bin - A
Practical Approach to Two-Dimensional Rectangle Bin Packing*, which can
currently be read at http://clb.demon.fi/files/RectangleBinPack.pdf
This is minus the optimization to rotate rectangles to make better fits.
- GetSystemMetrics can lie about the window border sizes, so we can't
trust it if the executable is flagged as Vista-targetting
(default behavior for VS2012/2013).
defaults to 200. Setting it to 0 will restore the previous behavior of having no frame rate
limit. Note that vid_maxfps 35 is NOT the same as cl_capfps 1. cl_capfps caps the frame rate
by tying the video update directly to the game timer. With vid_maxfps 35, the video update and
game timer are running on separate timers, and results will not be as good as with cl_capfps 1,
which uses only one timer.
SVN r3872 (trunk)
decided there was nothing to draw. In practical terms, this means that if your weapon is
completely invisible, the game would not draw anything outside of the main play area because
the scissor test would be left on for the entire frame and not just the weapon's quad.
Making the call to SetStyle() before the scissor check is enough to fix this.
SVN r3412 (trunk)
also decided to compile some other shaders slightly differently, too.)
- Fixed: The InGameColormap had been designed without taking alpha into consideration.
As the least likely parameter to be used, desaturation has been moved into a constant
register to make room for the alpha parameter to live in the vertex's color value.
SVN r3208 (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)
since the screenwipe speedup fixes also mean that this function no longer operates directly
with the front buffer, but rather with a copy that is not letterboxed.
SVN r2355 (trunk)
some other application already has it. While technically this is a failure, the device is
still created, so we can continue using it anyway.
SVN r2326 (trunk)
swap between them each frame. The one that's not the TempRenderTexture is used
as the FrontCopySurface without the need for a copy operation. This removes the
performance penalty the previous commit introduced for these modes.
SVN r2014 (trunk)
properly in letterboxed modes.
- Added another surface to receive a copy of the top back buffer immediately
before it is presented. This effectively produces a copy of the front
buffer without the performance penalty of GetFrontBufferData, so fullscreen
wipe preparation and screenshots are faster now. At lower resolutions,
always copying the backbuffer does incur a slight FPS hit, but it's
practically free at higher resolutions.
SVN r2013 (trunk)
assumed that since the wipes only run at 35 FPS, the time spent DMA'ing
it from system to video memory would be acceptable. Apparently I was wrong.
In particular, updating the same surface several times probably has to
synchronize between each one, making melt particularly slower than it
needs to be.
SVN r2012 (trunk)
unsigned integer that can use all 32 bits. They must therefore use
the unsigned mul instruction rather than the signed imul instruction.
- Fixed several signed/unsigned comparison and possibly uninitialized
variable warnings flagged by GCC.
SVN r1965 (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)
at just fixing it at a specific value, since the supply of SM14 cards isn't
all that diverse and all from ATI, but apparently Radeon 8500s and 9000s
have different precision levels in their pixel shaders. See bug report
<http://forum.zdoom.org/viewtopic.php?p=444523>
- Removed unused variables FBFormat and PalFormat.
SVN r1901 (trunk)
Mobility Radeon 9000 (on a PCI card, no less!), I have decided to give the
PS14 support some loving: D3D windowed gamma now works on these cards using
a texture lookup for the gamma table. Sadly, this halves my framerate, so
setting gamma to 1 will skip the gamma correction, as it was before, for
full speed. (On my 8800 GT, the gamma correction was free.)
SVN r1898 (trunk)
surfaces are alternately locked for read-only access each frame, forcing
the driver to stop buffering more than one frame at a time. The input lag
on my system doesn't seem to be as bad as it once was (I can no longer
see it obviously with my naked eye), but turning antilag on "feels"
slightly more responsive. The cvar d3d_antilag turns this technique on and
off. See <http://www.xyzw.de/c120.html> for more details.
SVN r1870 (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)
so that all files are included by a central one instead of compiling
each one separately. This speeds up the compilation process by 25%
when doing a complete rebuild in Visual C.
- Cleaned up more header dependencies.
SVN r1226 (trunk)
