pod OEM 1.0 (Planet of Death) Unknown resource format: D3DDDIFMT_UNKNOWN

[Sol1vaN]

Hi there,

It seems theres a Texture Format that DDrawCompat can't handle. I want to play pod OEM 1.0 (not pod 2.0). Because the OEM version have unique features and has been removed in pod 2.0 Can you make DDrawCompat work with pod oem ?

DXWnd can run pod OEM, but this program can't scale the internal resolution like do DDrawCompat .

I've attached the log. Cheers. DDrawCompat-PODMMX.log

[narzoul]

It's not a texture format problem. It seems there is some memory corruption (buffer overflow) in the game when too many display modes are available, causing it to try and set an invalid display mode (in my case 640x480x900). There was no check for the color depth in DDrawCompat, so it allowed the resolution change with the invalid color depth, which leads to problems when creating the primary surface. I will fix that, but then the game will just exit with a different error on startup.

You can work around the issue by setting SupportedResolutions=640x480 in DDrawCompat.ini. This gets the game working fine for me, but it won't get you what you want. PODMMX doesn't use Direct3D, it has its own software renderer, so it's not possible to upscale the rendering resolution.

[Sol1vaN]

Thanks for the reply!

But now I get this error when run PODDMMX:

Searching for this I've found this article: https://learn.microsoft.com/en-us/windows/win32/api/ddraw/nf-ddraw-idirectdraw7-testcooperativelevel

But I can't understand anything, can you figure out what means this? I apreciate a lot your help, many thanks!

[narzoul]

I don't have this issue. Please set LogLevel=debug in DDrawCompat.ini and upload the resulting debug logs.

[Sol1vaN]

I've tested with and w/o PodHacks patcher from nicode, but the problem still persist.

https://svn.nicode.net/podhacks/bin/ DDrawCompat-PODMMX.zip

[narzoul]

Ah, you haven't mentioned that you're using an older version of DDrawCompat (v0.5.1 based on your screenshot). Can you check with the latest version (v0.5.2) too? Although I can't reproduce the issue with v0.5.1 either.

[Sol1vaN]

the same issue with 0.5.2 maybe you haven't test the same pod. i mean, pod oem 1.0, not pod retail 2.0 here's the iso: https://archive.org/details/pod_oem

my podmmx.exe is 1.194 KB

[narzoul]

Yes, I'm using the 1.0 version, more specifically 1.0.2.0, even though you linked to the wrong version above (2.1).

Based on your debug logs, I suspect the issue is that the game tries to establish exclusive fullscreen mode from a second thread, without properly releasing the exclusive mode already established by the first thread. The issue is somewhat similar to https://github.com/narzoul/DDrawCompat/issues/286#issuecomment-2029973283 except that the second thread tries to release the first thread's DirectDraw object, which then (I assume) will fail to release the exclusive mode mutex, which can only be released by the first thread itself. This might be confirmed by debug logs with DDrawCompat v0.5.2.

In the other issue it was mentioned that the "EmulateDirectDrawSync" shim could "fix" this issue, so you could try that, if you know how to use Microsoft Compatibility Administrator.

The reason I'm not getting the same error is that in my case, all attempts to establish exclusive fullscreen mode happen on the first thread. Additionally, this whole multiple attempts to establish exclusive fullscreen mode only happens when PodHacks is enabled. If you properly remove it, then the game should only do it once, at least based on my own logs, so you shouldn't be getting this error. I don't know why my game sets the fullscreen mode always from the same thread, while yours is switching threads. I'm not familiar with PodHacks, and despite it being open source, I did not find any direct calls to such functions in it, so it must be doing something else to trigger this behavior.

Please make sure you remove PodHacks properly, test with DDrawCompat v0.5.2, and upload debug logs again, if it still doesn't work.

[Sol1vaN]

i've tested in a new profile on windows, but nothing. ill test in a vm to see what happens.

ps: DDrawCompat can work on vm? (vmware)

[Sol1vaN]

I've found the problem, and this is about you comment, to use Microsoft Compatibility Administrator Compatibility mode (Win95 / Win98) 🤦‍♂️ 😂😂😂😂 This work with and without PodHacks! ✨🎉 Another thing that I've forgot to mention is that I've two monitors, can be this the problem? I think not, because I've tryed turning off one of them but the problem persist.

Here's the LOGs of the two modes (with and without podhacks). without podhacks DDrawCompat-PODMMX.zip

with podhacks DDrawCompat-PODMMX.zip

Last question/request (if exist a trick or somewere). You mention the following: but it won't get you what you want. PODMMX doesn't use Direct3D, it has its own software renderer

knowing this is a propietary software renderer, is impossible in anyway, tool, trick, black voodo magic to upscale this in today? i know, maybe the last hope is reverse engineering, like Wipeout Phantom edition: https://github.com/wipeout-phantom-edition/wipeout-phantom-edition

The following you can skip (I hop not). Historical memories of my brain: I remember a lost pod forum (cant remember its name), many guys debating about releasing the source code of pod 2.0 retail and pod 1.0 oem. But one guy didn't want to release the source code for "ideological reasons", the debate was something like:

Ubisoft managed the development of POD through 2 parallel projects: One team was in charge of the software render, and the other team handled the 3dfx and Direct3D version 3 and 5 renders. The whole main development (software and 3dfx/D3D) was done in the Watcom 5 language (a derivative of the C language of that time, 1997/1998). Both engines operated on a single pipeline for everything, making it extremely difficult to develop a source port for these engines.

That about pipeline I can't figure out what it means, but I think they mean that all graphics, physics, and sound pass through one pipeline, and this complicates the entire process.

Well, thanks very much for your help! 😅👍 I hope you can read this. I'd like to know the opinion of developers (although I'm not one of them, sadly).

[narzoul]

ps: DDrawCompat can work on vm? (vmware)

Maybe, if the VM has good enough WDDM GPU drivers, but it's not supported by me.

Compatibility mode (Win95 / Win98)

Yes, those two include the EmulateDirectDrawSync compatibility shim, among others.

Another thing that I've forgot to mention is that I've two monitors, can be this the problem?

No, I don't think it's related.

knowing this is a propietary software renderer, is impossible in anyway, tool, trick, black voodo magic to upscale this in today? i know, maybe the last hope is reverse engineering, like Wipeout Phantom edition

Yes, without access to the source code, it can only be done by reverse engineering and modding the renderer.

That about pipeline I can't figure out what it means

I don't know either in this context.

[Sol1vaN]

many many thanks for all. pod oem works pperfect.