I had to head home early from work today due to what feels like heat exhaustion. As I was resting, I had mad fever dreams about how best to fix the flickering from UltraMon.
After some heavy research, It seems to be a symptom of DirectX - after all, I'm trying to capture hardware overlays. I decided that I'm using a lot of system resource, and an imperfect solution to resolve this issue. In response, I've developed my own little solution.
I've posted the Source Code below. Though the interval on the timer should be 50, not 25. It seems quite simple, but it's the result of a few hours of research and coding. I began with BitBlt calls from GDI, but ultimately settled on Graphics.CopyFromScreen() (basically the same thing, but a lot easier to code).
I added in some command-line parameters to override the hard-coded screen coordinates if needed.
Finally, the application presented the same problems that Ultramon did, in that the display flickered every few frames. As a workaround, I recorded the pixel values of random locations for every frame. This allowed me to identify which frames were blank. As I'm now using my own code, it was simple to ignore these blank frames.
The end result is a constant output with far less flickering, and far less impact on system performance. The frame rate is sporadic, only updating approx 2/3rds of the output desired, and there is no hardware overlay. However, the dimensions of the output are now almost perfect, and it's a lot better than a constantly flickering device. As a nice bonus, I can now "activate" the display by launching a single application - currently it's in the Windows Startup folder!
I've been looking into Direct X Hooks to capture the true 3d output. This would be the best result, and tests with SlimDX on my desktop were very promising, however there seems to be some comparability issues on the gaming rig, so for now, this will have to do.
No comments:
Post a Comment