Would the timeslip DDraw work as an asi with thirteenag's Ultimate ASI Loader? i know to get the Hitman Contracts widescreen patch paired with dgvoodoo i needed to have the widescreen patch stuff in the scripts directory with the dll renamed to asi instead with the asi loader as something other than d3d8.dll in order to use dgv with it. maybe the same applies to the ddraw in this situation?

JJXB wrote:

Would the timeslip DDraw work as an asi with thirteenag's Ultimate ASI Loader? i know to get the Hitman Contracts widescreen patch paired with dgvoodoo i needed to have the widescreen patch stuff in the scripts directory with the dll renamed to asi instead with the asi loader as something other than d3d8.dll in order to use dgv with it. maybe the same applies to the ddraw in this situation?

It's an interesting idea, thank you. Alas, it didn't work. I tried to rename the loader to some of the suggested names (excluding ddraw of course), but it makes no difference, it crashes the game if I choose the "correct" name. I guess because the patch already has some ddraw injection code in it and it interferes with the wrapper.
Perhaps Dege can shed some light on this.
The FMVs need to be fixed either way, if it's possible. I suspect the wrapper somehow messes with D3D acceleration, which was one of the reasons the movies didn't work on modern systems. The devs (those who made the latest patch for the game) made their own custom QuickTime.qtp and QuickTime.qts files and bundled them with the game. If I try to change them with original QT ones, only sound is played.
Oh and of course, I have Win10 (1903).

Shifroval wrote:

FMVs play just fine with the latests updates to the game, but whenever I try to force the game to run in 4:3 aspect ratio, or force higher resolutions, they become corrupted and stuttering mess. If I set everything to Unscpecified, they do work, but then the game is stretched and looks ugly.Is it possible to fix them somehow? It's been bugging me for some time actually, but I was always too lazy to register here and report it.

If you select a scaling mode other than 'unspecified' or force a resolution then the physical size of the game window changes compared to the expected one.
I think QuickTime relies on the size (it may do some calcs what position the decoded data to put, based on that) and that's why 4:3 or forced resolutions breaks its rendering.
I don't know how to workaround it. Maybe if the presence of quicktime could be detected then dgVoodoo could do some workaround in the background as it does for DirectShow now. But, unfortunately it's not a small change that can be included in a minor incremental release.

What about unspecified scaling mode + unforced resolution and setting the aspect ratio on the display driver control panel (if you have option for that)?

Shifroval wrote:

Also as I see this new WIP has some changes in DDraw, and for some reason now all loading bars in Septerra Core just do not display like there are not in the game at all. 2.62.1 works fine.

I checked it out and I have the loading bars. Right when I begin a new game, a blue-red bar quickly grows through the screen.

Shifroval wrote:

There is also an unofficial patch for the game (by Timeslip), but it also uses ddraw.dll, so it can't be used together with dgVoodoo. Do you have some sort of proxy dll loading implementation, like Kaldaien made in his Special K? Then it may be possible to inject this patch an use its features (it has some very useful ones).

No, there is not proxy dll loading in dgVoodoo. I think the simplest way is to change strings 'ddraw.dll' to, say, 'dgraw.dll' in the patch ddraw.dll, then rename dgvoodoo's ddraw.dll to dgraw.dll. So, the chain would be: game.exe -> ddraw.dll (patch) -> dgraw.dll (dgvoodoo)

Dege wrote:

What about unspecified scaling mode + unforced resolution and setting the aspect ratio on the display driver control panel (if you have option for that)?

I don't have such specific option to force 4:3 in drivers (GTX 1080 Ti here), but when I change scaling option from Display to GPU (combined with Unsecified and Unforced) I get correct 4:3 ratio and FMVs are working. So you are correct, that's how QT is working under such conditions. The only difference is that the mouse icons are now filtered and smooth, rather that pixelated and upscaled.

Dege wrote:

I checked it out and I have the loading bars. Right when I begin a new game, a blue-red bar quickly grows through the screen.

Hmm, just checked some other loading screens and it seems that the bar appears sometimes, but sometimes not. Try changing areas, not just starting a new game. Or entering combat. Sometimes it's there for a split second, but before it was easily noticable. It was the first thing I noticed when I loaded the game.

Dege wrote:

No, there is not proxy dll loading in dgVoodoo. I think the simplest way is to change strings 'ddraw.dll' to, say, 'dgraw.dll' in the patch ddraw.dll, then rename dgvoodoo's ddraw.dll to dgraw.dll. So, the chain would be: game.exe -> ddraw.dll (patch) -> dgraw.dll (dgvoodoo)

How do I do that? With hex editor? Then what should I change there? Sorry, I'm not good at such things.

Shifroval wrote:

Hmm, just checked some other loading screens and it seems that the bar appears sometimes, but sometimes not. Try changing areas, not just starting a new game. Or entering combat. Sometimes it's there for a split second, but before it was easily noticable. It was the first thing I noticed when I loaded the game.

Is there a difference between 2.62.1 and WIP66? Maybe it's just me but both of them seem to work the same. WIP66 has only changes in DDraw Create methods, so nothing really explains the difference.

Shifroval wrote:

How do I do that? With hex editor? Then what should I change there? Sorry, I'm not good at such things.

Yes, a hex editor is needed. I can recommend HxD, it's a free and good tool. Open ddraw.dll in it, search for strings 'ddraw.dll' and modify them to dgraw.dll.
Or if you can send me the mod itself, I can have a look at it.

Dege wrote:

Is there a difference between 2.62.1 and WIP66? Maybe it's just me but both of them seem to work the same. WIP66 has only changes in DDraw Create methods, so nothing really explains the difference.

There is. For example when entering combat there is no loading bar at all (all the times, I checked, it doesn't even blink). Like it's not there. And when selecting continue from the main menu. If loading a specific save it's there, but only for a split second and hardly noticable if you know where to look. Maybe it's shown, but the animation plays much much faster than needed? So I tried using vsync to see if it can slow it down. 2.62.1 applies it correctly and the bars are moving smoothly and steadily. In WIP66 there is no difference at all. So maybe it's somehow connected to vsync? Or maybe it's another thing with ddraw compatibility in Win10, a regression and whatnot. Also I noticed when the game shows loading bars or battle results/found items, fps spikes up massively, making my GPU mosfets to whine. Maybe this can help you find the problem.

Dege wrote:

Open ddraw.dll in it, search for strings 'ddraw.dll' and modify them to dgraw.dll.
Or if you can send me the mod itself, I can have a look at it.

It seems the only string which matches 'ddraw' there is the reference to one of the settings. Also the mod has its own scaling options and uses directshow for movie playback (it requires format conversion), so it may conflict with dgvoodoo, or maybe not, it's just a hunch. I tried using ASI loader before, but it just crashes the game with ddraw panic error. Hooking the same addresses maybe?
You can get the mod here
http://timeslip.users.sourceforge.net/current/sc_patch.7z

I moved posts related to Septerra Core to this dedicated thread.

Thanks for the patch!

I had a look at it and turned out that this is a DDraw -> D3D9 + GDI wrapper.

This game is a fully software rendered one, using the usual rendering model: render everything into a software buffer then blit it to the primary screen.
That's all DDraw is utilized for (that's why I don't understand the loading bars).

The patch seems only to utilize D3D9 to set the screen mode(?), the blitting part is done with regular GDI (which is very slow for me for some reason, I got only 2-3 fps).
You can use this with dgVoodoo's D3D9.dll but makes absolutely no sense at all.

Btw, dgVoodoo debug layer reports a lot of errors for QuickTime-played parts with non-default config: it wants to lock the software buffer with invalid rectangles that backs my theory about miscalculated rectangle coordinates based on the window size.

Dege wrote:

This game is a fully software rendered one, using the usual rendering model: render everything into a software buffer then blit it to the primary screen.
That's all DDraw is utilized for (that's why I don't understand the loading bars).

Maybe it's vendor specific and only happens with Nvidia gpus? And what about vsync behavior in WIP66? It seems to work differently, than in 2.62.1. I may be wrong about it, but still it was making loading bars move slowly before. Intro movies have some noticable tearing and it's gone with vsync enabled regardless of the version I use, so I can assume that at least it's working.

Dege wrote:

The patch seems only to utilize D3D9 to set the screen mode(?), the blitting part is done with regular GDI (which is very slow for me for some reason, I got only 2-3 fps).
You can use this with dgVoodoo's D3D9.dll but makes absolutely no sense at all.

This patch has possibly only one very useful feature: you can queue actions in combat by pressing the mouse wheel on the character icon. It just auto selects it for you. Very useful, the game is mostly combat and frantically clicking trying to match the needed power tier is very tiring. It also has 'always run' with mouse wheel.
About low performance, I also experience this and if I remember right, it was not the case on Win8. Also I've heard that GDI originates from XP era and it has some troubles running on modern systems, especially Win10.
If Timeslip was still interested in updating this patch, I'd ask him to release just the queue and run part to use with dgvoodoo and possibly other wrappers. But I doubt he'll ever respond to my pleas. Most likely he's abandoned all his projects long time ago.

Dege wrote:

Btw, dgVoodoo debug layer reports a lot of errors for QuickTime-played parts with non-default config: it wants to lock the software buffer with invalid rectangles that backs my theory about miscalculated rectangle coordinates based on the window size.

Well, at least we know the reason. Maybe some day there will be a solution for it.
Thanks for all the help, Septerra is one of my all-time favourite old games and as the time moves on, it's harder and harder to play it like I used to. At least now I have some sort of universal solution, if I wish to play it in the future.

Shifroval wrote:

Maybe it's vendor specific and only happens with Nvidia gpus? And what about vsync behavior in WIP66?

No, it's pure software rendering. Old game, it feels a software rendered one at the first glance.
I cannot find a single modification in the repo between 2.62.1 and WIP66 that could affect vsync. 😖

Shifroval wrote:

About low performance, I also experience this and if I remember right, it was not the case on Win8. Also I've heard that GDI originates from XP era and it has some troubles running on modern systems, especially Win10.

GDI originates from the beginning of Windows... and it's fast even on nowadays Windows.
I think the problem here is the patch renders with GDI into a D3D window which isn't liked by the desktop compositor (windows should be either fully rendered by GDI or D3D but not mixed). I guess Win7/Vista just shut down dwm and aero when this game is being run, Wins' older that didn't use a compositor so it wasn't a problem back then. The compositor for Win8 and above is mandatory, cannot be shut down.

I think dgVoodoo might be useful for the patch anyway. I cannot test it now, but doesn't it work in conjunction with dgVoodoo's D3D9 with option GeneralExt\EnableGDIHooking enabled?

Dege wrote:

I cannot find a single modification in the repo between 2.62.1 and WIP66 that could affect vsync. 😖

Maybe it's not vsync per se, but something causing loading bar animations to render faster? Because that's exactly what happens with WIP66. Everything else in the game performs exactly the same as before.
I'm not that much tech savvy, so I can't explain it that well with correct words. Also I can't debug (or at least to try) it with utilities, such as 3dmigoto and others, because it's a ddraw game, I don't know any useful software to help trace this strange unexplainable behavior. Well maybe except dgvoodoo debug build itself, but I don't know how to use it...

Dege wrote:

I think dgVoodoo might be useful for the patch anyway. I cannot test it now, but doesn't it work in conjunction with dgVoodoo's D3D9 with option GeneralExt\EnableGDIHooking enabled?

I tried it and it works (the game is launching at least), but it doesn't fix low fps. Strange, it feels like the game starts in borderless window whenever I do this. It scales the window height to my resolution if I choose no scaling option in the patch, and it still looks sharp and pixelated. When I tried to use Alt+Enter (after unchecking the box, disabling this), it crashes with ddraw panic error. Could this be something related to exclusive fullscreen mode in Win10 and fullscreen optimizations? I have them disabled completely with registry keys.
Also I don't see dgvoodoo watermark in this case after I try to enable it. So it's not working after all?

I checked it out myself and indeed it doesn't work. Windows's own compatibility layer bypasses dgVoodoo's GDI hook, so it's bypassed. 😖
Currently I have no idea how to fix it.

Dege wrote:

I checked it out myself and indeed it doesn't work. Windows's own compatibility layer bypasses dgVoodoo's GDI hook, so it's bypassed. 😖
Currently I have no idea how to fix it.

Try statically linking dgvoodoo dlls with gdi32.dll\user32.dll

Perhaps you might be able to use Application Compatibility Toolkit to see what the actual fixes Windows is applying are. On Windows 7, I do indeed have a built-in compatibility setting for Septerra Core.

It applied the fix "Virtual Registry" to the files "Launch.exe", "Monolith.db", "Septerra.db", and "Septerra.exe".

These fixes don't prevent Septerra Core from running with dgVoodoo on Win 7, as you can see. These shots were with 2.62_1, but the game also works with 2.53/2.54.

Peixoto wrote:

Dege wrote:

I checked it out myself and indeed it doesn't work. Windows's own compatibility layer bypasses dgVoodoo's GDI hook, so it's bypassed. 😖
Currently I have no idea how to fix it.

Try statically linking dgvoodoo dlls with gdi32.dll\user32.dll

Forget it, it doesn't work anymore, some recent update must have broken it. My outwars patch doesn't scale FMVs correctly anymore. If you find a way to hook bitblt and stretchblt let me know

Peixoto wrote:

Peixoto wrote:

Dege wrote:

I checked it out myself and indeed it doesn't work. Windows's own compatibility layer bypasses dgVoodoo's GDI hook, so it's bypassed. 😖
Currently I have no idea how to fix it.

Try statically linking dgvoodoo dlls with gdi32.dll\user32.dll

Forget it, it doesn't work anymore, some recent update must have broken it. My outwars patch doesn't scale FMVs correctly anymore. If you find a way to hook bitblt and stretchblt let me know

Edit: Hook the functions exported by Gdi32Full.dll and it will work.

I didn't yet check out what happens exactly.
But, when I query the address of a USER function, like 'GetDC' by LoadLibrary, it gives back a pointer to a pre-hook in AppHelp.dll (afaik) which then never get called later. 😕