I am running Windows Vista, using the latest version of FCEUX (Although this has been a problem for all versions of FCEU I have used.)
I am using windowed mode, and all video options are set to default.
Now, the problem is when I switch to a different window, then switch back to FCEUX, it seems that FCEUX's drawing canvas gets set wrong, and the display gets broken. The part of the FCEUX window that overlapped with the window I switched out of will be redrawn as normal, but the rest of the window is frozen with the image displayed as it was when I switched over.
This is very annoying, as it can cause many user errors when trying to play normally (or even TASing) when half the screen is frozen. It has caused me to lose many battles in many games because I wonder for a second why my character isn't moving, then I die. :/
The problem is fixed as soon as the FCEUX window is moved or resized. But I have to wonder if this is a bug that can be fixed on the Windows platform, or if there could be a video-related workaround for it.
I realized that using the screencap command also fixes the issue. So maybe some kind of refresh command is called in the screencap procedure that could be used in the focus get procedure to fix the problem.
It seems to be a bug in the Direct X library incorrectly detecting a window overlay (in Windows Vista with Aero enabled all windows have their contents drawn no matter what and then they are arranged, in non-accelerated desktops windows that did not occupy space simply weren't drawn to the screen, the version of the library assumes the latter behavior I guess)
FCEU doesn't actually check for focus in either its Text Drawing Routines, its screen drawing routines. It checks for focus in src/windows/drivers/windows.cpp and stores it in a variable called nofocus. (BTW the person who wrote the windows code used some.... creative, yet nondescript variable names)
It seems that the magic occurs when you try to draw text to the screen (with the snapshot routine.) Why the routine to draw text to the screen causes DirectX to stop bugging is beyond me.
Also:
omnipotententity@oberus% grep -i -R -C3 destionation *
drivers/win/directx/ddraw.h-
drivers/win/directx/ddraw.h-/*
drivers/win/directx/ddraw.h- * returned when GetOverlayPosition is called on a overlay that UpdateOverlay
drivers/win/directx/ddraw.h: * has never been called on to establish a destionation.
drivers/win/directx/ddraw.h- */
drivers/win/directx/ddraw.h-#define DDERR_NOOVERLAYDEST MAKE_DDHRESULT( 578 )
drivers/win/directx/ddraw.h-
drivers/win/directx/ddraw.h-/*
drivers/win/directx/ddraw.h: * returned when the position of the overlay on the destionation is no longer
drivers/win/directx/ddraw.h: * legal for that destionation.
drivers/win/directx/ddraw.h- */
drivers/win/directx/ddraw.h-#define DDERR_INVALIDPOSITION MAKE_DDHRESULT( 579 )
drivers/win/directx/ddraw.h-
I could, of course be terribly wrong. If that is the case, you never saw me, I was never here.
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.
For Windows Vista or even 7, I always close the other windows (even Explorer-related) when I run FCEU(X). And to ensure it behaves, I go into Task Manager and set priority to "Above Normal". How many of you ever tried that?
