elishacloud / dxwrapper

Fixes compatibility issues with older games running on Windows 10/11 by wrapping DirectX dlls. Also allows loading custom libraries with the file extension .asi into game processes.
zlib License
1.17k stars 83 forks source link

Bad Mojo Redux #42

Closed legluondunet closed 4 years ago

legluondunet commented 4 years ago

Hello again Elisha, like discussed here: https://github.com/CnCNet/cnc-ddraw/issues/16 dxwapper is the only wrapper that does not crash Bad Mojo Redux. But for the moment, no fullscreen and we have only quicktime sound, no video. As you know I'm a Linux user, I launch Windows games with Wine. Actually I'm using Wine 4.15 staging (Lutris version, virtual desktop mode on) on Ubuntu 19.04 with a Nvidia GPU. I joined you log file for debug. The idealistic objective will be to play this game FullscreenWindowMode , active vsync on with native gamer desktop resolution, with aspect ratio respected. I played a lot with dwrapper.ini options without success. Thank you for your help.

nota: FullscreenWindowMode = 1 --> I can not see menu DdrawUseNativeResolution = 1 --> still 640x480 wine window

dxwrapper-badmojo.log

elishacloud commented 4 years ago

Hello @legluondunet, I will take a look at this when I get a chance. May not be for a couple of weeks.

mirh commented 4 years ago

I'm really really struggling to see a reason in caring for wine here. Dxwrapper exists to patch the godawful bugs in windows that you can't workaround otherwise. Wine is FOSS and if you happen to understand the problem, you can actually fix it properly and neatly.

If you have no videos check this, and if the game crash on start: a) it was reported to work here, so report to them b) it also mean you can use an older version and/or bisect the breaking commit

legluondunet commented 4 years ago

Hello @mirh , I didn't ask @elishacloud to resolve a Wine bug, Bad Mojo Redux works very good on Linux with Wine. But to try making dxwapper Bad Mojo Redux compatible. It is not a Wine bug but a graphic game limit: you can not play this game windowed, for the moment no wrapper can launch this game windowed. The benefit here will be to play this game fullscreen (window mode borderless) at your desktop native resolution, not in 640x480, on Windows and if it works on Windows, it could work on Linux with Wine too. You can use other wrappers on Linux with wine to play your old games at fullscreen native desktop resolution: DxWnd, dgVoodoo, cnc-draw...they are all Wine compatible and like Windows gamers, Linux gamers need them to play their old Windows games.

mirh commented 4 years ago

you can not play this game windowed, for the moment no wrapper can launch this game windowed

I hope you meant fullscreen, otherwise I have some headache to solve in reading your post.

If that's the case.. Uh, sorry. Though it'd seem super strange for wine/X not to be able to stretch the window in fullscreen.

on Windows and if it works on Windows, it could work on Linux with Wine too.

Totally fair.. But your report just mentioned wine.

elishacloud commented 4 years ago

GOG lists the Bad Mojo Redux as not supported on Windows 10 (or more accurate, only supported on Windows XP, Vista, 7 and 8). With the latest (unreleased) version of dxwrapper I can get the game working on Windows 10 in exclusive fullscreen and windowed fullscreen using Dd7to9. I believe this issue is specific to Wine, unless I misunderstand something.

Note: on Windows the game still runs in 640x480, but puts a large black border around the game. I believe this is the intent of the game when running in larger than 640x480 resolutions. The Dd7to9 feature is only intended to exactly convert ddraw to d3d9, not to change the way the game works.

However, you may be able to eliminate the black box around the game by modifying the ini file and forcing a smaller resolution, though I did not have time to try it yet:

DdrawOverrideWidth         = 640
DdrawOverrideHeight        = 480
legluondunet commented 4 years ago

@elishacloud I followed your advices and now I can launch Bad Mojo Redux fullscreen (Native desktop resolution Windowed/Fullscreen), can alt+tab, ratio ok, my desktop kept his native resolution (1920x1080). But the game still 640x480:

Capture d’écran de 2019-09-14 00-20-32

An idea/option to stretch/scale it with dxwrapper?

dxwrapper-badmojo.log

elishacloud commented 4 years ago

This is exactly how it looks on Windows as well. I don't have any scaling options yet, but I have considered making some. Other games would benefit from these options as well. Let me see if there is something I can do quickly.

BTW: I also noticed from the log file that several API's cannot be hooked because they are "not hotpatch aware". I wonder if you can help me troubleshoot those issues? This is the same issue that Silent Hill 2 had. I would like to fix the hot patching so it works even on Linux, if possible.

elishacloud commented 4 years ago

@legluondunet, on Windows there is an option called "Run in 640x480 screen resolution". If I enable this option it is able to fill the screen. I am not sure if there is an equivalent option on Linux.

image

elishacloud commented 4 years ago

Ok, I was able to stretch it to fill the screen. However, there are a few things to note:

  1. I was unable to stretch the menu screen as the menu screen is done via GDI and dxwrapper does not do anything with GDI. I doubt I will fix this anytime soon.
  2. For this test build I just hard coded the stretched resolution to be 640x480. I will make this customizable later, but this will work fine for this game.
  3. This test build does not work correctly if you have dual display setup unless you have them set to duplicate the display. There is nothing I can do in my wrapper about this because the game already gets the resolution before loading my wrapper. This will need to be fixed by GOG, or someone will need to build a replacement launcher to replace the GOG launcher.
  4. If you are NOT using the GOG build then this module won't work with any resolution larger than 1920x1080. That is the max resolution this game can support. There is nothing I can do in my wrapper about this because the game already gets the resolution before loading my wrapper. So you need the GOG version to support any larger resolution. Basically the GOG launcher sets the screen resolution to 1920x1080 at game launch if the resolution is larger than that.

Here is the test build: dxwrapper.zip

mirh commented 4 years ago

Seriously, individual games enhancement should be left out of here. There is a reason if 13AG has an entire project just for that.

If really really really any, something that may still fit is having control over "the kind of scaling". For example, as far as I am told, if you have a VGA monitor the graphics card cannot handle the various modes for you.

elishacloud commented 4 years ago

Unfortunately it looks like only the videos in this game uses DirectX. The rest of the game play uses GDI. So only the videos scale. However, the good news is that I created a fully customizable scaling feature when converting from ddraw to d3d9.

Here is the updated module with scaling enabled: dxwrapper.zip

Seriously, individual games enhancement should be left out of here.

I completely agree. But if there is a game that does not work with dxwrapper I want to fix it so that it works with dxwrapper. All the fixes I add to dxwrapper are generic.

If really really really any, something that may still fit is having control over "the kind of scaling".

Yep, added! I will check in the code later.

mirh commented 4 years ago

I guess that's using bilinear/bicubic? Would be perfect if you could support nearestneighbour/integerscaling.

legluondunet commented 4 years ago

I tried your last two releases, each time I didn't modify dxwrapper.ini and used the one that is in your archive, no changes, I always obtained the same result. I joined you the log file for information. I thank you very much for the interest you gave to my request and the positive result is that you ameliorated dxwrapper compatibility for this game. dxwrapper-badmojo.log

legluondunet commented 4 years ago

I forgot: did you see that the "launcher.exe" sources are available in "extras" folder?

elishacloud commented 4 years ago

I guess that's using bilinear/bicubic?

Currently I just use D3DTEXF_POINT which is just nearest neighbor. See here.

Would be perfect if you could support nearestneighbour/integerscaling.

It is easy to change this, but if I use anything other than nearest neighbor it breaks games that use palettes since I use a pixel shader for the palette and other interpolations expect the colors to be gradient, which is not usually true for palettes.

I could change the code from using pixel shaders to using my own code to interpret the palettes, but that would mean the code would be done by the CPU and not the GPU so it would be slower. Unless there is some other GPU function that can interpret the the palettes before applying the D3DSAMP_MAGFILTER I plan to just leave it at nearest neighbor.

@legluondunet, would you mind testing the game once more? I noticed there was some issues with dxwrapper hooking the APIs and I would like to troubleshoot that, if possible. I don't expect the behavior to be any different, but I did add some code for logging.

Can you try with the test module below and send me the logs?

Here is the test module: dxwrapper.zip

** Edit: thanks for letting me know about the code for the "launcher.exe". I may check is out at some point. Someone should edit this code to add support for multiple monitors. However, I don't really want to spend a lot of time on one-off fixes for specific games, other than the work I am doing for Silent Hill 2.

mirh commented 4 years ago

NN is perfect. I guess like the only thing you miss is the integer scaling "clamp" setting then.

elishacloud commented 4 years ago

I do have an option to preserve aspect ratio, but integer scaling clamp is a good idea. I'll add it to my list. Thanks!

legluondunet commented 4 years ago

@legluondunet, would you mind testing the game once more? I noticed there was some issues with dxwrapper hooking the APIs and I would like to troubleshoot that, if possible. I don't expect the behavior to be any different, but I did add some code for logging.

Can you try with the test module below and send me the logs?

@elishacloud It's a pleasure for me to be your Linux Wine tester. As I tweaked and I tweaked this game numerous times in last days, I tried with DxWnd, dgVoodoo 2...added extern dll..., to obtain cleaner testing results:

My config:

legluondunet commented 4 years ago

1) without dxwapper: Wine virtual desktop window 800x600, video ok, menu ok, game ok. 2) with dxwapper (added dsound dll to native, dxwrapper.ini not modified, d9vk off): Wine virtual desktop window 800x600, no video (only the sound, black window), menu ok, game ok. url: https://github.com/elishacloud/dxwrapper/files/3613131/dxwrapper.zip

Capture d’écran de 2019-09-15 15-30-34

dxwrapper-badmojo.log

3) with dxwapper (added dsound dll to native, dxwrapper.ini not modified, d9vk 0.20 on) : Wine virtual desktop window 800x600, no video (only the sound, black window), menu ok, game ok.

dxwrapper-badmojo.log

legluondunet commented 4 years ago

4) FullscreenWindowMode = 1, d9vk on: Wine virtual desktop window 800x600, video ok, menu nok (only a black window), game nok, I can not escape video (no keyboard)

Capture d’écran de 2019-09-15 15-46-36 - 1

dxwrapper-badmojo.log

legluondunet commented 4 years ago

same result as 4) with dx9vk off dxwrapper-badmojo.log

elishacloud commented 4 years ago

I guess like the only thing you miss is the integer scaling "clamp" setting then.

@mirh, I added integer scaling clamp to the project. 2bdfdd47c8a82bcedeb740d1f6c07544a95fc13d

I have to say that when scaling it looks a lot better when you enable integer scaling clamp! Good call!