What version of the game is this? What features are you trying to get out of wrapping ddraw.dll for this game?

the3dfxdude wrote on 2023-06-27, 04:06:

What version of the game is this? What features are you trying to get out of wrapping ddraw.dll for this game?

It is v2.10E, the latest version available from GOG.
As for what I want to do, the main thing I wanted to see is if dgVoodoo would fix some issues I'm having with the game (such as the game slowing to a crawl when I try do a box select, the game either not registering mouse button presses or thinking that it's held down, etc). These problems don't happen on my laptop, strangely enough; only my desktop.

Having the game in a borderless window would be a plus as well.

Ok, I'll check it out. Seems to be a dgV DDraw incompatibility issue.
What I don't understand though, you have a GF 1080 and partial depth copy is not supported... it should be. At least, it is on my 1060.

I found this in the src:

1// TODO MS DX allows inserting into a COMPLEX flipping chain and attaching plain offscreens

So, it must be implemented... 😀

Thanks for looking into this. I assume implementing that is not trivial.

As for partial depth copy, that does seem strange. Is this a hardware level feature, or something that can be disabled in the driver/OS?

XJDHDR wrote on 2023-06-29, 20:27:

Thanks for looking into this. I assume implementing that is not trivial.

As for partial depth copy, that does seem strange. Is this a hardware level feature, or something that can be disabled in the driver/OS?

I've already implemented the needed part. The game works, altough it's broken with forced resolution but that's another story and do not make sense for this game.

Partial depth copy is a hw feature, maybe driver dependent and I don't think it can be disabled in any way.

Dege wrote on 2023-06-30, 09:43:

I've already implemented the needed part. The game works, altough it's broken with forced resolution but that's another story and do not make sense for this game.

What's forced about the resolution and broken? The game tells the system to go fullscreen exclusive. Next in the game's vga.set_mode(), it does a dd_obj->SetDisplayMode( w, h, VGA_BPP, 0, 0); where w and h are selected by the user. VGA_BPP is fixed to 16-bit depth. Then the game queries the current display's pixel format so it knows which of the 16-bit formats to use in its blitting routines. So the only pitfall would be is if the you emulate DirectDraw, and do not give exclusive access or do not have a native 16-bit surface, then you'll have to emulate one, and rely on hints from the game on when to push the emulated surface to the actual screen. The thing about this game, is I still don't know if it does true double buffering, and if it's like the first game, it will not really do it. And that's even when it uses AddAttachedSurface and call Flip() in places in this version. It doesn't seem to set DDSCAPS_COMPLEX or DDSCAPS_FLIP anyway. So it was kind of tacked on, and maybe not really required.

XJDHDR wrote on 2023-06-27, 08:23:

It is v2.10E, the latest version available from GOG.
As for what I want to do, the main thing I wanted to see is if dgVoodoo would fix some issues I'm having with the game (such as the game slowing to a crawl when I try do a box select, the game either not registering mouse button presses or thinking that it's held down, etc). These problems don't happen on my laptop, strangely enough; only my desktop.

Did you go in and set the compatibility settings, as this game is not high DPI aware in the DirectX Version? I'm not sure if dgvoodoo2 will fix this on the fly, as this will be coming through DInput. I'm guessing your desktop is a high DPI screen and the laptop is not.

XJDHDR wrote on 2023-06-27, 08:23:

Having the game in a borderless window would be a plus as well.

A wrapper might provide this benefit.

XJDHDR wrote on 2023-06-27, 08:23:

the main thing I wanted to see is if dgVoodoo would fix some issues I'm having with the game (such as the game slowing to a crawl when I try do a box select, the game either not registering mouse button presses or thinking that it's held down, etc).

I did a bit more analysis and found the problem is not actually specific to selection boxes. It is any mouse movement that makes the game slow to a crawl. But this strangely only affects my desktop. The laptop has no problem with mouse input.

the3dfxdude wrote on 2023-06-30, 16:22:

Did you go in and set the compatibility settings, as this game is not high DPI aware in the DirectX Version? I'm not sure if dgvoodoo2 will fix this on the fly, as this will be coming through DInput. I'm guessing your desktop is a high DPI screen and the laptop is not.

That's not it, unfortunately. Both of my computers use the same DPI (100%). I did try to change this anyway, just in case, but noticed that Windows had already set this compatibility option by default.

Dege wrote on 2023-06-30, 09:43:

I've already implemented the needed part. The game works, altough it's broken with forced resolution but that's another story and do not make sense for this game.

Partial depth copy is a hw feature, maybe driver dependent and I don't think it can be disabled in any way.

Oh, that was quick. Thanks! As long as the game can be forced into windowed mode from fullscreen, the game's built in resolution support has what I need already.

As for Partial depth copy, perhaps Nvidia only partially implemented it in the 10 series? Maybe something like when I first tried to play Mass Effect, but it crashed on start because my GeForce 6200 didn't have Shader Model 3 support despite this being advertised as something the entire 6 series had.

XJDHDR wrote on 2023-07-01, 05:15:

As for Partial depth copy, perhaps Nvidia only partially implemented it in the 10 series? Maybe something like when I first tried to play Mass Effect, but it crashed on start because my GeForce 6200 didn't have Shader Model 3 support despite this being advertised as something the entire 6 series had.

Only now I see from the log that it's DX11... then forget it, all of those features are DX12 only. I'll remove that message for DX11.

the3dfxdude wrote on 2023-06-30, 16:07:

So the only pitfall would be is if the you emulate DirectDraw, and do not give exclusive access or do not have a native 16-bit surface, then you'll have to emulate one, and rely on hints from the game on when to push the emulated surface to the actual screen.

Actually that's what happening with dgVoodoo. Also, when resolution is externally forced then it has to do some not-so-easy extra work in the background.

the3dfxdude wrote on 2023-06-30, 16:07:

The thing about this game, is I still don't know if it does true double buffering, and if it's like the first game, it will not really do it. And that's even when it uses AddAttachedSurface and call Flip() in places in this version. It doesn't seem to set DDSCAPS_COMPLEX or DDSCAPS_FLIP anyway. So it was kind of tacked on, and maybe not really required.

Yes, it creates and renders into (or from?) an offscreen flip-chain that's what was not supported. Interesting, never seen any other game doing this.

XJDHDR wrote on 2023-07-01, 05:15:

the3dfxdude wrote on 2023-06-30, 16:22:

Did you go in and set the compatibility settings, as this game is not high DPI aware in the DirectX Version? I'm not sure if dgvoodoo2 will fix this on the fly, as this will be coming through DInput. I'm guessing your desktop is a high DPI screen and the laptop is not.

That's not it, unfortunately. Both of my computers use the same DPI (100%). I did try to change this anyway, just in case, but noticed that Windows had already set this compatibility option by default.

Ok if you still have issues with input, come by and share some more. I work on 7k1 and 7k2, and fixed a number of things in 7k1, which really could be used in 7k2. Some of what broke has been due to Windows changes, so I would like to be on top of these issues to help out everyone. I might not be able to help with 7k2hd just yet, but I can at least get ready for it.

Dege wrote:

Yes, it creates and renders into (or from?) an offscreen flip-chain that's what was not supported. Interesting, never seen any other game doing this.

I had not seen this myself, and the DX docs really don't suggest you could create such a flip chain. Everyone giving tutorials on this say you'd be making the surfaces in hardware and tells you to set certain flags. But it makes sense. It looks in the code like they commented out the flags to set them in video hardware, and so then it falls back to a mode that worked similar to a debugging mode of 7k1 in rendering offscreen. And the older game really just assumed classic access to the video memory, so it's perhaps a hack bolted on to get around limitations, and decided not to use video memory as the game engine is not built to for it.

the3dfxdude wrote on 2023-07-01, 16:26:

I had not seen this myself, and the DX docs really don't suggest you could create such a flip chain. Everyone giving tutorials on this say you'd be making the surfaces in hardware and tells you to set certain flags. But it makes sense. It looks in the code like they commented out the flags to set them in video hardware, and so then it falls back to a mode that worked similar to a debugging mode of 7k1 in rendering offscreen. And the older game really just assumed classic access to the video memory, so it's perhaps a hack bolted on to get around limitations, and decided not to use video memory as the game engine is not built to for it.

Actually a DDraw flip chain has nothing to do the hw itself directly. You can attach surfaces to each other to form a chain and simply Flip on the head to rotate the chain but it's a logical thing, only the implementation objects are changing behind the surface pointers. If the chain contains visible surfaces representing the buffers of the screen then the screen content also changes with a Flip, as a side effect (and indeed, this is the most common usage of flip-chains).
Also, a chain is only complex (and non-detachable) if it is created as a chain, implicitly. Attach/Detach makes/destroy a chain but it won't be complex. Also, the FLIP, FRONTBUFFER, ..., and flags like that are set/cleared by the Attach/Detach itself.