Hi there. I created a simple primary surface and a plain offscreen buffer in fullscreen exclusive mode. I put a BMP into the offscreen buffer and blit some rectangles to the primary surface for the user to see. Everything works fine under Win95 and Win98. In *WinNT* the offscreen buffer object pointer is set to zero if the amount of the allocated memory for the offscreen buffer is too much. For example: if the bitmap is a 640x480 my program works fine, but if the bitmap is 800x600 the pointer is set to zero and the program makes an "access violation". It is not a memory problem: memory on the video card is 32MB, and anycase the offscreen buffer is created in system memory when the video card memory would not suffice. Are there any issues between DDraw and WinNT 4 ??? And: why DirectX 7 does not install into WinNT 4 ??? Thanks 4 your help. A.V.
DirectX and Windows NT/2000 have always had incompatibilities. Even though Microsoft -claims- support under the secure OSes, it's really not supported very much (there's a very good reason for this, but most people wouldn't believe me anyway...=)). Therefore, only a few graphics modes are supported in Windows NT and 2000. 640 x 480 with 16 bpp color is one of them, and I think 800 x 600 with any color resolution isn't. I don't know why...the video drivers just query the VBE BIOS on the card to switch graphics modes. Unless, perhaps, Windows NT doesn't allow this, and makes the drivers do everything 'by hand'. (What a waste!) Anyway, the problem is probably due to the graphics resolution, and not to the actual allocation of memory. (And Windows 2000 may in fact be different in this respect. I haven't worked with it, so Win2k lovers and users don't bash me on this. I know that NT 4 does have this problem, however.)
Have you tried to do the surface with a simple IDirectDraw Interface NOT IDirectDraw4...just to test if it works with DirectX 1.0 or 3.0 (version supplied with Win NT 4.0) ? DX5,and DX6 may have problems running on NT...so i have heard... My game for example is alternatively reported to work on NT/2k ....sometimes it works sometimes it dosent....this makes me wannt to install NT4 just for testing... :) and i only use IdriectDraw interfaces...some DX5 in DirectPlay i think...doh i will have to eliminate that also....or i will make a separate version for NT :) however i am in 800x600x16 resolution...i wonder if i have to switch to 640x480 for NT....? This message was edited by BogdanOntanu, on 3/2/2001 11:43:49 PM
I run your game perfectly in win2K on 1600x1200x32 dual processor PC, so even that is covered :)
To Bogdan: I believe that Windows NT 4 out of the box (no service packs) only uses DX1, while SP 4 is said to have DX5, and SP6 has DX7 support. But that's what they say...not necessarily what is true. :) I've had games using DX1 not run in Windows NT 4.0 SP 4. (PS: If you put them in order together, you'll notice the service pack value is the DirectX version-1. Ie: SP2 probably has suppot for DX3, and SP3 is DX4, though it might just be a coincidence.)
Thanks for you answers. I am using DDraw 1. I casually discovered a bug and want to report it here. DDraw7 doc reports: sentence 1: "By default, DirectDraw creates a surface in display memory unless it will not fit, in which case it creates the surface in system memory." sentence 2: "You can explicitly choose display or system memory by including the DDSCAPS_SYSTEMMEMORY or DDSCAPS_VIDEOMEMORY flags in the dwCaps member of the DDSCAPS2 structure." The first sentence is true under Win95/98, it is false under WinNT. If you create a surface that requires more memory than the memory in the video card, the surface will be created in system memory only in Win95/98. In WinNT the create surface method will return a DDERR_NONE, but the long pointer to the ddraw surface will be set to zero (!). To create the surface in system memory under WinNT you *must* explicitly set the DDCAPS_SYSTEMMEMORY flag, as explained in the second sentence, because the default behaviour in sentence one is pure fantasy. Thanks again. Alvise. P.S.: my first experiments with ddraw at: www.hochfeiler.it/alvise/DDRAW.HTM
That sentence is semi pure fantasy even on Win98... on Savage Video Board we tested the game an OFFSCREENPLAIN marked surface was created half in videomemory and half in systemmemory by the driver (i hope :D ) so when we used the memory pointer returned by CreateSurface..that was ok...about half of the time *LOL* but you can imagine what happened when we incremented the pointer beyond the "video memory part" of the surface....eh? a GPF?....no windows dosent GPF when you want it to :) ...well to conclude...sometimes the surface was just allways black there ("nomater the cost") sometimes a GPF...sometimes a "no ctrl_alt_del anymore baby" ...you name it :) So take care...and decide for yourself if you need a surface in system of in video memory... Bottom line: LESS APIs in YOUR CODE = LESS BUGS :) so use the MINIMUM required API's that do the job...and NEVER TRUST THEM!