VOGONS


First post, by Drifter82

User metadata
Rank Newbie
Rank
Newbie

IWD2 has a lot of stuttering and frame drops, eg. going below 30 fps and slowing down in combat.

I tested it with 2.55 and the issue was still present.

I'm not sure what if anything can be done, but I'll post this here in case anyone comes up with something.

PrimarySurfaceBatchedUpdate = true gets rid of the mouse flickering as per the only post I could find on Infinity engine games.

It runs fine with ddrawcompat or the default Win10 ddraw implementation, but neither have the nifty upscaling of dgVoodoo.

This is Win 10, 8700k, 1080 ti, latest drivers and OS etc. I've tried disabling overlays, vsync\gsync etc.

Reply 1 of 6, by Dege

User metadata
Rank l33t
Rank
l33t

Try 'Fast videomemory access', it helps (I don't say it completely solves the problem).

Sadly, this game accesses the hw backbuffer by both GPU/CPU which requires a lot of videomemory readback, it's not optimal on discrete GPU's.
(It runs better on my integrated PU...)

Reply 2 of 6, by ZellSF

User metadata
Rank l33t
Rank
l33t
Dege wrote:

Try 'Fast videomemory access', it helps (I don't say it completely solves the problem).

Sadly, this game accesses the hw backbuffer by both GPU/CPU which requires a lot of videomemory readback, it's not optimal on discrete GPU's.
(It runs better on my integrated PU...)

On a GTX 1070 / i7 4790k I still find it too annoying to be playable. But I prefer Icewind Dale II with integer scaling anyway, and that's possible without dgVoodoo.

Reply 4 of 6, by Dege

User metadata
Rank l33t
Rank
l33t

In fact this game doesn't need to be rendered in hw. As far as I know it from my debugging memories, it only does simple blittings + some direct CPU rendering so a full sw impl replacement would be more than enough. The only problem is how to detect it in dgVoodoo without adding a stupid option again.

Reply 5 of 6, by Narzoul

User metadata
Rank Newbie
Rank
Newbie
Dege wrote:

In fact this game doesn't need to be rendered in hw. As far as I know it from my debugging memories, it only does simple blittings + some direct CPU rendering so a full sw impl replacement would be more than enough. The only problem is how to detect it in dgVoodoo without adding a stupid option again.

In DDrawCompat, I used to just force off-screen plain surfaces (i.e. those that can only be used for blits and locks) to system memory for a long time and it worked well enough. This should cover most 2D games.
From what I remember, the only problematic case then was conversion from FourCC surface formats to an off-screen plain surface, which still requires the conversion to be done in hardware (or implement it in software, but that's probably more hassle). For that you could use a temporary video memory surface for the conversion and just copy it back to the system memory surface after the blit. I think I used to test this with Dungeon Keeper 2, which uses such blits for the intro videos.