+ MultiBufferDuke has problems.  On a Windows 2000 machine with a Matrox Millenium II, a few of the display modes do not work (color problems).  From 24-bpp,  640x480x8x60 looks corrupted, as if drawing in the wrong depth, as do 800x600x8x60 and 512x384x8x85.  1024x768x8x60 flashes (strobes, really).
320x200x8x85 paints the sprite strangely, as if it's starting at the wrong memory location.

+ win98+Voodoo3, MultiBufferDuke: 8, 16 and 24 bit modes have color problems (even though the build was run locally), no matter what the desktop depth is. 32 bit is fine.

+ DukeRoids: This tends to have bad color problems.  On win2k, start in
16 bit mode. It works by default (1024x768x16).  When run with -d 32 option, colors are hosed. Run with -d 8 bad colors plus a crash when exiting.

N/A

Committing to mantis.
 xxxxx@xxxxx  2002-05-22

The problem was that we were not replacing the surfaceData object at the right
time.  Previously, we would call setDisplayMode(), followed by 
replaceSurfaceData().  However, there was no way to ensure that the right
stuff would happen in between these two calls to make sure that the new 
surfaceData would have the right color model. Specifically, when we change
display modes, the dynamicColorModel of the GraphicsDevice must be recreated
in the new display mode.  In order for this to happen, the old one must be
nulled-out by the time a request is made to the GraphicsDevice for a new
one.  When the colorModel is null, we cause it to be recreated, which 
forces us to examine the new color info for the new display mode.

What used to happen is that we would set display mode, not necessarily
null-out the obsolete dynamicColorModel in GraphicsDevice, then we would
create our new surfaceData object.  This new surfaceData object would 
request the dynamicColorModel, would get the reference to the obsolete
object, and would then create the surfaceData with the old (incorrect)
color data.  At the native level, everything would be fine because 
DirectDraw always creates surfaces in the current display mode.  But
the decisions we make in our Java code hinge on the color data at the
Java level, not at the native level, so we would do things like assign
an incorrect scan stride, or an incorrect color value for pixels, etc.

The fix is to wait until the right time to replace the surfaceData.
We currently null-out the obsolete dynamicColorModel when we
receive the WM_DISPLAYCHANGE event (which we receive at some indeterminate
time after the display mode switch).  So we should wait until after that
time to replace the surfaceData object.

The code change is simple; previously we would avoid propagating the
display switch event in some fullscreen situations, but really
we should only avoid recreating the primary.  By simply moving the
end-bracket of the if() clause in the WM_DISPLAYCHANGE case, we
force surfaceData recreations to happen in all cases, which forces all
surfaceData objects to be recreated with the new, correct colorModel
information.

At the same time, we should remove the old replaceSurfaceData() call;
the setDisplayMode() call will force a WM_DISPLAYCHANGE event in cases
where a replacement is necessary (when we have actually changed the
display mode and not just set it to the one that was already active)
and that, in turn, will force its own surfaceData replacement.

 xxxxx@xxxxx  2002-08-27