[AD] about DX windowed mode

["Isaac Cruz" <ICRUZBAL@xxxxxxxxxxx>]

I've been working on directX windowed mode to support different color depths as
the desktop. What I've done is to define "update_window" as a pointer to a
function, and in the init routine, check the color depth of the desktop and the
requested one to see which function to use (DX blit or software blit converting
between color depths). So far I've coded only the function that converts from 32
bit to 16 bit, and it's not very optimized.

The routine is too slow (I have a K6-2 350, TNT), so I've thought about using
inline asm with MMX (which should accelerate the routine a lot), and use a
boolean variable called "screen_changed", so it will only perform the blit if
screen has changed. Now some questions:

About inline MMX asm: I only use MSVC, and its syntax is _asm {.....},
supporting MMX instructions, but what about the rest of windows compilers?
Also, I think most processors now support MMX, and those which don't are too
slow to use this software blitting. What do you think?

Does video cards support 64 bit writes to video mem? That is, using movq
[video_mem], mm0. I think PCI is only 32 bit wide, but would this slow things
too much? Would it be better using two 32 bit writes instead of one 64 bit
write?

A problem I have encountered: In directx you can't create a surface in video mem
with a different color depth as the primary surface, so I have to create the
offscreen buffer in system memory. So there was a little bug in Allegro when
shutting down gfx: when it was to destroy screen (a system_bitmap), it called
destroy_bitmap, which called gfx_directx_destroy_system_bitmap. But the problem
is that this function calls again destroy_bitmap, so it was repeating the same
calls again and again. I fixed this by removing the destroy_bitmap line in
function
gfx_directx... But the problem I now have is that in debug buildings I get a
stack overflow error just when calling release_directx_bitmap (destroying
screen). Any suggestions?

Finally I wonder if it is worth implementing this kind of software blitting to
support different color depths. Other solutions are: the program using this
windowed mode can support different color depths, or just fail telling the user
to switch the desktop res; use GDI to change the desktop resolution to the color
depth requested (not a very clean solution though)