Re: [AD] about DX windowed mode

[Shawn Hargreaves <shawn@xxxxxxxxxx>]

Isaac Cruz <ICRUZBAL@xxxxxxxxxxx> writes:
> About inline MMX asm: I only use MSVC, and its syntax is _asm {.....},
> supporting MMX instructions, but what about the rest of windows compilers?

A good question :-) The most portable method is actually to write the asm 
code in AT&T format as a .s file, which all the compilers will be able to 
use somehow. To make this sort of code portable you need to:

- include "../i386/asmdefs.inc" at the top of it
- use FUNC(function_name) to declare the start of your functions
- use GLOBL(variable_name) to access global variables
- declare all global variables in C files, not .s ones
- don't call C functions from .s files: that doesn't work portably

If you don't know or like the AT&T syntax you can always stick with inline 
asm, but then we'll either need to convert it for other compilers (not a 
huge job, but still some work and chance of errors), or keep a straight C 
version around as an alternative.

> 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?

I tend to agree: I think it's important that the DOS and Linux console 
versions work ok on machines right down to a 386, but nobody (or at least 
nobody sensible :-) runs DirectX games on less than a Pentium, and 
especially the windowed mode with color conversions will be too slow to be 
useful on anything but a fairly fast one.

But if this worries you, you could always do a simple (not optimised) C 
version, to use on machines without MMX, and for other compilers.

> 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?

That's an interesting one. I have no idea, but would be tempted to play it 
safe and use 32 bit writes. This is purely my paranoia speaking, though, so 
please correct me if anyone knows better and can confirm that 64 bit writes 
are ok...

> 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.

That's a shame. No hardware acceleration for different-depth windowed modes, 
then. Not that it is really so important to have hardware rectfill in the 
backbuffer, when you still have to software convert the pixel format during 
the copy to the real screen :-)

> 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.

Ouch. Presumably this same problem will happen with any system bitmap 
objects? It's quite possible that this has just never been tested, since I 
don't think anyone has used these very much yet. I ought to add them as an 
option in something like exupdate, since there are a couple of potentially 
useful ways that they can optimise drawing on Windows systems that have 
system <-> vram copy acceleration, and it would be good to have at least one 
example that does actually test these :-)

> 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?

The problem is that the first time destroy_bitmap() is called, it passes the 
request on to the system driver, but then when it is called again by 
gfx_directx_destroy_system_bitmap(), it ought to just destroy the bitmap 
normally, as by this point the system-bitmapness of the object has already 
been removed. I think this can be fixed if you clear the system bitmap flag 
just before the call to destroy_bitmap() inside 
gfx_directx_destroy_system_bitmap(): try adding:

   bitmap->id &= ~BMP_ID_SYSTEM;

> 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)

Another option would be just to always use the GDI driver when color depths 
don't match. I don't have really strong feelings either way: a DirectDraw 
windowed driver with software conversion should be many times faster than 
the GDI one, but it will still be very slow, so probably only useful for 
debugging and editing apps rather than 'real' programs, so I can see a case 
for saying that performance isn't important here, and the GDI method is ok. 
It all comes down to whether you think the speed gain is worth the hassle of 
coding all the conversion routines: if you don't, we can always leave that 
for someone else to do if they ever need it. Or you could always just write 
a simple C version, and not worry about optimising it at all: even a very 
stupid implementation should be at least slightly faster than using GDI!



--
Shawn Hargreaves - shawn@xxxxxxxxxx - http://www.talula.demon.co.uk/
"A binary is barely software: it's more like hardware on a floppy disk."