zdoom/gzdoom-gles
0
0
Fork 0
mirror of https://github.com/ZDoom/gzdoom-gles.git synced 2024-11-19 10:51:26 +00:00
Code Issues Projects Releases Packages Wiki Activity
gzdoom-gles/src/v_draw.cpp

1184 lines
28 KiB
C++
Raw Normal View History

Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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"
- Changed compilation for g_doom, g_heretic, g_hexen and g_strife folders so that all files are included by a central one instead of compiling each one separately. This speeds up the compilation process by 25% when doing a complete rebuild in Visual C. - Cleaned up more header dependencies. SVN r1226 (trunk)
2008-09-15 14:11:05 +00:00
#include "r_main.h"
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
2006-02-24 04:48:15 +00:00
#include "r_things.h"
- Split off the entire translation code from r_draw.cpp into r_translate.cpp. - Moved the common code of ACS and DECORATE translation generation into the FRemapTable class. - Fixed: The DECORATE translation code was not changed for the new data structures. - Expanded range of ACS and DECORATE translations to 65535. - Fixed: R_CopyTranslation was not altered for the new functionality. I removed the function and replaced the one use with a simple assignment. SVN r644 (trunk)
2007-12-26 16:06:03 +00:00
#include "r_translate.h"
- Cleaned up some include dependencies. SVN r1224 (trunk)
2008-09-14 23:54:38 +00:00
#include "doomstat.h"
- Changed compilation for g_doom, g_heretic, g_hexen and g_strife folders so that all files are included by a central one instead of compiling each one separately. This speeds up the compilation process by 25% when doing a complete rebuild in Visual C. - Cleaned up more header dependencies. SVN r1226 (trunk)
2008-09-15 14:11:05 +00:00
#include "v_palette.h"
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
2006-02-24 04:48:15 +00:00
#include "i_system.h"
#include "i_video.h"
#include "templates.h"
- Cleaned up some include dependencies. SVN r1224 (trunk)
2008-09-14 23:54:38 +00:00
#include "d_net.h"
#include "colormatcher.h"
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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;
- The options menu no longer scales up so quickly, so it can fit wider text onscreen. In addition, it now uses the whole height available to it. Also, at lower resolutions, items on the compatibility options menu now cut off the beginning of the option label rather than the option setting, making this menu useable where previously it was not. SVN r2044 (trunk)
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;
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
2006-02-24 04:48:15 +00:00
CVAR (Bool, hud_scale, false, CVAR_ARCHIVE);
- Changed the MIDIStreamer to send the all notes off controller to each channel when restarting the song, rather than emitting a single note off event which only has a 1 in 127 chance of being for a note that's playing on that channel. Then I decided it would probably be a good idea to reset all the controllers as well. - Increasing the size of the internal Timidity stream buffer from 1/14 sec (copied from the OPL player) improved its sound dramatically, so apparently Timidity has issues with short stream buffers. It's now at 1/2 sec in length. However, there seems to be something weird going on with corazonazul_ff6boss.mid near the beginning where it stops and immediately restarts a guitar on the exact same note. - Added a new sound debugging cvar: snd_drawoutput, which can show various oscilloscopes and spectrums. - Internal TiMidity now plays music. - Changed the progdir global variable into an FString. SVN r900 (trunk)
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;
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, ...)
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
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)
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
2006-02-24 04:48:15 +00:00
{
FTexture::Span unmaskedSpan[2];
const FTexture::Span **spanptr, *spans;
static short bottomclipper[MAXWIDTH], topclipper[MAXWIDTH];
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
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))
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
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)
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
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)
- Changed DTA_Translation parameter for DrawTexture to an integer to avoid passing renderer specific data to the function. Also added DTA_Font so that the renderer can fetch font translations from the proper font. DIM_MAP/ConShade had to be made a regular translation table to make it work. - Added Karate Chris's fix for scoreboard displaying team play related data in non teamplay games. - Fixed: The team selection menu didn't work. - Fixed: UpdateTeam passed an FString to Printf. SVN r623 (trunk)
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;
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
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)
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
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];
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
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);
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
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;
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
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);
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
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);
#if 0
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
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()))
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
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
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
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);
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
2007-12-20 04:36:43 +00:00
fixed_t frac = 0;
- Fixed: Do not use scaled texture width when calculating xiscale. SVN r1968 (trunk)
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;
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
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);
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
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);
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
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;
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
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)
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
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;
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
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)
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
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);
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
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`
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
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;
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
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)
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
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);
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
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;
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
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);
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
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;
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
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);
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
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)
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
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);
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
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;
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
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();
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
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
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
2007-12-20 04:36:43 +00:00
{
- Fixed: cycle_t was still a DWORD and not a QWORD under GCC. - The stat meters now return an FString instead of sprintfing into a fixed output buffer. - NOASM is now automatically defined when compiling for a non-x86 target. - Some changes have been made to the integral types in doomtype.h: - For consistancy with the other integral types, byte is no longer a synonym for BYTE. - Most uses of BOOL have been change to the standard C++ bool type. Those that weren't were changed to INTBOOL to indicate they may contain values other than 0 or 1 but are still used as a boolean. - Compiler-provided types with explicit bit sizes are now used. In particular, DWORD is no longer a long so it will work with both 64-bit Windows and Linux. - Since some files need to include Windows headers, uint32 is a synonym for the non-Windows version of DWORD. - Removed d_textur.h. The pic_t struct it defined was used nowhere, and that was all it contained. SVN r326 (trunk)
2006-09-14 00:02:31 +00:00
INTBOOL boolval;
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
2006-02-24 04:48:15 +00:00
int intval;
- Changed DTA_Translation parameter for DrawTexture to an integer to avoid passing renderer specific data to the function. Also added DTA_Font so that the renderer can fetch font translations from the proper font. DIM_MAP/ConShade had to be made a regular translation table to make it work. - Added Karate Chris's fix for scoreboard displaying team play related data in non teamplay games. - Fixed: The team selection menu didn't work. - Fixed: UpdateTeam passed an FString to Printf. SVN r623 (trunk)
2007-12-23 14:13:29 +00:00
bool translationset = false;
- Fixed: Thing_SetTranslation still used a 16-bit word to hold the translation. - Bumped the maximum resolution up to 2560x1600. - Fixed: DCanvas::DrawTexture() only expanded virtual screen sizes for widescreen resolutions but left 5:4 modes alone. This fix neccessitated the addition of DTA_Bottom320x200 for the status bar to use so that it could be flush with the bottom of the screen rather than sitting slightly above it. - Fixed: FConfigFile::ReadConfig()'s definition of whitespace was too broad. - Fixed: Defining custom translation ranges in descending order and/or with gaps made for crashes. SVN r676 (trunk)
2008-01-08 01:08:27 +00:00
bool virtBottom;
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
2006-02-24 04:48:15 +00:00
if (img == NULL || img->UseType == FTexture::TEX_Null)
{
- Fixed: Not all control paths through DCanvas::ParseDrawTextureTags() called va_end. - Moved the va_copy check out of the non-Win32 part of CMakeLists.txt so that it gets used for MinGW, too. SVN r1527 (trunk)
2009-04-08 04:47:21 +00:00
va_end(tags);
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
2007-12-20 04:36:43 +00:00
return false;
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
2006-02-24 04:48:15 +00:00
}
- Added coordinate range checking to DCanvas::ParseDrawTextureTags() to avoid potential crashes in the situation that con_scaletext is 2 and somebody uses a hud message as if a hud size was specified, but forgot to actually set the hud size. SVN r1010 (trunk)
2008-06-01 04:09:49 +00:00
// Do some sanity checks on the coordinates.
if (x < -16383 || x > 16383 || y < -16383 || y > 16383)
{
- Fixed: Not all control paths through DCanvas::ParseDrawTextureTags() called va_end. - Moved the va_copy check out of the non-Win32 part of CMakeLists.txt so that it gets used for MinGW, too. SVN r1527 (trunk)
2009-04-08 04:47:21 +00:00
va_end(tags);
- Added coordinate range checking to DCanvas::ParseDrawTextureTags() to avoid potential crashes in the situation that con_scaletext is 2 and somebody uses a hud message as if a hud size was specified, but forgot to actually set the hud size. SVN r1010 (trunk)
2008-06-01 04:09:49 +00:00
return false;
}
- Fixed: Thing_SetTranslation still used a 16-bit word to hold the translation. - Bumped the maximum resolution up to 2560x1600. - Fixed: DCanvas::DrawTexture() only expanded virtual screen sizes for widescreen resolutions but left 5:4 modes alone. This fix neccessitated the addition of DTA_Bottom320x200 for the status bar to use so that it could be flush with the bottom of the screen rather than sitting slightly above it. - Fixed: FConfigFile::ReadConfig()'s definition of whitespace was too broad. - Fixed: Defining custom translation ranges in descending order and/or with gaps made for crashes. SVN r676 (trunk)
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();
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
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;
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
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;
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
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
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
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;
- Fixed: Wall drawing handled fixed light levels improperly (but did not completely ignore them, either). - Separated light level fixing out of player_t's fixedcolormap parameter. Using a fixed light level (e.g. PowerTorch) will no longer wipe out colored lighting. - Moved the blending rectangle drawing into a separate discrete stage, since doing it while copying the 3D view window to the display now blends underneath the weapon instead of on top of it. - Consolidated the special colormaps into a single 2D table. - Tweaked the special colormaps slightly to make the true color results more closely match the paletted approximations. - fb_d3d9_shaders.h was getting unwieldy, so I moved the shaders out of the executable and into zdoom.pk3. Shaders are still precompiled so I don't need to pull in a dependancy on D3DX. - Added a few more shaders to accomodate drawing weapons with all the in-game lighting models. These are accessed with the new DrawTexture tags DTA_SpecialColormap and DTA_ColormapStyle. - Player weapon sprites are now drawn using Direct3D and receive all the benefits thereof. SVN r1858 (trunk)
2009-09-20 03:50:05 +00:00
parms->specialcolormap = NULL;
parms->colormapstyle = NULL;
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
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;
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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.)
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
2006-02-24 04:48:15 +00:00
while (tag != TAG_DONE)
{
SVN r142 (trunk)
2006-05-24 15:31:21 +00:00
va_list *more_p;
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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);
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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 *);
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
2006-02-24 04:48:15 +00:00
va_end (tags);
- Fixed: Not all control paths through DCanvas::ParseDrawTextureTags() called va_end. - Moved the va_copy check out of the non-Win32 part of CMakeLists.txt so that it gets used for MinGW, too. SVN r1527 (trunk)
2009-04-08 04:47:21 +00:00
#ifndef NO_VA_COPY
- added some default definitions for constants that may miss in some headers. - replaced __va_copy with va_copy per Chris's suggestion. - replaced #include <malloc.h> with #include <stdlib.h> where possible. SVN r1524 (trunk)
2009-04-07 07:06:07 +00:00
va_copy (tags, *more_p);
SVN r142 (trunk)
2006-05-24 15:31:21 +00:00
#else
tags = *more_p;
#endif
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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);
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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);
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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);
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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;
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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);
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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;
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
2006-02-24 04:48:15 +00:00
}
break;
- The options menu no longer scales up so quickly, so it can fit wider text onscreen. In addition, it now uses the whole height available to it. Also, at lower resolutions, items on the compatibility options menu now cut off the beginning of the option label rather than the option setting, making this menu useable where previously it was not. SVN r2044 (trunk)
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;
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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);
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
2006-02-24 04:48:15 +00:00
if (boolval)
{
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
2007-12-20 04:36:43 +00:00
parms->virtWidth = 320;
parms->virtHeight = 200;
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
2006-02-24 04:48:15 +00:00
}
break;
- Fixed: Thing_SetTranslation still used a 16-bit word to hold the translation. - Bumped the maximum resolution up to 2560x1600. - Fixed: DCanvas::DrawTexture() only expanded virtual screen sizes for widescreen resolutions but left 5:4 modes alone. This fix neccessitated the addition of DTA_Bottom320x200 for the status bar to use so that it could be flush with the bottom of the screen rather than sitting slightly above it. - Fixed: FConfigFile::ReadConfig()'s definition of whitespace was too broad. - Fixed: Defining custom translation ranges in descending order and/or with gaps made for crashes. SVN r676 (trunk)
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);
- Fixed: Thing_SetTranslation still used a 16-bit word to hold the translation. - Bumped the maximum resolution up to 2560x1600. - Fixed: DCanvas::DrawTexture() only expanded virtual screen sizes for widescreen resolutions but left 5:4 modes alone. This fix neccessitated the addition of DTA_Bottom320x200 for the status bar to use so that it could be flush with the bottom of the screen rather than sitting slightly above it. - Fixed: FConfigFile::ReadConfig()'s definition of whitespace was too broad. - Fixed: Defining custom translation ranges in descending order and/or with gaps made for crashes. SVN r676 (trunk)
2008-01-08 01:08:27 +00:00
if (boolval)
{
parms->virtWidth = 320;
parms->virtHeight = 200;
}
virtBottom = true;
break;
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
2006-02-24 04:48:15 +00:00
case DTA_HUDRules:
{
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
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);
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
2006-02-24 04:48:15 +00:00
if (hud_scale)
{
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
2007-12-20 04:36:43 +00:00
parms->x *= CleanXfac;
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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;
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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;
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
2007-12-20 04:36:43 +00:00
parms->y *= CleanYfac;
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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;
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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;
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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;
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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;
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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);
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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);
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
2006-02-24 04:48:15 +00:00
break;
- fixed: fullscreen images with texture scaling used the unscaled size for positioning. To avoid future problems with them I added a new DTA_Fullscreen option for DrawTexture. SVN r1983 (trunk)
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;
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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));
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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);
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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);
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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 *);
- Setting a Player.ColorRange now completely disables the translation rather than just making it an identity map. SVN r2194 (trunk)
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;
}
- Changed DTA_Translation parameter for DrawTexture to an integer to avoid passing renderer specific data to the function. Also added DTA_Font so that the renderer can fetch font translations from the proper font. DIM_MAP/ConShade had to be made a regular translation table to make it work. - Added Karate Chris's fix for scoreboard displaying team play related data in non teamplay games. - Fixed: The team selection menu didn't work. - Fixed: UpdateTeam passed an FString to Printf. SVN r623 (trunk)
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);
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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);
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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);
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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);
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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))
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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;
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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))
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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;
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
2007-12-20 04:36:43 +00:00
parms->top = parms->texheight;
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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);
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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);
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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);
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
2007-12-20 04:36:43 +00:00
if (parms->uclip < 0)
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
2006-02-24 04:48:15 +00:00
{
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
2007-12-20 04:36:43 +00:00
parms->uclip = 0;
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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);
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
2007-12-20 04:36:43 +00:00
if (parms->dclip > this->GetHeight())
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
2006-02-24 04:48:15 +00:00
{
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
2007-12-20 04:36:43 +00:00
parms->dclip = this->GetHeight();
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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);
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
2007-12-20 04:36:43 +00:00
if (parms->lclip < 0)
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
2006-02-24 04:48:15 +00:00
{
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
2007-12-20 04:36:43 +00:00
parms->lclip = 0;
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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);
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
2007-12-20 04:36:43 +00:00
if (parms->rclip > this->GetWidth())
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
2006-02-24 04:48:15 +00:00
{
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
2007-12-20 04:36:43 +00:00
parms->rclip = this->GetWidth();
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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));
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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);
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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);
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
2006-02-24 04:48:15 +00:00
if (boolval)
{
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
2007-12-20 04:36:43 +00:00
parms->shadowAlpha = FRACUNIT/2;
parms->shadowColor = 0;
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
2006-02-24 04:48:15 +00:00
}
else
{
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
2007-12-20 04:36:43 +00:00
parms->shadowAlpha = 0;
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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);
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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;
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
2006-02-24 04:48:15 +00:00
case DTA_KeepRatio:
- Applied a modified version of Karate Chris's screenshot naming patch. - Sbarinfo optimization: Creating and destroying bar textures every frame is a relatively expensive operation. We can skip the custom texture entirely and just draw the bars directly to the screen, using the clipping parameters for DrawTexture(). This also means bars are no longer limited to the game palette, and the bar itself has the same resolution as the screen. SVN r731 (trunk)
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);
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
2006-02-24 04:48:15 +00:00
break;
- Added a new MapMarker actor. Instead of appearing in the 3D view, it appears on the automap instead. If its first argument is zero, the map marker itself appears on the automap, otherwise it is drawn on top of any actor with a TID matching that argument. If the second argument is one, then the map marker will only be appear if the player has previously seen the sector it is one. You can use Thing_Activate and Thing_Deactivate on markers to turn them on and off. And if you subclass MapMarker with DECORATE, you can easily make your own custom markers. - Fixed: Map markers could not be drawn partially off the map. They were drawn either fully or not at all. - Fixed: Map markers appeared in the wrong place on a rotated overlay map if screenblocks < 10. SVN r356 (trunk)
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);
- Added a new MapMarker actor. Instead of appearing in the 3D view, it appears on the automap instead. If its first argument is zero, the map marker itself appears on the automap, otherwise it is drawn on top of any actor with a TID matching that argument. If the second argument is one, then the map marker will only be appear if the player has previously seen the sector it is one. You can use Thing_Activate and Thing_Deactivate on markers to turn them on and off. And if you subclass MapMarker with DECORATE, you can easily make your own custom markers. - Fixed: Map markers could not be drawn partially off the map. They were drawn either fully or not at all. - Fixed: Map markers appeared in the wrong place on a rotated overlay map if screenblocks < 10. SVN r356 (trunk)
2006-10-20 04:04:04 +00:00
break;
- Fixed: Wall drawing handled fixed light levels improperly (but did not completely ignore them, either). - Separated light level fixing out of player_t's fixedcolormap parameter. Using a fixed light level (e.g. PowerTorch) will no longer wipe out colored lighting. - Moved the blending rectangle drawing into a separate discrete stage, since doing it while copying the 3D view window to the display now blends underneath the weapon instead of on top of it. - Consolidated the special colormaps into a single 2D table. - Tweaked the special colormaps slightly to make the true color results more closely match the paletted approximations. - fb_d3d9_shaders.h was getting unwieldy, so I moved the shaders out of the executable and into zdoom.pk3. Shaders are still precompiled so I don't need to pull in a dependancy on D3DX. - Added a few more shaders to accomodate drawing weapons with all the in-game lighting models. These are accessed with the new DrawTexture tags DTA_SpecialColormap and DTA_ColormapStyle. - Player weapon sprites are now drawn using Direct3D and receive all the benefits thereof. SVN r1858 (trunk)
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 *);
- Fixed: Wall drawing handled fixed light levels improperly (but did not completely ignore them, either). - Separated light level fixing out of player_t's fixedcolormap parameter. Using a fixed light level (e.g. PowerTorch) will no longer wipe out colored lighting. - Moved the blending rectangle drawing into a separate discrete stage, since doing it while copying the 3D view window to the display now blends underneath the weapon instead of on top of it. - Consolidated the special colormaps into a single 2D table. - Tweaked the special colormaps slightly to make the true color results more closely match the paletted approximations. - fb_d3d9_shaders.h was getting unwieldy, so I moved the shaders out of the executable and into zdoom.pk3. Shaders are still precompiled so I don't need to pull in a dependancy on D3DX. - Added a few more shaders to accomodate drawing weapons with all the in-game lighting models. These are accessed with the new DrawTexture tags DTA_SpecialColormap and DTA_ColormapStyle. - Player weapon sprites are now drawn using Direct3D and receive all the benefits thereof. SVN r1858 (trunk)
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 *);
- Fixed: Wall drawing handled fixed light levels improperly (but did not completely ignore them, either). - Separated light level fixing out of player_t's fixedcolormap parameter. Using a fixed light level (e.g. PowerTorch) will no longer wipe out colored lighting. - Moved the blending rectangle drawing into a separate discrete stage, since doing it while copying the 3D view window to the display now blends underneath the weapon instead of on top of it. - Consolidated the special colormaps into a single 2D table. - Tweaked the special colormaps slightly to make the true color results more closely match the paletted approximations. - fb_d3d9_shaders.h was getting unwieldy, so I moved the shaders out of the executable and into zdoom.pk3. Shaders are still precompiled so I don't need to pull in a dependancy on D3DX. - Added a few more shaders to accomodate drawing weapons with all the in-game lighting models. These are accessed with the new DrawTexture tags DTA_SpecialColormap and DTA_ColormapStyle. - Player weapon sprites are now drawn using Direct3D and receive all the benefits thereof. SVN r1858 (trunk)
2009-09-20 03:50:05 +00:00
break;
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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);
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
2006-02-24 04:48:15 +00:00
}
va_end (tags);
- Applied a modified version of Karate Chris's screenshot naming patch. - Sbarinfo optimization: Creating and destroying bar textures every frame is a relatively expensive operation. We can skip the custom texture entirely and just draw the bars directly to the screen, using the clipping parameters for DrawTexture(). This also means bars are no longer limited to the game palette, and the bar itself has the same resolution as the screen. SVN r731 (trunk)
2008-02-05 05:29:31 +00:00
if (parms->uclip >= parms->dclip || parms->lclip >= parms->rclip)
{
return false;
}
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
2007-12-20 04:36:43 +00:00
if (parms->virtWidth != Width || parms->virtHeight != Height)
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
2006-02-24 04:48:15 +00:00
{
- Applied a modified version of Karate Chris's screenshot naming patch. - Sbarinfo optimization: Creating and destroying bar textures every frame is a relatively expensive operation. We can skip the custom texture entirely and just draw the bars directly to the screen, using the clipping parameters for DrawTexture(). This also means bars are no longer limited to the game palette, and the bar itself has the same resolution as the screen. SVN r731 (trunk)
2008-02-05 05:29:31 +00:00
VirtualToRealCoords(parms->x, parms->y, parms->destwidth, parms->destheight,
parms->virtWidth, parms->virtHeight, virtBottom, !parms->keepratio);
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
2006-02-24 04:48:15 +00:00
}
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
2007-12-20 04:36:43 +00:00
if (parms->destwidth <= 0 || parms->destheight <= 0)
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
2006-02-24 04:48:15 +00:00
{
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
2007-12-20 04:36:43 +00:00
return false;
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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)
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
2006-02-24 04:48:15 +00:00
{
- Fixed: R_GetOneSkyColumn() and R_GetTwoSkyColumns are mulscaling an unsigned integer that can use all 32 bits. They must therefore use the unsigned mul instruction rather than the signed imul instruction. - Fixed several signed/unsigned comparison and possibly uninitialized variable warnings flagged by GCC. SVN r1965 (trunk)
2009-11-08 02:51:22 +00:00
if (parms->fillcolor != ~0u)
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
2006-02-24 04:48:15 +00:00
{
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
2007-12-20 04:36:43 +00:00
if (parms->alphaChannel)
- Added a new MapMarker actor. Instead of appearing in the 3D view, it appears on the automap instead. If its first argument is zero, the map marker itself appears on the automap, otherwise it is drawn on top of any actor with a TID matching that argument. If the second argument is one, then the map marker will only be appear if the player has previously seen the sector it is one. You can use Thing_Activate and Thing_Deactivate on markers to turn them on and off. And if you subclass MapMarker with DECORATE, you can easily make your own custom markers. - Fixed: Map markers could not be drawn partially off the map. They were drawn either fully or not at all. - Fixed: Map markers appeared in the wrong place on a rotated overlay map if screenblocks < 10. SVN r356 (trunk)
2006-10-20 04:04:04 +00:00
{
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
2007-12-20 04:36:43 +00:00
parms->style = STYLE_Shaded;
- Added a new MapMarker actor. Instead of appearing in the 3D view, it appears on the automap instead. If its first argument is zero, the map marker itself appears on the automap, otherwise it is drawn on top of any actor with a TID matching that argument. If the second argument is one, then the map marker will only be appear if the player has previously seen the sector it is one. You can use Thing_Activate and Thing_Deactivate on markers to turn them on and off. And if you subclass MapMarker with DECORATE, you can easily make your own custom markers. - Fixed: Map markers could not be drawn partially off the map. They were drawn either fully or not at all. - Fixed: Map markers appeared in the wrong place on a rotated overlay map if screenblocks < 10. SVN r356 (trunk)
2006-10-20 04:04:04 +00:00
}
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
2007-12-20 04:36:43 +00:00
else if (parms->alpha < FRACUNIT)
- Added a new MapMarker actor. Instead of appearing in the 3D view, it appears on the automap instead. If its first argument is zero, the map marker itself appears on the automap, otherwise it is drawn on top of any actor with a TID matching that argument. If the second argument is one, then the map marker will only be appear if the player has previously seen the sector it is one. You can use Thing_Activate and Thing_Deactivate on markers to turn them on and off. And if you subclass MapMarker with DECORATE, you can easily make your own custom markers. - Fixed: Map markers could not be drawn partially off the map. They were drawn either fully or not at all. - Fixed: Map markers appeared in the wrong place on a rotated overlay map if screenblocks < 10. SVN r356 (trunk)
2006-10-20 04:04:04 +00:00
{
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
2007-12-20 04:36:43 +00:00
parms->style = STYLE_TranslucentStencil;
- Added a new MapMarker actor. Instead of appearing in the 3D view, it appears on the automap instead. If its first argument is zero, the map marker itself appears on the automap, otherwise it is drawn on top of any actor with a TID matching that argument. If the second argument is one, then the map marker will only be appear if the player has previously seen the sector it is one. You can use Thing_Activate and Thing_Deactivate on markers to turn them on and off. And if you subclass MapMarker with DECORATE, you can easily make your own custom markers. - Fixed: Map markers could not be drawn partially off the map. They were drawn either fully or not at all. - Fixed: Map markers appeared in the wrong place on a rotated overlay map if screenblocks < 10. SVN r356 (trunk)
2006-10-20 04:04:04 +00:00
}
else
{
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
2007-12-20 04:36:43 +00:00
parms->style = STYLE_Stencil;
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
2006-02-24 04:48:15 +00:00
}
}
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
2007-12-20 04:36:43 +00:00
else if (parms->alpha < FRACUNIT)
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
2006-02-24 04:48:15 +00:00
{
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
2007-12-20 04:36:43 +00:00
parms->style = STYLE_Translucent;
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
2006-02-24 04:48:15 +00:00
}
else
{
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
2007-12-20 04:36:43 +00:00
parms->style = STYLE_Normal;
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
2006-02-24 04:48:15 +00:00
}
}
- Added a framework for drawing the 2D screen elements with Direct3D textures. They are not actually drawn with it yet, nor is it complete, but it's something to start with. - Split up DCanvas::DrawTexture() into more pieces to make it easier to virtualize. - Removed support for non-32-bit palette textures from D3DFB. What kind of card supports pixel shaders but not 32-bit textures? SVN r605 (trunk)
2007-12-20 04:36:43 +00:00
return true;
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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
- Applied a modified version of Karate Chris's screenshot naming patch. - Sbarinfo optimization: Creating and destroying bar textures every frame is a relatively expensive operation. We can skip the custom texture entirely and just draw the bars directly to the screen, using the clipping parameters for DrawTexture(). This also means bars are no longer limited to the game palette, and the bar itself has the same resolution as the screen. SVN r731 (trunk)
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;
- Applied a modified version of Karate Chris's screenshot naming patch. - Sbarinfo optimization: Creating and destroying bar textures every frame is a relatively expensive operation. We can skip the custom texture entirely and just draw the bars directly to the screen, using the clipping parameters for DrawTexture(). This also means bars are no longer limited to the game palette, and the bar itself has the same resolution as the screen. SVN r731 (trunk)
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;
- Applied a modified version of Karate Chris's screenshot naming patch. - Sbarinfo optimization: Creating and destroying bar textures every frame is a relatively expensive operation. We can skip the custom texture entirely and just draw the bars directly to the screen, using the clipping parameters for DrawTexture(). This also means bars are no longer limited to the game palette, and the bar itself has the same resolution as the screen. SVN r731 (trunk)
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;
- Applied a modified version of Karate Chris's screenshot naming patch. - Sbarinfo optimization: Creating and destroying bar textures every frame is a relatively expensive operation. We can skip the custom texture entirely and just draw the bars directly to the screen, using the clipping parameters for DrawTexture(). This also means bars are no longer limited to the game palette, and the bar itself has the same resolution as the screen. SVN r731 (trunk)
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;
- Applied a modified version of Karate Chris's screenshot naming patch. - Sbarinfo optimization: Creating and destroying bar textures every frame is a relatively expensive operation. We can skip the custom texture entirely and just draw the bars directly to the screen, using the clipping parameters for DrawTexture(). This also means bars are no longer limited to the game palette, and the bar itself has the same resolution as the screen. SVN r731 (trunk)
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;
- Applied a modified version of Karate Chris's screenshot naming patch. - Sbarinfo optimization: Creating and destroying bar textures every frame is a relatively expensive operation. We can skip the custom texture entirely and just draw the bars directly to the screen, using the clipping parameters for DrawTexture(). This also means bars are no longer limited to the game palette, and the bar itself has the same resolution as the screen. SVN r731 (trunk)
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;
- Applied a modified version of Karate Chris's screenshot naming patch. - Sbarinfo optimization: Creating and destroying bar textures every frame is a relatively expensive operation. We can skip the custom texture entirely and just draw the bars directly to the screen, using the clipping parameters for DrawTexture(). This also means bars are no longer limited to the game palette, and the bar itself has the same resolution as the screen. SVN r731 (trunk)
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);
}
- Applied a modified version of Karate Chris's screenshot naming patch. - Sbarinfo optimization: Creating and destroying bar textures every frame is a relatively expensive operation. We can skip the custom texture entirely and just draw the bars directly to the screen, using the clipping parameters for DrawTexture(). This also means bars are no longer limited to the game palette, and the bar itself has the same resolution as the screen. SVN r731 (trunk)
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;
- Applied a modified version of Karate Chris's screenshot naming patch. - Sbarinfo optimization: Creating and destroying bar textures every frame is a relatively expensive operation. We can skip the custom texture entirely and just draw the bars directly to the screen, using the clipping parameters for DrawTexture(). This also means bars are no longer limited to the game palette, and the bar itself has the same resolution as the screen. SVN r731 (trunk)
2008-02-05 05:29:31 +00:00
}
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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
{
- Added versions of Dim and Clear to D3DFB for use in 2D mode. - Added a new color parameter to DCanvas::Clear() that specifies the ARGB value of the color. This is used if the old color parameter, which specifies a palette entry, is -1. SVN r617 (trunk)
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
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
2006-02-24 04:48:15 +00:00
}
}
- also replaced the AM crosshair drawer by a DCanvas::DrawPixel function. - moved the AM line drawer into DCanvas as a virtual function. While testing this code I discovered that the antialias precalculation was never used except for the very first frame of AM drawing. However, since I couldn't detect even a marginal performance improvement using this code on 2 computers I just disabled it completely because it severely complicates a more generic implementation. I also disabled am_ovtrans in the process because I couldn't see any positive effects of using this cvar. All it does is adding some ugly distortion to the lines it affects without any apparent benefits. * Added fix by Karate Chris containing: - Added a 'No team changing' DMFlag2 which prevents players from changing teams unless they are not on a team. - Added a 'No respawn' DMFlag2 which prevents a player from respawning after they have died. - Added a 'Keep frags gained' DMFlag2 which allows you to choose whether you want to reset the frags of each player next level or not. - Added a small visual enhancement to the cooperative scoreboard to show if a player has died. - Fixed: If the 'teamplay' console variable was set to 'true' in a cooperative game, the scoreboard would show team play related items as opposed to cooperative items. - Fixed: The 'bot_observer' console variable should not work in network games. - Fixed: Bots made intermission skip really fast. SVN r634 (trunk)
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)
{
- Changed the MIDIStreamer to send the all notes off controller to each channel when restarting the song, rather than emitting a single note off event which only has a 1 in 127 chance of being for a note that's playing on that channel. Then I decided it would probably be a good idea to reset all the controllers as well. - Increasing the size of the internal Timidity stream buffer from 1/14 sec (copied from the OPL player) improved its sound dramatically, so apparently Timidity has issues with short stream buffers. It's now at 1/2 sec in length. However, there seems to be something weird going on with corazonazul_ff6boss.mid near the beginning where it stops and immediately restarts a guitar on the exact same note. - Added a new sound debugging cvar: snd_drawoutput, which can show various oscilloscopes and spectrums. - Internal TiMidity now plays music. - Changed the progdir global variable into an FString. SVN r900 (trunk)
2008-04-11 04:59:23 +00:00
palColor = PalFromRGB(realcolor);
- also replaced the AM crosshair drawer by a DCanvas::DrawPixel function. - moved the AM line drawer into DCanvas as a virtual function. While testing this code I discovered that the antialias precalculation was never used except for the very first frame of AM drawing. However, since I couldn't detect even a marginal performance improvement using this code on 2 computers I just disabled it completely because it severely complicates a more generic implementation. I also disabled am_ovtrans in the process because I couldn't see any positive effects of using this cvar. All it does is adding some ugly distortion to the lines it affects without any apparent benefits. * Added fix by Karate Chris containing: - Added a 'No team changing' DMFlag2 which prevents players from changing teams unless they are not on a team. - Added a 'No respawn' DMFlag2 which prevents a player from respawning after they have died. - Added a 'Keep frags gained' DMFlag2 which allows you to choose whether you want to reset the frags of each player next level or not. - Added a small visual enhancement to the cooperative scoreboard to show if a player has died. - Fixed: If the 'teamplay' console variable was set to 'true' in a cooperative game, the scoreboard would show team play related items as opposed to cooperative items. - Fixed: The 'bot_observer' console variable should not work in network games. - Fixed: Bots made intermission skip really fast. SVN r634 (trunk)
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)
{
swap (x0, x1);
}
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)
{
- Changed the MIDIStreamer to send the all notes off controller to each channel when restarting the song, rather than emitting a single note off event which only has a 1 in 127 chance of being for a note that's playing on that channel. Then I decided it would probably be a good idea to reset all the controllers as well. - Increasing the size of the internal Timidity stream buffer from 1/14 sec (copied from the OPL player) improved its sound dramatically, so apparently Timidity has issues with short stream buffers. It's now at 1/2 sec in length. However, there seems to be something weird going on with corazonazul_ff6boss.mid near the beginning where it stops and immediately restarts a guitar on the exact same note. - Added a new sound debugging cvar: snd_drawoutput, which can show various oscilloscopes and spectrums. - Internal TiMidity now plays music. - Changed the progdir global variable into an FString. SVN r900 (trunk)
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)
- also replaced the AM crosshair drawer by a DCanvas::DrawPixel function. - moved the AM line drawer into DCanvas as a virtual function. While testing this code I discovered that the antialias precalculation was never used except for the very first frame of AM drawing. However, since I couldn't detect even a marginal performance improvement using this code on 2 computers I just disabled it completely because it severely complicates a more generic implementation. I also disabled am_ovtrans in the process because I couldn't see any positive effects of using this cvar. All it does is adding some ugly distortion to the lines it affects without any apparent benefits. * Added fix by Karate Chris containing: - Added a 'No team changing' DMFlag2 which prevents players from changing teams unless they are not on a team. - Added a 'No respawn' DMFlag2 which prevents a player from respawning after they have died. - Added a 'Keep frags gained' DMFlag2 which allows you to choose whether you want to reset the frags of each player next level or not. - Added a small visual enhancement to the cooperative scoreboard to show if a player has died. - Fixed: If the 'teamplay' console variable was set to 'true' in a cooperative game, the scoreboard would show team play related items as opposed to cooperative items. - Fixed: The 'bot_observer' console variable should not work in network games. - Fixed: Bots made intermission skip really fast. SVN r634 (trunk)
2007-12-24 14:24:24 +00:00
{
- Changed the MIDIStreamer to send the all notes off controller to each channel when restarting the song, rather than emitting a single note off event which only has a 1 in 127 chance of being for a note that's playing on that channel. Then I decided it would probably be a good idea to reset all the controllers as well. - Increasing the size of the internal Timidity stream buffer from 1/14 sec (copied from the OPL player) improved its sound dramatically, so apparently Timidity has issues with short stream buffers. It's now at 1/2 sec in length. However, there seems to be something weird going on with corazonazul_ff6boss.mid near the beginning where it stops and immediately restarts a guitar on the exact same note. - Added a new sound debugging cvar: snd_drawoutput, which can show various oscilloscopes and spectrums. - Internal TiMidity now plays music. - Changed the progdir global variable into an FString. SVN r900 (trunk)
2008-04-11 04:59:23 +00:00
Dim(color, APART(color)/255.f, left, top, right - left, bottom - top);
return;
- also replaced the AM crosshair drawer by a DCanvas::DrawPixel function. - moved the AM line drawer into DCanvas as a virtual function. While testing this code I discovered that the antialias precalculation was never used except for the very first frame of AM drawing. However, since I couldn't detect even a marginal performance improvement using this code on 2 computers I just disabled it completely because it severely complicates a more generic implementation. I also disabled am_ovtrans in the process because I couldn't see any positive effects of using this cvar. All it does is adding some ugly distortion to the lines it affects without any apparent benefits. * Added fix by Karate Chris containing: - Added a 'No team changing' DMFlag2 which prevents players from changing teams unless they are not on a team. - Added a 'No respawn' DMFlag2 which prevents a player from respawning after they have died. - Added a 'Keep frags gained' DMFlag2 which allows you to choose whether you want to reset the frags of each player next level or not. - Added a small visual enhancement to the cooperative scoreboard to show if a player has died. - Fixed: If the 'teamplay' console variable was set to 'true' in a cooperative game, the scoreboard would show team play related items as opposed to cooperative items. - Fixed: The 'bot_observer' console variable should not work in network games. - Fixed: Bots made intermission skip really fast. SVN r634 (trunk)
2007-12-24 14:24:24 +00:00
}
- Changed the MIDIStreamer to send the all notes off controller to each channel when restarting the song, rather than emitting a single note off event which only has a 1 in 127 chance of being for a note that's playing on that channel. Then I decided it would probably be a good idea to reset all the controllers as well. - Increasing the size of the internal Timidity stream buffer from 1/14 sec (copied from the OPL player) improved its sound dramatically, so apparently Timidity has issues with short stream buffers. It's now at 1/2 sec in length. However, there seems to be something weird going on with corazonazul_ff6boss.mid near the beginning where it stops and immediately restarts a guitar on the exact same note. - Added a new sound debugging cvar: snd_drawoutput, which can show various oscilloscopes and spectrums. - Internal TiMidity now plays music. - Changed the progdir global variable into an FString. SVN r900 (trunk)
2008-04-11 04:59:23 +00:00
palcolor = PalFromRGB(color);
- also replaced the AM crosshair drawer by a DCanvas::DrawPixel function. - moved the AM line drawer into DCanvas as a virtual function. While testing this code I discovered that the antialias precalculation was never used except for the very first frame of AM drawing. However, since I couldn't detect even a marginal performance improvement using this code on 2 computers I just disabled it completely because it severely complicates a more generic implementation. I also disabled am_ovtrans in the process because I couldn't see any positive effects of using this cvar. All it does is adding some ugly distortion to the lines it affects without any apparent benefits. * Added fix by Karate Chris containing: - Added a 'No team changing' DMFlag2 which prevents players from changing teams unless they are not on a team. - Added a 'No respawn' DMFlag2 which prevents a player from respawning after they have died. - Added a 'Keep frags gained' DMFlag2 which allows you to choose whether you want to reset the frags of each player next level or not. - Added a small visual enhancement to the cooperative scoreboard to show if a player has died. - Fixed: If the 'teamplay' console variable was set to 'true' in a cooperative game, the scoreboard would show team play related items as opposed to cooperative items. - Fixed: The 'bot_observer' console variable should not work in network games. - Fixed: Bots made intermission skip really fast. SVN r634 (trunk)
2007-12-24 14:24:24 +00:00
}
- Changed the MIDIStreamer to send the all notes off controller to each channel when restarting the song, rather than emitting a single note off event which only has a 1 in 127 chance of being for a note that's playing on that channel. Then I decided it would probably be a good idea to reset all the controllers as well. - Increasing the size of the internal Timidity stream buffer from 1/14 sec (copied from the OPL player) improved its sound dramatically, so apparently Timidity has issues with short stream buffers. It's now at 1/2 sec in length. However, there seems to be something weird going on with corazonazul_ff6boss.mid near the beginning where it stops and immediately restarts a guitar on the exact same note. - Added a new sound debugging cvar: snd_drawoutput, which can show various oscilloscopes and spectrums. - Internal TiMidity now plays music. - Changed the progdir global variable into an FString. SVN r900 (trunk)
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;
}
- also replaced the AM crosshair drawer by a DCanvas::DrawPixel function. - moved the AM line drawer into DCanvas as a virtual function. While testing this code I discovered that the antialias precalculation was never used except for the very first frame of AM drawing. However, since I couldn't detect even a marginal performance improvement using this code on 2 computers I just disabled it completely because it severely complicates a more generic implementation. I also disabled am_ovtrans in the process because I couldn't see any positive effects of using this cvar. All it does is adding some ugly distortion to the lines it affects without any apparent benefits. * Added fix by Karate Chris containing: - Added a 'No team changing' DMFlag2 which prevents players from changing teams unless they are not on a team. - Added a 'No respawn' DMFlag2 which prevents a player from respawning after they have died. - Added a 'Keep frags gained' DMFlag2 which allows you to choose whether you want to reset the frags of each player next level or not. - Added a small visual enhancement to the cooperative scoreboard to show if a player has died. - Fixed: If the 'teamplay' console variable was set to 'true' in a cooperative game, the scoreboard would show team play related items as opposed to cooperative items. - Fixed: The 'bot_observer' console variable should not work in network games. - Fixed: Bots made intermission skip really fast. SVN r634 (trunk)
2007-12-24 14:24:24 +00:00
}
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
2006-02-24 04:48:15 +00:00
/********************************/
/* */
/* Other miscellaneous routines */
/* */
/********************************/
//
// V_DrawBlock
// Draw a linear block of pixels into the view buffer.
//
- Fixed: cycle_t was still a DWORD and not a QWORD under GCC. - The stat meters now return an FString instead of sprintfing into a fixed output buffer. - NOASM is now automatically defined when compiling for a non-x86 target. - Some changes have been made to the integral types in doomtype.h: - For consistancy with the other integral types, byte is no longer a synonym for BYTE. - Most uses of BOOL have been change to the standard C++ bool type. Those that weren't were changed to INTBOOL to indicate they may contain values other than 0 or 1 but are still used as a boolean. - Compiler-provided types with explicit bit sizes are now used. In particular, DWORD is no longer a long so it will work with both 64-bit Windows and Linux. - Since some files need to include Windows headers, uint32 is a synonym for the non-Windows version of DWORD. - Removed d_textur.h. The pic_t struct it defined was used nowhere, and that was all it contained. SVN r326 (trunk)
2006-09-14 00:02:31 +00:00
void DCanvas::DrawBlock (int x, int y, int _width, int _height, const BYTE *src) const
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
2006-02-24 04:48:15 +00:00
{
int srcpitch = _width;
int destpitch;
- Fixed: cycle_t was still a DWORD and not a QWORD under GCC. - The stat meters now return an FString instead of sprintfing into a fixed output buffer. - NOASM is now automatically defined when compiling for a non-x86 target. - Some changes have been made to the integral types in doomtype.h: - For consistancy with the other integral types, byte is no longer a synonym for BYTE. - Most uses of BOOL have been change to the standard C++ bool type. Those that weren't were changed to INTBOOL to indicate they may contain values other than 0 or 1 but are still used as a boolean. - Compiler-provided types with explicit bit sizes are now used. In particular, DWORD is no longer a long so it will work with both 64-bit Windows and Linux. - Since some files need to include Windows headers, uint32 is a synonym for the non-Windows version of DWORD. - Removed d_textur.h. The pic_t struct it defined was used nowhere, and that was all it contained. SVN r326 (trunk)
2006-09-14 00:02:31 +00:00
BYTE *dest;
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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.
//
- Fixed: cycle_t was still a DWORD and not a QWORD under GCC. - The stat meters now return an FString instead of sprintfing into a fixed output buffer. - NOASM is now automatically defined when compiling for a non-x86 target. - Some changes have been made to the integral types in doomtype.h: - For consistancy with the other integral types, byte is no longer a synonym for BYTE. - Most uses of BOOL have been change to the standard C++ bool type. Those that weren't were changed to INTBOOL to indicate they may contain values other than 0 or 1 but are still used as a boolean. - Compiler-provided types with explicit bit sizes are now used. In particular, DWORD is no longer a long so it will work with both 64-bit Windows and Linux. - Since some files need to include Windows headers, uint32 is a synonym for the non-Windows version of DWORD. - Removed d_textur.h. The pic_t struct it defined was used nowhere, and that was all it contained. SVN r326 (trunk)
2006-09-14 00:02:31 +00:00
void DCanvas::GetBlock (int x, int y, int _width, int _height, BYTE *dest) const
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
2006-02-24 04:48:15 +00:00
{
- Fixed: cycle_t was still a DWORD and not a QWORD under GCC. - The stat meters now return an FString instead of sprintfing into a fixed output buffer. - NOASM is now automatically defined when compiling for a non-x86 target. - Some changes have been made to the integral types in doomtype.h: - For consistancy with the other integral types, byte is no longer a synonym for BYTE. - Most uses of BOOL have been change to the standard C++ bool type. Those that weren't were changed to INTBOOL to indicate they may contain values other than 0 or 1 but are still used as a boolean. - Compiler-provided types with explicit bit sizes are now used. In particular, DWORD is no longer a long so it will work with both 64-bit Windows and Linux. - Since some files need to include Windows headers, uint32 is a synonym for the non-Windows version of DWORD. - Removed d_textur.h. The pic_t struct it defined was used nowhere, and that was all it contained. SVN r326 (trunk)
2006-09-14 00:02:31 +00:00
const BYTE *src;
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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.
- Fixed: cycle_t was still a DWORD and not a QWORD under GCC. - The stat meters now return an FString instead of sprintfing into a fixed output buffer. - NOASM is now automatically defined when compiling for a non-x86 target. - Some changes have been made to the integral types in doomtype.h: - For consistancy with the other integral types, byte is no longer a synonym for BYTE. - Most uses of BOOL have been change to the standard C++ bool type. Those that weren't were changed to INTBOOL to indicate they may contain values other than 0 or 1 but are still used as a boolean. - Compiler-provided types with explicit bit sizes are now used. In particular, DWORD is no longer a long so it will work with both 64-bit Windows and Linux. - Since some files need to include Windows headers, uint32 is a synonym for the non-Windows version of DWORD. - Removed d_textur.h. The pic_t struct it defined was used nowhere, and that was all it contained. SVN r326 (trunk)
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
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk)
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;
}
Reference in a new issue Copy permalink