Here I've attached a full debug log from running the game when a failed texture loaded. I've tried converting the face texture to different formats using texconv.exe from DirectXTex, but none of them appear to fix the problem.

Thanks for the log!
Unfortunately I should have a look into it by debugging but I don't know how to run this game. If I get it right this is an online game which requires a server but there is none by today.

Dege wrote on 2025-04-29, 20:00:

Thanks for the log!
Unfortunately I should have a look into it by debugging but I don't know how to run this game. If I get it right this is an online game which requires a server but there is none by today.

There are private servers run by some in the community. The one I'm currently playing in is called SWG Restoration. You can find it here: https://swgr.org/play/.

There are tools available to help access many of the game asset files which I can help with if need be.

Here are some assets relevant to how the game handles texture mapping. Not sure if this will help, but figured I'd provide them anyway.

Thanks. I still didn't look into the game itself but I released a new WIP version. I improved the debug layer for UpdateSurface. Could you plz check out what error message comes now, with that?

I ran with the new debug version you mentioned. The error has slightly changed to:

1SwgClient_r.exe [dgVoodoo] ERROR: Direct3DDevice9Ex (0000022F91D6CBE0)::UpdateSurface: Formats of the source and destination surfaces are different.

I've attached the log below.

According to one of the devs, "The client finishes baking the face texture into a system memory surface through the texture renderer... The client then attempts to call UpdateSurface() to push that into a GPU-usable texture, but dgVoodoo2 internally redirects this through D3D11, and it fails, leading the GPU texture to remain empty or black, hence the black face render." They're guessing it might have something to do with DgVoodoo2's handling of D3DPOOL. They also let me know that the format of the baked face texture is D3DFMT_A8R8G8B8, which has the Direct3D 11 format equivalents of DXGI_FORMAT_B8G8R8A8_UNORM and DXGI_FORMAT_B8G8R8A8_UNORM_SRGB.

Hopefully that helps!

Thanx. Yes, it's obvious that the black face is because of the failed texture data upload.
But dgVoodoo frontend does some validation in UpdateSurface and if it fails, the call is not routed into the DX11/12 backend. And this is the case here. It's not failing in DX11 but dgVoodoo DX9 frontend code.

According to my experience, the typical case is when format of either surface is D3DFMT_A8R8G8B8 and D3DFMT_X8R8G8B8 is of the other. The same, but with or without an alpha channel, because, for example, the game tries to align the texture formats with the current display mode (which never has an alpha component). The 2 formats must exactly match otherwise UpdateSurface fails, it does not support format conversion.

It's a pity that I forgot to dump the 2 formats in the error message.
Could you plz try to create another log with debug option "tracing" enabled, to see what surfaces the method is called on?
The game will be very slow, so if you have a hard time to get to the erroneous point that way, then I'll give you a D3D9 version dumping the formats instead.

Btw, I didn't know that you are in contact with the game developers.

Dege wrote on 2025-05-02, 18:14:

Btw, I didn't know that you are in contact with the game developers.

It's a bit of a unique scenario, but I'm in contact with the private server devs, not the original game devs.

I've attached the new log with tracing set to 2 in the config.

Thanks! I created a new D3D9 build (64 bit spec-release), dumping a little more information in UpdateSurface:

http://dege.fw.hu/temp/d3d9_updatesurface.zip

Could you run the game with it again, plz? (tracing enabled)

Just as you suspected:

1SwgClient_r.exe	[dgVoodoo] ERROR: Direct3DDevice9Ex (000002B8A9487910)::UpdateSurface: Formats of the source and destination surfaces are different. Src surface (parent texture: 000002B8A91EF350): D3DFMT_X8R8G8B8, dst surface (parent texture: 000002B8D1FA7600): D3DFMT_A8R8G8B8

I've attached the debug text below.

Thanks!
Yep. In addition both textures are dynamic. Dynamic textures are not intended to be used this way.

The question is, how does this work natively. I guess the game runs on some other code path.
You can try if selecting another virtual card like the GF9800 help. I may be able to install this game some day, but if not, I'm afraid I can't fix this problem.

Dege wrote on 2025-05-04, 20:01:

I may be able to install this game some day...

You can go here to install it: https://swgr.org/play/. You do need to make an account on that website to play it though.

I'll try your suggestion and get back to you.

Thanks!
I could reproduce the issue. But there is something that I don't understand: my executable is 32 bit, not 64. Also, I don't have an UpdateSurface call with it, so the whole issue with it is irrelevant, the problem comes without it too.
But why the different executables?

In the launcher, there's an options section. There's a setting to run the game in 64-bit.

Dege wrote on 2025-05-06, 07:46:

Thanks!
I could reproduce the issue. But there is something that I don't understand: my executable is 32 bit, not 64. Also, I don't have an UpdateSurface call with it, so the whole issue with it is irrelevant, the problem comes without it too.
But why the different executables?

I'll try it in 32bit and see what happens. I'm surprised you're not getting the UpdateSurface error.

The way I tested was by having a human character in the second slot so that I could see the issue in the character select screen, but only after switching to that character.

I'd then run with and without switching to that character, and the main difference I would see is that error.

I think I fixed it:

http://dege.fw.hu/temp/d3d9_SWG_Restoration_fix_x64.zip

The UpdateSurface error comes with the 64 bit version but not with the 32 bit one.
It's irrelevant though, I found a bug in the code for reading back rendertarget data.

You did it! Wow, I'm confused as to why that error only presents when black faces are loaded. I wonder if it's just faces in general?

C4RP3 N0CT3M wrote on 2025-05-07, 03:10:

You did it! Wow, I'm confused as to why that error only presents when black faces are loaded. I wonder if it's just faces in general?

They generate face textures by drawing by the 3D hw into a rt texture, then read back the result and load it into a plain managed texture. I don't know why face textures are not static but generated this way and I also don't know if face textures are the only special ones of this kind.

Also, if UpdateSurface (used to move data into the plain texture) fails, then the game code probably runs on a fallback path that does the same but "manually" (LockRect/UnlockRect + mem copy).

The game devs could answer those questions.

You sir are a legend. I have been talking to C4RP about this and it has allowed me to use reshade with RTGI and REST both in swg. I am a very very happy person. Ideally it could work with 32-bit as well, as the 64-bit client has some issues, but this is truly legendary work you've done here. Thank you!

The game was made long long ago and most of these issues are old legacy issues now being addressed by the new dev team at the restoration project, but until much of this is fixed, we were stuck unable to wrap the game to dx11 or vulkan without major issues. I applaud you and the help you provided the swg community today.