Rainbow Six (1998) - Rainbow Six Rogue Spear

[greasythemattis]

I'm posting both cause they both use the same game engine.Can separate if needed.

Description: Both games ain't able to load in FULLSCREEN with DDrawCompat installed.I've tried with all options from the Windows ACT, and they still doesn't load in Fullscreen.Could also be related to the same bug Midtown Madness 2 suffers from.

---

RS(98)

R6(98) only works in Windowed mode plus Software Mode.I should mention that albeit not perfect the game is able to launch and play through the latest version of dgvoodoo in Fullscreen.

ddraw log for R6(98)

_9684 17:20:59.401 Process path: C:\Program Files (x86)\Ubisoft\Tom Clancys Rainbow Six\RainbowSix.exe
9684 17:20:59.402 Loading DDrawCompat from C:\Program Files (x86)\Ubisoft\Tom Clancys Rainbow Six\DDRAW.dll
9684 17:20:59.407 DDrawCompat loaded successfully
9684 17:20:59.695 Installing DirectDraw hooks
9684 17:20:59.864 Installing GDI hooks
9684 17:20:59.881 Installing registry hooks
9684 17:20:59.881 Finished installing hooks
9684 17:21:01.196 Failed to set the display mode to 640x480x32
9684 17:21:01.432 Failed to set the display mode to 640x480x32
9684 17:21:01.681 Failed to set the display mode to 640x480x32
9684 17:21:07.323 Detaching DDrawCompat
9684 17:21:07.336 DDrawCompat detached successfully_

---

RogueSpear Rogue Spear is able run in Windowed mode in both Software mode and non-software mode, fullscreen the game crashes. ddraw log for Rogue Spear

3608 17:29:07.025 Process path: C:\Program Files (x86)\Red Storm Entertainment\Rogue Spear\RogueSpear.exe
3608 17:29:07.025 Loading DDrawCompat from C:\Program Files (x86)\Red Storm Entertainment\Rogue Spear\DDRAW.dll
3608 17:29:07.028 DDrawCompat loaded successfully
3608 17:29:07.224 Installing DirectDraw hooks
3608 17:29:07.296 Installing GDI hooks
3608 17:29:07.312 Installing registry hooks
3608 17:29:07.312 Finished installing hooks
3608 17:29:13.238 Detaching DDrawCompat
3608 17:29:13.253 DDrawCompat detached successfully

---

-Update- With some changes on the register(FULLSCREN=TRUE to FALSE) of the game, mainly, Rogue Spear I was able to run in windowed mode(640x480,800x600 and 1024x600 higher than this the game crashes).

Didn't have the same luck with R6(98) using the same method.It finally launchs the game but crash as you load a map/campaign.

-Update2- R6(98) does actually run with DDrawCompat but only via Software Mode(and all the above things/fixes/compatibilities above, frames also get a hit.

[narzoul]

I have the GOG version of Rainbow Six (98). "Unfortunately" it's working correctly both with and without DDrawCompat. Those display mode change errors are definitely odd... With Rogue Spear I didn't have as much luck, I only have a demo but it doesn't even get as far as initializing DirectDraw, just silently terminates beforehand (unlike yours, based on the logs you posted). I'll experiment a bit more with it later.

Meanwhile, I could really use some more debug info on what functions are failing and why exactly. Could you use API Monitor to get some captures? Use the 32-bit alpha version (I personally just use the 32-bit exe from the portable version, but I suppose the installer works fine too if you prefer).

From the API filters you could select just the full "Graphics and Gaming" category for now. Then click on Monitor New Process in the Monitored Processes window, browse to the game's exe as Process and click OK.

Once the game exits, it would be best if you could save the capture to a file and upload it somewhere so I can look at it. Otherwise you can look for suspicious failing calls yourself (probably towards the end of the capture; they're usually marked by yellow). For the failing display mode changes you can look for "SetDisplayMode" calls, and note the parameters and the returned error code in particular. For Rogue Spear it'll be more difficult since there is no clue in ddraw.log as to what is failing. Most likely suspect would be one of the CreateSurface calls.

Also, out of curiosity, can you compile DDrawCompat yourself, perhaps make some simple changes in the code? It would probably make it easier to fix/test things that I can't reproduce, rather than having to wait for new releases that may or may not fix the problem.

[greasythemattis]

Logs and captures here: https://www.dropbox.com/sh/qziyqmkxhzcitx5/AACUpd5uSAxWp0uZh0jNBbkOa?dl=0

---

OS:Win10x64 Version used: Rainbow Six 98 1.04 (GOG) Softwareonly=true/false stands for the registry key located in _HKEY_LOCALMACHINE\SOFTWARE\WOW6432Node\Red Storm Entertainment\Tom Clancy's Rainbow Six DDrawCompat was used of course.

In the capture "R6(98)softwareonly=false", line 381, in yellow:

Line: 381
Module: RainbowSix.exe
API: IDirectDraw::CreateSurface ( 0x0019fab4, 0x008bc59c, NULL )
Return Value:  DDERR_UNSUPPORTED
Error: 0x80004001 = Not implemented 

Also IDirectDraw::SetDisplayMode ( 640, 480, 16 ) appears in line 208 this is the only one that returns value as DD_OK.Line 499,688 and 877 returns with value DDERR_NOEXCLUSIVEMODE.All of these lines under the module RainbowSix.exe

---

Version used: Rainbow Six Rogue Spear 2.05 fullscreen=true/false and Softwareonly=true/false stands for the registry key located in _HKEY_LOCALMACHINE\SOFTWARE\WOW6432Node\Red Storm Entertainment\Tom Clancy's Rainbow Six DDrawCompat: used

In the capture "RogueSpear softwareonly=false fullscreen=true", line 659

Line 659
Module:RogueSpear.exe
API:IDirectDraw4::CreateSurface ( 0x0019f838, 0x04fb28a0, NULL )
Return Value:DDERR_OUTOFVIDEOMEMORY
Error:0x8876017c = 

And

Line 679
Module:RogueSpear.exe
API:IDirectDraw4::CreateSurface ( 0x0019f6e0, 0x00a6e0c8, NULL )
Return Value:DDERR_GENERIC
Error:0x80004005 = Not specified error

Could these be what you were suspecting?

Also I could try compile a version but don't count me on coding.I'm not into that :) I closed the issue by mistake, sorry. :-D.

[narzoul]

Rainbow Six (98):

Ignore the SetDisplayMode failures, it's a false track. Apparently the game's error handling logic is faulty and after the CreateSurface failure it creates new DirectDraw objects (DirectDrawCreate calls) without releasing the old one, or at least resetting its exclusive cooperative level to normal, which makes SetCooperativeLevel fail on the new objects. This also causes the SetDisplayMode failures afterwards.

The real problem seems to be that the CreateSurface call fails when creating a Z-buffer with 32-bit depth in video memory. I found a discussion about a similar issue on DxWnd forums for a different game here. It seems the problem could be solved there by forcing the Z-buffer into system memory instead of video memory. Could you check if you can get the game working (or at least this call not failing) with the same solution, using DxWnd?

Alternatively, this thread on GOG discusses using an older version of atiumdag.dll to fix similar problems. Here is a link to version 12.8, taken from the same thread.

If either of the above solutions work for you, please take new captures with API Monitor and check the parameters of the second CreateSurface call again. In particular, expand the lpDDSurfaceDesc struct in the Parameters window at the bottom, and check the values used for dwZBufferBitDepth (this is part of the union directly after the dwBackBufferCount parameter) and the ddsCaps flags.

---

Rainbow Six Rogue Spear:

Both CreateSurface failures are not really a problem, because they are immediately repeated with system memory instead of video memory as storage, and they are passing then. I observed similar "failures" on my GPU with different games as well and it was never really an issue as long as the retry in system memory was successful.

That said, I can't see any other problematic calls in the capture either, but the process ends rather abruptly (without cleaning up all the DirectDraw resources). I suspect something may have gone wrong with some Direct3D call, but sadly API Monitor does not have the API definitions for older Direct3D versions (v7 and below), so it doesn't capture them. There is a command line capture tool, apitrace, which does support it. If you could get a capture with that as well, it may provide some more clues. There is help available for the usage there but you can ask me too if you can't figure it out.

Meanwhile I'll keep trying to get the trial version working on my system, perhaps I can reproduce the problem on my end.

[greasythemattis]

https://dl.dropboxusercontent.com/u/19651065/R6(98)%2Bold%20dll.apmx86 R6(98)

Both DxWnd and the atiumdag.dll worked at fullscreen without software mode.Although DxWnd had some textures and objects not loading the game ran at good speed.The old dll didn't have any glitches but ran at lower speed(the lower speed could be because the game used the ddraw inside %system32%) compared to DxWnd.Now using DDrawCompat+the legacy dll the game ran flawless.

These caps were generated using the legacy dll alone.

---

Rogue Spear

dwZBufferBitDepth

Line:247
Module:RainbowSix.exe
API:IDirectDraw::CreateSurface ( 0x0019fa6c, 0x008bc430, NULL )
ReturnValue:DD_OK
#   Type    Name    Pre-Call Value  Post-Call Value
    DWORD   dwZBufferBitDepth   0   0

Now in the second appearance of CreateSurface both Pre-Call and Post-Call value is set to 16.This looks like to be the only CreateSurface where the value is anything but 0.

Line:605
Module:RainbowSix.exe
ReturnValue:DD_OK
API:IDirectDraw::CreateSurface ( 0x0019fab4, 0x008bc59c, NULL )
#   Type    Name    Pre-Call Value  Post-Call Value
    DWORD   dwZBufferBitDepth   16  16

---

ddsCaps

Line:247
Module:RainbowSix.exe
API:IDirectDraw::CreateSurface ( 0x0019fa6c, 0x008bc430, NULL )
ReturnValue:DD_OK
Pre-Call Value{ dwCaps = DDSCAPS_3DDEVICE | DDSCAPS_COMPLEX | DDSCAPS_FLIP | DDSCAPS_PRIMARYSURFACE | DDSCAPS_VIDEOMEMORY }
Post-Call Value{ dwCaps = DDSCAPS_3DDEVICE | DDSCAPS_COMPLEX | DDSCAPS_FLIP | DDSCAPS_PRIMARYSURFACE | DDSCAPS_VIDEOMEMORY }

Line:605
Module:RainbowSix.exe
ReturnValue:DD_OK
API:IDirectDraw::CreateSurface ( 0x0019fab4, 0x008bc59c, NULL )
Pre-Call Value { dwCaps = DDSCAPS_VIDEOMEMORY | DDSCAPS_ZBUFFER }
Post-Call Value { dwCaps = DDSCAPS_VIDEOMEMORY | DDSCAPS_ZBUFFER }

__

Here is the trace using apitrace! https://dl.dropboxusercontent.com/u/19651065/RogueSpear.trace.

[narzoul]

Thanks!

Rainbow Six (98):

I found your GPU's specs online, and it supposedly supports 16, 24 and 32 bit z-buffers. It is odd then, that with newer drivers the game correctly picks the highest available option (32), but it can't actually create such a z-buffer in video memory. And the older driver (atiumdag.dll) apparently doesn't report 32 bit support at all so the game picks 16 bit instead, which at least actually works. Seems like a driver issue, but this raises some more questions on how to best work around this problem in DDrawCompat. I would appreciate it if you could do some more testing as follows:

Remove both ddraw.dll and atiumdag.dll from the game directory. Run a new capture with API Monitor. Find the first CreateSurface call (make sure it has IDirectDraw prefix and not IDirectDraw4 or some other numbered version), right click on it and select Breakpoint -> Before Call. Then right click on it again and select Include -> COM Method Name. This should filter the list to contain only CreateSurface calls, which will make the next steps easier. (You can later delete this filter from the Display tab on the left side panel).

Now you can remove this capture by right clicking on the process in the Monitored Processes window (from which you started monitoring) and selecting Remove. Start a new capture and once your monitor switches to 640x480 resolution, you should get a Breakpoint popup window where you will see the parameters of the first CreateSurface call. This one isn't interesting for us so you can just click Continue. The next popup should contain the z-buffer surface's parameters. You can verify by looking at the ddsCaps.dwCaps value, it should say DDSCAPS_VIDEOMEMORY | DDSCAPS_ZBUFFER.

Now comes the fun(?) part: you can actually modify these parameters in runtime from this window. I would like you to do 3 test runs and modify the parameters as follows in each case:

1st run: dwZBufferBitDepth=32 ddsCaps.dwCaps=DDSCAPS_ZBUFFER

2nd run: dwZBufferBitDepth=32 ddsCaps.dwCaps=DDSCAPS_SYSTEMMEMORY | DDSCAPS_ZBUFFER

3rd run: dwZBufferBitDepth=16

Once you do any of these modifications you can click Continue, and if the game doesn't crash already then just click Break on the next window and kill the game manually from the Task Manager (Ctrl-Shift-Esc) if needed. Then note the return value of the second CreateSurface call (the one you modified) in each case. (Note that the modified parameter values will only show up in the Post-Call Value column, but that's okay.)

If you have some extra time you could do one more test with the old atiumdag.dll in the game directory as well: dwZBufferBitDepth=32

Let me know the results and based on that I'll figure out the best approach for a fix.

Rainbow Six Rogue Spear:

Bad news here, the game seems to crash due to a bug in the game itself: it calls GetSurfaceDesc on a texture surface that it just released in the previous step, so a crash is not at all surprising.

What I'm curious about is why this same crash doesn't happen with dgVoodoo or in windowed mode. Please repeat the apitrace capture with the following setups:

1. with dgVoodoo + full-screen mode
2. without dgVoodoo + windowed mode.

[greasythemattis]

1st run: dwZBufferBitDepth was already set to 32.

2nd run: dwZBufferBitDepth was also already set to 32.

3rd run: When I set the the value to 16 a new window appears and what looks to be a infinite error.

__ With atiumdag.dll

dwZBufferBitDepth set to 32

---

Rogue Spear Used the new 2.52 version I'm really sorry, I forgot to mention during all of this that I've been using this fix that apparently creates a large surface for the game or at least the fonts.

FullScreen + dgvoodoo(modified fonts.fdf) https://dl.dropboxusercontent.com/u/19651065/RogueSpear%20fullscreen%2Bdgvoodoo.trace Windowed without dgvoodoo(modified fonts.fdf) https://dl.dropboxusercontent.com/u/19651065/RogueSpear%20Windowed.trace

---

FullScreen+dgvoodoo https://dl.dropboxusercontent.com/u/19651065/RogueSpearFullScreen%2BDgvoodoo%2BOriginalFonts.trace Windowed without dgvoodoo https://dl.dropboxusercontent.com/u/19651065/RogueSpearWindowed%2BOriginalFonts.trace

[narzoul]

Rainbow Six (98):

Thank you! Based on the input so far, my preference for a fix would be to suppress all z-buffer formats (during enumeration) that can't actually be created in video memory (test with CreateSurface during enumeration). Unless none of them can be created in video memory, in which case suppress only those that can't be created in system memory either (and perhaps automatically switch to system memory if the game still tries to create it in video memory).

Rainbow Six Rogue Spear:

I'm confused here. I thought the game was supposed to work with these combinations? But based on these captures, all of them are crashing the same way as in the capture you sent initially. So just to clarify, does the game actually start with any of these combinations, but crashes when running the same setup through apitrace or API Monitor? If so, that would make it rather difficult to debug the issue further.

From what I can see z-buffer creation is not an issue in any of the cases (including the original capture) as the game always uses a 16 bit z-buffer, which is always created successfully.

[greasythemattis]

Rogue Spear

I understand why you are confused now.Made an update in the OP.Things should be clearer now!

So far in Rogue Spear I've made the game run and play only during windowed mode.In fullscreen the far as I could go was running the intro videos and crashing before the main menu appears.

The game crashes when should be running only under apitrace(I've tested with other games the same thing happens so idk if its a intended or not), API Monitor it goes just fine.

[narzoul]

Rainbow Six (98):

I managed to reproduce the issue on a laptop with ATI Mobility Radeon HD 5470. Its supported z-buffer pixel formats are nearly identical to my NVIDIA GeForce GTX 760, yet the game selects an unsupported format when using newer AMD drivers.

Found the reason: the dwDeviceZBufferBitDepth of the D3DDEVICEDESC structure reports 16 and 32 on AMD vs 16 and 24 on NVIDIA. It seems that the numbers reported by NVIDIA are correct, since those z-buffers can actually be created (on both devices), while a 32 bit one can't.

It's not entirely straightforward though. The game uses very old Direct3D interfaces where the z-buffer format is specified differently (as a single number) compared to the newer interfaces where a full pixel format is given. Both cards support a kind of 32-bit depth buffer pixel format, but it's actually a combination of 24 bit z-buffer and 8 bit stencil buffer. And it seems when you give 32 to the old interface it means it's looking for a pure 32-bit z-buffer format, which is indeed unsupported on both GPUs.

Unfortunately I don't have any GPUs that support a full 32 bit z-buffer, so I can't test if that would actually work, but according to some old DirectX SDKs, 32-bit z-buffers were not even supported on those old interfaces. I'm guessing they would still let you create one if you had a capable GPU though.

Anyway, I'll alter my plan slightly and modify just the dwDeviceZBufferBitDepth member of the D3DDEVICEDESC struct to return the actually supported bit depths, with the assumption that this means all pixel formats consisting of only z-bits. Hopefully that will work on all devices.

Rainbow Six Rogue Spear:

I found an alternative demo version (an actual demo rather than a time limited trial version I've been experimenting with) and that actually "works" to the degree that it crashes the same way as for you. But at least it allowed me to debug the problem more easily.

Apparently CreateSurface always assumes that the DDSD_CAPS flag is set, even if it's not. DDrawCompat isn't prepared for that, so it "misses" hooking the primary surface, and as a result the game prepares a texture with the wrong primary pixel format (the real display format, which is 32 bit, instead of the emulated 16 bit). That's probably what causes the game to release the texture prematurely (and then crash due to some incorrect error handling logic).

I quickly tested a fix for this and it made the game playable, but there are a few other issues that will need to be investigated. One is that parts of the main menu are flickering when it is first displayed (but it fixes itself after opening a submenu). The other is that there are some serious slowdowns on the mission briefing screens whenever the camera images are changing.

[jrfonseca]

The game crashes when should be running only under apitrace(I've tested with other games the same thing happens so idk if its a intended or not), API Monitor it goes just fine.

DirectDraw support in Apitrace hasn't been thoroughly tested. I wouldn't be surprised if there are bugs in the API specs. Patches are welcome though.

[narzoul]

Well, I just fixed the large surface/font related crash that happens on AMD drivers, so that "font hack" should not be needed anymore. If anyone is still around and could test it, please let me know the results. It's included in the latest experimental/test release.

As far as I know two more issues remain to be fixed: one of them is the flicking in the menus, and the other is alt-tabbing. Rainbow six crashes while Rogue Spear doesn't seem to restore lost textures, so 3D areas will become blank/corrupted. I have a feeling neither games ever supported alt-tabbing, but I'll try to fix them anyway.

There's a third issue in Rogue Spear with objects/polygons sometimes becoming invisible when looking at them at certain angles. It seems to be a memory corruption issue somewhere because applying the "FaultTolerantHeap" fix in Microsoft Application Compatibility Toolkit apparently fixes it. I'm not sure if I'll ever be able to fix this in DDrawCompat (especially if the bug is in the game engine or some drivers/runtime), but this external fix should help at least.

[Matthaiks]

Good job. Those games are now playable.

[greasythemattis]

Rogue Spear is running flawless with the latest version and so is RS98, I'm so happy! Thanks for your time and effort narzoul! Cheers!!

[narzoul]

The black flickering in Rogue Spear menus should be fixed in the latest experimental release. I've been working on a generic solution for the alt-tabbing problems but it's still just an experiment and not quite ready for testing yet. Seems promising though. Once it's ready it should fully fix alt-tabbing in both games.

[Volcanotron]

The black flickering in Rogue Spear menus should be fixed in the latest experimental release. I've been working on a generic solution for the alt-tabbing problems but it's still just an experiment and not quite ready for testing yet. Seems promising though. Once it's ready it should fully fix alt-tabbing in both games.

hey champ if you're still here. is the black flickering you mentioned shown in this video? https://www.youtube.com/watch?v=pQg2U_mc0jA also lost at what's causing the really long loads since the game loads almost instantly in window or borderless fullscreen. also the 3rd person view is very slow when above 30fps, seems to work best around 24fps. i think it takes 9seconds for 3rd person to work correctly when running at 60fps
I'm running the latest ddraw

[narzoul]

No, I don't see any flickering in your menus.

The long black parts are probably caused by your display taking a long time to change resolution. You could try to enable display scaling on GPU if you haven't already done so to see if it speeds things up. The option should be available in your display driver settings. You can use this guide to set it up: http://www.damirscorner.com/blog/posts/20150125-ConfigureDriversToMaintainAspectRatioWhenScalingTheImageNvidiaAndAmd.html

also the 3rd person view is very slow when above 30fps, seems to work best around 24fps. i think it takes 9seconds for 3rd person to work correctly when running at 60fps

I'm not sure what you mean by this, could you please elaborate?

[Volcanotron]

I'm not sure what you mean by this, could you please elaborate?

I tried that solution to the black screen already and it didn't change anything as for the 3rd person view ill send another video showing what i mean. chase cam might be a better word for it? i used 25,60,120 and uncapped frame rate in this forced by nvidia inspector https://www.youtube.com/watch?v=5SiLEOLFs98

Also supplied is the ddrawlog file and dxtory(fps overlay) error log. the window/borderless ddraw log gave me the same log as the fullscreen one so I didn't bother uploading them dxtory ErrorLog_2018-10-29 12-45-52.txt fullscreen ddraw.txt ddraw without dxtory.log

[narzoul]

Ok, I see what you meant with the camera now. It just moves slower at higher frame rates, but it's not a performance issue. It seems to be a timing bug in the game, so it's not something that can be fixed with a DirectDraw/Direct3D wrapper. Unfortunately an fps limiter may really be the only workaround (which is something that could be implemented in a later version of DDrawCompat too).

From your log files I see that you have both Win98 compatibility mode and 16 bit color mode enabled, which is what seems to be causing the "Failed to create a render target for hooking: -2005532527" error. Neither of those compatibility settings should be necessary (at least on my system), though I don't think disabling them will fix any of your problems either (apart from making that error log go away). It may be worth a try anyway.

I can't reproduce the long black screens issue with either my AMD or Intel GPUs, and I don't remember having that problem even when I had an NVIDIA GPU. I only have a demo version of the game but I don't think it makes any difference. I still suspect it's somehow related to long display mode switches (which would also explain why it doesn't happen in windowed mode). If you can compile DDrawCompat yourself and maybe make a few simple code modifications we could test that further. If you have other 3rd party tools that could be interfering, such as overlays or video recorders, turning those off could also help.

[Volcanotron]

I uninstalled voobly and rogue spear and then deleted everything from the registry. installed the demo, wouldn't launch without the ddraw and then would slow load. reinstalled the full game same thing happened. tried disabling my other screen to see if that was part of the problem, didn't help. nvidia shadow play is disabled to check if that was interfering, no change. I haven't enabled any compatibility settings, if your ddraw or my system automatically doing it is another story 1monitorddraw.txt ddraw.log

If you can compile DDrawCompat yourself and maybe make a few simple code modifications we could test that further.

As for compiling I have no experience in it but I'm happy to give it a go if you can tell me what I should download

[narzoul]

Ah, if you have a second screen, have you tried playing the game on that to see if it's any better? Is it connected to the same GPU? If you have some integrated GPU like Intel HD you could also give that a try.

The compatibility settings must have been installed earlier by the game or by one of the mods/patches you've added. The easiest way to get rid of them is to rename the executable RogueSpear.exe to something else like RogueSpear_.exe. You could also use the Compatibility Administrator to only remove those specific compatibility modes and keep the rest if needed, but that's a bit advanced.

Anyway, let's not get into compilation yet if you have no experience. I've attached to this post the current experimental version (commit 60c3c4f) with debug logging enabled (I just replaced all "#ifdef _DEBUG" directives with "#ifndef _DEBUG"). It may be enough to find the culprit.

ddraw-debuglogs.zip

Please use this version and repeat the things you've done in your first video. No need to record anything, in fact please turn off all such software that could interfere. Then compress and attach the resulting ddraw.log file here.

Note that it is going to be huge (probably 100+ MB uncompressed) so keep the testing time to a minimum to also minimize the log file size. I'm only really interested in the black screen parts anyway, the rest you can skip as quickly as possible. Expect some additional performance issues during testing due to the large amount of logging.

[Volcanotron]

debugddraw.zip here's the larger log you wanted

[narzoul]

Thanks! It does confirm that the display mode change is rather slow on your system. It takes ~3 seconds for a mode change unless the target mode is the same as the current one (in which case it's almost instantaneous).

Another problem is that sometimes on top of that, there is an another 3 seconds delay after the mode change. This is most likely caused by DirectDraw waiting on the DWM_DX_FULLSCREEN_TRANSITION_EVENT to be set after the mode change, which has exactly 3s timeout. For some reason the event doesn't get consistently set on your system which can cause an additional 3s delay. I've only seen this problem before when the new mode is the same as the current one, but that's already fixed in the current experimental version. But in your case it happens on actual mode changes too.

I've added a patch on top of the current experimental version that unconditionally sets the DWM_DX_FULLSCREEN_TRANSITION_EVENT after each mode change, so that the extra 3s delay can be avoided. I don't know if this has any negative side effects, so far it looks fine on my system. I've attached the patch diff and the compiled version below.

patch-diff.txt ddraw-patched.zip

I can't do much about the remaining 3s for the mode change itself. I'm not sure why it's so high on your system. On mine it only takes 1s, which can be reduced to just 0.2s by enabling GPU scaling. Maybe you should give GPU scaling another try after this patch to see if it can further reduce that time for you. It could also have something to do with the high refresh rate (120 Hz), but I don't have such a monitor for testing. Maybe try setting your monitor to 60 Hz (if it's supported) before launching the game?

[Volcanotron]

it did feel slightly faster on my 2nd screen which uses display scaling and has a 60hz limit, my main screen which i've been working with uses gpu scaling but i also tried 60hz and 120hz which didn't change the outcome. im not able to change from gpu scaling it seems tried changing desktop resolution to 800x600 and ingame to 800x600, tried cpu priorities and how many cores it uses. tried running my main screen with hdmi instead of dvi. I personally don't mind the current method I'm using for borderless fullscreen window with the program Borderless Gaming which only results in small menu sections and fast loads and 1080p in game. i was just trying to figure out what was causing it to slow load when using normal fullscreen.

[Volcanotron]

just an update on this, since uninstalling geforce experience the slow loading doesn't happen. even though i had shadowplay disabled before something else might have been messing with it. im unsure if the latest windows update 1809 helped with anything which i installed tonight as well

though an existing issue is still present with alt tabbing which ill upload. after alt tabbing the screen goes black and i cant seem to bring it back until i go back to the main menu

[ijemafe]

Trying to run Rogue Spear (and the Urban Ops expansion) on experimental version 8f67fd1. I used this guide to install the game. I'm able to launch and play the game, but when I complete the second mission successfully (first mission worked, failing second mission works, but beating second mission crashes), I get a failure to create the primary surface:

Game log (Rommel.log):

Direct3DRendererGuts::CreateBuffers() failed during Direct3DRendererGuts::CreateBuffers() - Cannot create primary surface in file C:\develop\common\New Renderer\Direct3D\Direct3DRendererGuts.cpp at line 606
Renderer::CreateEnvironment() failed during Direct3DRendererGuts::CreateBuffers() in file C:\develop\common\New Renderer\Direct3D\Direct3DRendererGuts.cpp at line 692
  Error = "DDERR_INVALIDPIXELFORMAT"
DISPLAY::Reset: We are sorry, but we are unable to initialize the renderer at 640x480x16

DDrawCompat log (DDrawCompat-UrbanOperations.log):

4f34 18:16:49.491 Finished installing hooks
4f34 18:19:17.854 ERROR: Failed to create the compat primary surface: 0x88760091
4f34 18:19:17.861 ERROR: Failed to create the compat primary surface: 0x88760091
4f34 18:19:18.742 Detaching DDrawCompat due to process termination

Is there a way I can resolve this INVALIDPIXELFORMAT error? I've also tried latest stable DDrawCompat (from 2016), which fails to correctly draw the game in windowed mode (if the resolution is larger than 640x480 it crops the frame).

Edit 1: The latest experimental version, debug build, with the debug logging enabled, no longer crashes. However, it has significantly worse performance. Will try again without debug build.

Edit 2: Latest experimental version (non-debug build) fails with the same error. Will try experimental debug without logging.

Overall results:

VERSION BUILD     SIZE   CRASH PERFORMANCE
8f67fd1 release   968kb  yes   good
d8b4209 release   975kb  yes   good
d8b4209 debug     5105kb game fails to start
d8b4209 debug+log 2246kb no    bad

Edit 3: In the meantime, I completed the second mission using the debug+log build, then switched back to the release build. Will report back if I experience further crashes.

Edit 4: Still getting occasional crashes with the same log lines as above (including when I successfully complete the third mission, as well).

[Volcanotron]

looks like old mate is mostly using my guide which i did here https://www.gog.com/forum/rainbow_six_tom_clancys/rogue_spear_windows_10_fullscreenwindow_fix this ddrawcompat version is the one i suggested people use and the one i would use. the newer version would cause issues https://mega.nz/#!eiokQQxZ!f7C4kxTz7zTJ_00fq47jGgeOq0oK97l5qtJjop3W4qo

[narzoul]

Is there a faster way to reproduce the issue, e.g. by aborting the mission? Also, how did you enable windowed mode? Is it through the registry or some other app?

I'll look into this later, but for now, if you can reproduce the issue with debug logs, please check the details in those logs about the error. Search for the "ERROR: Failed to create the compat primary surface: 0x88760091" string. It should be part of a CreateSurface function call block. Upload at least that entire block here please. (Probably the whole file will be too large to upload.)

[ijemafe]

@Volcanotron That version of DDrawCompat works, thanks! Do you know what specific version/revision that DLL is from?

@narzoul Aborting the mission doesn't crash, unfortunately. I enabled windowed mode by setting Fullscreen=FALSE in the registry. As mentioned in my earlier comment, for some reason I was unable to repro the crash using the logging debug build.

[narzoul]

Based on the date of that release, it should be this commit: https://github.com/narzoul/DDrawCompat/commit/0f88271668b68778c317c0b5da02ee40a209e271

Anyway, I can't reproduce the issue. I can complete the second mission without any crashes. There might be some differences between our setups, or maybe it's just a random crash. Do you have multiple monitors active while playing? Any game recorders, overlays or whatever else running that could also be hooking the game? Did you set UrbanOperations.exe to Win98 compatibility mode and 16 bit color?

If you're willing to investigate further, I could add some extra logs to the primary surface creation in the Release build to narrow down the issue.

[ijemafe]

Thanks for the commit ref. I do have multiple monitors, with the game launching as a window on my primary monitor. UrbanOperations is using the compatibility settings you mentioned as well.

Now that I have a working copy of ddraw.dll I'm all set, but let me know if you have a build you'd like me to try.

[Volcanotron]

your guide also says that the ddraw fix might work for r6 1998, it doesn't and its not the same engine. r6 98 requires dgVoodoo to fix its issues

[narzoul]

In what way doesn't this work with R6 1998? It's been working for me since around the same time as Rogue Spear (I tested both games back then). I briefly retested it now with the latest experimental release and it's still running great (GOG version).

On the other hand, I get this with dgVoodoo in the menus (and in many other games), which I think is a known issue with dgVoodoo and AMD GPUs:

[Volcanotron]

hmm it seems between now and the last time i tested ddraw which would've been 2 years ago something on my end has changed because it used to stall on map loading or crash as you entered the level, i dont think its needed though as i can play just fine without ddraw. just needs a fps cap so AI doesnt mess up

[narzoul]

@ijemafe Do you still have the logs from the ReleaseWithDebugLogs version? If not, could you run the game one more time with it? No need to go through a whole map, just enter one of them, then go back to the main menu and exit the game. Compress and attach the log file, please.

[Volcanotron]

hello again narzoul. some of our returning players to rogue spear have been experiencing crashing on your latest version and the version i posted above that was proven to work (works for me still). randomly or on round 3 or 4 they crash without fail. here is his log (1gb) which goes through the 3rounds and then the crash on the 4th. is this related to ddraw or is something else breaking the game? https://mega.nz/file/Fdt3AKgR#odVIdytPfhP86oAU5nY1aZHIP2S9SYNq0TtL2QhtIuk

[narzoul]

First, a note about the log: even the Windows built-in zip compressor can reduce the file size to just 61 MB. Next time it may be better to use it before uploading a 1GB file. :)

The issue seems to be a GDI handle exhaustion, most probably caused by a resource leak somewhere. The CreateCompatibleBitmap function calls work up to a point, but eventually they all return null.

Now the suspicious thing is that most of these calls are coming from _D3DDDI_DEVICEFUNCS::pfnPresent1, where I wouldn't expect to see them. My AMD display driver certainly doesn't make such calls here, though that could be down to driver differences. The bitmaps are used by SetDIBits/GetDIBits calls from the same function, which is also strange.

_D3DDDI_DEVICEFUNCS::pfnPresent1 in this case is hosted by nvd3dum.dll, which is part of the NVIDIA display driver. I checked a recent version of the file (456.71) and it doesn't seem to contain any references to CreateCompatibleBitmap, neither in its import address table nor as a plain text string, so I suspect it may be injected by some 3rd party code. Is there any overlay or screen recorder or something similar running?

My guess is that the bitmaps created by those CreateCompatibleBitmap calls are not getting cleaned up here. I could add some extra logs to verify that, but first let's see if I'm correct about it being injected by some other tool.

If you also have an NVIDIA GPU, could you check in your own logs if you see any CreateCompatibleBitmap calls nested within _D3DDDI_DEVICEFUNCS::pfnPresent1? The first number on each line is the thread identifier. The calls would need to be on the same thread as the pfnPresent1 call. The first pfnPresent1 call has a bunch of extra stuff going on in it, so it may be better to check from the second call onwards, where the first nested call is already CreateCompatibleBitmap in the uploaded log.

[Volcanotron]

https://mega.nz/file/Xuhh0AyK#OZI8y6J864pu17sKPbHzysxJt_xBqmWV1hg0nkGM2_Y these ones are my logs until the folks with the crashing problem get back online. when they do ill ask them if they have any overlay stuff or reshade(if that would cause a problem?) i run a 1080ti one of the people who have the issue run this setup ryzen 9 3900x 32gb ram, 2080 super

[narzoul]

Out of those 3, only shadowplayenabledDDrawCompat-RogueSpear.log has similar calls to CreateCompatibleBitmap as the original one. But this one was running in full-screen mode while the original was windowed. Is ShadowPlay supported in windowed mode?

[Volcanotron]

the ingame overlay is enabled but doesn't actually work for RS the shortcut keys dont do anything.like in the fullscreen one for testing i also turned on shadowplays instant replay which is a continuous recording of X amount of minutes Win-SshadowplayDDrawCompat-RogueSpear.zip

after disabling desktop capture from shadowplay and using the toggle recording i ran into a lot of issues, one being the scene not updating but i can still hear my player moving and shooting while having a frozen image ingameonlySplayDDrawCompat-RogueSpear.zip

[narzoul]

Incompatibility with various game recorders is a known issue: https://github.com/narzoul/DDrawCompat/issues/13 I'm not sure it can be fixed in a generic way, since both those tools and DDrawCompat are using injection techniques that often clash. For now, it's not high on my list to attempt to fix again (I tried it once with Fraps but got nowhere after wasting a lot of time on it).

For the GDI handle leak, please repeat the Win-SshadowplayDDrawCompat-RogueSpear test with this modified version (ReleaseWithDebugLogs build only): ddraw.zip It's built on top of the current experimental version (799e9a9) with just logging added for the DeleteObject calls. Source code diff: diff_799e9a9.txt

It should confirm if those bitmaps are getting properly deleted or not.

[Volcanotron]

Win-SshadowplayDDrawCompat-RogueSpear.zip version 2.0 its alright if shadowplay needs to be disabled for the sake of having a playable game, im pretty certain for any of my recordings i used OBS anyway

[narzoul]

Thanks for the tests! Yes, it looks like ShadowPlay is leaking those bitmaps. I'd recommend turning it off, that should prevent the crashes hopefully.

[Volcanotron]

just an update. the guy who gave me the 1gb file tells me that after disabling shadowplay the game works, and the other guy while not testing yet did say have shadowplay on so i can only assume its fixed for him as well. thank you for your help again

[sarnara2]

resolution.zip download First of all, thank you for your hard work! I am Japanese so I speak English incorrectly. Sorry ㅠ

RogueSpear can't run 4k with the old narzoul ddraw.dll. The file i have works with narzoul ddraw.dll file even in 4k high resolution. !! Can you put the uploaded file code into narzoul ddraw.dll file? Also, if you start after selecting a mission in RogueSpear 4k resolution, The ui scale size is very small. 3d resolution remains at 4k, but Can it be arbitrarily modified like the 2d UI scale size shown in 1080p? At 4k resolution, even 2d ui is affected, so it looks too small It would be nice if this could be modified

[narzoul]

I've already implemented high resolution support in DDrawCompat. 4k resolution should work fine in the latest experimental release. I've just tested it with Rogue Spear and had no issues.

As for UI scaling, it can possibly be implemented in a future release, but I can't do it any time soon.

[sarnara2]

DDrawCompat에서 이미 고해상도 지원을 구현했습니다. 4k 해상도는 최신 실험 릴리스에서 제대로 작동합니다. 방금 Rogue Spear로 테스트했는데 문제가 없었습니다.

UI 확장은 향후 릴리스에서 구현할 수 있지만 조만간 수행 할 수 없습니다.

Yes I just tested it! 4k seems to work on computers

And thank you so much for the answer to 2d ui !! I'll wait slowly!

[narzoul]

Resolution scaling has been implemented in v0.4.0. Check the ResolutionScale setting in the wiki.