can share the same hardware texture. This greatly reduces the number of
DrawPrimitive calls that need to be made when drawing text (or any 2D
graphics in general), so now hardware text is much faster than software text
all around. (As an example, one scenario went from 315 fps to over 1635 fps
for hardware, compared to 540 fps for software.)
SVN r687 (trunk)
- Modified M_DrawFrame() and R_DrawTopBorder() so that they call FlatFill() to
draw the edges of the frames. This at least seems a bit faster for hardware
2D.
- Implemented FlatFill() for D3DFB. It seems to be exactly as fast as the
default implementation that just calls DrawTexture() to tile the pieces onto
the screen, so I'm not sure it was worth the bother.
SVN r686 (trunk)
vertex buffer, made line batching automatic, and added an index buffer for
use when batching quads. The index buffer actually offered more of a
performance boost than simply batching the quads alone did.
SVN r685 (trunk)
players are on teams.
- Set TEAM_None back to 255. Since a player's team has already been accessible
through ACS, needlessly redefining this is a bad thing to do, since it can
break existing maps. 255 different teams should still be more than enough.
- Fixed: At certain resolutions, there was a one pixel row between the status
bar and the rest of the screen, thanks to rounding error.
- Added automatic batching of quads to D3DFB. Screens with a lot of text are
ever-so-slightly faster now, though still only about half the speed of
sofware-only text. I suppose the only way to see a marked improvement is
going to be by stuffing multiple glyphs in a single texture.
- Fixed: Crosshairgrow's animation was not framerate-independent.
SVN r668 (trunk)
and into the vertex data.
- Added functions for doing line drawing with Direct3D, including a new pair
of functions to do batched line drawing so that the map can actually be
drawn faster in hardware than in software (instead of an order of magnitude
slower).
SVN r663 (trunk)
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)
since I couldn't think of any reason why it should be grabbed at any other
time. (This only applies to windowed mode, where it makes sense to let the
OS have control of the pointer.)
SVN r661 (trunk)
a long-abandoned experiment to write directly to video memory instead of
to a temporary buffer in system meroy.
- Added Direct3D versions of the melt and burn screenwipes.
- Fixed the strip sizes for the melt screenwipe to match what Doom would have
produced on a 320x200 screen, rather than producing more, thinner strips
for wider screens.
SVN r659 (trunk)
allocated. (I wonder if D3D actually handles this automatically when you use
D3DPOOL_MANAGED, because I'm pretty sure my laptops's x300 doesn't support
non-power-of-2 texture sizes, yet it worked just fine before.)
- Fixed vertical positioning of 2D elements in letterboxed modes.
SVN r653 (trunk)
drawn to a texture, then that texture is copied to the real back buffer
using a gamma-correcting pixel shader. In fullscreen mode, SetGammaRamp
is used.
- Fixed flashing of vid_fps display when fps > 1000.
- Fixed loading of RGB textures for native 2D mode.
- Changed the first rotozoomer's data because it just became too obvious when
the backdrop is drawn with a full 256 distinct colors available.
- Set the player backdrop to update no more frequently than 35 FPS, so opening
the player setup menu before starting a game won't produce a very fast
moving backdrop.
- Changed the player backdrop into a texture so that it can be drawn like
anything else.
SVN r648 (trunk)
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)
- 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)
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)
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)
- Fixed: If the FBTexture wasn't exactly the same size as the screen,
D3DFB::PaintToWindow() would still lock it with D3DLOCK_DISCARD. Alas,
I saw no speedup for using a dirty region. (Side note: The Radeons are
apparently slower compared to DirectDraw because they must do
power-of-2 textures. If they ever add non-power-of-2 support like nvidia,
I assume they will also see a speed gain.)
- Changed fb_d3d9.cpp so that instead of trying to compensate for Geforce
off-by-one errors in the pixel shader, it automatically detects where
the error occurs and modifies the way the palette is uploaded to
compensate. Palette color 255 is then represented using the texture
border color instead of actually being part of the palette. This should
work correctly with all cards, since I had a report of an FX where the
off-by-one occurred in a different spot from the place where I observed
it on a 6 and 7 series cards. Since the shader now has one fewer
instruction, I notice a very marginal speedup. (Interestingly, removing
the flash blending from the shader had no perceivable performance gain.)
SVN r399 (trunk)
