Hi Bryan, > Actually - almost exactly that - Mame maintains both DD1 and > DD4 in the same binary, it's not even an option. The DD1 device is > created, then a query is made on it to get a DD4 device. If it > succeeds great, if it fails no problem and the DD1 device is used. > > Anything DD4 specific (not very much) just gets tested for: > > if (ddraw4) > result = IDirectDraw4_EnumDisplayModes(ddraw4, > else > result = IDirectDraw_EnumDisplayModes(ddraw, Interesting, that was how I was going to do it as well. I was wary of making it use DD4 automatically, after the experience of inadvertently using DirectSound 7 in v2.3 I really want to avoid any changes to DirectX versions. > Having said that I didn't think hardware stretch required DD4 - I > thought you could just check the caps bits for > DDCAPS_BLTSTRETCH then blit with it. Can't remember the > exact details though so I could be wrong. No, unfortunately many cards are capable of a hardware stretch but don't by default anti-alias it. In "Stretch Blt" mode Steem always uses stretching without checking that flag, that is probably not a good idea actually (I might fix that in the next version). All I could find to force anti-aliasing was DDSCAPS2_HINTANTIALIAS, but I just noticed that it requires the surface to be created with the DDSCAPS_3DDEVICE flag, that could cause some problems. Also it doesn't say whether the source or destination (or both) must have that flag to do anti-aliasing, if it needs to be set on the destination then it will cause more problems (the destination is the primary surface). I really don't want to start fiddling with more surfaces and intermediate blits, that would be nasty, especially for a little option like this. Thanks for your help, Russ -- Steem - http://www.blimey.strayduck.com/ Manage your list membership - //www.freelists.org/ Click here to unsubscribe - mailto:steem-request@xxxxxxxxxxxxx?subject=unsubscribe