Tropico - hardware rendering mode yields corrupted graphics

[Ligushka]

The 2001 simulation game Tropico works fine in modern Windows versions using software rendering. However, when hardware rendering is attempted, graphics are mostly corrupted, as seen in the screenshot.

Is there a way to use dxwrapper to correct the problem?

[elishacloud]

This issue is almost certainly related to pitch/stride. I have seen this issue before. What version of DirectX does Tropica use?

[Ligushka]

Sorry for the delayed reply, Github did not send me an email notification.

My understanding is that Tropico uses Direct3D 7.

[Ligushka]

I just checked the Tropico demo and it exhibits similar behavior when using Hardware rendering. The demo can be downloaded from CNET: https://download.cnet.com/Tropico-demo/3055-2119_4-10059685.html

[elishacloud]

Thanks for the link to the demo!

[elishacloud]

The issue is that the game completely ignores the pitch/stride sent by DirectDraw. In newer versions of Windows the surfaces are byte aligned for performance reasons and so the pitch may be larger than the width. In this case some of the game's video data is written to the unused part of the surface.

I added a quick fix for this by emulating the lock function and feeding the game a pitch that it is expecting.

Here is the updated build: dxwrapper.zip

[elishacloud]

I guess the game is loading ddraw.dll from the system folder. Try renaming the ddraw.dll stub file to something else. Keep dxwrapper.dll and dxwrapper.ini the same.

Here are some possible options for renaming ddraw.dll: dsound.dll, dinput.dll, winmm.dll, dciman32.dll

[msbr0815]

Wow, thanks a lot for your quick reply – it is working when I rename the file to dsound.dll (but none of the others). The Windows XP compatibility mode is required, but I expected that. The system indeed loads ddraw.dll from the system folder according to the log file. Again, thanks a lot, now I can finally play this game on my current setup! :)

Out of interest, would it somehow be possible to rename ddraw.dll to something else and load it through the ini file instead of renaming it to dsound.dll? I gave it a quick try, but couldn't get it to work. I may not have used the proper syntax, though, and since your suggestion is working, I didn't want to spend too much time on it.

[elishacloud]

There are a number of other file names you can use to rename ddraw.dll to. I just picked those ones because they are the best chance of working. Is there something wrong with using dsound.dll?

BTW: if you want to use a different dsound.dll file you can use the dsound.dll ini file to redirect it to any other file. See here: https://github.com/elishacloud/dxwrapper/wiki/Configuration-(stub)

[msbr0815]

Nothing wrong at all, I was just curious to see what was possible, e. g. in case I'd run into similar problems with other games in the future.

[elishacloud]

The possible file names are mentioned in the link I gave above: https://github.com/elishacloud/dxwrapper/wiki/Configuration-(stub)

[Ligushka]

Somewhat related, is there a way to use dxwrapper to have the 1280x1024 resolution "boxed in" at the native res of 1920x1080 with black filling in the rest of the screen? Enabling dd7to9 and then these settings yields the correct look, but also results in the mouse cursor having an "offset" / binding to what seems to be a 640x480 box in the upper left corner of the main menu, plus Tropico believes hardware mode is not usable when using dd7to9 without these settings defined.

DdrawUseNativeResolution = 1
DdrawIntegerScalingClamp = 1
DdrawMaintainAspectRatio = 1

I can adjust my monitor's settings to display 5:4 aspect ratio instead as a workaround if there's no way around the resolution limitation.

Thank you again for your time and effort. I find dxwrapper indispensable for playing Star Trek: Armada (1) as well.

[elishacloud]

Somewhat related, is there a way to use dxwrapper to have the 1280x1024 resolution "boxed in" at the native res of 1920x1080 with black filling in the rest of the screen?

I spent sometime looking into this. The game handles the mouse using hardware rather than using DirectX. This means if you stretch the game graphics it will not line up with the mouse. I don't have code in dxwrapper to handle games that use mouse hardware rather than DirectX. I might look into this later, but it is not really the purpose of dxwrapper.

plus Tropico believes hardware mode is not usable when using dd7to9 without these settings defined.

This is happening because when using hardware mode it uses Direct3D APIs. I have not yet added support for Direct3D APIs when using dd7to9. I started that code earlier this year, but it will take a good amount of time before it is all completed.

[Ligushka]

Thanks for taking the time to check that out. I understand, I'll adjust aspect ratio on my monitor instead.

I've spent about 3 hours playing Tropico using the hardware rendering mode with dxwrapper and it's working well and stable. Thank you again.