Normally Direct3D sets the FPU to single precision. We don't want that,
since it can mean going out of sync with machines that are using the
standard precision. Additionally, the nodebuilder requires the extra
precision that single precision lacks.
SVN r455 (trunk)
warnings. At first, I was going to try and clean them all up. Then I decided
that was a worthless cause and went about just acting on the ones that
might actually be helpful:
C4189 (local variable is initialized but not referenced)
C4702 (unreachable code)
C4512 (assignment operator could not be generated)
SVN r420 (trunk)
otherwise it gets reset to black and unused.
- Fixed: I_SetWndProc() needs to be called before any of the DirectX
interfaces are initialized, because DirectX subclasses the window itself,
and I_SetWndProc() undoes that subclassing.
SVN r419 (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)
to PO_MovePolyobj() from P_SerializePolyobjs() for a crushing polyobject
that touches a player actor will not have a valid actor->player->mo chain
for P_DamageMobj and crash if it happens to touch the player. Since the
polyobject was presumably in a good spot when the game was saved, we can
just skip this step entirely and let it take care of itself the next time
it moves (by which time, the players will be valid).
- Fixed: When transitioning from fullscreen to windowed mode with D3DFB, the
window kept the WS_EX_TOPMOST style.
- Slight correctness fix: When in fullscreen, the window should have WS_POPUP
style.
- Added a NULL target check to P_SpawnMissileXYZ(), A_DemonAttack1(),
A_DemonAttack2_1(), and A_DemonAttack2_2().
SVN r384 (trunk)
