2006-02-24 04:48:15 +00:00
|
|
|
/*
|
|
|
|
|
** v_draw.cpp
|
|
|
|
|
** Draw patches and blocks to a canvas
|
|
|
|
|
**
|
|
|
|
|
**---------------------------------------------------------------------------
|
- Discovered that Shader Model 1.4 clamps my constants, so I can't use
palettes smaller than 256 entries with the shader I wrote for it. Is there
a list of gotchas like this listed some where? I'd really like to see it.
Well, when compiled with SM2.0, the PalTex shader seems to be every-so-
slightly faster on my GF7950GT than the SM1.4 version, so I guess it's a
minor win for cards that support it.
- Fixed: ST_Endoom() failed to free the bitmap it used.
- Added the DTA_ColorOverlay attribute to blend a color with the texture
being drawn. For software, this (currently) only works with black. For
hardware, it works with any color. The motiviation for this was so I could
rewrite the status bar calls that passed DIM_MAP to DTA_Translation to
draw darker icons into something that didn't require making a whole new
remap table.
- After having an "OMG! How could I have been so stupid?" moment, I have
removed the off-by-one check from D3DFB. I had thought the off-by-one error
was caused by rounding errors by the shader hardware. Not so. Rather, I
wasn't sampling what I thought I was sampling. A texture that uses palette
index 255 passes the value 1.0 to the shader. The shader needs to adjust the
range of its palette indexes, or it will end up trying to read color 256
from the palette texture when it should be reading color 255. Doh!
- The TranslationToTable() function has been added to map from translation
numbers used by actors to the tables those numbers represent. This function
performs validation for the input and returns NULL if the input value
is invalid.
- Major changes to the way translation tables work: No longer are they each a
256-byte array. Instead, the FRemapTable structure is used to represent each
one. It includes a remap array for the software renderer, a palette array
for a hardware renderer, and a native texture pointer for D3DFB. The
translationtables array itself is now an array of TArrays that point to the
real tables. The DTA_Translation attribute must also be passed a pointer
to a FRemapTable, not a byte array as previously.
- Modified DFrameBuffer::DrawRateStuff() so that it can do its thing properly
for D3DFB's 2D mode. Before, any fullscreen graphics (like help images)
covered it up.
SVN r640 (trunk)
2007-12-26 04:42:15 +00:00
|
|
|
** Copyright 1998-2008 Randy Heit
|
2006-02-24 04:48:15 +00:00
|
|
|
** All rights reserved.
|
|
|
|
|
**
|
|
|
|
|
** Redistribution and use in source and binary forms, with or without
|
|
|
|
|
** modification, are permitted provided that the following conditions
|
|
|
|
|
** are met:
|
|
|
|
|
**
|
|
|
|
|
** 1. Redistributions of source code must retain the above copyright
|
|
|
|
|
** notice, this list of conditions and the following disclaimer.
|
|
|
|
|
** 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
|
** notice, this list of conditions and the following disclaimer in the
|
|
|
|
|
** documentation and/or other materials provided with the distribution.
|
|
|
|
|
** 3. The name of the author may not be used to endorse or promote products
|
|
|
|
|
** derived from this software without specific prior written permission.
|
|
|
|
|
**
|
|
|
|
|
** THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
|
|
|
|
|
** IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
|
|
|
|
|
** OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
|
|
|
|
|
** IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
|
|
|
|
|
** INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
|
|
|
|
|
** NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
|
|
|
|
|
** DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
|
|
|
|
|
** THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
|
|
|
|
** (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
|
|
|
|
|
** THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
|
**---------------------------------------------------------------------------
|
|
|
|
|
**
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <stdio.h>
|
|
|
|
|
#include <stdarg.h>
|
|
|
|
|
|
|
|
|
|
#include "doomtype.h"
|
|
|
|
|
#include "v_video.h"
|
|
|
|
|
#include "m_swap.h"
|
|
|
|
|
#include "r_defs.h"
|
|
|
|
|
#include "r_draw.h"
|
2008-09-15 14:11:05 +00:00
|
|
|
#include "r_main.h"
|
2006-02-24 04:48:15 +00:00
|
|
|
#include "r_things.h"
|
2011-07-06 08:50:15 +00:00
|
|
|
#include "r_data/r_translate.h"
|
2008-09-14 23:54:38 +00:00
|
|
|
#include "doomstat.h"
|
2008-09-15 14:11:05 +00:00
|
|
|
#include "v_palette.h"
|
2010-09-14 17:28:18 +00:00
|
|
|
#include "gi.h"
|
2011-07-05 20:41:53 +00:00
|
|
|
#include "g_level.h"
|
|
|
|
|
#include "st_stuff.h"
|
2006-02-24 04:48:15 +00:00
|
|
|
|
|
|
|
|
#include "i_system.h"
|
|
|
|
|
#include "i_video.h"
|
|
|
|
|
#include "templates.h"
|
2008-09-14 23:54:38 +00:00
|
|
|
#include "d_net.h"
|
|
|
|
|
#include "colormatcher.h"
|
2011-07-06 07:35:36 +00:00
|
|
|
#include "r_data/colormaps.h"
|
2006-02-24 04:48:15 +00:00
|
|
|
|
|
|
|
|
// [RH] Stretch values to make a 320x200 image best fit the screen
|
|
|
|
|
// without using fractional steppings
|
|
|
|
|
int CleanXfac, CleanYfac;
|
|
|
|
|
|
|
|
|
|
// [RH] Effective screen sizes that the above scale values give you
|
|
|
|
|
int CleanWidth, CleanHeight;
|
|
|
|
|
|
2009-12-25 05:55:51 +00:00
|
|
|
// Above minus 1 (or 1, if they are already 1)
|
|
|
|
|
int CleanXfac_1, CleanYfac_1, CleanWidth_1, CleanHeight_1;
|
|
|
|
|
|
2010-08-27 15:20:05 +00:00
|
|
|
// FillSimplePoly uses this
|
|
|
|
|
extern "C" short spanend[MAXHEIGHT];
|
2011-07-05 20:41:53 +00:00
|
|
|
extern int setblocks;
|
2010-08-27 15:20:05 +00:00
|
|
|
|
2006-02-24 04:48:15 +00:00
|
|
|
CVAR (Bool, hud_scale, false, CVAR_ARCHIVE);
|
|
|
|
|
|
2008-04-11 04:59:23 +00:00
|
|
|
// For routines that take RGB colors, cache the previous lookup in case there
|
|
|
|
|
// are several repetitions with the same color.
|
|
|
|
|
static int LastPal = -1;
|
|
|
|
|
static uint32 LastRGB;
|
|
|
|
|
|
2010-08-27 15:20:05 +00:00
|
|
|
|
2008-04-11 04:59:23 +00:00
|
|
|
static int PalFromRGB(uint32 rgb)
|
|
|
|
|
{
|
|
|
|
|
if (LastPal >= 0 && LastRGB == rgb)
|
|
|
|
|
{
|
|
|
|
|
return LastPal;
|
|
|
|
|
}
|
|
|
|
|
// Quick check for black and white.
|
|
|
|
|
if (rgb == MAKEARGB(255,0,0,0))
|
|
|
|
|
{
|
|
|
|
|
LastPal = GPalette.BlackIndex;
|
|
|
|
|
}
|
|
|
|
|
else if (rgb == MAKEARGB(255,255,255,255))
|
|
|
|
|
{
|
|
|
|
|
LastPal = GPalette.WhiteIndex;
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
LastPal = ColorMatcher.Pick(RPART(rgb), GPART(rgb), BPART(rgb));
|
|
|
|
|
}
|
|
|
|
|
LastRGB = rgb;
|
|
|
|
|
return LastPal;
|
|
|
|
|
}
|
|
|
|
|
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
void STACK_ARGS DCanvas::DrawTexture (FTexture *img, double x, double y, int tags_first, ...)
|
2007-12-20 04:36:43 +00:00
|
|
|
{
|
|
|
|
|
va_list tags;
|
|
|
|
|
va_start(tags, tags_first);
|
|
|
|
|
DrawTextureV(img, x, y, tags_first, tags);
|
|
|
|
|
}
|
|
|
|
|
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
void STACK_ARGS DCanvas::DrawTextureV(FTexture *img, double x, double y, uint32 tag, va_list tags)
|
2006-02-24 04:48:15 +00:00
|
|
|
{
|
|
|
|
|
FTexture::Span unmaskedSpan[2];
|
|
|
|
|
const FTexture::Span **spanptr, *spans;
|
|
|
|
|
static short bottomclipper[MAXWIDTH], topclipper[MAXWIDTH];
|
2007-12-20 04:36:43 +00:00
|
|
|
|
|
|
|
|
DrawParms parms;
|
|
|
|
|
|
- Discovered that Shader Model 1.4 clamps my constants, so I can't use
palettes smaller than 256 entries with the shader I wrote for it. Is there
a list of gotchas like this listed some where? I'd really like to see it.
Well, when compiled with SM2.0, the PalTex shader seems to be every-so-
slightly faster on my GF7950GT than the SM1.4 version, so I guess it's a
minor win for cards that support it.
- Fixed: ST_Endoom() failed to free the bitmap it used.
- Added the DTA_ColorOverlay attribute to blend a color with the texture
being drawn. For software, this (currently) only works with black. For
hardware, it works with any color. The motiviation for this was so I could
rewrite the status bar calls that passed DIM_MAP to DTA_Translation to
draw darker icons into something that didn't require making a whole new
remap table.
- After having an "OMG! How could I have been so stupid?" moment, I have
removed the off-by-one check from D3DFB. I had thought the off-by-one error
was caused by rounding errors by the shader hardware. Not so. Rather, I
wasn't sampling what I thought I was sampling. A texture that uses palette
index 255 passes the value 1.0 to the shader. The shader needs to adjust the
range of its palette indexes, or it will end up trying to read color 256
from the palette texture when it should be reading color 255. Doh!
- The TranslationToTable() function has been added to map from translation
numbers used by actors to the tables those numbers represent. This function
performs validation for the input and returns NULL if the input value
is invalid.
- Major changes to the way translation tables work: No longer are they each a
256-byte array. Instead, the FRemapTable structure is used to represent each
one. It includes a remap array for the software renderer, a palette array
for a hardware renderer, and a native texture pointer for D3DFB. The
translationtables array itself is now an array of TArrays that point to the
real tables. The DTA_Translation attribute must also be passed a pointer
to a FRemapTable, not a byte array as previously.
- Modified DFrameBuffer::DrawRateStuff() so that it can do its thing properly
for D3DFB's 2D mode. Before, any fullscreen graphics (like help images)
covered it up.
SVN r640 (trunk)
2007-12-26 04:42:15 +00:00
|
|
|
if (!ParseDrawTextureTags(img, x, y, tag, tags, &parms, false))
|
2007-12-20 04:36:43 +00:00
|
|
|
{
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (parms.masked)
|
|
|
|
|
{
|
|
|
|
|
spanptr = &spans;
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
spanptr = NULL;
|
|
|
|
|
}
|
|
|
|
|
|
- Discovered that Shader Model 1.4 clamps my constants, so I can't use
palettes smaller than 256 entries with the shader I wrote for it. Is there
a list of gotchas like this listed some where? I'd really like to see it.
Well, when compiled with SM2.0, the PalTex shader seems to be every-so-
slightly faster on my GF7950GT than the SM1.4 version, so I guess it's a
minor win for cards that support it.
- Fixed: ST_Endoom() failed to free the bitmap it used.
- Added the DTA_ColorOverlay attribute to blend a color with the texture
being drawn. For software, this (currently) only works with black. For
hardware, it works with any color. The motiviation for this was so I could
rewrite the status bar calls that passed DIM_MAP to DTA_Translation to
draw darker icons into something that didn't require making a whole new
remap table.
- After having an "OMG! How could I have been so stupid?" moment, I have
removed the off-by-one check from D3DFB. I had thought the off-by-one error
was caused by rounding errors by the shader hardware. Not so. Rather, I
wasn't sampling what I thought I was sampling. A texture that uses palette
index 255 passes the value 1.0 to the shader. The shader needs to adjust the
range of its palette indexes, or it will end up trying to read color 256
from the palette texture when it should be reading color 255. Doh!
- The TranslationToTable() function has been added to map from translation
numbers used by actors to the tables those numbers represent. This function
performs validation for the input and returns NULL if the input value
is invalid.
- Major changes to the way translation tables work: No longer are they each a
256-byte array. Instead, the FRemapTable structure is used to represent each
one. It includes a remap array for the software renderer, a palette array
for a hardware renderer, and a native texture pointer for D3DFB. The
translationtables array itself is now an array of TArrays that point to the
real tables. The DTA_Translation attribute must also be passed a pointer
to a FRemapTable, not a byte array as previously.
- Modified DFrameBuffer::DrawRateStuff() so that it can do its thing properly
for D3DFB's 2D mode. Before, any fullscreen graphics (like help images)
covered it up.
SVN r640 (trunk)
2007-12-26 04:42:15 +00:00
|
|
|
if (APART(parms.colorOverlay) != 0)
|
2007-12-20 04:36:43 +00:00
|
|
|
{
|
- Updated lempar.c to v1.31.
- Added .txt files to the list of types (wad, zip, and pk3) that can be
loaded without listing them after -file.
- Fonts that are created by the ACS setfont command to wrap a texture now
support animated textures.
- FON2 fonts can now use their full palette for CR_UNTRANSLATED when drawn
with the hardware 2D path instead of being restricted to the game palette.
- Fixed: Toggling vid_vsync would reset the displayed fullscreen gamma to 1
on a Radeon 9000.
- Added back the off-by-one palette handling, but in a much more limited
scope than before. The skipped entry is assumed to always be at 248, and
it is assumed that all Shader Model 1.4 cards suffer from this. That's
because all SM1.4 cards are based on variants of the ATI R200 core, and the
RV250 in a Radeon 9000 craps up like this. I see no reason to assume that
other flavors of the R200 are any different. (Interesting note: With the
Radeon 9000, D3DTADDRESS_CLAMP is an invalid address mode when using the
debug Direct3D 9 runtime, but it works perfectly fine with the retail
Direct3D 9 runtime.) (Insight: The R200 probably uses bytes for all its
math inside pixel shaders. That would explain perfectly why I can't use
constants greater than 1 with PS1.4 and why it can't do an exact mapping to
every entry in the color palette.
- Fixed: The software shaded drawer did not work for 2D, because its selected
"color"map was replaced with the identitymap before being used.
- Fixed: I cannot use Printf to output messages before the framebuffer was
completely setup, meaning that Shader Model 1.4 cards could not change
resolution.
- I have decided to let remap palettes specify variable alpha values for
their colors. D3DFB no longer forces them to 255.
- Updated re2c to version 0.12.3.
- Fixed: A_Wander used threshold as a timer, when it should have used
reactiontime.
- Fixed: A_CustomRailgun would not fire at all for actors without a target
when the aim parameter was disabled.
- Made the warp command work in multiplayer, again courtesy of Karate Chris.
- Fixed: Trying to spawn a bot while not in a game made for a crashing time.
(Patch courtesy of Karate Chris.)
- Removed some floating point math from hu_scores.cpp that somebody's GCC
gave warnings for (not mine, though).
- Fixed: The SBarInfo drawbar command crashed if the sprite image was
unavailable.
- Fixed: FString::operator=(const char *) did not release its old buffer when
being assigned to the null string.
- The scanner no longer has an upper limit on the length of strings it
accepts, though short strings will be faster than long ones.
- Moved all the text scanning functions into a class. Mainly, this means that
multiple script scanner states can be stored without being forced to do so
recursively. I think I might be taking advantage of that in the near
future. Possibly. Maybe.
- Removed some potential buffer overflows from the decal parser.
- Applied Blzut3's SBARINFO update #9:
* Fixed: When using even length values in drawnumber it would cap to a 98
value instead of a 99 as intended.
* The SBarInfo parser can now accept negatives for coordinates. This
doesn't allow much right now, but later I plan to add better fullscreen
hud support in which the negatives will be more useful. This also cleans
up the source a bit since all calls for (x, y) coordinates are with the
function getCoordinates().
- Added support for stencilling actors.
- Added support for non-black colors specified with DTA_ColorOverlay to the
software renderer.
- Fixed: The inverse, gold, red, and green fixed colormaps each allocated
space for 32 different colormaps, even though each only used the first one.
- Added two new blending flags to make reverse subtract blending more useful:
STYLEF_InvertSource and STYLEF_InvertOverlay. These invert the color that
gets blended with the background, since that seems like a good idea for
reverse subtraction. They also work with the other two blending operations.
- Added subtract and reverse subtract blending operations to the renderer.
Since the ERenderStyle enumeration was getting rather unwieldy, I converted
it into a new FRenderStyle structure that lets each parameter of the
blending equation be set separately. This simplified the set up for the
blend quite a bit, and it means a number of new combinations are available
by setting the parameters properly.
SVN r710 (trunk)
2008-01-25 23:57:44 +00:00
|
|
|
// The software renderer cannot invert the source without inverting the overlay
|
|
|
|
|
// too. That means if the source is inverted, we need to do the reverse of what
|
|
|
|
|
// the invert overlay flag says to do.
|
|
|
|
|
INTBOOL invertoverlay = (parms.style.Flags & STYLEF_InvertOverlay);
|
- Discovered that Shader Model 1.4 clamps my constants, so I can't use
palettes smaller than 256 entries with the shader I wrote for it. Is there
a list of gotchas like this listed some where? I'd really like to see it.
Well, when compiled with SM2.0, the PalTex shader seems to be every-so-
slightly faster on my GF7950GT than the SM1.4 version, so I guess it's a
minor win for cards that support it.
- Fixed: ST_Endoom() failed to free the bitmap it used.
- Added the DTA_ColorOverlay attribute to blend a color with the texture
being drawn. For software, this (currently) only works with black. For
hardware, it works with any color. The motiviation for this was so I could
rewrite the status bar calls that passed DIM_MAP to DTA_Translation to
draw darker icons into something that didn't require making a whole new
remap table.
- After having an "OMG! How could I have been so stupid?" moment, I have
removed the off-by-one check from D3DFB. I had thought the off-by-one error
was caused by rounding errors by the shader hardware. Not so. Rather, I
wasn't sampling what I thought I was sampling. A texture that uses palette
index 255 passes the value 1.0 to the shader. The shader needs to adjust the
range of its palette indexes, or it will end up trying to read color 256
from the palette texture when it should be reading color 255. Doh!
- The TranslationToTable() function has been added to map from translation
numbers used by actors to the tables those numbers represent. This function
performs validation for the input and returns NULL if the input value
is invalid.
- Major changes to the way translation tables work: No longer are they each a
256-byte array. Instead, the FRemapTable structure is used to represent each
one. It includes a remap array for the software renderer, a palette array
for a hardware renderer, and a native texture pointer for D3DFB. The
translationtables array itself is now an array of TArrays that point to the
real tables. The DTA_Translation attribute must also be passed a pointer
to a FRemapTable, not a byte array as previously.
- Modified DFrameBuffer::DrawRateStuff() so that it can do its thing properly
for D3DFB's 2D mode. Before, any fullscreen graphics (like help images)
covered it up.
SVN r640 (trunk)
2007-12-26 04:42:15 +00:00
|
|
|
|
- Updated lempar.c to v1.31.
- Added .txt files to the list of types (wad, zip, and pk3) that can be
loaded without listing them after -file.
- Fonts that are created by the ACS setfont command to wrap a texture now
support animated textures.
- FON2 fonts can now use their full palette for CR_UNTRANSLATED when drawn
with the hardware 2D path instead of being restricted to the game palette.
- Fixed: Toggling vid_vsync would reset the displayed fullscreen gamma to 1
on a Radeon 9000.
- Added back the off-by-one palette handling, but in a much more limited
scope than before. The skipped entry is assumed to always be at 248, and
it is assumed that all Shader Model 1.4 cards suffer from this. That's
because all SM1.4 cards are based on variants of the ATI R200 core, and the
RV250 in a Radeon 9000 craps up like this. I see no reason to assume that
other flavors of the R200 are any different. (Interesting note: With the
Radeon 9000, D3DTADDRESS_CLAMP is an invalid address mode when using the
debug Direct3D 9 runtime, but it works perfectly fine with the retail
Direct3D 9 runtime.) (Insight: The R200 probably uses bytes for all its
math inside pixel shaders. That would explain perfectly why I can't use
constants greater than 1 with PS1.4 and why it can't do an exact mapping to
every entry in the color palette.
- Fixed: The software shaded drawer did not work for 2D, because its selected
"color"map was replaced with the identitymap before being used.
- Fixed: I cannot use Printf to output messages before the framebuffer was
completely setup, meaning that Shader Model 1.4 cards could not change
resolution.
- I have decided to let remap palettes specify variable alpha values for
their colors. D3DFB no longer forces them to 255.
- Updated re2c to version 0.12.3.
- Fixed: A_Wander used threshold as a timer, when it should have used
reactiontime.
- Fixed: A_CustomRailgun would not fire at all for actors without a target
when the aim parameter was disabled.
- Made the warp command work in multiplayer, again courtesy of Karate Chris.
- Fixed: Trying to spawn a bot while not in a game made for a crashing time.
(Patch courtesy of Karate Chris.)
- Removed some floating point math from hu_scores.cpp that somebody's GCC
gave warnings for (not mine, though).
- Fixed: The SBarInfo drawbar command crashed if the sprite image was
unavailable.
- Fixed: FString::operator=(const char *) did not release its old buffer when
being assigned to the null string.
- The scanner no longer has an upper limit on the length of strings it
accepts, though short strings will be faster than long ones.
- Moved all the text scanning functions into a class. Mainly, this means that
multiple script scanner states can be stored without being forced to do so
recursively. I think I might be taking advantage of that in the near
future. Possibly. Maybe.
- Removed some potential buffer overflows from the decal parser.
- Applied Blzut3's SBARINFO update #9:
* Fixed: When using even length values in drawnumber it would cap to a 98
value instead of a 99 as intended.
* The SBarInfo parser can now accept negatives for coordinates. This
doesn't allow much right now, but later I plan to add better fullscreen
hud support in which the negatives will be more useful. This also cleans
up the source a bit since all calls for (x, y) coordinates are with the
function getCoordinates().
- Added support for stencilling actors.
- Added support for non-black colors specified with DTA_ColorOverlay to the
software renderer.
- Fixed: The inverse, gold, red, and green fixed colormaps each allocated
space for 32 different colormaps, even though each only used the first one.
- Added two new blending flags to make reverse subtract blending more useful:
STYLEF_InvertSource and STYLEF_InvertOverlay. These invert the color that
gets blended with the background, since that seems like a good idea for
reverse subtraction. They also work with the other two blending operations.
- Added subtract and reverse subtract blending operations to the renderer.
Since the ERenderStyle enumeration was getting rather unwieldy, I converted
it into a new FRenderStyle structure that lets each parameter of the
blending equation be set separately. This simplified the set up for the
blend quite a bit, and it means a number of new combinations are available
by setting the parameters properly.
SVN r710 (trunk)
2008-01-25 23:57:44 +00:00
|
|
|
if (parms.style.Flags & STYLEF_InvertSource)
|
2007-12-23 14:13:29 +00:00
|
|
|
{
|
- Updated lempar.c to v1.31.
- Added .txt files to the list of types (wad, zip, and pk3) that can be
loaded without listing them after -file.
- Fonts that are created by the ACS setfont command to wrap a texture now
support animated textures.
- FON2 fonts can now use their full palette for CR_UNTRANSLATED when drawn
with the hardware 2D path instead of being restricted to the game palette.
- Fixed: Toggling vid_vsync would reset the displayed fullscreen gamma to 1
on a Radeon 9000.
- Added back the off-by-one palette handling, but in a much more limited
scope than before. The skipped entry is assumed to always be at 248, and
it is assumed that all Shader Model 1.4 cards suffer from this. That's
because all SM1.4 cards are based on variants of the ATI R200 core, and the
RV250 in a Radeon 9000 craps up like this. I see no reason to assume that
other flavors of the R200 are any different. (Interesting note: With the
Radeon 9000, D3DTADDRESS_CLAMP is an invalid address mode when using the
debug Direct3D 9 runtime, but it works perfectly fine with the retail
Direct3D 9 runtime.) (Insight: The R200 probably uses bytes for all its
math inside pixel shaders. That would explain perfectly why I can't use
constants greater than 1 with PS1.4 and why it can't do an exact mapping to
every entry in the color palette.
- Fixed: The software shaded drawer did not work for 2D, because its selected
"color"map was replaced with the identitymap before being used.
- Fixed: I cannot use Printf to output messages before the framebuffer was
completely setup, meaning that Shader Model 1.4 cards could not change
resolution.
- I have decided to let remap palettes specify variable alpha values for
their colors. D3DFB no longer forces them to 255.
- Updated re2c to version 0.12.3.
- Fixed: A_Wander used threshold as a timer, when it should have used
reactiontime.
- Fixed: A_CustomRailgun would not fire at all for actors without a target
when the aim parameter was disabled.
- Made the warp command work in multiplayer, again courtesy of Karate Chris.
- Fixed: Trying to spawn a bot while not in a game made for a crashing time.
(Patch courtesy of Karate Chris.)
- Removed some floating point math from hu_scores.cpp that somebody's GCC
gave warnings for (not mine, though).
- Fixed: The SBarInfo drawbar command crashed if the sprite image was
unavailable.
- Fixed: FString::operator=(const char *) did not release its old buffer when
being assigned to the null string.
- The scanner no longer has an upper limit on the length of strings it
accepts, though short strings will be faster than long ones.
- Moved all the text scanning functions into a class. Mainly, this means that
multiple script scanner states can be stored without being forced to do so
recursively. I think I might be taking advantage of that in the near
future. Possibly. Maybe.
- Removed some potential buffer overflows from the decal parser.
- Applied Blzut3's SBARINFO update #9:
* Fixed: When using even length values in drawnumber it would cap to a 98
value instead of a 99 as intended.
* The SBarInfo parser can now accept negatives for coordinates. This
doesn't allow much right now, but later I plan to add better fullscreen
hud support in which the negatives will be more useful. This also cleans
up the source a bit since all calls for (x, y) coordinates are with the
function getCoordinates().
- Added support for stencilling actors.
- Added support for non-black colors specified with DTA_ColorOverlay to the
software renderer.
- Fixed: The inverse, gold, red, and green fixed colormaps each allocated
space for 32 different colormaps, even though each only used the first one.
- Added two new blending flags to make reverse subtract blending more useful:
STYLEF_InvertSource and STYLEF_InvertOverlay. These invert the color that
gets blended with the background, since that seems like a good idea for
reverse subtraction. They also work with the other two blending operations.
- Added subtract and reverse subtract blending operations to the renderer.
Since the ERenderStyle enumeration was getting rather unwieldy, I converted
it into a new FRenderStyle structure that lets each parameter of the
blending equation be set separately. This simplified the set up for the
blend quite a bit, and it means a number of new combinations are available
by setting the parameters properly.
SVN r710 (trunk)
2008-01-25 23:57:44 +00:00
|
|
|
invertoverlay = !invertoverlay;
|
2007-12-20 04:36:43 +00:00
|
|
|
}
|
- Updated lempar.c to v1.31.
- Added .txt files to the list of types (wad, zip, and pk3) that can be
loaded without listing them after -file.
- Fonts that are created by the ACS setfont command to wrap a texture now
support animated textures.
- FON2 fonts can now use their full palette for CR_UNTRANSLATED when drawn
with the hardware 2D path instead of being restricted to the game palette.
- Fixed: Toggling vid_vsync would reset the displayed fullscreen gamma to 1
on a Radeon 9000.
- Added back the off-by-one palette handling, but in a much more limited
scope than before. The skipped entry is assumed to always be at 248, and
it is assumed that all Shader Model 1.4 cards suffer from this. That's
because all SM1.4 cards are based on variants of the ATI R200 core, and the
RV250 in a Radeon 9000 craps up like this. I see no reason to assume that
other flavors of the R200 are any different. (Interesting note: With the
Radeon 9000, D3DTADDRESS_CLAMP is an invalid address mode when using the
debug Direct3D 9 runtime, but it works perfectly fine with the retail
Direct3D 9 runtime.) (Insight: The R200 probably uses bytes for all its
math inside pixel shaders. That would explain perfectly why I can't use
constants greater than 1 with PS1.4 and why it can't do an exact mapping to
every entry in the color palette.
- Fixed: The software shaded drawer did not work for 2D, because its selected
"color"map was replaced with the identitymap before being used.
- Fixed: I cannot use Printf to output messages before the framebuffer was
completely setup, meaning that Shader Model 1.4 cards could not change
resolution.
- I have decided to let remap palettes specify variable alpha values for
their colors. D3DFB no longer forces them to 255.
- Updated re2c to version 0.12.3.
- Fixed: A_Wander used threshold as a timer, when it should have used
reactiontime.
- Fixed: A_CustomRailgun would not fire at all for actors without a target
when the aim parameter was disabled.
- Made the warp command work in multiplayer, again courtesy of Karate Chris.
- Fixed: Trying to spawn a bot while not in a game made for a crashing time.
(Patch courtesy of Karate Chris.)
- Removed some floating point math from hu_scores.cpp that somebody's GCC
gave warnings for (not mine, though).
- Fixed: The SBarInfo drawbar command crashed if the sprite image was
unavailable.
- Fixed: FString::operator=(const char *) did not release its old buffer when
being assigned to the null string.
- The scanner no longer has an upper limit on the length of strings it
accepts, though short strings will be faster than long ones.
- Moved all the text scanning functions into a class. Mainly, this means that
multiple script scanner states can be stored without being forced to do so
recursively. I think I might be taking advantage of that in the near
future. Possibly. Maybe.
- Removed some potential buffer overflows from the decal parser.
- Applied Blzut3's SBARINFO update #9:
* Fixed: When using even length values in drawnumber it would cap to a 98
value instead of a 99 as intended.
* The SBarInfo parser can now accept negatives for coordinates. This
doesn't allow much right now, but later I plan to add better fullscreen
hud support in which the negatives will be more useful. This also cleans
up the source a bit since all calls for (x, y) coordinates are with the
function getCoordinates().
- Added support for stencilling actors.
- Added support for non-black colors specified with DTA_ColorOverlay to the
software renderer.
- Fixed: The inverse, gold, red, and green fixed colormaps each allocated
space for 32 different colormaps, even though each only used the first one.
- Added two new blending flags to make reverse subtract blending more useful:
STYLEF_InvertSource and STYLEF_InvertOverlay. These invert the color that
gets blended with the background, since that seems like a good idea for
reverse subtraction. They also work with the other two blending operations.
- Added subtract and reverse subtract blending operations to the renderer.
Since the ERenderStyle enumeration was getting rather unwieldy, I converted
it into a new FRenderStyle structure that lets each parameter of the
blending equation be set separately. This simplified the set up for the
blend quite a bit, and it means a number of new combinations are available
by setting the parameters properly.
SVN r710 (trunk)
2008-01-25 23:57:44 +00:00
|
|
|
if (invertoverlay)
|
2007-12-20 04:36:43 +00:00
|
|
|
{
|
- Updated lempar.c to v1.31.
- Added .txt files to the list of types (wad, zip, and pk3) that can be
loaded without listing them after -file.
- Fonts that are created by the ACS setfont command to wrap a texture now
support animated textures.
- FON2 fonts can now use their full palette for CR_UNTRANSLATED when drawn
with the hardware 2D path instead of being restricted to the game palette.
- Fixed: Toggling vid_vsync would reset the displayed fullscreen gamma to 1
on a Radeon 9000.
- Added back the off-by-one palette handling, but in a much more limited
scope than before. The skipped entry is assumed to always be at 248, and
it is assumed that all Shader Model 1.4 cards suffer from this. That's
because all SM1.4 cards are based on variants of the ATI R200 core, and the
RV250 in a Radeon 9000 craps up like this. I see no reason to assume that
other flavors of the R200 are any different. (Interesting note: With the
Radeon 9000, D3DTADDRESS_CLAMP is an invalid address mode when using the
debug Direct3D 9 runtime, but it works perfectly fine with the retail
Direct3D 9 runtime.) (Insight: The R200 probably uses bytes for all its
math inside pixel shaders. That would explain perfectly why I can't use
constants greater than 1 with PS1.4 and why it can't do an exact mapping to
every entry in the color palette.
- Fixed: The software shaded drawer did not work for 2D, because its selected
"color"map was replaced with the identitymap before being used.
- Fixed: I cannot use Printf to output messages before the framebuffer was
completely setup, meaning that Shader Model 1.4 cards could not change
resolution.
- I have decided to let remap palettes specify variable alpha values for
their colors. D3DFB no longer forces them to 255.
- Updated re2c to version 0.12.3.
- Fixed: A_Wander used threshold as a timer, when it should have used
reactiontime.
- Fixed: A_CustomRailgun would not fire at all for actors without a target
when the aim parameter was disabled.
- Made the warp command work in multiplayer, again courtesy of Karate Chris.
- Fixed: Trying to spawn a bot while not in a game made for a crashing time.
(Patch courtesy of Karate Chris.)
- Removed some floating point math from hu_scores.cpp that somebody's GCC
gave warnings for (not mine, though).
- Fixed: The SBarInfo drawbar command crashed if the sprite image was
unavailable.
- Fixed: FString::operator=(const char *) did not release its old buffer when
being assigned to the null string.
- The scanner no longer has an upper limit on the length of strings it
accepts, though short strings will be faster than long ones.
- Moved all the text scanning functions into a class. Mainly, this means that
multiple script scanner states can be stored without being forced to do so
recursively. I think I might be taking advantage of that in the near
future. Possibly. Maybe.
- Removed some potential buffer overflows from the decal parser.
- Applied Blzut3's SBARINFO update #9:
* Fixed: When using even length values in drawnumber it would cap to a 98
value instead of a 99 as intended.
* The SBarInfo parser can now accept negatives for coordinates. This
doesn't allow much right now, but later I plan to add better fullscreen
hud support in which the negatives will be more useful. This also cleans
up the source a bit since all calls for (x, y) coordinates are with the
function getCoordinates().
- Added support for stencilling actors.
- Added support for non-black colors specified with DTA_ColorOverlay to the
software renderer.
- Fixed: The inverse, gold, red, and green fixed colormaps each allocated
space for 32 different colormaps, even though each only used the first one.
- Added two new blending flags to make reverse subtract blending more useful:
STYLEF_InvertSource and STYLEF_InvertOverlay. These invert the color that
gets blended with the background, since that seems like a good idea for
reverse subtraction. They also work with the other two blending operations.
- Added subtract and reverse subtract blending operations to the renderer.
Since the ERenderStyle enumeration was getting rather unwieldy, I converted
it into a new FRenderStyle structure that lets each parameter of the
blending equation be set separately. This simplified the set up for the
blend quite a bit, and it means a number of new combinations are available
by setting the parameters properly.
SVN r710 (trunk)
2008-01-25 23:57:44 +00:00
|
|
|
parms.colorOverlay = PalEntry(parms.colorOverlay).InverseColor();
|
- Discovered that Shader Model 1.4 clamps my constants, so I can't use
palettes smaller than 256 entries with the shader I wrote for it. Is there
a list of gotchas like this listed some where? I'd really like to see it.
Well, when compiled with SM2.0, the PalTex shader seems to be every-so-
slightly faster on my GF7950GT than the SM1.4 version, so I guess it's a
minor win for cards that support it.
- Fixed: ST_Endoom() failed to free the bitmap it used.
- Added the DTA_ColorOverlay attribute to blend a color with the texture
being drawn. For software, this (currently) only works with black. For
hardware, it works with any color. The motiviation for this was so I could
rewrite the status bar calls that passed DIM_MAP to DTA_Translation to
draw darker icons into something that didn't require making a whole new
remap table.
- After having an "OMG! How could I have been so stupid?" moment, I have
removed the off-by-one check from D3DFB. I had thought the off-by-one error
was caused by rounding errors by the shader hardware. Not so. Rather, I
wasn't sampling what I thought I was sampling. A texture that uses palette
index 255 passes the value 1.0 to the shader. The shader needs to adjust the
range of its palette indexes, or it will end up trying to read color 256
from the palette texture when it should be reading color 255. Doh!
- The TranslationToTable() function has been added to map from translation
numbers used by actors to the tables those numbers represent. This function
performs validation for the input and returns NULL if the input value
is invalid.
- Major changes to the way translation tables work: No longer are they each a
256-byte array. Instead, the FRemapTable structure is used to represent each
one. It includes a remap array for the software renderer, a palette array
for a hardware renderer, and a native texture pointer for D3DFB. The
translationtables array itself is now an array of TArrays that point to the
real tables. The DTA_Translation attribute must also be passed a pointer
to a FRemapTable, not a byte array as previously.
- Modified DFrameBuffer::DrawRateStuff() so that it can do its thing properly
for D3DFB's 2D mode. Before, any fullscreen graphics (like help images)
covered it up.
SVN r640 (trunk)
2007-12-26 04:42:15 +00:00
|
|
|
}
|
- Updated lempar.c to v1.31.
- Added .txt files to the list of types (wad, zip, and pk3) that can be
loaded without listing them after -file.
- Fonts that are created by the ACS setfont command to wrap a texture now
support animated textures.
- FON2 fonts can now use their full palette for CR_UNTRANSLATED when drawn
with the hardware 2D path instead of being restricted to the game palette.
- Fixed: Toggling vid_vsync would reset the displayed fullscreen gamma to 1
on a Radeon 9000.
- Added back the off-by-one palette handling, but in a much more limited
scope than before. The skipped entry is assumed to always be at 248, and
it is assumed that all Shader Model 1.4 cards suffer from this. That's
because all SM1.4 cards are based on variants of the ATI R200 core, and the
RV250 in a Radeon 9000 craps up like this. I see no reason to assume that
other flavors of the R200 are any different. (Interesting note: With the
Radeon 9000, D3DTADDRESS_CLAMP is an invalid address mode when using the
debug Direct3D 9 runtime, but it works perfectly fine with the retail
Direct3D 9 runtime.) (Insight: The R200 probably uses bytes for all its
math inside pixel shaders. That would explain perfectly why I can't use
constants greater than 1 with PS1.4 and why it can't do an exact mapping to
every entry in the color palette.
- Fixed: The software shaded drawer did not work for 2D, because its selected
"color"map was replaced with the identitymap before being used.
- Fixed: I cannot use Printf to output messages before the framebuffer was
completely setup, meaning that Shader Model 1.4 cards could not change
resolution.
- I have decided to let remap palettes specify variable alpha values for
their colors. D3DFB no longer forces them to 255.
- Updated re2c to version 0.12.3.
- Fixed: A_Wander used threshold as a timer, when it should have used
reactiontime.
- Fixed: A_CustomRailgun would not fire at all for actors without a target
when the aim parameter was disabled.
- Made the warp command work in multiplayer, again courtesy of Karate Chris.
- Fixed: Trying to spawn a bot while not in a game made for a crashing time.
(Patch courtesy of Karate Chris.)
- Removed some floating point math from hu_scores.cpp that somebody's GCC
gave warnings for (not mine, though).
- Fixed: The SBarInfo drawbar command crashed if the sprite image was
unavailable.
- Fixed: FString::operator=(const char *) did not release its old buffer when
being assigned to the null string.
- The scanner no longer has an upper limit on the length of strings it
accepts, though short strings will be faster than long ones.
- Moved all the text scanning functions into a class. Mainly, this means that
multiple script scanner states can be stored without being forced to do so
recursively. I think I might be taking advantage of that in the near
future. Possibly. Maybe.
- Removed some potential buffer overflows from the decal parser.
- Applied Blzut3's SBARINFO update #9:
* Fixed: When using even length values in drawnumber it would cap to a 98
value instead of a 99 as intended.
* The SBarInfo parser can now accept negatives for coordinates. This
doesn't allow much right now, but later I plan to add better fullscreen
hud support in which the negatives will be more useful. This also cleans
up the source a bit since all calls for (x, y) coordinates are with the
function getCoordinates().
- Added support for stencilling actors.
- Added support for non-black colors specified with DTA_ColorOverlay to the
software renderer.
- Fixed: The inverse, gold, red, and green fixed colormaps each allocated
space for 32 different colormaps, even though each only used the first one.
- Added two new blending flags to make reverse subtract blending more useful:
STYLEF_InvertSource and STYLEF_InvertOverlay. These invert the color that
gets blended with the background, since that seems like a good idea for
reverse subtraction. They also work with the other two blending operations.
- Added subtract and reverse subtract blending operations to the renderer.
Since the ERenderStyle enumeration was getting rather unwieldy, I converted
it into a new FRenderStyle structure that lets each parameter of the
blending equation be set separately. This simplified the set up for the
blend quite a bit, and it means a number of new combinations are available
by setting the parameters properly.
SVN r710 (trunk)
2008-01-25 23:57:44 +00:00
|
|
|
// Note that this overrides DTA_Translation in software, but not in hardware.
|
|
|
|
|
FDynamicColormap *colormap = GetSpecialLights(MAKERGB(255,255,255),
|
|
|
|
|
parms.colorOverlay & MAKEARGB(0,255,255,255), 0);
|
|
|
|
|
parms.translation = &colormap->Maps[(APART(parms.colorOverlay)*NUMCOLORMAPS/255)*256];
|
2007-12-20 04:36:43 +00:00
|
|
|
}
|
|
|
|
|
|
- Updated lempar.c to v1.31.
- Added .txt files to the list of types (wad, zip, and pk3) that can be
loaded without listing them after -file.
- Fonts that are created by the ACS setfont command to wrap a texture now
support animated textures.
- FON2 fonts can now use their full palette for CR_UNTRANSLATED when drawn
with the hardware 2D path instead of being restricted to the game palette.
- Fixed: Toggling vid_vsync would reset the displayed fullscreen gamma to 1
on a Radeon 9000.
- Added back the off-by-one palette handling, but in a much more limited
scope than before. The skipped entry is assumed to always be at 248, and
it is assumed that all Shader Model 1.4 cards suffer from this. That's
because all SM1.4 cards are based on variants of the ATI R200 core, and the
RV250 in a Radeon 9000 craps up like this. I see no reason to assume that
other flavors of the R200 are any different. (Interesting note: With the
Radeon 9000, D3DTADDRESS_CLAMP is an invalid address mode when using the
debug Direct3D 9 runtime, but it works perfectly fine with the retail
Direct3D 9 runtime.) (Insight: The R200 probably uses bytes for all its
math inside pixel shaders. That would explain perfectly why I can't use
constants greater than 1 with PS1.4 and why it can't do an exact mapping to
every entry in the color palette.
- Fixed: The software shaded drawer did not work for 2D, because its selected
"color"map was replaced with the identitymap before being used.
- Fixed: I cannot use Printf to output messages before the framebuffer was
completely setup, meaning that Shader Model 1.4 cards could not change
resolution.
- I have decided to let remap palettes specify variable alpha values for
their colors. D3DFB no longer forces them to 255.
- Updated re2c to version 0.12.3.
- Fixed: A_Wander used threshold as a timer, when it should have used
reactiontime.
- Fixed: A_CustomRailgun would not fire at all for actors without a target
when the aim parameter was disabled.
- Made the warp command work in multiplayer, again courtesy of Karate Chris.
- Fixed: Trying to spawn a bot while not in a game made for a crashing time.
(Patch courtesy of Karate Chris.)
- Removed some floating point math from hu_scores.cpp that somebody's GCC
gave warnings for (not mine, though).
- Fixed: The SBarInfo drawbar command crashed if the sprite image was
unavailable.
- Fixed: FString::operator=(const char *) did not release its old buffer when
being assigned to the null string.
- The scanner no longer has an upper limit on the length of strings it
accepts, though short strings will be faster than long ones.
- Moved all the text scanning functions into a class. Mainly, this means that
multiple script scanner states can be stored without being forced to do so
recursively. I think I might be taking advantage of that in the near
future. Possibly. Maybe.
- Removed some potential buffer overflows from the decal parser.
- Applied Blzut3's SBARINFO update #9:
* Fixed: When using even length values in drawnumber it would cap to a 98
value instead of a 99 as intended.
* The SBarInfo parser can now accept negatives for coordinates. This
doesn't allow much right now, but later I plan to add better fullscreen
hud support in which the negatives will be more useful. This also cleans
up the source a bit since all calls for (x, y) coordinates are with the
function getCoordinates().
- Added support for stencilling actors.
- Added support for non-black colors specified with DTA_ColorOverlay to the
software renderer.
- Fixed: The inverse, gold, red, and green fixed colormaps each allocated
space for 32 different colormaps, even though each only used the first one.
- Added two new blending flags to make reverse subtract blending more useful:
STYLEF_InvertSource and STYLEF_InvertOverlay. These invert the color that
gets blended with the background, since that seems like a good idea for
reverse subtraction. They also work with the other two blending operations.
- Added subtract and reverse subtract blending operations to the renderer.
Since the ERenderStyle enumeration was getting rather unwieldy, I converted
it into a new FRenderStyle structure that lets each parameter of the
blending equation be set separately. This simplified the set up for the
blend quite a bit, and it means a number of new combinations are available
by setting the parameters properly.
SVN r710 (trunk)
2008-01-25 23:57:44 +00:00
|
|
|
if (parms.translation != NULL)
|
|
|
|
|
{
|
|
|
|
|
dc_colormap = (lighttable_t *)parms.translation;
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
dc_colormap = identitymap;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
fixedcolormap = dc_colormap;
|
|
|
|
|
ESPSResult mode = R_SetPatchStyle (parms.style, parms.alpha, 0, parms.fillcolor);
|
|
|
|
|
|
2007-12-20 04:36:43 +00:00
|
|
|
BYTE *destorgsave = dc_destorg;
|
|
|
|
|
dc_destorg = screen->GetBuffer();
|
|
|
|
|
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
double x0 = parms.x - parms.left * parms.destwidth / parms.texwidth;
|
|
|
|
|
double y0 = parms.y - parms.top * parms.destheight / parms.texheight;
|
2007-12-20 04:36:43 +00:00
|
|
|
|
|
|
|
|
if (mode != DontDraw)
|
|
|
|
|
{
|
|
|
|
|
const BYTE *pixels;
|
|
|
|
|
int stop4;
|
|
|
|
|
|
|
|
|
|
if (spanptr == NULL)
|
|
|
|
|
{ // Create a single span for forced unmasked images
|
|
|
|
|
spans = unmaskedSpan;
|
|
|
|
|
unmaskedSpan[0].TopOffset = 0;
|
|
|
|
|
unmaskedSpan[0].Length = img->GetHeight();
|
|
|
|
|
unmaskedSpan[1].TopOffset = 0;
|
|
|
|
|
unmaskedSpan[1].Length = 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
fixed_t centeryback = centeryfrac;
|
|
|
|
|
centeryfrac = 0;
|
|
|
|
|
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
sprtopscreen = FLOAT2FIXED(y0);
|
|
|
|
|
// There is not enough precision in the drawing routines to keep the full
|
|
|
|
|
// precision for y0. :(
|
|
|
|
|
sprtopscreen &= ~(FRACUNIT - 1);
|
2007-12-20 04:36:43 +00:00
|
|
|
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
double yscale = parms.destheight / img->GetHeight();
|
|
|
|
|
double iyscale = 1 / yscale;
|
|
|
|
|
|
|
|
|
|
spryscale = FLOAT2FIXED(yscale);
|
2010-08-27 15:20:05 +00:00
|
|
|
assert(spryscale > 2);
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
#if 0
|
2007-12-20 04:36:43 +00:00
|
|
|
// Fix precision errors that are noticeable at some resolutions
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
if ((y0 + parms.destheight) > (y0 + yscale * img->GetHeight()))
|
2007-12-20 04:36:43 +00:00
|
|
|
{
|
|
|
|
|
spryscale++;
|
|
|
|
|
}
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
#endif
|
2007-12-20 04:36:43 +00:00
|
|
|
|
|
|
|
|
sprflipvert = false;
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
//dc_iscale = FLOAT2FIXED(iyscale);
|
|
|
|
|
//dc_texturemid = FLOAT2FIXED((-y0) * iyscale);
|
|
|
|
|
//dc_iscale = 0xffffffffu / (unsigned)spryscale;
|
|
|
|
|
dc_iscale = DivScale32(1, spryscale);
|
|
|
|
|
dc_texturemid = FixedMul(-sprtopscreen, dc_iscale) + FixedMul(centeryfrac-FRACUNIT, dc_iscale);
|
2007-12-20 04:36:43 +00:00
|
|
|
fixed_t frac = 0;
|
2009-11-10 03:40:54 +00:00
|
|
|
double xiscale = img->GetWidth() / parms.destwidth;
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
double x2 = x0 + parms.destwidth;
|
2007-12-20 04:36:43 +00:00
|
|
|
|
|
|
|
|
if (bottomclipper[0] != parms.dclip)
|
|
|
|
|
{
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
clearbufshort(bottomclipper, screen->GetWidth(), (short)parms.dclip);
|
2007-12-20 04:36:43 +00:00
|
|
|
}
|
|
|
|
|
if (parms.uclip != 0)
|
|
|
|
|
{
|
|
|
|
|
if (topclipper[0] != parms.uclip)
|
|
|
|
|
{
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
clearbufshort(topclipper, screen->GetWidth(), (short)parms.uclip);
|
2007-12-20 04:36:43 +00:00
|
|
|
}
|
|
|
|
|
mceilingclip = topclipper;
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
mceilingclip = zeroarray;
|
|
|
|
|
}
|
|
|
|
|
mfloorclip = bottomclipper;
|
|
|
|
|
|
|
|
|
|
if (parms.flipX)
|
|
|
|
|
{
|
|
|
|
|
frac = (img->GetWidth() << FRACBITS) - 1;
|
|
|
|
|
xiscale = -xiscale;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (parms.windowleft > 0 || parms.windowright < parms.texwidth)
|
|
|
|
|
{
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
double xscale = parms.destwidth / parms.texwidth;
|
|
|
|
|
x0 += parms.windowleft * xscale;
|
|
|
|
|
frac += FLOAT2FIXED(parms.windowleft);
|
|
|
|
|
x2 -= (parms.texwidth - parms.windowright) * xscale;
|
2007-12-20 04:36:43 +00:00
|
|
|
}
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
if (x0 < parms.lclip)
|
2007-12-20 04:36:43 +00:00
|
|
|
{
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
frac += FLOAT2FIXED((parms.lclip - x0) * xiscale);
|
|
|
|
|
x0 = parms.lclip;
|
2007-12-20 04:36:43 +00:00
|
|
|
}
|
|
|
|
|
if (x2 > parms.rclip)
|
|
|
|
|
{
|
|
|
|
|
x2 = parms.rclip;
|
|
|
|
|
}
|
|
|
|
|
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
// Drawing short output ought to fit in the data cache well enough
|
|
|
|
|
// if we draw one column at a time, so do that, since it's simpler.
|
|
|
|
|
if (parms.destheight < 32 || (parms.dclip - parms.uclip) < 32)
|
2007-12-20 04:36:43 +00:00
|
|
|
{
|
|
|
|
|
mode = DoDraw0;
|
|
|
|
|
}
|
|
|
|
|
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
dc_x = int(x0);
|
|
|
|
|
int x2_i = int(x2);
|
|
|
|
|
fixed_t xiscale_i = FLOAT2FIXED(xiscale);
|
|
|
|
|
|
2007-12-20 04:36:43 +00:00
|
|
|
if (mode == DoDraw0)
|
|
|
|
|
{
|
|
|
|
|
// One column at a time
|
|
|
|
|
stop4 = dc_x;
|
|
|
|
|
}
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
else // DoDraw1`
|
2007-12-20 04:36:43 +00:00
|
|
|
{
|
|
|
|
|
// Up to four columns at a time
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
stop4 = x2_i & ~3;
|
2007-12-20 04:36:43 +00:00
|
|
|
}
|
|
|
|
|
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
if (dc_x < x2_i)
|
2007-12-20 04:36:43 +00:00
|
|
|
{
|
|
|
|
|
while ((dc_x < stop4) && (dc_x & 3))
|
|
|
|
|
{
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
pixels = img->GetColumn(frac >> FRACBITS, spanptr);
|
|
|
|
|
R_DrawMaskedColumn(pixels, spans);
|
2007-12-20 04:36:43 +00:00
|
|
|
dc_x++;
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
frac += xiscale_i;
|
2007-12-20 04:36:43 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
while (dc_x < stop4)
|
|
|
|
|
{
|
|
|
|
|
rt_initcols();
|
|
|
|
|
for (int zz = 4; zz; --zz)
|
|
|
|
|
{
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
pixels = img->GetColumn(frac >> FRACBITS, spanptr);
|
|
|
|
|
R_DrawMaskedColumnHoriz(pixels, spans);
|
2007-12-20 04:36:43 +00:00
|
|
|
dc_x++;
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
frac += xiscale_i;
|
2007-12-20 04:36:43 +00:00
|
|
|
}
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
rt_draw4cols(dc_x - 4);
|
2007-12-20 04:36:43 +00:00
|
|
|
}
|
|
|
|
|
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
while (dc_x < x2_i)
|
2007-12-20 04:36:43 +00:00
|
|
|
{
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
pixels = img->GetColumn(frac >> FRACBITS, spanptr);
|
|
|
|
|
R_DrawMaskedColumn(pixels, spans);
|
2007-12-20 04:36:43 +00:00
|
|
|
dc_x++;
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
frac += xiscale_i;
|
2007-12-20 04:36:43 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
centeryfrac = centeryback;
|
|
|
|
|
}
|
|
|
|
|
R_FinishSetPatchStyle ();
|
|
|
|
|
|
|
|
|
|
dc_destorg = destorgsave;
|
|
|
|
|
|
|
|
|
|
if (ticdup != 0 && menuactive == MENU_Off)
|
|
|
|
|
{
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
NetUpdate();
|
2007-12-20 04:36:43 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
bool DCanvas::ParseDrawTextureTags (FTexture *img, double x, double y, DWORD tag, va_list tags, DrawParms *parms, bool hw) const
|
2007-12-20 04:36:43 +00:00
|
|
|
{
|
2006-09-14 00:02:31 +00:00
|
|
|
INTBOOL boolval;
|
2006-02-24 04:48:15 +00:00
|
|
|
int intval;
|
2007-12-23 14:13:29 +00:00
|
|
|
bool translationset = false;
|
2008-01-08 01:08:27 +00:00
|
|
|
bool virtBottom;
|
2006-02-24 04:48:15 +00:00
|
|
|
|
|
|
|
|
if (img == NULL || img->UseType == FTexture::TEX_Null)
|
|
|
|
|
{
|
2009-04-08 04:47:21 +00:00
|
|
|
va_end(tags);
|
2007-12-20 04:36:43 +00:00
|
|
|
return false;
|
2006-02-24 04:48:15 +00:00
|
|
|
}
|
|
|
|
|
|
2008-06-01 04:09:49 +00:00
|
|
|
// Do some sanity checks on the coordinates.
|
|
|
|
|
if (x < -16383 || x > 16383 || y < -16383 || y > 16383)
|
|
|
|
|
{
|
2009-04-08 04:47:21 +00:00
|
|
|
va_end(tags);
|
2008-06-01 04:09:49 +00:00
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2008-01-08 01:08:27 +00:00
|
|
|
virtBottom = false;
|
|
|
|
|
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
parms->texwidth = img->GetScaledWidthDouble();
|
|
|
|
|
parms->texheight = img->GetScaledHeightDouble();
|
2007-12-20 04:36:43 +00:00
|
|
|
|
|
|
|
|
parms->windowleft = 0;
|
|
|
|
|
parms->windowright = parms->texwidth;
|
|
|
|
|
parms->dclip = this->GetHeight();
|
|
|
|
|
parms->uclip = 0;
|
|
|
|
|
parms->lclip = 0;
|
|
|
|
|
parms->rclip = this->GetWidth();
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
parms->destwidth = parms->windowright;
|
|
|
|
|
parms->destheight = parms->texheight;
|
2007-12-20 04:36:43 +00:00
|
|
|
parms->top = img->GetScaledTopOffset();
|
|
|
|
|
parms->left = img->GetScaledLeftOffset();
|
|
|
|
|
parms->alpha = FRACUNIT;
|
|
|
|
|
parms->fillcolor = -1;
|
- Discovered that Shader Model 1.4 clamps my constants, so I can't use
palettes smaller than 256 entries with the shader I wrote for it. Is there
a list of gotchas like this listed some where? I'd really like to see it.
Well, when compiled with SM2.0, the PalTex shader seems to be every-so-
slightly faster on my GF7950GT than the SM1.4 version, so I guess it's a
minor win for cards that support it.
- Fixed: ST_Endoom() failed to free the bitmap it used.
- Added the DTA_ColorOverlay attribute to blend a color with the texture
being drawn. For software, this (currently) only works with black. For
hardware, it works with any color. The motiviation for this was so I could
rewrite the status bar calls that passed DIM_MAP to DTA_Translation to
draw darker icons into something that didn't require making a whole new
remap table.
- After having an "OMG! How could I have been so stupid?" moment, I have
removed the off-by-one check from D3DFB. I had thought the off-by-one error
was caused by rounding errors by the shader hardware. Not so. Rather, I
wasn't sampling what I thought I was sampling. A texture that uses palette
index 255 passes the value 1.0 to the shader. The shader needs to adjust the
range of its palette indexes, or it will end up trying to read color 256
from the palette texture when it should be reading color 255. Doh!
- The TranslationToTable() function has been added to map from translation
numbers used by actors to the tables those numbers represent. This function
performs validation for the input and returns NULL if the input value
is invalid.
- Major changes to the way translation tables work: No longer are they each a
256-byte array. Instead, the FRemapTable structure is used to represent each
one. It includes a remap array for the software renderer, a palette array
for a hardware renderer, and a native texture pointer for D3DFB. The
translationtables array itself is now an array of TArrays that point to the
real tables. The DTA_Translation attribute must also be passed a pointer
to a FRemapTable, not a byte array as previously.
- Modified DFrameBuffer::DrawRateStuff() so that it can do its thing properly
for D3DFB's 2D mode. Before, any fullscreen graphics (like help images)
covered it up.
SVN r640 (trunk)
2007-12-26 04:42:15 +00:00
|
|
|
parms->remap = NULL;
|
|
|
|
|
parms->translation = NULL;
|
|
|
|
|
parms->colorOverlay = 0;
|
2007-12-20 04:36:43 +00:00
|
|
|
parms->alphaChannel = false;
|
|
|
|
|
parms->flipX = false;
|
|
|
|
|
parms->shadowAlpha = 0;
|
|
|
|
|
parms->shadowColor = 0;
|
|
|
|
|
parms->virtWidth = this->GetWidth();
|
|
|
|
|
parms->virtHeight = this->GetHeight();
|
|
|
|
|
parms->keepratio = false;
|
- Updated lempar.c to v1.31.
- Added .txt files to the list of types (wad, zip, and pk3) that can be
loaded without listing them after -file.
- Fonts that are created by the ACS setfont command to wrap a texture now
support animated textures.
- FON2 fonts can now use their full palette for CR_UNTRANSLATED when drawn
with the hardware 2D path instead of being restricted to the game palette.
- Fixed: Toggling vid_vsync would reset the displayed fullscreen gamma to 1
on a Radeon 9000.
- Added back the off-by-one palette handling, but in a much more limited
scope than before. The skipped entry is assumed to always be at 248, and
it is assumed that all Shader Model 1.4 cards suffer from this. That's
because all SM1.4 cards are based on variants of the ATI R200 core, and the
RV250 in a Radeon 9000 craps up like this. I see no reason to assume that
other flavors of the R200 are any different. (Interesting note: With the
Radeon 9000, D3DTADDRESS_CLAMP is an invalid address mode when using the
debug Direct3D 9 runtime, but it works perfectly fine with the retail
Direct3D 9 runtime.) (Insight: The R200 probably uses bytes for all its
math inside pixel shaders. That would explain perfectly why I can't use
constants greater than 1 with PS1.4 and why it can't do an exact mapping to
every entry in the color palette.
- Fixed: The software shaded drawer did not work for 2D, because its selected
"color"map was replaced with the identitymap before being used.
- Fixed: I cannot use Printf to output messages before the framebuffer was
completely setup, meaning that Shader Model 1.4 cards could not change
resolution.
- I have decided to let remap palettes specify variable alpha values for
their colors. D3DFB no longer forces them to 255.
- Updated re2c to version 0.12.3.
- Fixed: A_Wander used threshold as a timer, when it should have used
reactiontime.
- Fixed: A_CustomRailgun would not fire at all for actors without a target
when the aim parameter was disabled.
- Made the warp command work in multiplayer, again courtesy of Karate Chris.
- Fixed: Trying to spawn a bot while not in a game made for a crashing time.
(Patch courtesy of Karate Chris.)
- Removed some floating point math from hu_scores.cpp that somebody's GCC
gave warnings for (not mine, though).
- Fixed: The SBarInfo drawbar command crashed if the sprite image was
unavailable.
- Fixed: FString::operator=(const char *) did not release its old buffer when
being assigned to the null string.
- The scanner no longer has an upper limit on the length of strings it
accepts, though short strings will be faster than long ones.
- Moved all the text scanning functions into a class. Mainly, this means that
multiple script scanner states can be stored without being forced to do so
recursively. I think I might be taking advantage of that in the near
future. Possibly. Maybe.
- Removed some potential buffer overflows from the decal parser.
- Applied Blzut3's SBARINFO update #9:
* Fixed: When using even length values in drawnumber it would cap to a 98
value instead of a 99 as intended.
* The SBarInfo parser can now accept negatives for coordinates. This
doesn't allow much right now, but later I plan to add better fullscreen
hud support in which the negatives will be more useful. This also cleans
up the source a bit since all calls for (x, y) coordinates are with the
function getCoordinates().
- Added support for stencilling actors.
- Added support for non-black colors specified with DTA_ColorOverlay to the
software renderer.
- Fixed: The inverse, gold, red, and green fixed colormaps each allocated
space for 32 different colormaps, even though each only used the first one.
- Added two new blending flags to make reverse subtract blending more useful:
STYLEF_InvertSource and STYLEF_InvertOverlay. These invert the color that
gets blended with the background, since that seems like a good idea for
reverse subtraction. They also work with the other two blending operations.
- Added subtract and reverse subtract blending operations to the renderer.
Since the ERenderStyle enumeration was getting rather unwieldy, I converted
it into a new FRenderStyle structure that lets each parameter of the
blending equation be set separately. This simplified the set up for the
blend quite a bit, and it means a number of new combinations are available
by setting the parameters properly.
SVN r710 (trunk)
2008-01-25 23:57:44 +00:00
|
|
|
parms->style.BlendOp = 255; // Dummy "not set" value
|
2007-12-20 04:36:43 +00:00
|
|
|
parms->masked = true;
|
- Tried adding bilinear filtering support for paletted textures, but the
shader seems to be producing crappy output, so it's disabled for now.
Specifically, it produces distorted output at regular intervals for
textures that aren't power-of-2-sized, and it's still doing visible
filtering when the texture is rendered at its original size, so
obviously it's not doing something right.
- Fixed the use of power-of-2-sized native textures for smaller game
textures again.
- Fixed: D3DFB did not restore all the state it needed to after resetting
the device.
- Fixed: R_DrawTopBorder() must clip itself around the 3D view, since it's
now drawn later.
- With full software rendering, palette flashes once again effect the whole
screen.
Changes I neglected to put in the previous commit log:
- Moved the view border drawing into the 2D mode part. When using Begin2D()
now, the only part of the software buffer that gets updated to the screen
is the part with the actual 3D scene and only if you tell it to.
- Fixed a D3D memory leak on every frame in windowed mode and the same thing
for the screen wipes. Note to self: If it's an interface, be sure to
Release it, because it will be AddRef'ed before being returned to you.
- Moved the BlendView() call out of FBaseStatusBar::Draw() so that it can be
applied before copying the 3D scene to the screen underneath the 2D parts.
- Restored the console's darkening level to its old table-based amount.
- Fixed D3DFB::SetColorOverlay()'s incorrect calculations.
- Fixed the D3D screen wipes for letterboxed modes.
SVN r662 (trunk)
2008-01-03 05:39:36 +00:00
|
|
|
parms->bilinear = false;
|
2009-09-20 03:50:05 +00:00
|
|
|
parms->specialcolormap = NULL;
|
|
|
|
|
parms->colormapstyle = NULL;
|
2007-12-20 04:36:43 +00:00
|
|
|
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
parms->x = x;
|
|
|
|
|
parms->y = y;
|
2006-02-24 04:48:15 +00:00
|
|
|
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
// Parse the tag list for attributes. (For floating point attributes,
|
|
|
|
|
// consider that the C ABI dictates that all floats be promoted to
|
|
|
|
|
// doubles when passed as function arguments.)
|
2006-02-24 04:48:15 +00:00
|
|
|
while (tag != TAG_DONE)
|
|
|
|
|
{
|
2006-05-24 15:31:21 +00:00
|
|
|
va_list *more_p;
|
2006-02-24 04:48:15 +00:00
|
|
|
DWORD data;
|
|
|
|
|
|
|
|
|
|
switch (tag)
|
|
|
|
|
{
|
|
|
|
|
case TAG_IGNORE:
|
|
|
|
|
default:
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
data = va_arg(tags, DWORD);
|
2006-02-24 04:48:15 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case TAG_MORE:
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
more_p = va_arg(tags, va_list *);
|
2006-02-24 04:48:15 +00:00
|
|
|
va_end (tags);
|
2009-04-08 04:47:21 +00:00
|
|
|
#ifndef NO_VA_COPY
|
2009-04-07 07:06:07 +00:00
|
|
|
va_copy (tags, *more_p);
|
2006-05-24 15:31:21 +00:00
|
|
|
#else
|
|
|
|
|
tags = *more_p;
|
|
|
|
|
#endif
|
2006-02-24 04:48:15 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case DTA_DestWidth:
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
parms->destwidth = va_arg(tags, int);
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case DTA_DestWidthF:
|
|
|
|
|
parms->destwidth = va_arg(tags, double);
|
2006-02-24 04:48:15 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case DTA_DestHeight:
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
parms->destheight = va_arg(tags, int);
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case DTA_DestHeightF:
|
|
|
|
|
parms->destheight = va_arg(tags, double);
|
2006-02-24 04:48:15 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case DTA_Clean:
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
boolval = va_arg(tags, INTBOOL);
|
2006-02-24 04:48:15 +00:00
|
|
|
if (boolval)
|
|
|
|
|
{
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
parms->x = (parms->x - 160.0) * CleanXfac + (Width * 0.5);
|
|
|
|
|
parms->y = (parms->y - 100.0) * CleanYfac + (Height * 0.5);
|
|
|
|
|
parms->destwidth = parms->texwidth * CleanXfac;
|
|
|
|
|
parms->destheight = parms->texheight * CleanYfac;
|
2006-02-24 04:48:15 +00:00
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case DTA_CleanNoMove:
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
boolval = va_arg(tags, INTBOOL);
|
2006-02-24 04:48:15 +00:00
|
|
|
if (boolval)
|
|
|
|
|
{
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
parms->destwidth = parms->texwidth * CleanXfac;
|
|
|
|
|
parms->destheight = parms->texheight * CleanYfac;
|
2006-02-24 04:48:15 +00:00
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
|
2009-12-25 05:55:51 +00:00
|
|
|
case DTA_CleanNoMove_1:
|
|
|
|
|
boolval = va_arg(tags, INTBOOL);
|
|
|
|
|
if (boolval)
|
|
|
|
|
{
|
|
|
|
|
parms->destwidth = parms->texwidth * CleanXfac_1;
|
|
|
|
|
parms->destheight = parms->texheight * CleanYfac_1;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
|
2006-02-24 04:48:15 +00:00
|
|
|
case DTA_320x200:
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
boolval = va_arg(tags, INTBOOL);
|
2006-02-24 04:48:15 +00:00
|
|
|
if (boolval)
|
|
|
|
|
{
|
2007-12-20 04:36:43 +00:00
|
|
|
parms->virtWidth = 320;
|
|
|
|
|
parms->virtHeight = 200;
|
2006-02-24 04:48:15 +00:00
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
|
2008-01-08 01:08:27 +00:00
|
|
|
case DTA_Bottom320x200:
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
boolval = va_arg(tags, INTBOOL);
|
2008-01-08 01:08:27 +00:00
|
|
|
if (boolval)
|
|
|
|
|
{
|
|
|
|
|
parms->virtWidth = 320;
|
|
|
|
|
parms->virtHeight = 200;
|
|
|
|
|
}
|
|
|
|
|
virtBottom = true;
|
|
|
|
|
break;
|
|
|
|
|
|
2006-02-24 04:48:15 +00:00
|
|
|
case DTA_HUDRules:
|
|
|
|
|
{
|
2007-12-20 04:36:43 +00:00
|
|
|
bool xright = parms->x < 0;
|
|
|
|
|
bool ybot = parms->y < 0;
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
intval = va_arg(tags, int);
|
2006-02-24 04:48:15 +00:00
|
|
|
|
|
|
|
|
if (hud_scale)
|
|
|
|
|
{
|
2007-12-20 04:36:43 +00:00
|
|
|
parms->x *= CleanXfac;
|
2006-02-24 04:48:15 +00:00
|
|
|
if (intval == HUD_HorizCenter)
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
parms->x += Width * 0.5;
|
2006-02-24 04:48:15 +00:00
|
|
|
else if (xright)
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
parms->x = Width + parms->x;
|
2007-12-20 04:36:43 +00:00
|
|
|
parms->y *= CleanYfac;
|
2006-02-24 04:48:15 +00:00
|
|
|
if (ybot)
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
parms->y = Height + parms->y;
|
|
|
|
|
parms->destwidth = parms->texwidth * CleanXfac;
|
|
|
|
|
parms->destheight = parms->texheight * CleanYfac;
|
2006-02-24 04:48:15 +00:00
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
if (intval == HUD_HorizCenter)
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
parms->x += Width * 0.5;
|
2006-02-24 04:48:15 +00:00
|
|
|
else if (xright)
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
parms->x = Width + parms->x;
|
2006-02-24 04:48:15 +00:00
|
|
|
if (ybot)
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
parms->y = Height + parms->y;
|
2006-02-24 04:48:15 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case DTA_VirtualWidth:
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
parms->virtWidth = va_arg(tags, int);
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case DTA_VirtualWidthF:
|
|
|
|
|
parms->virtWidth = va_arg(tags, double);
|
2006-02-24 04:48:15 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case DTA_VirtualHeight:
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
parms->virtHeight = va_arg(tags, int);
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case DTA_VirtualHeightF:
|
|
|
|
|
parms->virtHeight = va_arg(tags, double);
|
2006-02-24 04:48:15 +00:00
|
|
|
break;
|
|
|
|
|
|
2009-11-15 14:33:35 +00:00
|
|
|
case DTA_Fullscreen:
|
|
|
|
|
boolval = va_arg(tags, INTBOOL);
|
|
|
|
|
if (boolval)
|
|
|
|
|
{
|
|
|
|
|
parms->x = parms->y = 0;
|
|
|
|
|
parms->virtWidth = img->GetScaledWidthDouble();
|
|
|
|
|
parms->virtHeight = img->GetScaledHeightDouble();
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
|
2006-02-24 04:48:15 +00:00
|
|
|
case DTA_Alpha:
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
parms->alpha = MIN<fixed_t>(FRACUNIT, va_arg (tags, fixed_t));
|
2006-02-24 04:48:15 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case DTA_AlphaChannel:
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
parms->alphaChannel = va_arg(tags, INTBOOL);
|
2006-02-24 04:48:15 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case DTA_FillColor:
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
parms->fillcolor = va_arg(tags, uint32);
|
2006-02-24 04:48:15 +00:00
|
|
|
break;
|
|
|
|
|
|
- Discovered that Shader Model 1.4 clamps my constants, so I can't use
palettes smaller than 256 entries with the shader I wrote for it. Is there
a list of gotchas like this listed some where? I'd really like to see it.
Well, when compiled with SM2.0, the PalTex shader seems to be every-so-
slightly faster on my GF7950GT than the SM1.4 version, so I guess it's a
minor win for cards that support it.
- Fixed: ST_Endoom() failed to free the bitmap it used.
- Added the DTA_ColorOverlay attribute to blend a color with the texture
being drawn. For software, this (currently) only works with black. For
hardware, it works with any color. The motiviation for this was so I could
rewrite the status bar calls that passed DIM_MAP to DTA_Translation to
draw darker icons into something that didn't require making a whole new
remap table.
- After having an "OMG! How could I have been so stupid?" moment, I have
removed the off-by-one check from D3DFB. I had thought the off-by-one error
was caused by rounding errors by the shader hardware. Not so. Rather, I
wasn't sampling what I thought I was sampling. A texture that uses palette
index 255 passes the value 1.0 to the shader. The shader needs to adjust the
range of its palette indexes, or it will end up trying to read color 256
from the palette texture when it should be reading color 255. Doh!
- The TranslationToTable() function has been added to map from translation
numbers used by actors to the tables those numbers represent. This function
performs validation for the input and returns NULL if the input value
is invalid.
- Major changes to the way translation tables work: No longer are they each a
256-byte array. Instead, the FRemapTable structure is used to represent each
one. It includes a remap array for the software renderer, a palette array
for a hardware renderer, and a native texture pointer for D3DFB. The
translationtables array itself is now an array of TArrays that point to the
real tables. The DTA_Translation attribute must also be passed a pointer
to a FRemapTable, not a byte array as previously.
- Modified DFrameBuffer::DrawRateStuff() so that it can do its thing properly
for D3DFB's 2D mode. Before, any fullscreen graphics (like help images)
covered it up.
SVN r640 (trunk)
2007-12-26 04:42:15 +00:00
|
|
|
case DTA_Translation:
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
parms->remap = va_arg(tags, FRemapTable *);
|
2010-03-06 03:02:24 +00:00
|
|
|
if (parms->remap != NULL && parms->remap->Inactive)
|
|
|
|
|
{ // If it's inactive, pretend we were passed NULL instead.
|
|
|
|
|
parms->remap = NULL;
|
|
|
|
|
}
|
2007-12-23 14:13:29 +00:00
|
|
|
break;
|
|
|
|
|
|
- Discovered that Shader Model 1.4 clamps my constants, so I can't use
palettes smaller than 256 entries with the shader I wrote for it. Is there
a list of gotchas like this listed some where? I'd really like to see it.
Well, when compiled with SM2.0, the PalTex shader seems to be every-so-
slightly faster on my GF7950GT than the SM1.4 version, so I guess it's a
minor win for cards that support it.
- Fixed: ST_Endoom() failed to free the bitmap it used.
- Added the DTA_ColorOverlay attribute to blend a color with the texture
being drawn. For software, this (currently) only works with black. For
hardware, it works with any color. The motiviation for this was so I could
rewrite the status bar calls that passed DIM_MAP to DTA_Translation to
draw darker icons into something that didn't require making a whole new
remap table.
- After having an "OMG! How could I have been so stupid?" moment, I have
removed the off-by-one check from D3DFB. I had thought the off-by-one error
was caused by rounding errors by the shader hardware. Not so. Rather, I
wasn't sampling what I thought I was sampling. A texture that uses palette
index 255 passes the value 1.0 to the shader. The shader needs to adjust the
range of its palette indexes, or it will end up trying to read color 256
from the palette texture when it should be reading color 255. Doh!
- The TranslationToTable() function has been added to map from translation
numbers used by actors to the tables those numbers represent. This function
performs validation for the input and returns NULL if the input value
is invalid.
- Major changes to the way translation tables work: No longer are they each a
256-byte array. Instead, the FRemapTable structure is used to represent each
one. It includes a remap array for the software renderer, a palette array
for a hardware renderer, and a native texture pointer for D3DFB. The
translationtables array itself is now an array of TArrays that point to the
real tables. The DTA_Translation attribute must also be passed a pointer
to a FRemapTable, not a byte array as previously.
- Modified DFrameBuffer::DrawRateStuff() so that it can do its thing properly
for D3DFB's 2D mode. Before, any fullscreen graphics (like help images)
covered it up.
SVN r640 (trunk)
2007-12-26 04:42:15 +00:00
|
|
|
case DTA_ColorOverlay:
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
parms->colorOverlay = va_arg(tags, DWORD);
|
2006-02-24 04:48:15 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case DTA_FlipX:
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
parms->flipX = va_arg(tags, INTBOOL);
|
2006-02-24 04:48:15 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case DTA_TopOffset:
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
parms->top = va_arg(tags, int);
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case DTA_TopOffsetF:
|
|
|
|
|
parms->top = va_arg(tags, double);
|
2006-02-24 04:48:15 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case DTA_LeftOffset:
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
parms->left = va_arg(tags, int);
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case DTA_LeftOffsetF:
|
|
|
|
|
parms->left = va_arg(tags, double);
|
2006-02-24 04:48:15 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case DTA_CenterOffset:
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
if (va_arg(tags, int))
|
2006-02-24 04:48:15 +00:00
|
|
|
{
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
parms->left = parms->texwidth * 0.5;
|
|
|
|
|
parms->top = parms->texheight * 0.5;
|
2006-02-24 04:48:15 +00:00
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case DTA_CenterBottomOffset:
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
if (va_arg(tags, int))
|
2006-02-24 04:48:15 +00:00
|
|
|
{
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
parms->left = parms->texwidth * 0.5;
|
2007-12-20 04:36:43 +00:00
|
|
|
parms->top = parms->texheight;
|
2006-02-24 04:48:15 +00:00
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case DTA_WindowLeft:
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
parms->windowleft = va_arg(tags, int);
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case DTA_WindowLeftF:
|
|
|
|
|
parms->windowleft = va_arg(tags, double);
|
2006-02-24 04:48:15 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case DTA_WindowRight:
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
parms->windowright = va_arg(tags, int);
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case DTA_WindowRightF:
|
|
|
|
|
parms->windowright = va_arg(tags, double);
|
2006-02-24 04:48:15 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case DTA_ClipTop:
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
parms->uclip = va_arg(tags, int);
|
2007-12-20 04:36:43 +00:00
|
|
|
if (parms->uclip < 0)
|
2006-02-24 04:48:15 +00:00
|
|
|
{
|
2007-12-20 04:36:43 +00:00
|
|
|
parms->uclip = 0;
|
2006-02-24 04:48:15 +00:00
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case DTA_ClipBottom:
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
parms->dclip = va_arg(tags, int);
|
2007-12-20 04:36:43 +00:00
|
|
|
if (parms->dclip > this->GetHeight())
|
2006-02-24 04:48:15 +00:00
|
|
|
{
|
2007-12-20 04:36:43 +00:00
|
|
|
parms->dclip = this->GetHeight();
|
2006-02-24 04:48:15 +00:00
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case DTA_ClipLeft:
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
parms->lclip = va_arg(tags, int);
|
2007-12-20 04:36:43 +00:00
|
|
|
if (parms->lclip < 0)
|
2006-02-24 04:48:15 +00:00
|
|
|
{
|
2007-12-20 04:36:43 +00:00
|
|
|
parms->lclip = 0;
|
2006-02-24 04:48:15 +00:00
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case DTA_ClipRight:
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
parms->rclip = va_arg(tags, int);
|
2007-12-20 04:36:43 +00:00
|
|
|
if (parms->rclip > this->GetWidth())
|
2006-02-24 04:48:15 +00:00
|
|
|
{
|
2007-12-20 04:36:43 +00:00
|
|
|
parms->rclip = this->GetWidth();
|
2006-02-24 04:48:15 +00:00
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case DTA_ShadowAlpha:
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
parms->shadowAlpha = MIN<fixed_t>(FRACUNIT, va_arg (tags, fixed_t));
|
2006-02-24 04:48:15 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case DTA_ShadowColor:
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
parms->shadowColor = va_arg(tags, int);
|
2006-02-24 04:48:15 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case DTA_Shadow:
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
boolval = va_arg(tags, INTBOOL);
|
2006-02-24 04:48:15 +00:00
|
|
|
if (boolval)
|
|
|
|
|
{
|
2007-12-20 04:36:43 +00:00
|
|
|
parms->shadowAlpha = FRACUNIT/2;
|
|
|
|
|
parms->shadowColor = 0;
|
2006-02-24 04:48:15 +00:00
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
2007-12-20 04:36:43 +00:00
|
|
|
parms->shadowAlpha = 0;
|
2006-02-24 04:48:15 +00:00
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case DTA_Masked:
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
parms->masked = va_arg(tags, INTBOOL);
|
2006-02-24 04:48:15 +00:00
|
|
|
break;
|
|
|
|
|
|
- Tried adding bilinear filtering support for paletted textures, but the
shader seems to be producing crappy output, so it's disabled for now.
Specifically, it produces distorted output at regular intervals for
textures that aren't power-of-2-sized, and it's still doing visible
filtering when the texture is rendered at its original size, so
obviously it's not doing something right.
- Fixed the use of power-of-2-sized native textures for smaller game
textures again.
- Fixed: D3DFB did not restore all the state it needed to after resetting
the device.
- Fixed: R_DrawTopBorder() must clip itself around the 3D view, since it's
now drawn later.
- With full software rendering, palette flashes once again effect the whole
screen.
Changes I neglected to put in the previous commit log:
- Moved the view border drawing into the 2D mode part. When using Begin2D()
now, the only part of the software buffer that gets updated to the screen
is the part with the actual 3D scene and only if you tell it to.
- Fixed a D3D memory leak on every frame in windowed mode and the same thing
for the screen wipes. Note to self: If it's an interface, be sure to
Release it, because it will be AddRef'ed before being returned to you.
- Moved the BlendView() call out of FBaseStatusBar::Draw() so that it can be
applied before copying the 3D scene to the screen underneath the 2D parts.
- Restored the console's darkening level to its old table-based amount.
- Fixed D3DFB::SetColorOverlay()'s incorrect calculations.
- Fixed the D3D screen wipes for letterboxed modes.
SVN r662 (trunk)
2008-01-03 05:39:36 +00:00
|
|
|
case DTA_BilinearFilter:
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
parms->bilinear = va_arg(tags, INTBOOL);
|
- Tried adding bilinear filtering support for paletted textures, but the
shader seems to be producing crappy output, so it's disabled for now.
Specifically, it produces distorted output at regular intervals for
textures that aren't power-of-2-sized, and it's still doing visible
filtering when the texture is rendered at its original size, so
obviously it's not doing something right.
- Fixed the use of power-of-2-sized native textures for smaller game
textures again.
- Fixed: D3DFB did not restore all the state it needed to after resetting
the device.
- Fixed: R_DrawTopBorder() must clip itself around the 3D view, since it's
now drawn later.
- With full software rendering, palette flashes once again effect the whole
screen.
Changes I neglected to put in the previous commit log:
- Moved the view border drawing into the 2D mode part. When using Begin2D()
now, the only part of the software buffer that gets updated to the screen
is the part with the actual 3D scene and only if you tell it to.
- Fixed a D3D memory leak on every frame in windowed mode and the same thing
for the screen wipes. Note to self: If it's an interface, be sure to
Release it, because it will be AddRef'ed before being returned to you.
- Moved the BlendView() call out of FBaseStatusBar::Draw() so that it can be
applied before copying the 3D scene to the screen underneath the 2D parts.
- Restored the console's darkening level to its old table-based amount.
- Fixed D3DFB::SetColorOverlay()'s incorrect calculations.
- Fixed the D3D screen wipes for letterboxed modes.
SVN r662 (trunk)
2008-01-03 05:39:36 +00:00
|
|
|
break;
|
|
|
|
|
|
2006-02-24 04:48:15 +00:00
|
|
|
case DTA_KeepRatio:
|
2008-02-05 05:29:31 +00:00
|
|
|
// I think this is a terribly misleading name, since it actually turns
|
|
|
|
|
// *off* aspect ratio correction.
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
parms->keepratio = va_arg(tags, INTBOOL);
|
2006-02-24 04:48:15 +00:00
|
|
|
break;
|
2006-10-20 04:04:04 +00:00
|
|
|
|
|
|
|
|
case DTA_RenderStyle:
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
parms->style.AsDWORD = va_arg(tags, DWORD);
|
2006-10-20 04:04:04 +00:00
|
|
|
break;
|
2009-09-20 03:50:05 +00:00
|
|
|
|
|
|
|
|
case DTA_SpecialColormap:
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
parms->specialcolormap = va_arg(tags, FSpecialColormap *);
|
2009-09-20 03:50:05 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case DTA_ColormapStyle:
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
parms->colormapstyle = va_arg(tags, FColormapStyle *);
|
2009-09-20 03:50:05 +00:00
|
|
|
break;
|
2006-02-24 04:48:15 +00:00
|
|
|
}
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
tag = va_arg(tags, DWORD);
|
2006-02-24 04:48:15 +00:00
|
|
|
}
|
|
|
|
|
va_end (tags);
|
|
|
|
|
|
2008-02-05 05:29:31 +00:00
|
|
|
if (parms->uclip >= parms->dclip || parms->lclip >= parms->rclip)
|
|
|
|
|
{
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2007-12-20 04:36:43 +00:00
|
|
|
if (parms->virtWidth != Width || parms->virtHeight != Height)
|
2006-02-24 04:48:15 +00:00
|
|
|
{
|
2008-02-05 05:29:31 +00:00
|
|
|
VirtualToRealCoords(parms->x, parms->y, parms->destwidth, parms->destheight,
|
|
|
|
|
parms->virtWidth, parms->virtHeight, virtBottom, !parms->keepratio);
|
2006-02-24 04:48:15 +00:00
|
|
|
}
|
|
|
|
|
|
2007-12-20 04:36:43 +00:00
|
|
|
if (parms->destwidth <= 0 || parms->destheight <= 0)
|
2006-02-24 04:48:15 +00:00
|
|
|
{
|
2007-12-20 04:36:43 +00:00
|
|
|
return false;
|
2006-02-24 04:48:15 +00:00
|
|
|
}
|
|
|
|
|
|
- Discovered that Shader Model 1.4 clamps my constants, so I can't use
palettes smaller than 256 entries with the shader I wrote for it. Is there
a list of gotchas like this listed some where? I'd really like to see it.
Well, when compiled with SM2.0, the PalTex shader seems to be every-so-
slightly faster on my GF7950GT than the SM1.4 version, so I guess it's a
minor win for cards that support it.
- Fixed: ST_Endoom() failed to free the bitmap it used.
- Added the DTA_ColorOverlay attribute to blend a color with the texture
being drawn. For software, this (currently) only works with black. For
hardware, it works with any color. The motiviation for this was so I could
rewrite the status bar calls that passed DIM_MAP to DTA_Translation to
draw darker icons into something that didn't require making a whole new
remap table.
- After having an "OMG! How could I have been so stupid?" moment, I have
removed the off-by-one check from D3DFB. I had thought the off-by-one error
was caused by rounding errors by the shader hardware. Not so. Rather, I
wasn't sampling what I thought I was sampling. A texture that uses palette
index 255 passes the value 1.0 to the shader. The shader needs to adjust the
range of its palette indexes, or it will end up trying to read color 256
from the palette texture when it should be reading color 255. Doh!
- The TranslationToTable() function has been added to map from translation
numbers used by actors to the tables those numbers represent. This function
performs validation for the input and returns NULL if the input value
is invalid.
- Major changes to the way translation tables work: No longer are they each a
256-byte array. Instead, the FRemapTable structure is used to represent each
one. It includes a remap array for the software renderer, a palette array
for a hardware renderer, and a native texture pointer for D3DFB. The
translationtables array itself is now an array of TArrays that point to the
real tables. The DTA_Translation attribute must also be passed a pointer
to a FRemapTable, not a byte array as previously.
- Modified DFrameBuffer::DrawRateStuff() so that it can do its thing properly
for D3DFB's 2D mode. Before, any fullscreen graphics (like help images)
covered it up.
SVN r640 (trunk)
2007-12-26 04:42:15 +00:00
|
|
|
if (parms->remap != NULL)
|
|
|
|
|
{
|
|
|
|
|
parms->translation = parms->remap->Remap;
|
|
|
|
|
}
|
|
|
|
|
|
- Updated lempar.c to v1.31.
- Added .txt files to the list of types (wad, zip, and pk3) that can be
loaded without listing them after -file.
- Fonts that are created by the ACS setfont command to wrap a texture now
support animated textures.
- FON2 fonts can now use their full palette for CR_UNTRANSLATED when drawn
with the hardware 2D path instead of being restricted to the game palette.
- Fixed: Toggling vid_vsync would reset the displayed fullscreen gamma to 1
on a Radeon 9000.
- Added back the off-by-one palette handling, but in a much more limited
scope than before. The skipped entry is assumed to always be at 248, and
it is assumed that all Shader Model 1.4 cards suffer from this. That's
because all SM1.4 cards are based on variants of the ATI R200 core, and the
RV250 in a Radeon 9000 craps up like this. I see no reason to assume that
other flavors of the R200 are any different. (Interesting note: With the
Radeon 9000, D3DTADDRESS_CLAMP is an invalid address mode when using the
debug Direct3D 9 runtime, but it works perfectly fine with the retail
Direct3D 9 runtime.) (Insight: The R200 probably uses bytes for all its
math inside pixel shaders. That would explain perfectly why I can't use
constants greater than 1 with PS1.4 and why it can't do an exact mapping to
every entry in the color palette.
- Fixed: The software shaded drawer did not work for 2D, because its selected
"color"map was replaced with the identitymap before being used.
- Fixed: I cannot use Printf to output messages before the framebuffer was
completely setup, meaning that Shader Model 1.4 cards could not change
resolution.
- I have decided to let remap palettes specify variable alpha values for
their colors. D3DFB no longer forces them to 255.
- Updated re2c to version 0.12.3.
- Fixed: A_Wander used threshold as a timer, when it should have used
reactiontime.
- Fixed: A_CustomRailgun would not fire at all for actors without a target
when the aim parameter was disabled.
- Made the warp command work in multiplayer, again courtesy of Karate Chris.
- Fixed: Trying to spawn a bot while not in a game made for a crashing time.
(Patch courtesy of Karate Chris.)
- Removed some floating point math from hu_scores.cpp that somebody's GCC
gave warnings for (not mine, though).
- Fixed: The SBarInfo drawbar command crashed if the sprite image was
unavailable.
- Fixed: FString::operator=(const char *) did not release its old buffer when
being assigned to the null string.
- The scanner no longer has an upper limit on the length of strings it
accepts, though short strings will be faster than long ones.
- Moved all the text scanning functions into a class. Mainly, this means that
multiple script scanner states can be stored without being forced to do so
recursively. I think I might be taking advantage of that in the near
future. Possibly. Maybe.
- Removed some potential buffer overflows from the decal parser.
- Applied Blzut3's SBARINFO update #9:
* Fixed: When using even length values in drawnumber it would cap to a 98
value instead of a 99 as intended.
* The SBarInfo parser can now accept negatives for coordinates. This
doesn't allow much right now, but later I plan to add better fullscreen
hud support in which the negatives will be more useful. This also cleans
up the source a bit since all calls for (x, y) coordinates are with the
function getCoordinates().
- Added support for stencilling actors.
- Added support for non-black colors specified with DTA_ColorOverlay to the
software renderer.
- Fixed: The inverse, gold, red, and green fixed colormaps each allocated
space for 32 different colormaps, even though each only used the first one.
- Added two new blending flags to make reverse subtract blending more useful:
STYLEF_InvertSource and STYLEF_InvertOverlay. These invert the color that
gets blended with the background, since that seems like a good idea for
reverse subtraction. They also work with the other two blending operations.
- Added subtract and reverse subtract blending operations to the renderer.
Since the ERenderStyle enumeration was getting rather unwieldy, I converted
it into a new FRenderStyle structure that lets each parameter of the
blending equation be set separately. This simplified the set up for the
blend quite a bit, and it means a number of new combinations are available
by setting the parameters properly.
SVN r710 (trunk)
2008-01-25 23:57:44 +00:00
|
|
|
if (parms->style.BlendOp == 255)
|
2006-02-24 04:48:15 +00:00
|
|
|
{
|
2009-11-08 02:51:22 +00:00
|
|
|
if (parms->fillcolor != ~0u)
|
2006-02-24 04:48:15 +00:00
|
|
|
{
|
2007-12-20 04:36:43 +00:00
|
|
|
if (parms->alphaChannel)
|
2006-10-20 04:04:04 +00:00
|
|
|
{
|
2007-12-20 04:36:43 +00:00
|
|
|
parms->style = STYLE_Shaded;
|
2006-10-20 04:04:04 +00:00
|
|
|
}
|
2007-12-20 04:36:43 +00:00
|
|
|
else if (parms->alpha < FRACUNIT)
|
2006-10-20 04:04:04 +00:00
|
|
|
{
|
2007-12-20 04:36:43 +00:00
|
|
|
parms->style = STYLE_TranslucentStencil;
|
2006-10-20 04:04:04 +00:00
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
2007-12-20 04:36:43 +00:00
|
|
|
parms->style = STYLE_Stencil;
|
2006-02-24 04:48:15 +00:00
|
|
|
}
|
|
|
|
|
}
|
2007-12-20 04:36:43 +00:00
|
|
|
else if (parms->alpha < FRACUNIT)
|
2006-02-24 04:48:15 +00:00
|
|
|
{
|
2007-12-20 04:36:43 +00:00
|
|
|
parms->style = STYLE_Translucent;
|
2006-02-24 04:48:15 +00:00
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
2007-12-20 04:36:43 +00:00
|
|
|
parms->style = STYLE_Normal;
|
2006-02-24 04:48:15 +00:00
|
|
|
}
|
|
|
|
|
}
|
2007-12-20 04:36:43 +00:00
|
|
|
return true;
|
2006-02-24 04:48:15 +00:00
|
|
|
}
|
|
|
|
|
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
void DCanvas::VirtualToRealCoords(double &x, double &y, double &w, double &h,
|
|
|
|
|
double vwidth, double vheight, bool vbottom, bool handleaspect) const
|
2008-02-05 05:29:31 +00:00
|
|
|
{
|
|
|
|
|
int myratio = handleaspect ? CheckRatio (Width, Height) : 0;
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
double right = x + w;
|
|
|
|
|
double bottom = y + h;
|
2008-02-05 05:29:31 +00:00
|
|
|
|
|
|
|
|
if (myratio != 0 && myratio != 4)
|
|
|
|
|
{ // The target surface is either 16:9 or 16:10, so expand the
|
|
|
|
|
// specified virtual size to avoid undesired stretching of the
|
|
|
|
|
// image. Does not handle non-4:3 virtual sizes. I'll worry about
|
|
|
|
|
// those if somebody expresses a desire to use them.
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
x = (x - vwidth * 0.5) * Width * 960 / (vwidth * BaseRatioSizes[myratio][0]) + Width * 0.5;
|
|
|
|
|
w = (right - vwidth * 0.5) * Width * 960 / (vwidth * BaseRatioSizes[myratio][0]) + Width * 0.5 - x;
|
2008-02-05 05:29:31 +00:00
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
x = x * Width / vwidth;
|
|
|
|
|
w = right * Width / vwidth - x;
|
2008-02-05 05:29:31 +00:00
|
|
|
}
|
|
|
|
|
if (myratio == 4)
|
|
|
|
|
{ // The target surface is 5:4
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
y = (y - vheight * 0.5) * Height * 600 / (vheight * BaseRatioSizes[myratio][1]) + Height * 0.5;
|
|
|
|
|
h = (bottom - vheight * 0.5) * Height * 600 / (vheight * BaseRatioSizes[myratio][1]) + Height * 0.5 - y;
|
2008-02-05 05:29:31 +00:00
|
|
|
if (vbottom)
|
|
|
|
|
{
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
y += (Height - Height * BaseRatioSizes[myratio][3] / 48.0) * 0.5;
|
2008-02-05 05:29:31 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
y = y * Height / vheight;
|
|
|
|
|
h = bottom * Height / vheight - y;
|
2008-02-05 05:29:31 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
void DCanvas::VirtualToRealCoordsFixed(fixed_t &x, fixed_t &y, fixed_t &w, fixed_t &h,
|
|
|
|
|
int vwidth, int vheight, bool vbottom, bool handleaspect) const
|
|
|
|
|
{
|
|
|
|
|
double dx, dy, dw, dh;
|
|
|
|
|
|
|
|
|
|
dx = FIXED2FLOAT(x);
|
|
|
|
|
dy = FIXED2FLOAT(y);
|
|
|
|
|
dw = FIXED2FLOAT(w);
|
|
|
|
|
dh = FIXED2FLOAT(h);
|
|
|
|
|
VirtualToRealCoords(dx, dy, dw, dh, vwidth, vheight, vbottom, handleaspect);
|
|
|
|
|
x = FLOAT2FIXED(dx);
|
|
|
|
|
y = FLOAT2FIXED(dy);
|
|
|
|
|
w = FLOAT2FIXED(dw);
|
|
|
|
|
h = FLOAT2FIXED(dh);
|
|
|
|
|
}
|
|
|
|
|
|
2008-02-05 05:29:31 +00:00
|
|
|
void DCanvas::VirtualToRealCoordsInt(int &x, int &y, int &w, int &h,
|
|
|
|
|
int vwidth, int vheight, bool vbottom, bool handleaspect) const
|
|
|
|
|
{
|
- Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
|
|
|
double dx, dy, dw, dh;
|
|
|
|
|
|
|
|
|
|
dx = x;
|
|
|
|
|
dy = y;
|
|
|
|
|
dw = w;
|
|
|
|
|
dh = h;
|
|
|
|
|
VirtualToRealCoords(dx, dy, dw, dh, vwidth, vheight, vbottom, handleaspect);
|
|
|
|
|
x = int(dx + 0.5);
|
|
|
|
|
y = int(dy + 0.5);
|
|
|
|
|
w = int(dx + dw + 0.5) - x;
|
|
|
|
|
h = int(dy + dh + 0.5) - y;
|
2008-02-05 05:29:31 +00:00
|
|
|
}
|
|
|
|
|
|
2006-02-24 04:48:15 +00:00
|
|
|
void DCanvas::FillBorder (FTexture *img)
|
|
|
|
|
{
|
|
|
|
|
int myratio = CheckRatio (Width, Height);
|
|
|
|
|
if (myratio == 0)
|
|
|
|
|
{ // This is a 4:3 display, so no border to show
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
int bordtop, bordbottom, bordleft, bordright, bord;
|
|
|
|
|
if (myratio & 4)
|
|
|
|
|
{ // Screen is taller than it is wide
|
|
|
|
|
bordleft = bordright = 0;
|
|
|
|
|
bord = Height - Height * BaseRatioSizes[myratio][3] / 48;
|
|
|
|
|
bordtop = bord / 2;
|
|
|
|
|
bordbottom = bord - bordtop;
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{ // Screen is wider than it is tall
|
|
|
|
|
bordtop = bordbottom = 0;
|
|
|
|
|
bord = Width - Width * BaseRatioSizes[myratio][3] / 48;
|
|
|
|
|
bordleft = bord / 2;
|
|
|
|
|
bordright = bord - bordleft;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (img != NULL)
|
|
|
|
|
{
|
|
|
|
|
FlatFill (0, 0, Width, bordtop, img); // Top
|
|
|
|
|
FlatFill (0, bordtop, bordleft, Height - bordbottom, img); // Left
|
|
|
|
|
FlatFill (Width - bordright, bordtop, Width, Height - bordbottom, img); // Right
|
|
|
|
|
FlatFill (0, Height - bordbottom, Width, Height, img); // Bottom
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
2007-12-22 04:52:51 +00:00
|
|
|
Clear (0, 0, Width, bordtop, 0, 0); // Top
|
|
|
|
|
Clear (0, bordtop, bordleft, Height - bordbottom, 0, 0); // Left
|
|
|
|
|
Clear (Width - bordright, bordtop, Width, Height - bordbottom, 0, 0); // Right
|
|
|
|
|
Clear (0, Height - bordbottom, Width, Height, 0, 0); // Bottom
|
2006-02-24 04:48:15 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2007-12-24 14:24:24 +00:00
|
|
|
void DCanvas::PUTTRANSDOT (int xx, int yy, int basecolor, int level)
|
|
|
|
|
{
|
|
|
|
|
static int oldyy;
|
|
|
|
|
static int oldyyshifted;
|
|
|
|
|
|
|
|
|
|
#if 0
|
|
|
|
|
if(xx < 32)
|
|
|
|
|
cc += 7-(xx>>2);
|
|
|
|
|
else if(xx > (finit_width - 32))
|
|
|
|
|
cc += 7-((finit_width-xx) >> 2);
|
|
|
|
|
// if(cc==oldcc) //make sure that we don't double fade the corners.
|
|
|
|
|
// {
|
|
|
|
|
if(yy < 32)
|
|
|
|
|
cc += 7-(yy>>2);
|
|
|
|
|
else if(yy > (finit_height - 32))
|
|
|
|
|
cc += 7-((finit_height-yy) >> 2);
|
|
|
|
|
// }
|
|
|
|
|
if(cc > cm && cm != NULL)
|
|
|
|
|
{
|
|
|
|
|
cc = cm;
|
|
|
|
|
}
|
|
|
|
|
else if(cc > oldcc+6) // don't let the color escape from the fade table...
|
|
|
|
|
{
|
|
|
|
|
cc=oldcc+6;
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
if (yy == oldyy+1)
|
|
|
|
|
{
|
|
|
|
|
oldyy++;
|
|
|
|
|
oldyyshifted += GetPitch();
|
|
|
|
|
}
|
|
|
|
|
else if (yy == oldyy-1)
|
|
|
|
|
{
|
|
|
|
|
oldyy--;
|
|
|
|
|
oldyyshifted -= GetPitch();
|
|
|
|
|
}
|
|
|
|
|
else if (yy != oldyy)
|
|
|
|
|
{
|
|
|
|
|
oldyy = yy;
|
|
|
|
|
oldyyshifted = yy * GetPitch();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
BYTE *spot = GetBuffer() + oldyyshifted + xx;
|
|
|
|
|
DWORD *bg2rgb = Col2RGB8[1+level];
|
|
|
|
|
DWORD *fg2rgb = Col2RGB8[63-level];
|
|
|
|
|
DWORD fg = fg2rgb[basecolor];
|
|
|
|
|
DWORD bg = bg2rgb[*spot];
|
|
|
|
|
bg = (fg+bg) | 0x1f07c1f;
|
|
|
|
|
*spot = RGB32k[0][0][bg&(bg>>15)];
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void DCanvas::DrawLine(int x0, int y0, int x1, int y1, int palColor, uint32 realcolor)
|
|
|
|
|
//void DrawTransWuLine (int x0, int y0, int x1, int y1, BYTE palColor)
|
|
|
|
|
{
|
|
|
|
|
const int WeightingScale = 0;
|
|
|
|
|
const int WEIGHTBITS = 6;
|
|
|
|
|
const int WEIGHTSHIFT = 16-WEIGHTBITS;
|
|
|
|
|
const int NUMWEIGHTS = (1<<WEIGHTBITS);
|
|
|
|
|
const int WEIGHTMASK = (NUMWEIGHTS-1);
|
|
|
|
|
|
|
|
|
|
if (palColor < 0)
|
|
|
|
|
{
|
2008-04-11 04:59:23 +00:00
|
|
|
palColor = PalFromRGB(realcolor);
|
2007-12-24 14:24:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Lock();
|
|
|
|
|
int deltaX, deltaY, xDir;
|
|
|
|
|
|
|
|
|
|
if (y0 > y1)
|
|
|
|
|
{
|
|
|
|
|
int temp = y0; y0 = y1; y1 = temp;
|
|
|
|
|
temp = x0; x0 = x1; x1 = temp;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
PUTTRANSDOT (x0, y0, palColor, 0);
|
|
|
|
|
|
|
|
|
|
if ((deltaX = x1 - x0) >= 0)
|
|
|
|
|
{
|
|
|
|
|
xDir = 1;
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
xDir = -1;
|
|
|
|
|
deltaX = -deltaX;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if ((deltaY = y1 - y0) == 0)
|
|
|
|
|
{ // horizontal line
|
|
|
|
|
if (x0 > x1)
|
|
|
|
|
{
|
2010-07-23 21:19:59 +00:00
|
|
|
swapvalues (x0, x1);
|
2007-12-24 14:24:24 +00:00
|
|
|
}
|
|
|
|
|
memset (GetBuffer() + y0*GetPitch() + x0, palColor, deltaX+1);
|
|
|
|
|
}
|
|
|
|
|
else if (deltaX == 0)
|
|
|
|
|
{ // vertical line
|
|
|
|
|
BYTE *spot = GetBuffer() + y0*GetPitch() + x0;
|
|
|
|
|
int pitch = GetPitch ();
|
|
|
|
|
do
|
|
|
|
|
{
|
|
|
|
|
*spot = palColor;
|
|
|
|
|
spot += pitch;
|
|
|
|
|
} while (--deltaY != 0);
|
|
|
|
|
}
|
|
|
|
|
else if (deltaX == deltaY)
|
|
|
|
|
{ // diagonal line.
|
|
|
|
|
BYTE *spot = GetBuffer() + y0*GetPitch() + x0;
|
|
|
|
|
int advance = GetPitch() + xDir;
|
|
|
|
|
do
|
|
|
|
|
{
|
|
|
|
|
*spot = palColor;
|
|
|
|
|
spot += advance;
|
|
|
|
|
} while (--deltaY != 0);
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
// line is not horizontal, diagonal, or vertical
|
|
|
|
|
fixed_t errorAcc = 0;
|
|
|
|
|
|
|
|
|
|
if (deltaY > deltaX)
|
|
|
|
|
{ // y-major line
|
|
|
|
|
fixed_t errorAdj = (((unsigned)deltaX << 16) / (unsigned)deltaY) & 0xffff;
|
|
|
|
|
if (xDir < 0)
|
|
|
|
|
{
|
|
|
|
|
if (WeightingScale == 0)
|
|
|
|
|
{
|
|
|
|
|
while (--deltaY)
|
|
|
|
|
{
|
|
|
|
|
errorAcc += errorAdj;
|
|
|
|
|
y0++;
|
|
|
|
|
int weighting = (errorAcc >> WEIGHTSHIFT) & WEIGHTMASK;
|
|
|
|
|
PUTTRANSDOT (x0 - (errorAcc >> 16), y0, palColor, weighting);
|
|
|
|
|
PUTTRANSDOT (x0 - (errorAcc >> 16) - 1, y0,
|
|
|
|
|
palColor, WEIGHTMASK - weighting);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
while (--deltaY)
|
|
|
|
|
{
|
|
|
|
|
errorAcc += errorAdj;
|
|
|
|
|
y0++;
|
|
|
|
|
int weighting = ((errorAcc * WeightingScale) >> (WEIGHTSHIFT+8)) & WEIGHTMASK;
|
|
|
|
|
PUTTRANSDOT (x0 - (errorAcc >> 16), y0, palColor, weighting);
|
|
|
|
|
PUTTRANSDOT (x0 - (errorAcc >> 16) - 1, y0,
|
|
|
|
|
palColor, WEIGHTMASK - weighting);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
if (WeightingScale == 0)
|
|
|
|
|
{
|
|
|
|
|
while (--deltaY)
|
|
|
|
|
{
|
|
|
|
|
errorAcc += errorAdj;
|
|
|
|
|
y0++;
|
|
|
|
|
int weighting = (errorAcc >> WEIGHTSHIFT) & WEIGHTMASK;
|
|
|
|
|
PUTTRANSDOT (x0 + (errorAcc >> 16), y0, palColor, weighting);
|
|
|
|
|
PUTTRANSDOT (x0 + (errorAcc >> 16) + xDir, y0,
|
|
|
|
|
palColor, WEIGHTMASK - weighting);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
while (--deltaY)
|
|
|
|
|
{
|
|
|
|
|
errorAcc += errorAdj;
|
|
|
|
|
y0++;
|
|
|
|
|
int weighting = ((errorAcc * WeightingScale) >> (WEIGHTSHIFT+8)) & WEIGHTMASK;
|
|
|
|
|
PUTTRANSDOT (x0 + (errorAcc >> 16), y0, palColor, weighting);
|
|
|
|
|
PUTTRANSDOT (x0 + (errorAcc >> 16) + xDir, y0,
|
|
|
|
|
palColor, WEIGHTMASK - weighting);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{ // x-major line
|
|
|
|
|
fixed_t errorAdj = (((DWORD) deltaY << 16) / (DWORD) deltaX) & 0xffff;
|
|
|
|
|
|
|
|
|
|
if (WeightingScale == 0)
|
|
|
|
|
{
|
|
|
|
|
while (--deltaX)
|
|
|
|
|
{
|
|
|
|
|
errorAcc += errorAdj;
|
|
|
|
|
x0 += xDir;
|
|
|
|
|
int weighting = (errorAcc >> WEIGHTSHIFT) & WEIGHTMASK;
|
|
|
|
|
PUTTRANSDOT (x0, y0 + (errorAcc >> 16), palColor, weighting);
|
|
|
|
|
PUTTRANSDOT (x0, y0 + (errorAcc >> 16) + 1,
|
|
|
|
|
palColor, WEIGHTMASK - weighting);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
while (--deltaX)
|
|
|
|
|
{
|
|
|
|
|
errorAcc += errorAdj;
|
|
|
|
|
x0 += xDir;
|
|
|
|
|
int weighting = ((errorAcc * WeightingScale) >> (WEIGHTSHIFT+8)) & WEIGHTMASK;
|
|
|
|
|
PUTTRANSDOT (x0, y0 + (errorAcc >> 16), palColor, weighting);
|
|
|
|
|
PUTTRANSDOT (x0, y0 + (errorAcc >> 16) + 1,
|
|
|
|
|
palColor, WEIGHTMASK - weighting);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
PUTTRANSDOT (x1, y1, palColor, 0);
|
|
|
|
|
}
|
|
|
|
|
Unlock();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void DCanvas::DrawPixel(int x, int y, int palColor, uint32 realcolor)
|
|
|
|
|
{
|
|
|
|
|
if (palColor < 0)
|
|
|
|
|
{
|
2008-04-11 04:59:23 +00:00
|
|
|
palColor = PalFromRGB(realcolor);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Buffer[Pitch * y + x] = (BYTE)palColor;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
//==========================================================================
|
|
|
|
|
//
|
|
|
|
|
// DCanvas :: Clear
|
|
|
|
|
//
|
|
|
|
|
// Set an area to a specified color.
|
|
|
|
|
//
|
|
|
|
|
//==========================================================================
|
|
|
|
|
|
|
|
|
|
void DCanvas::Clear (int left, int top, int right, int bottom, int palcolor, uint32 color)
|
|
|
|
|
{
|
|
|
|
|
int x, y;
|
|
|
|
|
BYTE *dest;
|
|
|
|
|
|
|
|
|
|
if (left == right || top == bottom)
|
|
|
|
|
{
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
assert(left < right);
|
|
|
|
|
assert(top < bottom);
|
|
|
|
|
|
|
|
|
|
if (palcolor < 0)
|
|
|
|
|
{
|
|
|
|
|
if (APART(color) != 255)
|
2007-12-24 14:24:24 +00:00
|
|
|
{
|
2008-04-11 04:59:23 +00:00
|
|
|
Dim(color, APART(color)/255.f, left, top, right - left, bottom - top);
|
|
|
|
|
return;
|
2007-12-24 14:24:24 +00:00
|
|
|
}
|
2008-04-11 04:59:23 +00:00
|
|
|
|
|
|
|
|
palcolor = PalFromRGB(color);
|
2007-12-24 14:24:24 +00:00
|
|
|
}
|
|
|
|
|
|
2008-04-11 04:59:23 +00:00
|
|
|
dest = Buffer + top * Pitch + left;
|
|
|
|
|
x = right - left;
|
|
|
|
|
for (y = top; y < bottom; y++)
|
|
|
|
|
{
|
|
|
|
|
memset(dest, palcolor, x);
|
|
|
|
|
dest += Pitch;
|
|
|
|
|
}
|
2007-12-24 14:24:24 +00:00
|
|
|
}
|
|
|
|
|
|
2010-08-27 15:20:05 +00:00
|
|
|
//==========================================================================
|
|
|
|
|
//
|
|
|
|
|
// DCanvas :: FillSimplePoly
|
|
|
|
|
//
|
|
|
|
|
// Fills a simple polygon with a texture. Here, "simple" means that a
|
|
|
|
|
// horizontal scanline at any vertical position within the polygon will
|
|
|
|
|
// not cross it more than twice.
|
|
|
|
|
//
|
|
|
|
|
// The originx, originy, scale, and rotation parameters specify
|
|
|
|
|
// transformation of the filling texture, not of the points.
|
|
|
|
|
//
|
|
|
|
|
// The points must be specified in clockwise order.
|
|
|
|
|
//
|
|
|
|
|
//==========================================================================
|
|
|
|
|
|
|
|
|
|
void DCanvas::FillSimplePoly(FTexture *tex, FVector2 *points, int npoints,
|
|
|
|
|
double originx, double originy, double scalex, double scaley, angle_t rotation,
|
|
|
|
|
FDynamicColormap *colormap, int lightlevel)
|
|
|
|
|
{
|
|
|
|
|
// Use an equation similar to player sprites to determine shade
|
|
|
|
|
fixed_t shade = LIGHT2SHADE(lightlevel) - 12*FRACUNIT;
|
|
|
|
|
float topy, boty, leftx, rightx;
|
|
|
|
|
int toppt, botpt, pt1, pt2;
|
|
|
|
|
int i;
|
|
|
|
|
int y1, y2, y;
|
|
|
|
|
fixed_t x;
|
|
|
|
|
double rot = rotation * M_PI / double(1u << 31);
|
|
|
|
|
bool dorotate = rot != 0;
|
|
|
|
|
double cosrot, sinrot;
|
|
|
|
|
|
|
|
|
|
if (--npoints < 2 || Buffer == NULL)
|
|
|
|
|
{ // not a polygon or we're not locked
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Find the extents of the polygon, in particular the highest and lowest points.
|
|
|
|
|
for (botpt = toppt = 0, boty = topy = points[0].Y, leftx = rightx = points[0].X, i = 1; i <= npoints; ++i)
|
|
|
|
|
{
|
|
|
|
|
if (points[i].Y < topy)
|
|
|
|
|
{
|
|
|
|
|
topy = points[i].Y;
|
|
|
|
|
toppt = i;
|
|
|
|
|
}
|
|
|
|
|
if (points[i].Y > boty)
|
|
|
|
|
{
|
|
|
|
|
boty = points[i].Y;
|
|
|
|
|
botpt = i;
|
|
|
|
|
}
|
|
|
|
|
if (points[i].X < leftx)
|
|
|
|
|
{
|
|
|
|
|
leftx = points[i].X;
|
|
|
|
|
}
|
|
|
|
|
if (points[i].X > rightx)
|
|
|
|
|
{
|
|
|
|
|
rightx = points[i].X;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if (topy >= Height || // off the bottom of the screen
|
|
|
|
|
boty <= 0 || // off the top of the screen
|
|
|
|
|
leftx >= Width || // off the right of the screen
|
|
|
|
|
rightx <= 0) // off the left of the screen
|
|
|
|
|
{
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
cosrot = cos(rot);
|
|
|
|
|
sinrot = sin(rot);
|
|
|
|
|
|
|
|
|
|
// Setup constant texture mapping parameters.
|
|
|
|
|
R_SetupSpanBits(tex);
|
|
|
|
|
R_SetSpanColormap(colormap != NULL ? &colormap->Maps[clamp(shade >> FRACBITS, 0, NUMCOLORMAPS-1) * 256] : identitymap);
|
|
|
|
|
R_SetSpanSource(tex->GetPixels());
|
|
|
|
|
scalex = double(1u << (32 - ds_xbits)) / scalex;
|
|
|
|
|
scaley = double(1u << (32 - ds_ybits)) / scaley;
|
|
|
|
|
ds_xstep = xs_RoundToInt(cosrot * scalex);
|
|
|
|
|
ds_ystep = xs_RoundToInt(sinrot * scaley);
|
|
|
|
|
|
|
|
|
|
// Travel down the right edge and create an outline of that edge.
|
|
|
|
|
pt1 = toppt;
|
|
|
|
|
pt2 = toppt + 1; if (pt2 > npoints) pt2 = 0;
|
|
|
|
|
y1 = xs_RoundToInt(points[pt1].Y + 0.5f);
|
|
|
|
|
do
|
|
|
|
|
{
|
|
|
|
|
x = FLOAT2FIXED(points[pt1].X + 0.5f);
|
|
|
|
|
y2 = xs_RoundToInt(points[pt2].Y + 0.5f);
|
|
|
|
|
if (y1 >= y2 || (y1 < 0 && y2 < 0) || (y1 >= Height && y2 >= Height))
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
fixed_t xinc = FLOAT2FIXED((points[pt2].X - points[pt1].X) / (points[pt2].Y - points[pt1].Y));
|
|
|
|
|
int y3 = MIN(y2, Height);
|
|
|
|
|
if (y1 < 0)
|
|
|
|
|
{
|
|
|
|
|
x += xinc * -y1;
|
|
|
|
|
y1 = 0;
|
|
|
|
|
}
|
|
|
|
|
for (y = y1; y < y3; ++y)
|
|
|
|
|
{
|
|
|
|
|
spanend[y] = clamp<short>(x >> FRACBITS, -1, Width);
|
|
|
|
|
x += xinc;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
y1 = y2;
|
|
|
|
|
pt1 = pt2;
|
|
|
|
|
pt2++; if (pt2 > npoints) pt2 = 0;
|
|
|
|
|
} while (pt1 != botpt);
|
|
|
|
|
|
|
|
|
|
// Travel down the left edge and fill it in.
|
|
|
|
|
pt1 = toppt;
|
|
|
|
|
pt2 = toppt - 1; if (pt2 < 0) pt2 = npoints;
|
|
|
|
|
y1 = xs_RoundToInt(points[pt1].Y + 0.5f);
|
|
|
|
|
do
|
|
|
|
|
{
|
|
|
|
|
x = FLOAT2FIXED(points[pt1].X + 0.5f);
|
|
|
|
|
y2 = xs_RoundToInt(points[pt2].Y + 0.5f);
|
|
|
|
|
if (y1 >= y2 || (y1 < 0 && y2 < 0) || (y1 >= Height && y2 >= Height))
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
fixed_t xinc = FLOAT2FIXED((points[pt2].X - points[pt1].X) / (points[pt2].Y - points[pt1].Y));
|
|
|
|
|
int y3 = MIN(y2, Height);
|
|
|
|
|
if (y1 < 0)
|
|
|
|
|
{
|
|
|
|
|
x += xinc * -y1;
|
|
|
|
|
y1 = 0;
|
|
|
|
|
}
|
|
|
|
|
for (y = y1; y < y3; ++y)
|
|
|
|
|
{
|
|
|
|
|
int x1 = x >> FRACBITS;
|
|
|
|
|
int x2 = spanend[y];
|
|
|
|
|
if (x2 > x1 && x2 > 0 && x1 < Width)
|
|
|
|
|
{
|
|
|
|
|
x1 = MAX(x1, 0);
|
|
|
|
|
x2 = MIN(x2, Width);
|
|
|
|
|
#if 0
|
|
|
|
|
memset(this->Buffer + y * this->Pitch + x1, (int)tex, x2 - x1);
|
|
|
|
|
#else
|
|
|
|
|
ds_y = y;
|
|
|
|
|
ds_x1 = x1;
|
|
|
|
|
ds_x2 = x2 - 1;
|
|
|
|
|
|
|
|
|
|
TVector2<double> tex(x1 - originx, y - originy);
|
|
|
|
|
if (dorotate)
|
|
|
|
|
{
|
|
|
|
|
double t = tex.X;
|
|
|
|
|
tex.X = t * cosrot - tex.Y * sinrot;
|
|
|
|
|
tex.Y = tex.Y * cosrot + t * sinrot;
|
|
|
|
|
}
|
|
|
|
|
ds_xfrac = xs_RoundToInt(tex.X * scalex);
|
|
|
|
|
ds_yfrac = xs_RoundToInt(tex.Y * scaley);
|
|
|
|
|
|
|
|
|
|
R_DrawSpan();
|
|
|
|
|
#endif
|
|
|
|
|
}
|
|
|
|
|
x += xinc;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
y1 = y2;
|
|
|
|
|
pt1 = pt2;
|
|
|
|
|
pt2--; if (pt2 < 0) pt2 = npoints;
|
|
|
|
|
} while (pt1 != botpt);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2006-02-24 04:48:15 +00:00
|
|
|
/********************************/
|
|
|
|
|
/* */
|
|
|
|
|
/* Other miscellaneous routines */
|
|
|
|
|
/* */
|
|
|
|
|
/********************************/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
//
|
|
|
|
|
// V_DrawBlock
|
|
|
|
|
// Draw a linear block of pixels into the view buffer.
|
|
|
|
|
//
|
2006-09-14 00:02:31 +00:00
|
|
|
void DCanvas::DrawBlock (int x, int y, int _width, int _height, const BYTE *src) const
|
2006-02-24 04:48:15 +00:00
|
|
|
{
|
|
|
|
|
int srcpitch = _width;
|
|
|
|
|
int destpitch;
|
2006-09-14 00:02:31 +00:00
|
|
|
BYTE *dest;
|
2006-02-24 04:48:15 +00:00
|
|
|
|
|
|
|
|
if (ClipBox (x, y, _width, _height, src, srcpitch))
|
|
|
|
|
{
|
|
|
|
|
return; // Nothing to draw
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
destpitch = Pitch;
|
|
|
|
|
dest = Buffer + y*Pitch + x;
|
|
|
|
|
|
|
|
|
|
do
|
|
|
|
|
{
|
|
|
|
|
memcpy (dest, src, _width);
|
|
|
|
|
src += srcpitch;
|
|
|
|
|
dest += destpitch;
|
|
|
|
|
} while (--_height);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
//
|
|
|
|
|
// V_GetBlock
|
|
|
|
|
// Gets a linear block of pixels from the view buffer.
|
|
|
|
|
//
|
2006-09-14 00:02:31 +00:00
|
|
|
void DCanvas::GetBlock (int x, int y, int _width, int _height, BYTE *dest) const
|
2006-02-24 04:48:15 +00:00
|
|
|
{
|
2006-09-14 00:02:31 +00:00
|
|
|
const BYTE *src;
|
2006-02-24 04:48:15 +00:00
|
|
|
|
|
|
|
|
#ifdef RANGECHECK
|
|
|
|
|
if (x<0
|
|
|
|
|
||x+_width > Width
|
|
|
|
|
|| y<0
|
|
|
|
|
|| y+_height>Height)
|
|
|
|
|
{
|
|
|
|
|
I_Error ("Bad V_GetBlock");
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
src = Buffer + y*Pitch + x;
|
|
|
|
|
|
|
|
|
|
while (_height--)
|
|
|
|
|
{
|
|
|
|
|
memcpy (dest, src, _width);
|
|
|
|
|
src += Pitch;
|
|
|
|
|
dest += _width;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Returns true if the box was completely clipped. False otherwise.
|
2006-09-14 00:02:31 +00:00
|
|
|
bool DCanvas::ClipBox (int &x, int &y, int &w, int &h, const BYTE *&src, const int srcpitch) const
|
2006-02-24 04:48:15 +00:00
|
|
|
{
|
|
|
|
|
if (x >= Width || y >= Height || x+w <= 0 || y+h <= 0)
|
|
|
|
|
{ // Completely clipped off screen
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
if (x < 0) // clip left edge
|
|
|
|
|
{
|
|
|
|
|
src -= x;
|
|
|
|
|
w += x;
|
|
|
|
|
x = 0;
|
|
|
|
|
}
|
|
|
|
|
if (x+w > Width) // clip right edge
|
|
|
|
|
{
|
|
|
|
|
w = Width - x;
|
|
|
|
|
}
|
|
|
|
|
if (y < 0) // clip top edge
|
|
|
|
|
{
|
|
|
|
|
src -= y*srcpitch;
|
|
|
|
|
h += y;
|
|
|
|
|
y = 0;
|
|
|
|
|
}
|
|
|
|
|
if (y+h > Height) // clip bottom edge
|
|
|
|
|
{
|
|
|
|
|
h = Height - y;
|
|
|
|
|
}
|
|
|
|
|
return false;
|
|
|
|
|
}
|
2010-09-14 17:28:18 +00:00
|
|
|
|
|
|
|
|
// Draw a frame around the specified area using the view border
|
|
|
|
|
// frame graphics. The border is drawn outside the area, not in it.
|
|
|
|
|
void V_DrawFrame (int left, int top, int width, int height)
|
|
|
|
|
{
|
|
|
|
|
FTexture *p;
|
|
|
|
|
const gameborder_t *border = gameinfo.border;
|
|
|
|
|
// Sanity check for incomplete gameinfo
|
|
|
|
|
if (border == NULL)
|
|
|
|
|
return;
|
|
|
|
|
int offset = border->offset;
|
|
|
|
|
int right = left + width;
|
|
|
|
|
int bottom = top + height;
|
|
|
|
|
|
|
|
|
|
// Draw top and bottom sides.
|
|
|
|
|
p = TexMan[border->t];
|
|
|
|
|
screen->FlatFill(left, top - p->GetHeight(), right, top, p, true);
|
|
|
|
|
p = TexMan[border->b];
|
|
|
|
|
screen->FlatFill(left, bottom, right, bottom + p->GetHeight(), p, true);
|
|
|
|
|
|
|
|
|
|
// Draw left and right sides.
|
|
|
|
|
p = TexMan[border->l];
|
|
|
|
|
screen->FlatFill(left - p->GetWidth(), top, left, bottom, p, true);
|
|
|
|
|
p = TexMan[border->r];
|
|
|
|
|
screen->FlatFill(right, top, right + p->GetWidth(), bottom, p, true);
|
|
|
|
|
|
|
|
|
|
// Draw beveled corners.
|
|
|
|
|
screen->DrawTexture (TexMan[border->tl], left-offset, top-offset, TAG_DONE);
|
|
|
|
|
screen->DrawTexture (TexMan[border->tr], left+width, top-offset, TAG_DONE);
|
|
|
|
|
screen->DrawTexture (TexMan[border->bl], left-offset, top+height, TAG_DONE);
|
|
|
|
|
screen->DrawTexture (TexMan[border->br], left+width, top+height, TAG_DONE);
|
2011-07-05 20:41:53 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
//==========================================================================
|
|
|
|
|
//
|
|
|
|
|
//
|
|
|
|
|
//
|
|
|
|
|
//==========================================================================
|
|
|
|
|
|
|
|
|
|
void V_DrawBorder (int x1, int y1, int x2, int y2)
|
|
|
|
|
{
|
|
|
|
|
FTextureID picnum;
|
|
|
|
|
|
|
|
|
|
if (level.info != NULL && level.info->bordertexture[0] != 0)
|
|
|
|
|
{
|
|
|
|
|
picnum = TexMan.CheckForTexture (level.info->bordertexture, FTexture::TEX_Flat);
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
picnum = TexMan.CheckForTexture (gameinfo.borderFlat, FTexture::TEX_Flat);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (picnum.isValid())
|
|
|
|
|
{
|
|
|
|
|
screen->FlatFill (x1, y1, x2, y2, TexMan(picnum));
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
screen->Clear (x1, y1, x2, y2, 0, 0);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
//==========================================================================
|
|
|
|
|
//
|
|
|
|
|
// R_DrawViewBorder
|
|
|
|
|
//
|
|
|
|
|
// Draws the border around the view for different size windows
|
|
|
|
|
//
|
|
|
|
|
//==========================================================================
|
|
|
|
|
|
|
|
|
|
int BorderNeedRefresh;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
static void V_DrawViewBorder (void)
|
|
|
|
|
{
|
|
|
|
|
// [RH] Redraw the status bar if SCREENWIDTH > status bar width.
|
|
|
|
|
// Will draw borders around itself, too.
|
|
|
|
|
if (SCREENWIDTH > 320)
|
|
|
|
|
{
|
|
|
|
|
SB_state = screen->GetPageCount ();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (viewwidth == SCREENWIDTH)
|
|
|
|
|
{
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
V_DrawBorder (0, 0, SCREENWIDTH, viewwindowy);
|
|
|
|
|
V_DrawBorder (0, viewwindowy, viewwindowx, viewheight + viewwindowy);
|
|
|
|
|
V_DrawBorder (viewwindowx + viewwidth, viewwindowy, SCREENWIDTH, viewheight + viewwindowy);
|
|
|
|
|
V_DrawBorder (0, viewwindowy + viewheight, SCREENWIDTH, ST_Y);
|
|
|
|
|
|
|
|
|
|
V_DrawFrame (viewwindowx, viewwindowy, viewwidth, viewheight);
|
|
|
|
|
V_MarkRect (0, 0, SCREENWIDTH, ST_Y);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
//==========================================================================
|
|
|
|
|
//
|
|
|
|
|
// R_DrawTopBorder
|
|
|
|
|
//
|
|
|
|
|
// Draws the top border around the view for different size windows
|
|
|
|
|
//
|
|
|
|
|
//==========================================================================
|
|
|
|
|
|
|
|
|
|
static void V_DrawTopBorder ()
|
|
|
|
|
{
|
|
|
|
|
FTexture *p;
|
|
|
|
|
int offset;
|
|
|
|
|
|
|
|
|
|
if (viewwidth == SCREENWIDTH)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
offset = gameinfo.border->offset;
|
|
|
|
|
|
|
|
|
|
if (viewwindowy < 34)
|
|
|
|
|
{
|
|
|
|
|
V_DrawBorder (0, 0, viewwindowx, 34);
|
|
|
|
|
V_DrawBorder (viewwindowx, 0, viewwindowx + viewwidth, viewwindowy);
|
|
|
|
|
V_DrawBorder (viewwindowx + viewwidth, 0, SCREENWIDTH, 34);
|
|
|
|
|
p = TexMan(gameinfo.border->t);
|
|
|
|
|
screen->FlatFill(viewwindowx, viewwindowy - p->GetHeight(),
|
|
|
|
|
viewwindowx + viewwidth, viewwindowy, p, true);
|
|
|
|
|
|
|
|
|
|
p = TexMan(gameinfo.border->l);
|
|
|
|
|
screen->FlatFill(viewwindowx - p->GetWidth(), viewwindowy,
|
|
|
|
|
viewwindowx, 35, p, true);
|
|
|
|
|
p = TexMan(gameinfo.border->r);
|
|
|
|
|
screen->FlatFill(viewwindowx + viewwidth, viewwindowy,
|
|
|
|
|
viewwindowx + viewwidth + p->GetWidth(), 35, p, true);
|
|
|
|
|
|
|
|
|
|
p = TexMan(gameinfo.border->tl);
|
|
|
|
|
screen->DrawTexture (p, viewwindowx - offset, viewwindowy - offset, TAG_DONE);
|
|
|
|
|
|
|
|
|
|
p = TexMan(gameinfo.border->tr);
|
|
|
|
|
screen->DrawTexture (p, viewwindowx + viewwidth, viewwindowy - offset, TAG_DONE);
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
V_DrawBorder (0, 0, SCREENWIDTH, 34);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
//==========================================================================
|
|
|
|
|
//
|
|
|
|
|
// R_RefreshViewBorder
|
|
|
|
|
//
|
|
|
|
|
// Draws the border around the player view, if needed.
|
|
|
|
|
//
|
|
|
|
|
//==========================================================================
|
|
|
|
|
|
|
|
|
|
void V_RefreshViewBorder ()
|
|
|
|
|
{
|
|
|
|
|
if (setblocks < 10)
|
|
|
|
|
{
|
|
|
|
|
if (BorderNeedRefresh)
|
|
|
|
|
{
|
|
|
|
|
BorderNeedRefresh--;
|
|
|
|
|
if (BorderTopRefresh)
|
|
|
|
|
{
|
|
|
|
|
BorderTopRefresh--;
|
|
|
|
|
}
|
|
|
|
|
V_DrawViewBorder();
|
|
|
|
|
}
|
|
|
|
|
else if (BorderTopRefresh)
|
|
|
|
|
{
|
|
|
|
|
BorderTopRefresh--;
|
|
|
|
|
V_DrawTopBorder();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
