2006-02-24 04:48:15 +00:00
|
|
|
/*
|
|
|
|
** v_video.h
|
|
|
|
**
|
|
|
|
**---------------------------------------------------------------------------
|
2007-12-27 04:30:12 +00:00
|
|
|
** Copyright 1998-2008 Randy Heit
|
2006-02-24 04:48:15 +00:00
|
|
|
** All rights reserved.
|
|
|
|
**
|
|
|
|
** Redistribution and use in source and binary forms, with or without
|
|
|
|
** modification, are permitted provided that the following conditions
|
|
|
|
** are met:
|
|
|
|
**
|
|
|
|
** 1. Redistributions of source code must retain the above copyright
|
|
|
|
** notice, this list of conditions and the following disclaimer.
|
|
|
|
** 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
** notice, this list of conditions and the following disclaimer in the
|
|
|
|
** documentation and/or other materials provided with the distribution.
|
|
|
|
** 3. The name of the author may not be used to endorse or promote products
|
|
|
|
** derived from this software without specific prior written permission.
|
|
|
|
**
|
|
|
|
** THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
|
|
|
|
** IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
|
|
|
|
** OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
|
|
|
|
** IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
|
|
|
|
** INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
|
|
|
|
** NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
|
|
|
|
** DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
|
|
|
|
** THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
|
|
|
** (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
|
|
|
|
** THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
**---------------------------------------------------------------------------
|
|
|
|
**
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef __V_VIDEO_H__
|
|
|
|
#define __V_VIDEO_H__
|
|
|
|
|
|
|
|
#include "doomtype.h"
|
|
|
|
|
|
|
|
#include "doomdef.h"
|
2008-09-15 14:11:05 +00:00
|
|
|
#include "dobject.h"
|
2011-07-06 07:35:36 +00:00
|
|
|
#include "r_data/renderstyle.h"
|
2008-09-15 14:11:05 +00:00
|
|
|
#include "c_cvars.h"
|
2006-02-24 04:48:15 +00:00
|
|
|
|
|
|
|
extern int CleanWidth, CleanHeight, CleanXfac, CleanYfac;
|
2009-12-25 05:55:51 +00:00
|
|
|
extern int CleanWidth_1, CleanHeight_1, CleanXfac_1, CleanYfac_1;
|
2006-02-24 04:48:15 +00:00
|
|
|
extern int DisplayWidth, DisplayHeight, DisplayBits;
|
|
|
|
|
2008-01-28 10:23:18 +00:00
|
|
|
bool V_DoModeSetup (int width, int height, int bits);
|
2012-07-21 02:32:04 +00:00
|
|
|
void V_CalcCleanFacs (int designwidth, int designheight, int realwidth, int realheight, int *cleanx, int *cleany, int *cx1=NULL, int *cx2=NULL);
|
2008-01-28 10:23:18 +00:00
|
|
|
|
2006-02-24 04:48:15 +00:00
|
|
|
class FTexture;
|
|
|
|
|
|
|
|
// TagItem definitions for DrawTexture. As far as I know, tag lists
|
|
|
|
// originated on the Amiga.
|
|
|
|
//
|
|
|
|
// Think of TagItems as an array of the following structure:
|
|
|
|
//
|
|
|
|
// struct TagItem {
|
|
|
|
// DWORD ti_Tag;
|
|
|
|
// DWORD ti_Data;
|
|
|
|
// };
|
|
|
|
|
2006-05-24 15:31:21 +00:00
|
|
|
#define TAG_DONE (0) /* Used to indicate the end of the Tag list */
|
|
|
|
#define TAG_END (0) /* Ditto */
|
|
|
|
#define TAG_IGNORE (1) /* Ignore this Tag */
|
|
|
|
#define TAG_MORE (2) /* Ends this list and continues with the */
|
2006-02-24 04:48:15 +00:00
|
|
|
/* list pointed to in ti_Data */
|
|
|
|
|
2006-12-21 04:34:43 +00:00
|
|
|
#define TAG_USER ((DWORD)(1u<<30))
|
2006-02-24 04:48:15 +00:00
|
|
|
|
|
|
|
enum
|
|
|
|
{
|
|
|
|
DTA_Base = TAG_USER + 5000,
|
|
|
|
DTA_DestWidth, // width of area to draw to
|
|
|
|
DTA_DestHeight, // height of area to draw to
|
|
|
|
DTA_Alpha, // alpha value for translucency
|
|
|
|
DTA_FillColor, // color to stencil onto the destination
|
|
|
|
DTA_Translation, // translation table to recolor the source
|
|
|
|
DTA_AlphaChannel, // bool: the source is an alpha channel; used with DTA_FillColor
|
|
|
|
DTA_Clean, // bool: scale texture size and position by CleanXfac and CleanYfac
|
|
|
|
DTA_320x200, // bool: scale texture size and position to fit on a virtual 320x200 screen
|
2008-01-08 01:08:27 +00:00
|
|
|
DTA_Bottom320x200, // bool: same as DTA_320x200 but centers virtual screen on bottom for 1280x1024 targets
|
2006-02-24 04:48:15 +00:00
|
|
|
DTA_CleanNoMove, // bool: like DTA_Clean but does not reposition output position
|
2009-12-25 05:55:51 +00:00
|
|
|
DTA_CleanNoMove_1, // bool: like DTA_CleanNoMove, but uses Clean[XY]fac_1 instead
|
2007-12-20 04:36:43 +00:00
|
|
|
DTA_FlipX, // bool: flip image horizontally //FIXME: Does not work with DTA_Window(Left|Right)
|
2006-02-24 04:48:15 +00:00
|
|
|
DTA_ShadowColor, // color of shadow
|
|
|
|
DTA_ShadowAlpha, // alpha of shadow
|
|
|
|
DTA_Shadow, // set shadow color and alphas to defaults
|
|
|
|
DTA_VirtualWidth, // pretend the canvas is this wide
|
|
|
|
DTA_VirtualHeight, // pretend the canvas is this tall
|
|
|
|
DTA_TopOffset, // override texture's top offset
|
|
|
|
DTA_LeftOffset, // override texture's left offset
|
- 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
|
|
|
DTA_CenterOffset, // bool: override texture's left and top offsets and set them for the texture's middle
|
|
|
|
DTA_CenterBottomOffset,// bool: override texture's left and top offsets and set them for the texture's bottom middle
|
2006-02-24 04:48:15 +00:00
|
|
|
DTA_WindowLeft, // don't draw anything left of this column (on source, not dest)
|
|
|
|
DTA_WindowRight, // don't draw anything at or to the right of this column (on source, not dest)
|
|
|
|
DTA_ClipTop, // don't draw anything above this row (on dest, not source)
|
|
|
|
DTA_ClipBottom, // don't draw anything at or below this row (on dest, not source)
|
|
|
|
DTA_ClipLeft, // don't draw anything to the left of this column (on dest, not source)
|
|
|
|
DTA_ClipRight, // don't draw anything at or to the right of this column (on dest, not source)
|
|
|
|
DTA_Masked, // true(default)=use masks from texture, false=ignore masks
|
|
|
|
DTA_HUDRules, // use fullscreen HUD rules to position and size textures
|
|
|
|
DTA_KeepRatio, // doesn't adjust screen size for DTA_Virtual* if the aspect ratio is not 4:3
|
2006-10-20 04:04:04 +00:00
|
|
|
DTA_RenderStyle, // same as render style for actors
|
- 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
|
|
|
DTA_ColorOverlay, // DWORD: ARGB to overlay on top of image; limited to black for software
|
|
|
|
DTA_BilinearFilter, // bool: apply bilinear filtering to the image
|
2009-09-20 03:50:05 +00:00
|
|
|
DTA_SpecialColormap,// pointer to FSpecialColormapParameters (likely to be forever hardware-only)
|
|
|
|
DTA_ColormapStyle, // pointer to FColormapStyle (hardware-only)
|
2009-11-15 14:33:35 +00:00
|
|
|
DTA_Fullscreen, // Draw image fullscreen (same as DTA_VirtualWidth/Height with graphics size.)
|
2007-12-09 03:40:02 +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
|
|
|
// floating point duplicates of some of the above:
|
|
|
|
DTA_DestWidthF,
|
|
|
|
DTA_DestHeightF,
|
|
|
|
DTA_TopOffsetF,
|
|
|
|
DTA_LeftOffsetF,
|
|
|
|
DTA_VirtualWidthF,
|
|
|
|
DTA_VirtualHeightF,
|
|
|
|
DTA_WindowLeftF,
|
|
|
|
DTA_WindowRightF,
|
|
|
|
|
2007-12-09 03:40:02 +00:00
|
|
|
// For DrawText calls:
|
2007-12-20 04:36:43 +00:00
|
|
|
DTA_TextLen, // stop after this many characters, even if \0 not hit
|
2007-12-09 03:40:02 +00:00
|
|
|
DTA_CellX, // horizontal size of character cell
|
|
|
|
DTA_CellY, // vertical size of character cell
|
2006-02-24 04:48:15 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
enum
|
|
|
|
{
|
|
|
|
HUD_Normal,
|
|
|
|
HUD_HorizCenter
|
|
|
|
};
|
|
|
|
|
|
|
|
|
2008-09-15 14:11:05 +00:00
|
|
|
class FFont;
|
|
|
|
struct FRemapTable;
|
|
|
|
class player_t;
|
2010-08-27 15:20:05 +00:00
|
|
|
typedef uint32 angle_t;
|
2008-09-15 14:11:05 +00:00
|
|
|
|
2006-02-24 04:48:15 +00:00
|
|
|
//
|
|
|
|
// VIDEO
|
|
|
|
//
|
|
|
|
// [RH] Made screens more implementation-independant:
|
|
|
|
//
|
|
|
|
class DCanvas : public DObject
|
|
|
|
{
|
|
|
|
DECLARE_ABSTRACT_CLASS (DCanvas, DObject)
|
|
|
|
public:
|
|
|
|
DCanvas (int width, int height);
|
|
|
|
virtual ~DCanvas ();
|
|
|
|
|
|
|
|
// Member variable access
|
|
|
|
inline BYTE *GetBuffer () const { return Buffer; }
|
|
|
|
inline int GetWidth () const { return Width; }
|
|
|
|
inline int GetHeight () const { return Height; }
|
|
|
|
inline int GetPitch () const { return Pitch; }
|
|
|
|
|
|
|
|
virtual bool IsValid ();
|
|
|
|
|
|
|
|
// Access control
|
2014-01-06 00:50:09 +00:00
|
|
|
virtual bool Lock (bool buffered=true) = 0; // Returns true if the surface was lost since last time
|
2006-02-24 04:48:15 +00:00
|
|
|
virtual void Unlock () = 0;
|
|
|
|
virtual bool IsLocked () { return Buffer != NULL; } // Returns true if the surface is locked
|
|
|
|
|
|
|
|
// Draw a linear block of pixels into the canvas
|
2006-09-14 00:02:31 +00:00
|
|
|
virtual void DrawBlock (int x, int y, int width, int height, const BYTE *src) const;
|
2006-02-24 04:48:15 +00:00
|
|
|
|
|
|
|
// Reads a linear block of pixels into the view buffer.
|
2006-09-14 00:02:31 +00:00
|
|
|
virtual void GetBlock (int x, int y, int width, int height, BYTE *dest) const;
|
2006-02-24 04:48:15 +00:00
|
|
|
|
|
|
|
// Dim the entire canvas for the menus
|
- 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
|
|
|
virtual void Dim (PalEntry color = 0);
|
2006-02-24 04:48:15 +00:00
|
|
|
|
|
|
|
// Dim part of the 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
|
|
|
virtual void Dim (PalEntry color, float amount, int x1, int y1, int w, int h);
|
2006-02-24 04:48:15 +00:00
|
|
|
|
|
|
|
// Fill an area with a texture
|
2008-01-09 23:04:49 +00:00
|
|
|
virtual void FlatFill (int left, int top, int right, int bottom, FTexture *src, bool local_origin=false);
|
2006-02-24 04:48:15 +00:00
|
|
|
|
2010-08-27 15:20:05 +00:00
|
|
|
// Fill a simple polygon with a texture
|
|
|
|
virtual void FillSimplePoly(FTexture *tex, FVector2 *points, int npoints,
|
|
|
|
double originx, double originy, double scalex, double scaley, angle_t rotation,
|
|
|
|
struct FDynamicColormap *colormap, int lightlevel);
|
|
|
|
|
2006-02-24 04:48:15 +00:00
|
|
|
// Set an area to a specified color
|
- 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
|
|
|
virtual void Clear (int left, int top, int right, int bottom, int palcolor, uint32 color);
|
2006-02-24 04:48:15 +00:00
|
|
|
|
2008-01-04 05:22:30 +00:00
|
|
|
// Draws a line
|
2007-12-24 14:24:24 +00:00
|
|
|
virtual void DrawLine(int x0, int y0, int x1, int y1, int palColor, uint32 realcolor);
|
|
|
|
|
2008-01-04 05:22:30 +00:00
|
|
|
// Draws a single pixel
|
2007-12-24 14:24:24 +00:00
|
|
|
virtual void DrawPixel(int x, int y, int palcolor, uint32 rgbcolor);
|
|
|
|
|
2006-02-24 04:48:15 +00:00
|
|
|
// Calculate gamma table
|
|
|
|
void CalcGamma (float gamma, BYTE gammalookup[256]);
|
|
|
|
|
2007-12-24 21:56:49 +00:00
|
|
|
|
2008-01-12 06:27:13 +00:00
|
|
|
// Retrieves a buffer containing image data for a screenshot.
|
|
|
|
// Hint: Pitch can be negative for upside-down images, in which case buffer
|
|
|
|
// points to the last row in the buffer, which will be the first row output.
|
|
|
|
virtual void GetScreenshotBuffer(const BYTE *&buffer, int &pitch, ESSType &color_type);
|
2007-12-26 09:56:09 +00:00
|
|
|
|
2008-01-12 06:27:13 +00:00
|
|
|
// Releases the screenshot buffer.
|
|
|
|
virtual void ReleaseScreenshotBuffer();
|
2007-12-26 09:56:09 +00:00
|
|
|
|
2006-02-24 04:48:15 +00:00
|
|
|
// Text drawing functions -----------------------------------------------
|
|
|
|
|
|
|
|
// 2D Texture drawing
|
- 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 DrawTexture (FTexture *img, double x, double y, int tags, ...);
|
2006-02-24 04:48:15 +00:00
|
|
|
void FillBorder (FTexture *img); // Fills the border around a 4:3 part of the screen on non-4:3 displays
|
- 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 VirtualToRealCoords(double &x, double &y, double &w, double &h, double vwidth, double vheight, bool vbottom=false, bool handleaspect=true) const;
|
|
|
|
|
|
|
|
// Code that uses these (i.e. SBARINFO) should probably be evaluated for using doubles all around instead.
|
|
|
|
void VirtualToRealCoordsFixed(fixed_t &x, fixed_t &y, fixed_t &w, fixed_t &h, int vwidth, int vheight, bool vbottom=false, bool handleaspect=true) const;
|
2008-02-05 05:29:31 +00:00
|
|
|
void VirtualToRealCoordsInt(int &x, int &y, int &w, int &h, int vwidth, int vheight, bool vbottom=false, bool handleaspect=true) const;
|
2006-02-24 04:48:15 +00:00
|
|
|
|
|
|
|
// 2D Text drawing
|
2012-02-11 00:15:03 +00:00
|
|
|
void STACK_ARGS DrawText (FFont *font, int normalcolor, int x, int y, const char *string, ...);
|
- Fixed compilation with FMOD 4.38+. The removal of hardware voices and EAX was a fairly
major change, so I'm making no provisions for using older FMOD DLLs when compiled with the
4.38 API. However, sound positioning is still broken like in 4.28, so you are recommended
to continue building with 4.26. Also, the Freeverb-based DSP unit is no longer present in
FMOD, so the underwater effect is currently unavailable when using 4.38 until I can figure
out how to make it work with the SFX Reverb unit instead. (And on that topic, the Freeverb
DSP was officially only for stereo outputs, so I really shouldn't have been using it in the
first place.)
- Since I would like to eventually figure out the sound positioning issues with the newer
FMODs, the following have been added:
* snd_drawoutput now labels its outputs with the speakers they represent.
* DCanvas::DrawTextA was added as an alias for DrawText, since the Windows headers #define
DrawText to a Unicode/non-Unicode variant.
* The loopsound console command was added to spawn an actor at the player's location and
have it loop a sound infinitely.
Hopefully I can figure it out. FMOD's 3D example works, so I assume the problem lies with
my code, though I don't really know where to begin looking for the problem.
SVN r3350 (trunk)
2012-02-10 00:53:50 +00:00
|
|
|
#ifndef DrawText // See WinUser.h for the definition of DrawText as a macro
|
2012-02-11 00:15:03 +00:00
|
|
|
void STACK_ARGS DrawTextA (FFont *font, int normalcolor, int x, int y, const char *string, ...);
|
- Fixed compilation with FMOD 4.38+. The removal of hardware voices and EAX was a fairly
major change, so I'm making no provisions for using older FMOD DLLs when compiled with the
4.38 API. However, sound positioning is still broken like in 4.28, so you are recommended
to continue building with 4.26. Also, the Freeverb-based DSP unit is no longer present in
FMOD, so the underwater effect is currently unavailable when using 4.38 until I can figure
out how to make it work with the SFX Reverb unit instead. (And on that topic, the Freeverb
DSP was officially only for stereo outputs, so I really shouldn't have been using it in the
first place.)
- Since I would like to eventually figure out the sound positioning issues with the newer
FMODs, the following have been added:
* snd_drawoutput now labels its outputs with the speakers they represent.
* DCanvas::DrawTextA was added as an alias for DrawText, since the Windows headers #define
DrawText to a Unicode/non-Unicode variant.
* The loopsound console command was added to spawn an actor at the player's location and
have it loop a sound infinitely.
Hopefully I can figure it out. FMOD's 3D example works, so I assume the problem lies with
my code, though I don't really know where to begin looking for the problem.
SVN r3350 (trunk)
2012-02-10 00:53:50 +00:00
|
|
|
#endif
|
2012-02-11 00:15:03 +00:00
|
|
|
void DrawTextV (FFont *font, int normalcolor, int x, int y, const char *string, va_list tags);
|
2008-11-27 17:43:36 +00:00
|
|
|
void STACK_ARGS DrawChar (FFont *font, int normalcolor, int x, int y, BYTE character, ...);
|
2006-02-24 04:48:15 +00:00
|
|
|
|
2007-12-20 04:36:43 +00:00
|
|
|
struct DrawParms
|
|
|
|
{
|
- 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 x, y;
|
|
|
|
double texwidth;
|
|
|
|
double texheight;
|
|
|
|
double destwidth;
|
|
|
|
double destheight;
|
|
|
|
double virtWidth;
|
|
|
|
double virtHeight;
|
|
|
|
double windowleft;
|
|
|
|
double windowright;
|
2007-12-20 04:36:43 +00:00
|
|
|
int dclip;
|
|
|
|
int uclip;
|
|
|
|
int lclip;
|
|
|
|
int 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
|
|
|
double top;
|
|
|
|
double left;
|
2007-12-20 04:36:43 +00:00
|
|
|
fixed_t 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
|
|
|
uint32 fillcolor;
|
- 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
|
|
|
FRemapTable *remap;
|
|
|
|
const BYTE *translation;
|
2009-11-18 04:45:20 +00:00
|
|
|
uint32 colorOverlay;
|
2007-12-20 04:36:43 +00:00
|
|
|
INTBOOL alphaChannel;
|
|
|
|
INTBOOL flipX;
|
|
|
|
fixed_t shadowAlpha;
|
|
|
|
int shadowColor;
|
|
|
|
INTBOOL keepratio;
|
|
|
|
INTBOOL masked;
|
- 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
|
|
|
INTBOOL bilinear;
|
- 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
|
|
|
FRenderStyle style;
|
2009-09-21 13:15:36 +00:00
|
|
|
struct FSpecialColormap *specialcolormap;
|
2009-09-20 03:50:05 +00:00
|
|
|
struct FColormapStyle *colormapstyle;
|
2007-12-20 04:36:43 +00:00
|
|
|
};
|
|
|
|
|
2009-07-04 18:17:44 +00:00
|
|
|
protected:
|
|
|
|
BYTE *Buffer;
|
|
|
|
int Width;
|
|
|
|
int Height;
|
|
|
|
int Pitch;
|
|
|
|
int LockCount;
|
|
|
|
|
2006-09-14 00:02:31 +00:00
|
|
|
bool ClipBox (int &left, int &top, int &width, int &height, const BYTE *&src, const int srcpitch) 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
|
|
|
virtual void STACK_ARGS DrawTextureV (FTexture *img, double x, double y, uint32 tag, va_list tags);
|
|
|
|
bool ParseDrawTextureTags (FTexture *img, double x, double y, uint32 tag, va_list tags, DrawParms *parms, bool hw) const;
|
2006-02-24 04:48:15 +00:00
|
|
|
|
2006-11-19 02:10:25 +00:00
|
|
|
DCanvas() {}
|
|
|
|
|
2006-02-24 04:48:15 +00:00
|
|
|
private:
|
|
|
|
// Keep track of canvases, for automatic destruction at exit
|
|
|
|
DCanvas *Next;
|
|
|
|
static DCanvas *CanvasChain;
|
2007-12-24 14:24:24 +00:00
|
|
|
|
|
|
|
void PUTTRANSDOT (int xx, int yy, int basecolor, int level);
|
2006-02-24 04:48:15 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
// A canvas in system memory.
|
|
|
|
|
|
|
|
class DSimpleCanvas : public DCanvas
|
|
|
|
{
|
|
|
|
DECLARE_CLASS (DSimpleCanvas, DCanvas)
|
|
|
|
public:
|
|
|
|
DSimpleCanvas (int width, int height);
|
|
|
|
~DSimpleCanvas ();
|
|
|
|
|
|
|
|
bool IsValid ();
|
2014-01-06 00:50:09 +00:00
|
|
|
bool Lock (bool buffered=true);
|
2006-02-24 04:48:15 +00:00
|
|
|
void Unlock ();
|
|
|
|
|
|
|
|
protected:
|
|
|
|
BYTE *MemBuffer;
|
2006-11-19 02:10:25 +00:00
|
|
|
|
|
|
|
DSimpleCanvas() {}
|
2006-02-24 04:48:15 +00:00
|
|
|
};
|
|
|
|
|
2008-01-10 04:11:38 +00:00
|
|
|
// This class represents a native texture, as opposed to an FTexture.
|
|
|
|
class FNativeTexture
|
|
|
|
{
|
|
|
|
public:
|
|
|
|
virtual ~FNativeTexture();
|
|
|
|
virtual bool Update() = 0;
|
|
|
|
virtual bool CheckWrapping(bool wrapping);
|
|
|
|
};
|
|
|
|
|
|
|
|
// This class represents a texture lookup palette.
|
|
|
|
class FNativePalette
|
|
|
|
{
|
|
|
|
public:
|
|
|
|
virtual ~FNativePalette();
|
|
|
|
virtual bool Update() = 0;
|
|
|
|
};
|
|
|
|
|
2006-02-24 04:48:15 +00:00
|
|
|
// A canvas that represents the actual display. The video code is responsible
|
|
|
|
// for actually implementing this. Built on top of SimpleCanvas, because it
|
|
|
|
// needs a system memory buffer when buffered output is enabled.
|
|
|
|
|
|
|
|
class DFrameBuffer : public DSimpleCanvas
|
|
|
|
{
|
|
|
|
DECLARE_ABSTRACT_CLASS (DFrameBuffer, DSimpleCanvas)
|
|
|
|
public:
|
|
|
|
DFrameBuffer (int width, int height);
|
|
|
|
|
|
|
|
// Force the surface to use buffered output if true is passed.
|
|
|
|
virtual bool Lock (bool buffered) = 0;
|
|
|
|
|
|
|
|
// Make the surface visible. Also implies Unlock().
|
|
|
|
virtual void Update () = 0;
|
|
|
|
|
|
|
|
// Return a pointer to 256 palette entries that can be written to.
|
|
|
|
virtual PalEntry *GetPalette () = 0;
|
|
|
|
|
|
|
|
// Stores the palette with flash blended in into 256 dwords
|
|
|
|
virtual void GetFlashedPalette (PalEntry palette[256]) = 0;
|
|
|
|
|
|
|
|
// Mark the palette as changed. It will be updated on the next Update().
|
|
|
|
virtual void UpdatePalette () = 0;
|
|
|
|
|
|
|
|
// Sets the gamma level. Returns false if the hardware does not support
|
|
|
|
// gamma changing. (Always true for now, since palettes can always be
|
|
|
|
// gamma adjusted.)
|
|
|
|
virtual bool SetGamma (float gamma) = 0;
|
|
|
|
|
|
|
|
// Sets a color flash. RGB is the color, and amount is 0-256, with 256
|
|
|
|
// being all flash and 0 being no flash. Returns false if the hardware
|
|
|
|
// does not support this. (Always true for now, since palettes can always
|
|
|
|
// be flashed.)
|
|
|
|
virtual bool SetFlash (PalEntry rgb, int amount) = 0;
|
|
|
|
|
|
|
|
// Converse of SetFlash
|
|
|
|
virtual void GetFlash (PalEntry &rgb, int &amount) = 0;
|
|
|
|
|
|
|
|
// Returns the number of video pages the frame buffer is using.
|
|
|
|
virtual int GetPageCount () = 0;
|
|
|
|
|
|
|
|
// Returns true if running fullscreen.
|
|
|
|
virtual bool IsFullscreen () = 0;
|
|
|
|
|
2006-11-19 02:10:25 +00:00
|
|
|
// Changes the vsync setting, if supported by the device.
|
|
|
|
virtual void SetVSync (bool vsync);
|
|
|
|
|
2008-02-19 02:48:56 +00:00
|
|
|
// Tells the device to recreate itself with the new setting from vid_refreshrate.
|
|
|
|
virtual void NewRefreshRate ();
|
|
|
|
|
- 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
|
|
|
// Set the rect defining the area affected by blending.
|
2007-12-20 04:36:43 +00:00
|
|
|
virtual void SetBlendingRect (int x1, int y1, int x2, int y2);
|
|
|
|
|
2007-12-27 04:30:12 +00:00
|
|
|
bool Accel2D; // If true, 2D drawing can be accelerated.
|
2007-12-20 04:36:43 +00:00
|
|
|
|
|
|
|
// Begin 2D drawing operations. This is like Update, but it doesn't end
|
2008-01-02 05:21:48 +00:00
|
|
|
// the scene, and it doesn't present the image yet. If you are going to
|
|
|
|
// be covering the entire screen with 2D elements, then pass false to
|
2009-09-20 03:50:05 +00:00
|
|
|
// avoid copying the software buffer to the screen.
|
2008-01-02 05:21:48 +00:00
|
|
|
// Returns true if hardware-accelerated 2D has been entered, false if not.
|
|
|
|
virtual bool Begin2D(bool copy3d);
|
2007-12-20 04:36:43 +00:00
|
|
|
|
2007-12-22 04:00:25 +00:00
|
|
|
// DrawTexture calls after Begin2D use native textures.
|
2007-12-20 04:36:43 +00:00
|
|
|
|
2009-09-20 03:50:05 +00:00
|
|
|
// Draws the blending rectangle over the viewwindow if in hardware-
|
|
|
|
// accelerated 2D mode.
|
|
|
|
virtual void DrawBlendingRect();
|
|
|
|
|
2007-12-20 04:36:43 +00:00
|
|
|
// Create a native texture from a game texture.
|
2008-01-10 04:11:38 +00:00
|
|
|
virtual FNativeTexture *CreateTexture(FTexture *gametex, bool wrapping);
|
2007-12-20 04:36:43 +00:00
|
|
|
|
2008-01-10 04:11:38 +00:00
|
|
|
// Create a palette texture from a remap/palette table.
|
|
|
|
virtual FNativePalette *CreatePalette(FRemapTable *remap);
|
2007-12-18 01:50:08 +00:00
|
|
|
|
2008-01-28 10:23:18 +00:00
|
|
|
// Precaches or unloads a texture
|
2010-07-28 21:48:24 +00:00
|
|
|
virtual void GetHitlist(BYTE *hitlist);
|
2008-01-28 10:23:18 +00:00
|
|
|
|
2010-12-15 18:57:39 +00:00
|
|
|
// Report a game restart
|
|
|
|
virtual void GameRestart();
|
|
|
|
|
2007-12-30 04:18:39 +00:00
|
|
|
// Screen wiping
|
|
|
|
virtual bool WipeStartScreen(int type);
|
|
|
|
virtual void WipeEndScreen();
|
|
|
|
virtual bool WipeDo(int ticks);
|
|
|
|
virtual void WipeCleanup();
|
2015-04-16 22:39:45 +00:00
|
|
|
|
|
|
|
virtual void ScaleCoordsFromWindow(SWORD &x, SWORD &y) {}
|
2007-12-20 18:53:35 +00:00
|
|
|
|
2009-11-18 04:45:20 +00:00
|
|
|
uint32 GetLastFPS() const { return LastCount; }
|
2009-11-06 06:56:25 +00:00
|
|
|
|
2006-02-24 04:48:15 +00:00
|
|
|
#ifdef _WIN32
|
|
|
|
virtual void PaletteChanged () = 0;
|
|
|
|
virtual int QueryNewPalette () = 0;
|
2012-07-05 21:46:03 +00:00
|
|
|
virtual bool Is8BitMode() = 0;
|
2006-02-24 04:48:15 +00:00
|
|
|
#endif
|
|
|
|
|
|
|
|
protected:
|
|
|
|
void DrawRateStuff ();
|
|
|
|
void CopyFromBuff (BYTE *src, int srcPitch, int width, int height, BYTE *dest);
|
|
|
|
|
2006-11-19 02:10:25 +00:00
|
|
|
DFrameBuffer () {}
|
|
|
|
|
2006-02-24 04:48:15 +00:00
|
|
|
private:
|
2009-11-18 04:45:20 +00:00
|
|
|
uint32 LastMS, LastSec, FrameCount, LastCount, LastTic;
|
2006-02-24 04:48:15 +00:00
|
|
|
};
|
|
|
|
|
2008-04-14 12:10:45 +00:00
|
|
|
|
2006-02-24 04:48:15 +00:00
|
|
|
// This is the screen updated by I_FinishUpdate.
|
|
|
|
extern DFrameBuffer *screen;
|
|
|
|
|
|
|
|
#define SCREENWIDTH (screen->GetWidth ())
|
|
|
|
#define SCREENHEIGHT (screen->GetHeight ())
|
|
|
|
#define SCREENPITCH (screen->GetPitch ())
|
|
|
|
|
|
|
|
EXTERN_CVAR (Float, Gamma)
|
|
|
|
|
|
|
|
// Translucency tables
|
- 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
|
|
|
|
|
|
|
// RGB32k is a normal R5G5B5 -> palette lookup table.
|
2015-03-08 23:05:02 +00:00
|
|
|
|
|
|
|
// Use a union so we can "overflow" without warnings.
|
|
|
|
// Otherwise, we get stuff like this from Clang (when compiled
|
|
|
|
// with -fsanitize=bounds) while running:
|
|
|
|
// src/v_video.cpp:390:12: runtime error: index 1068 out of bounds for type 'BYTE [32]'
|
|
|
|
// src/r_draw.cpp:273:11: runtime error: index 1057 out of bounds for type 'BYTE [32]'
|
|
|
|
union ColorTable32k
|
|
|
|
{
|
|
|
|
BYTE RGB[32][32][32];
|
|
|
|
BYTE All[32 *32 *32];
|
|
|
|
};
|
|
|
|
extern "C" ColorTable32k RGB32k;
|
- 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
|
|
|
|
|
|
|
// Col2RGB8 is a pre-multiplied palette for color lookup. It is stored in a
|
|
|
|
// special R10B10G10 format for efficient blending computation.
|
|
|
|
// --RRRRRrrr--BBBBBbbb--GGGGGggg-- at level 64
|
|
|
|
// --------rrrr------bbbb------gggg at level 1
|
|
|
|
extern "C" DWORD Col2RGB8[65][256];
|
|
|
|
|
|
|
|
// Col2RGB8_LessPrecision is the same as Col2RGB8, but the LSB for red
|
|
|
|
// and blue are forced to zero, so if the blend overflows, it won't spill
|
|
|
|
// over into the next component's value.
|
|
|
|
// --RRRRRrrr-#BBBBBbbb-#GGGGGggg-- at level 64
|
|
|
|
// --------rrr#------bbb#------gggg at level 1
|
2006-02-24 04:48:15 +00:00
|
|
|
extern "C" DWORD *Col2RGB8_LessPrecision[65];
|
|
|
|
|
- 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
|
|
|
// Col2RGB8_Inverse is the same as Col2RGB8_LessPrecision, except the source
|
|
|
|
// palette has been inverted.
|
|
|
|
extern "C" DWORD Col2RGB8_Inverse[65][256];
|
|
|
|
|
|
|
|
// "Magic" numbers used during the blending:
|
|
|
|
// --000001111100000111110000011111 = 0x01f07c1f
|
|
|
|
// -0111111111011111111101111111111 = 0x3FEFFBFF
|
|
|
|
// -1000000000100000000010000000000 = 0x40100400
|
|
|
|
// ------10000000001000000000100000 = 0x40100400 >> 5
|
|
|
|
// --11111-----11111-----11111----- = 0x40100400 - (0x40100400 >> 5) aka "white"
|
|
|
|
// --111111111111111111111111111111 = 0x3FFFFFFF
|
|
|
|
|
2006-02-24 04:48:15 +00:00
|
|
|
// Allocates buffer screens, call before R_Init.
|
2010-12-15 11:45:39 +00:00
|
|
|
void V_Init (bool restart);
|
2006-02-24 04:48:15 +00:00
|
|
|
|
Note: I have not tried compiling these recent changes under Linux. I wouldn't
be surprised if it doesn't work.
- Reorganized the network startup loops so now they are event driven. There is
a single function that gets called to drive it, and it uses callbacks to
perform the different stages of the synchronization. This lets me have a nice,
responsive abort button instead of the previous unannounced hit-escape-to-
abort behavior, and I think the rearranged code is slightly easier to
understand too.
- Increased the number of bytes for version info during D_ArbitrateNetStart(),
in preparation for the day when NETGAMEVERSION requires more than one byte.
- I noticed an issue with Vista RC1 and the new fatal error setup. Even after
releasing a DirectDraw or Direct3D interface, the DWM can still use the
last image drawn using them when it composites the window. It doesn't always
do it but it does often enough that it is a real problem. At this point, I
don't know if it's a problem with the release version of Vista or not.
After messing around, I discovered the problem was caused by ~Win32Video()
hiding the window and then having it immediately shown soon after. The DWM
kept an image of the window to do the transition effect with, and then when
it didn't get a chance to do the transition, it didn't properly forget about
its saved image and kept plastering it on top of everything else
underneath.
- Added a network synchronization panel to the window during netgame startup.
- Fixed: PClass::CreateDerivedClass() must initialize StateList to NULL.
Otherwise, classic DECORATE definitions generate a big, fat crash.
- Resurrected the R_Init progress bar, now as a standard Windows control.
- Removed the sound failure dialog. The FMOD setup already defaulted to no
sound if initialization failed, so this only applies when snd_output is set
to "alternate" which now also falls back to no sound. In addition, it wasn't
working right, and I didn't feel like fixing it for the probably 0% of users
it affected.
- Fixed: The edit control used for logging output added text in reverse order
on Win9x.
- Went back to the roots and made graphics initialization one of the last
things to happen during setup. Now the startup text is visible again. More
importantly, the main window is no longer created invisible, which seems
to cause trouble with it not always appearing in the taskbar. The fatal
error dialog is now also embedded in the main window instead of being a
separate modal dialog, so you can play with the log window to see any
problems that might be reported there.
Rather than completely restoring the original startup order, I tried to
keep things as close to the way they were with early graphics startup. In
particular, V_Init() now creates a dummy screen so that things that need
screen dimensions can get them. It gets replaced by the real screen later
in I_InitGraphics(). Will need to check this under Linux to make sure it
didn't cause any problems there.
- Removed the following stubs that just called functions in Video:
- I_StartModeIterator()
- I_NextMode()
- I_DisplayType()
I_FullscreenChanged() was also removed, and a new fullscreen parameter
was added to IVideo::StartModeIterator(), since that's all it controlled.
- Renamed I_InitHardware() back to I_InitGraphics(), since that's all it's
initialized post-1.22.
SVN r416 (trunk)
2006-12-19 04:09:10 +00:00
|
|
|
// Initializes graphics mode for the first time.
|
|
|
|
void V_Init2 ();
|
|
|
|
|
2006-05-12 03:14:40 +00:00
|
|
|
void V_Shutdown ();
|
|
|
|
|
2006-02-24 04:48:15 +00:00
|
|
|
void V_MarkRect (int x, int y, int width, int height);
|
|
|
|
|
|
|
|
// Returns the closest color to the one desired. String
|
|
|
|
// should be of the form "rr gg bb".
|
|
|
|
int V_GetColorFromString (const DWORD *palette, const char *colorstring);
|
|
|
|
// Scans through the X11R6RGB lump for a matching color
|
|
|
|
// and returns a color string suitable for V_GetColorFromString.
|
2006-08-30 02:38:39 +00:00
|
|
|
FString V_GetColorStringByName (const char *name);
|
2006-02-24 04:48:15 +00:00
|
|
|
|
|
|
|
// Tries to get color by name, then by string
|
|
|
|
int V_GetColor (const DWORD *palette, const char *str);
|
2010-09-14 17:28:18 +00:00
|
|
|
void V_DrawFrame (int left, int top, int width, int height);
|
2006-02-24 04:48:15 +00:00
|
|
|
|
2011-07-05 20:41:53 +00:00
|
|
|
// If the view size is not full screen, draws a border around it.
|
|
|
|
void V_DrawBorder (int x1, int y1, int x2, int y2);
|
|
|
|
void V_RefreshViewBorder ();
|
|
|
|
|
2013-02-27 03:10:25 +00:00
|
|
|
void V_SetBorderNeedRefresh();
|
2011-07-05 20:41:53 +00:00
|
|
|
|
- Ported vlinetallasm4 to AMD64 assembly. Even with the increased number of
registers AMD64 provides, this routine still needs to be written as self-
modifying code for maximum performance. The additional registers do allow
for further optimization over the x86 version by allowing all four pixels
to be in flight at the same time. The end result is that AMD64 ASM is about
2.18 times faster than AMD64 C and about 1.06 times faster than x86 ASM.
(For further comparison, AMD64 C and x86 C are practically the same for
this function.) Should I port any more assembly to AMD64, mvlineasm4 is the
most likely candidate, but it's not used enough at this point to bother.
Also, this may or may not work with Linux at the moment, since it doesn't
have the eh_handler metadata. Win64 is easier, since I just need to
structure the function prologue and epilogue properly and use some
assembler directives/macros to automatically generate the metadata. And
that brings up another point: You need YASM to assemble the AMD64 code,
because NASM doesn't support the Win64 metadata directives.
- Added an SSE version of DoBlending. This is strictly C intrinsics.
VC++ still throws around unneccessary register moves. GCC seems to be
pretty close to optimal, requiring only about 2 cycles/color. They're
both faster than my hand-written MMX routine, so I don't need to feel
bad about not hand-optimizing this for x64 builds.
- Removed an extra instruction from DoBlending_MMX, transposed two
instructions, and unrolled it once, shaving off about 80 cycles from the
time required to blend 256 palette entries. Why? Because I tried writing
a C version of the routine using compiler intrinsics and was appalled by
all the extra movq's VC++ added to the code. GCC was better, but still
generated extra instructions. I only wanted a C version because I can't
use inline assembly with VC++'s x64 compiler, and x64 assembly is a bit
of a pain. (It's a pain because Linux and Windows have different calling
conventions, and you need to maintain extra metadata for functions.) So,
the assembly version stays and the C version stays out.
- Removed all the pixel doubling r_detail modes, since the one platform they
were intended to assist (486) actually sees very little benefit from them.
- Rewrote CheckMMX in C and renamed it to CheckCPU.
- Fixed: CPUID function 0x80000005 is specified to return detailed L1 cache
only for AMD processors, so we must not use it on other architectures, or
we end up overwriting the L1 cache line size with 0 or some other number
we don't actually understand.
SVN r1134 (trunk)
2008-08-09 03:13:43 +00:00
|
|
|
#if defined(X86_ASM) || defined(X64_ASM)
|
2006-02-24 04:48:15 +00:00
|
|
|
extern "C" void ASM_PatchPitch (void);
|
|
|
|
#endif
|
|
|
|
|
2011-01-02 18:02:27 +00:00
|
|
|
int CheckRatio (int width, int height, int *trueratio=NULL);
|
- 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
|
|
|
static inline int CheckRatio (double width, double height) { return CheckRatio(int(width), int(height)); }
|
2006-02-24 04:48:15 +00:00
|
|
|
extern const int BaseRatioSizes[5][4];
|
|
|
|
|
2007-12-20 18:53:35 +00:00
|
|
|
|
|
|
|
|
2006-02-24 04:48:15 +00:00
|
|
|
#endif // __V_VIDEO_H__
|