Update ddrawcompat?

[eierfrucht]

Ddrawcompat has recently been updated to v0.6.0

One specific game (Sacred Gold + a specific 16:9 patch) can finally run without any artifacts or shimmering with these minimal settings:

AlternatePixelCenter = on SpriteAltPixelCenter = on DisplayFilter = bilinear(0) ResolutionScaleFilter = point ResolutionScale = app(2) SpriteDetection = point SpriteFilter = app SpriteTexCoord = clamp TextureFilter = app

"ResolutionScale = app(2)" can also be (4), (8), etc. but other integers cause artifacts in certain locations.

Ddrawcompat's supersampling mechanism (integer scale the picture to 2x/4x/8x with Point Sample, then downscale with Bilinear/Bicubic/Lanczos) results in a super clean picture, but when zoomed out FPS gets down to mid-30s. DXWrapper and dgVoodoo2 have issues with the game, but easily yield several times more fps when zoomed out likely due to DX7-to-DX9/10/11/12 translation. (more on that below).

DXWrapper is able to run the game at 1920x1080 (via the 16:9 patch) but the image is poorly scaled / distorted because it's not the right way to do this; instead, it is neccessary to set the game resolution to 1366x768 then use Ddrawcompat's supersampling mechanism. The game engine is fit to run just at 768p, other (hacked) modes trigger picture scaling problems that are intrinsic to the engine and are outside of the scope of any wrapper. Still, if (wrongly) run at 1920x1080 in DXWrapper, the game has much better fps when zoomed out likely because of the DX7-to-DX9 translation. Trying to force 1366x768 upscaled to 1920x1080 without supersampling via DXWrapper results in a 1920x1080 black screen with the game running inside a 1366x768 square in the center, still high fps when zoomed out.

dgVoodoo2 is able to successfully superscale the game from 768p to 4X the size and back to the target display size, but lacks the above-listed DDrawcompat-specific fixes (so there are occasional worldspace tiling artifacts) and its supersampling mechanism, for some reason, still produces residual shimmering after downscaling the picture to monitor size (set to Bilinear in the config file; same works perfectly with DDrawcompat). dgVoodoo2 has never worked well with this game and probably never will.

So it appears that the latest DDrawcompat is the only thing that is able to fully resolve the game's issues on modern hardware AND neatly supersample the image to 2x/4x/8x with proper downscaling to actual screen size afterwards, which is vital to preventing both tiling seams and image shimmering while scrolling the worldspace, especially when zoomed out.

And DX9 translation (or something else that both DXWrapper and dgVoodoo2 have) is necessary to achieve high FPS when zoomed out.

Thus I would like to inquire if it is possible to update DXWrapper's builtin DDrawcompat to 0.6.0 to make it possible to both utilize its scaling mechanisms (DisplayFilter = bilinear(0) ; ResolutionScaleFilter = point ; ResolutionScale = app(2) ) and sprite-specific fixes (SpriteFilter = app ; SpriteTexCoord = clamp ; etc)

This game is a massive **** that will not tolerate certain interruptions (like setting TextureFilter or SpriteFilter to anything else than "app", or else issues ensue in certain game locations) but absolutely requires certain other enforcements (like SpriteTexCoord = clamp or SpriteDetection = point) and the way the engine zooms even when set to its native 768p (using Point Sample) causes lots of shimmering that can only be fixed by a specific supersampling mechanism (that the latest DDrawcompat has). Hacking the resolution beyond 768p triggers multiple issues that can't possibly be resolved by wrappers, so is out of the question.

P.S. Sorry for the wall of text. The issue is really, really complicated one. Any tiny wrong step with this game causes the engine to produce seams and artifacts in just a handful of locations (like second floors of buildings) with the 90% of the game world intact. Even changing the supersampling mode from app(2) to app(3) in Ddrawcompat does!

[eierfrucht]

/UPDATE/

Just checked with a clean unhacked installation of the game (locked at 1024x768):

DDRawcompat 0.6.0: poor fps when zoomed out, all specific fixes work as expected eliminating all artifacts; 2X supersampling gives a smooth picture even when running around zoomed out.

DXWrapper: occasional artifacts, game runs in a small 1024x768 square, very high fps when zoomed out; running around while zoomed out gives shimmering because that's a known vanilla behavior (the engine itself when zoomed out uses unfiltered Point Sample, supersampling combats this).

dgVoodoo2: occasional artifacts, very high fps when zoomed out; fullscreen & supersampling work but slightly distorted image overall, small amounts of shimmering while running around zoomed out -- apparently because the supersampled image doesn't get properly downscaled to screen size neither with Bilinear nor with Bicubic nor Lanczos (still way better than without supersampling).

So the vanilla behavior is identical to what I get with a 1024x768-->1366x768 widescreen patch.

Wrapping DX7 into something else is what seemingly boosts the performance. I remember playing this game 20 years ago on a single-core 2.4 Ghz CPU and an antique GPU, on Windows XP, and FPS when zoomed out was as high as I'm getting with DXWrapper and dgVoodoo2 with API translation enabled.

[elishacloud]

Ddrawcompat has recently been updated to v0.6.0

Yes, I saw that.

DXWrapper is able to run the game at 1920x1080 (via the 16:9 patch) but the image is poorly scaled / distorted because it's not the right way to do this; instead, it is neccessary to set the game resolution to 1366x768 then use Ddrawcompat's supersampling mechanism.

dxwrapper doesn't have any real scaling features. I am focusing in re-implementing each of the DirectDraw/Driect3D functions rather than adding enhancement features like this.

And DX9 translation (or something else that both DXWrapper and dgVoodoo2 have)

dgVoodoo2 translates it to DX11 or DX12. It cannot translate it to DX9.

Thus I would like to inquire if it is possible to update DXWrapper's builtin DDrawcompat to 0.6.0 to make it possible to both

dxwrapper's dd7to9 and DDrawCompat aren't compatible and there is no way to make them compatible. DDrawCompat would need to be completely rewritten to support DX9 for this to work.

So the vanilla behavior is identical to what I get with a 1024x768-->1366x768 widescreen patch.

Sounds like it is working the way it should. Probably what needs to happen is one of two things:

1. Someone makes a real mod for the game to allow for larger resolutions.
2. dxwrapper adds scaling features.

Unfortunately, I am a long way from #2. However, dxwrapper will convert the game to DX9. Maybe you can find a DX9 wrapper that is able to do scaling and use that along side dxwrapper. That is part of the reason I wanted to translate games to DX9 so you can use all the plethora of DX9 wrappers to do things like this.

[eierfrucht]

dxwrapper's dd7to9 and DDrawCompat aren't compatible and there is no way to make them compatible. DDrawCompat would need to be completely rewritten to support DX9 for this to work.

Oh! I see. I thought they could be chained simply because DXWrapper integrates DDrawcompat. What a bummer... I was hoping either to chainload DDrawcompat and DXwrapper, or utilize DXWrapper's built-in DDrawcompat AND DD9 translation.

dgVoodoo2 translates it to DX11 or DX12. It cannot translate it to DX9.

I stand corrected. It can translate DX9 to 11 or 12 though and this is where I erroneously got "DX9" from (was very tired). Still my point stands: it does api translation and maybe somehow that leads to a massive FPS boost under certain conditions, or maybe not.

Maybe you can find a DX9 wrapper that is able to do scaling and use that along side dxwrapper. That is part of the reason I wanted to translate games to DX9 so you can use all the plethora of DX9 wrappers to do things like this.

Since dgVoodoo2 can up DX9 to DX11/12 and supports scaling, maybe they could be chainloaded but... dgVoodoo2 can directly translate DX7 to 11/12, so no need for a second wrapper :D The rub is, both dgVoodoo2 and DXwrapper lack the following fixes that are necessary to run the game without artifacts:

AlternatePixelCenter = on SpriteAltPixelCenter = on SpriteDetection = point SpriteTexCoord = clamp

So it looks like DDrawcompat remains my best standing option.

Someone makes a real mod for the game to allow for larger resolutions.

At least two such mods exist, I'm using one of them. They support custom resolutions up to 1080p. The issue is that these mods/hacks can't do anything about the fact that the engine has a fixed camera distance and expects a specific number of pixels per inch so that each pixel of the 2D assets perfectly aligns with each pixel of the viewport. Anything above 768p results in every 2D asset wrongly scaled with Point Sample by the engine, which makes the picture messy but not any more detailed (since most of the game world is 2D tiles). This way forcing a higher resolution only makes things look essentially worse, let alone UI getting tiny and unusable. Thus 768p is the way to play it, no idea why someone even bothered to hack in the other resolutions given how poorly they fare with a mix of 2D assets, fixed camera distance, and obligatory Point Sample.

The two available alternate zoom levels are 0.5x and 2x, which are essentially integer scaling, so at 768p we still get a super clean picture in terms of pixel alignment, but at 0.5x there's inherent luma shimmering during camera movement due to the engine's Point Sample filter for the worldspace (this is why supersampling via a third party tool is necessary -- it removes that).

Enforcing unconditional sprite filtering (possible via both DDRawcompat and dgVoodoo2) causes seams and artifacts in random places depending on the current zoom level and a number of other factors but does nothing to resolve the root issues due to how janky the engine is. In fact, the reason why I'm able to decently run the game with DDrawcompat is that it has necessary fixes to achieve the opposite: prevent certain flats from being wrongly treated as textures and force alternate pixel center coordinates on others.

The DDrawcompat-related issue that I'm facing however has nothing to do with resolution or supersampling. Be it 1920x1080 or 1366x768, or even unmodded vanilla's 1024x768, with supersampling on or off, no matter what--a few locations suddently have very bad FPS when zoomed out to 0.5x. These problematic locations are settlements with multiple NPCs but no such lag happens in other crowded towns, or during combat in the wilderness with dozens of enemies rendered. My first thought was CPU affinity or priority, but upping the priority or locking the game process to a single core does nothing.

If say I hack in 1920x1080 and run the game with dxWrapper, no such issue happens (but dxWrapper lacks the necessary fixes from DDrawcompat, therefore artifacts galore). If I run it with dgVoodoo2, at 1080p in-game and with an insane supersampling factor, still no such issue (but somehow dgVoodoo2's supersampling results in a much poorer picture than DDrawcompat's even though I configure the pipeline to be identical: integer scale with Point Sample to a resolution that greatly exceeds that of the monitor →→→ downscale to the actual display resolution with Bilinear, Bicubic, or Lanczos; I cannot explain this difference in results). dgVoodoo2 too lacks DDrawcompat-specific fixes so some seams and artifacts persist in a few spots across the worldspace, and yet others afflict the UI.

Bottom line, something in DXWrapper and dgVoodoo2 makes them run the game like it was running natively back in the day or even better, no matter the resolution or supersampling. DDrawcompat runs into inexplicable FPS issues in just a few places and strictly at a specific zoom factor, also no matter the resolution or supersampling. Dialing down in-game graphics (lmao), switching off AA for good, running strictly vanilla executable at native 1024x768 -- nothing makes this weird lag go away. Quite on the contrary, running the game with either of the two other wrappers, with the resolution hacked waaay above spec (for experiment's sake), and/or topping that with an absurd level of supersampling, causes no such issues. Neither viewport resolution (vanilla or not) nor the amount of extra hauling the GPU has to do seem to affect this behavior.

I wonder whether or not the issue even is that somehow API translation in DXWrapper/dgVoodoo 2 provides a huge boost, or there's a bug in DDrawcompat and I should debug / report, and how I would even go about starting investigating.