Tropico dd7to9 causes "No 3D Hardware available" tropico Steam Version

[OverWorldD]

Hi!

I have been trying to find some settings to be able to get Tropico to run in hardware mode without the graphics errors. I've installed the latest version of dxwrapper, copied ddraw.dll and the dxwrapper files to tropico (Steam version) folder.

To use the DdrawFixByteAlignment it seems i need to enable dd7to9 as the DdrawFixByteAlignment is under that section. However if I enable that, and select hardware in the game the game tells me no 3d hardware is available.

I can add that the Steam overlay does work and the screenshot below is taken through Steam

What am I missing here?
Windows 10
1.5.4 (?) Steam version of Tropico

[elishacloud]

Yes, make sure the 3D Mode setting in Tropico is set to Software. dxwrapper does not yet support 3D Hardware for this game. There should be no performance issue using software mode as computers today are plenty fast enough to handle this.

[OverWorldD]

Okay, gotcha! Thank you for clarifying. You see the reason I wanted to use dxwrapper was because I read about people who managed to run hardware mode without graphic errors due to dxwrapper's DdrawFixByteAlignment function as described in this discussion. #109 But, yeah i can use software mode. Mainly curious :)

[OverWorldD]

OH!: It actually works perfectly in hardware mode with the build posted in that discussion :) I just assumed it would work with the latest build too but it didn't. I'll just run that older build then! The clouds look better and the overall performance is a bit better too.

[elishacloud]

The new version should work as well as the old version. Can you try enabling the DdrawDisableDirect3DCaps option in the ini file of the latest version of dxwrapper to see if this helps?

[OverWorldD]

Nope

Dd7to9 = 1
EnableDdrawWrapper = 1
DdrawFixByteAlignment = 1
DdrawDisableDirect3DCaps = 1

With the latest version as soon as i have Dd7to9 enabled it says no 3d hardware available.

[elishacloud]

Interesting. That doesn't sound right. Can you try with this update: dxwrapper.zip

Let me know if this works or not.

[SpikeBelfrey]

I'm not the original poster, but I tried the version linked with a fresh GOG install of Tropico and it crashes on startup, though when I tried enabling HandleExceptions it got in-game but without graphics. (Just a black screen)
Edit: I'm on an older graphics card, a Nvidia GTX 750 Ti for reference.

I can send the full log if desired but these were the raised exceptions:

11748 14:08:36.168 UnhandledExceptionFilter: exception code=0xc0000005 flags=0 addr=0052C9C0
11748 14:08:36.185 UnhandledExceptionFilter: NOP opcode=ʠlen=3
11748 14:08:36.185 UnhandledExceptionFilter: exception code=0xc0000005 flags=0 addr=0052C9C5
11748 14:08:36.185 UnhandledExceptionFilter: NOP opcode=ʠlen=2
11748 14:08:36.185 UnhandledExceptionFilter: exception code=0xc0000005 flags=0 addr=0052C9C9
11748 14:08:36.185 UnhandledExceptionFilter: NOP opcode=ʠlen=3
11748 14:08:36.186 UnhandledExceptionFilter: exception code=0xc0000005 flags=0 addr=0052CA60
11748 14:08:36.186 UnhandledExceptionFilter: NOP opcode=ɠlen=3

[elishacloud]

That is weird. I am using the demo version and not seeing the issues. Here is the latest build. Let me know if you still see an issue with this build: dxwrapper.zip

If you have issues I might need to have you try the debug build.

Edit: HandleExceptions is not a good fit for this case since that just skips over the crash and the crash in this case is a coding error, I guess.

[SpikeBelfrey]

No dice unfortunately. It crashes the same way with this new build.
Out of curiosity I tried this build with the demo (downloaded from archive.org) and it does get into the title screen fine, along with the tutorial, but once I set the renderer to Hardware it crashed and continues to crash once I go into the demo tutorial.

[elishacloud]

once I set the renderer to Hardware it crashed and continues to crash

Yeah, the older version of this wrapper only reported as showing software support (i.e. 2D). Now I am adding 3D (i.e. hardware) support so the game thinks it can use it. I recommend keeping the game on software support,

Note: the demo only supports software rendering. That is why it works with that.

[SpikeBelfrey]

Interesting that the demo even lets you select it then. In any case, I think I misinterpreted the newer builds as enabling proper hardware renderer support, so apologies for that. My crashes in the registered version are with the game set on software rendering, though.

(Edit: I've never explicitly mentioned, but the latest stable build does work fine.)

[elishacloud]

Edit: I've never explicitly mentioned, but the latest stable build does work fine.

Which build are you referring to that works fine? The latest one I posted in this thread?

[SpikeBelfrey]

1.1.6900.22.

[elishacloud]

It appears I must have broke something if it works on that build but not on the latest. Can you use the below debug build and send me the logs after it crashes? The logs will be large so you will need to zip them.

Here is the debug build: dxwrapper.zip

[SpikeBelfrey]

Here's what I get: dxwrapper-tropico.log
I tried a cursory search and couldn't find if Tropico had a way to load a game from command line or anything, so this is just from trying to launch the game since it crashes near instantly.

[elishacloud]

Thank you for the logs!

For some reason the game wants to run in windowed mode for you. It looks like you are using dual monitors since the display shows resolution of 3280x1080, but I only see 1920x1080 for the monitor size.

It looks like the game only get as far as the first Lock() and crashes after the Unlock(). I made a few changes and just reverted several fixes:

1. Disabled DDrawCompat fixes.
2. Set to 32bit aligned rather than 64bit.
3. Reversed the changes in EnumDevice7().
4. I forced limited display modes on.

Please try this out and send me the logs. If this works I will need to figure out which one of those changes caused the issue.

Here is the new build: dxwrapper.zip

[SpikeBelfrey]

I didn't think about windowed mode mattering. I intentionally had it on that, and I am using two monitors.
With whether it's fullscreen/windowed mattering in mind, I put 3 logs in this zip, log1 is using the version 3 posts above in fullscreen, log2 and log3 are using the one you just sent in windowed and fullscreen, respectively. Windowed still crashes but fullscreen worked on both versions.
4-12TropicoLogs.zip
(Both fullscreen logs are loading the main menu, going into the tutorial, then quitting.)

[elishacloud]

The issue should be fixed now. I added a change in the past to default to 16bit color and that broke this game. I reverted the change. It should work now.

Here is the latest build: dxwrapper.zip

[SpikeBelfrey]

Yep, it does work! Thanks for all that.

[elishacloud]

Does it work on both hardware and software rendering? I cannot test hardware rendering.

[SpikeBelfrey]

Hardware seems to mostly work from looking at the tutorial, with the only issue being text looking corrupted:

and in comparison in software rendering:

[elishacloud]

Ok, thank you. I will have to look into that later.

[elishacloud]

Ok, I think I know what is happening with the text in hardware rendering. I believe what is happening is that the game creates the surfaces for these texts as non-byte aligned. Then I align them to 64bit, making the textures slightly larger. When the game displays the textures they have it set to point filtering which causes them to get squished because I created them larger than the game expects.

I put a fix in for this. I added a couple of options. For your issue try setting DdrawFixByteAlignment to 2 in this new build. that will disable point filtering and should allow the texture to be display correctly.

Here is the new build: dxwrapper.zip

Please let me know if this works or not.

[OverWorldD]

Interesting. That doesn't sound right. Can you try with this update: dxwrapper.zip

Let me know if this works or not.

So sorry I missed this post! However it seems the discussion and development has gone even further now. I'm hoping to get time to test the latest build later today

[SpikeBelfrey]

It didn't seem to have much effect unfortunately. Tropico's text rendering is mysterious.

Also, I tried to test it in fullscreen as well, and this build and the last posted don't seem to like it all that much, tending to either crash with this error:

D3D Error in file '', line 745, 'undefined'
error code 1: #150
error code 2: #-2005532522

and/or being stuck on the last rendered frame but still running otherwise after switching resolutions. I'm not sure if they're helpful but here's a couple of logs. I'm pretty sure log1 is trying to start the game configured for fullscreen, and log2 is switching from windowed to fullscreen.
dxwrapper-tropico-log1.log
dxwrapper-tropico-log2.log

Software fullscreen still works as normal, though.

[elishacloud]

There seems to be something wrong with the last build I gave you. Maybe I gave you the wrong build? Anyways, I was able to reproduce the issue in the demo version and I put a fix in for this.

What was happening was that the game uses a texture for each character in the game. However, since they are not byte aligned Direct3D9 adds 1 or 2 extra columns of pixels to the texture. My previous code was updating the whole texture memory, including those columns of pixels. What you see as messed up text is just these extra rows of pixels, with garbage in them, getting displayed on the screen.

Here is the fix: dxwrapper.zip

[SpikeBelfrey]

It looks a lot better now, though text is squished slightly horizontally:

Additionally, something I should've spotted earlier is that tiles bordering water are a bit broken, in that they appear as just squares instead of using the shoreline tiles. A comparison of Hardware without and with dxwrapper:

Apologies for not noticing that sooner.

[elishacloud]

It looks a lot better now, though text is squished slightly horizontally:

That should be able to be fixed by enabling both DdrawFixByteAlignment and DdrawDisableByteAlignment. However, the text still does not look as smooth as with Software rendering.

Additionally, something I should've spotted earlier is that tiles bordering water are a bit broken, in that they appear as just squares instead of using the shoreline tiles. A comparison of Hardware without and with dxwrapper:

I see. I will need to look into this later. Not sure what is happening here.

[elishacloud]

This issue should be fixed in the latest build here: dxwrapper.zip

[c6-dev]

This issue should be fixed in the latest build here: dxwrapper.zip

I am using the GOG version of the game. This build causes my game to hang when switching to hardware mode with this error popup. Issue persists after restarting, clicking Continue just makes the popup reappear.

dxwrapper-tropico.log

I have not changed any settings in the .ini provided with the build.

[c6-dev]

I have also tried debug binaries from the latest GHA run 477, game window would not appear at all with Dd7to9 enabled.

dxwrapper-tropico.log

[elishacloud]

Looks like you are running Windows 11. For some reason there is an issue with Windows 11 when using the debug engine.

Can you try this build: dxwrapper.zip

Edit: Here is a build that uses Disasm instead of debug engine for hooking. Please try this build instead: dxwrapper.zip

[c6-dev]

Edit: Here is a build that uses Disasm instead of debug engine for hooking. Please try this build instead: dxwrapper.zip

Was able to start up with this build but attempting to enable hardware mode caused the same error as before.

dxwrapper-tropico.log

[elishacloud]

I was able to reproduce it. It only happens in fullscreen mode when using hardware rendering. If you are in windowed mode or software rendering then it works fine I will take a look at it and fix it.

[elishacloud]

Ok, I think I fixed all the issues here: dxwrapper.zip

[c6-dev]

Yep, no issues with this one. Thank you!

P.S. One tiny issue I'm still having is the game crashing when transitioning from main menu into the game if RTSS overlay is active. Probably out of scope for the wrapper, just thought it may be worth mentioning.

[mirh]

Not necessarily. Does it still happen?
If it does, it should still be reported either here or to Unwinder.

[elishacloud]

If it works fine with dxwrapper without RTSS, then I suspect it is an issue with RTSS not dxwrapper.