Is there a reason that "High Color" (16 bit) video modes are not available in Windows 8, other than development deadlines? Several of the programs sold by my company work best when used (at any resolution) when run in 16 bit mode... the lack of this mode is currently keeping me from recommending (or even using) Windows 8.
Any insight or wisdom would be appreciated!!! Thanks.
-JS in Austin, TX
Could you please be more specific about your programs: why do they work better in 16-bit screen modes? Do you use some special rendering technique in them?
Yes... our primary applications are teleprompting packages which require rendering the contents of RTF controls in real time. Smooth scrolling requires rendering frames during VBI... cutting down from 32bit color to 16bit color reduces the number of missed frames. We have used Windows rendering engine for RTF in two of our three applications... the third works well with Windows 8 but requires a "pre-rendering" of the RTF bitmap which slows program operation. Just for reference, TeleScript Pro is used by WHCA (White House Communication Agency), the group which teleprompts POTUS, as well as other executive branch officials. TeleScript Pro and TeleScript AV are generally considered the standard of teleprompting applications. Thanks.
-JS in Austin TX
Argh... RTF rendering. It seems to me that everyone has a problem with it .
Can you please describe shortly the method you use to cut down the color depth from 32-bit to 16-bit? I mean how exactly do you perform it: by using some API (GDI+/DirectDraw/etc) or manually (SIMD extensions, like MMX/SSE/etc)? In the first case, you shouldn't experience the problem you've described, right?
About your third application, which is used a "pre-rendered" technique: is that application a well multi-threaded (at least, a two-threaded) one? If no, then maybe your programmers should perform such an optimization, so your application would improve its quality. Who knows, maybe Windows 8 will never get a proper 16-bit color depth support, so you and your colleagues will have to deal with it.
We use the legacy DirectDraw (IDirectDraw7::SetDisplayMode()) function. Also, of course, we've tried the Windows 8 "compatibility" setting... some computers allow selecting a 16bit mode, but it doesn't really seem to do anything... after launching an application, we do a GetDisplayMode() before trying to set the bit depth -- we change only color depth, not the width or height -- and regardless of the compatibility setting, it has reverted to 32bit color.
Oddly enough, the teleprompter function really gives the system a workout. It is multi-threaded... even at 16 bits, there are a few frames which run long. I wish there were an easy way to access the front buffer when the RTF control is rasterized. It would make life easier!
Thanks for taking the time to respond... I was feeling a bit lonely on this issue!!! <grin>
-Jim in Austin TX.
I'm afraid that in the last versions of Windows, Microsoft has dropped compatibility with some legacy APIs. This means that you and your colleagues will probably have to find a workaround, maybe even to cease the use of DirectDraw and/or Microsoft RTF rendering engine.
I'm aware that many book reader utilities (they are siblings to your programs, aren't they?) use their own text rendering engines, so probably you should analyze how do they work and write your own, new engine. I know, it's a real pain, but right now I just can't see another alternative .
Yes... I'm sure book readers are akin to my applications, however they don't have to render frames inside VBI.
My job has been finding solutions to impossible problems... I guess this will fit with my job description! <grin>
-JS in Austin TX