Ultima 9 problems ( and a weird idea )

[rebb]

First of all, thanks for dgVoodoo, it's great that this exists and it works like a charm in most cases :)

I'm having some issues with Ultima 9 ( GoG Version ).

I'm trying to play the game with "correct aspect ratio" in all cases possible, that means the gameplay itself ( which works fine ), but also the Cutscenes.
U9 for some reason ships with cutscenes that are apparently using a 2:1 aspect ratio ( 640x320 resolution is reported by VLC ).

So when using 4:3 aspect ratio settings, the videos end up getting squished horizontally.

I've been wondering if it it somehow possible to get a sort of "virtual 4:3 monitor" going using dgVoodoo2 settings.
( the ROI settings in the Config File look promising but i don't understand them at this point )

So that it somehow detects the aspect ratio of something, and then tries to "best fit" it into the 4:3 surface, so to speak.

So instead of "Stretched" or "Centered" it would "Best Fit" it instead. Not sure if that makes sense :)

The other issue is the windows mouse cursor drawing over the dgVoodoo window - not sure how to fix that one either.

[dege-diosg]

Thanks!

I don't have this game so I never tested it with dgVoodoo. I'll check out it later, this time I can only answer the ROI issue.

So, the ROI config settings is about defining a rectangle inside the (upscaled) output image (coming from the game) which will be the base of the image presenting mechanism of dgVoodoo. Say, you define a rectangle (100, 100), (200, 200), then dgVoodoo will present the image as if that 100x100 pixel resolution rectangle was coming from the application itself. The problem is that the ROI is static, it cannot be changed while running the game.

So, for the video you could define a subrectangle with 2:1 aspect ratio inside the 4:3 resolution it rendered in, but it'd corrupt the ingame output.

"Stretched, keep aspect ratio" is already best-fit.
What you want is 'auto-dynamic ROI' but sadly dgVoodoo cannot detect if only a sub-part of the output image is rendered. It'd have to 'scan' for black letterboxes somehow to detect that.

[rebb]

I've thought about this problem a bit, and i think there may be a way to do this.
But it would be a system that involves some user-work and would be manual.

I've checked with the dgVoodoo debug release and it appears that dgVoodoo notices when the game changes the display mode.
That's what this whole thing would be based on, no need to scan for black bars ( which don't exist in the base video material anyway ).

In the case of U9, the gameplay view runs at 1280x960 ( set via the game, not forced by dgVoodoo ), but once it gets to a cutscene, it switches to 640x480, where the video is playing in wrong aspect.
( all of this is windowed )

The idea would be to have some kind of "resolution remapping" setting, where the user could basically set the actual resolution an incoming signal by the game is supposed to interpreted as, and dgVoodoo could then use this "remapped resolution" as a guide on how to output things.

Does that make sense ?

Example case of Ultima 9 could be, maybe somewhere in the dgVoodoo.conf, or an extra file :

[ ResolutionMapping ]
640x480 : 640x320 @ 1280x960

This is just an example, but what that line could mean is :

"If game switches to 640x480, rescale it to 640x320 and display it as best-fit inside a 1280x960 view".
Maybe there could be other options than "best-fit", who knows.

Note that unmentioned resolutions would not be touched by the Remapping.
In this example, any other resolution than 640x480 would be handled normally as by the usual dgVoodoo settings.

Here's a visual example of what i mean :

The "rescale" step can probably just be something like capturing the screen to a texture, and rendering that texture in an appropriately transformed quad in the output viewport.

I think such a system could be quite useful for certain games where getting the resolution right is tricky, because of things like cutscenes.
Granted there are probably not that many out there, but still, it could be pretty cool :)

[dege-diosg]

Sorry for the late respond,

so, basically you'd like an extra inner step (rescale to 640x320 in your example) into the presentation mechanism in dgVoodoo.
But, I still don't see how it'd solve the video problem.

You have the 640x320 sized video (vertically centered, I suppose) into the 640x480 rectangle, which is the 4:3 resolution. The video itself shouldn't be distorted if 'Stretched, keep AR' scaling option is used, it should appear with the expected aspect ratio because 640x480 itself is upscaled with aspect ratio kept.
Now, if you rescale that 640x480 rect into 640x320 then the upper and lower 80 pixel height black bars (coming from the game, dgVoodoo is not aware of them) are also scaled into the 640x320 output image which is obviously wrong.

What'd need here is telling dgVoodoo to only take the centered 640x320 subrectangle from the 640x480 image for the presentation (as if it were an independent image, with 640/320 aspect ratio). Display ROI is exactly about this. But display ROI currently is global, independent on resolutions (or I'd say, it was designed to use with one resolution in special cases/applications). A resolution -> display ROI would solve the problem, like defining

640x480: ROI: 640x320 centered subrectangle
any other resolution: ROI: default (full image)

Maybe some day I implement such a thing.

[rebb]

Yes this is would all be based on the current resolution coming in from the game, as a kind of trigger for the custom settings to be used.

I already tried Stretched:AR, it's my default mode of using dgVoodoo. The video comes out wrong, it is stretched to 4:3, which is wrong as the source video is not 4:3, it's 2:1 ( 640x320 ). There are no black bars coming in from the game, they don't exist in the source video.

If the video was already vertically centered, as you assume, there would be no problem. But it is not, it's wrongly stretched.

This happens in fullscreen as well as windowed mode.

The image in the red border up there is directly copied from the game window. And as visible it is stretched to the full 4:3, which it shouldn't be. Normally the video should have black bars on top and bottom, and be centered vertically. This can be seen in various Lets-Play videos for Ultima 9.

According to the dgVoodoo debug output, the game is using SetDisplayMode -> 640x480 before drawing the video.
This would be the "trigger condition" that could be used for the system i suggested.

Since the source code is not available i can only guess that maybe the "fit this into the display" algorithm doesn't work well if the source image is actually of a larger aspect ratio than the target. Maybe the math involved requires the source to be less/equal aspect ratio to the target or something ?

[dege-diosg]

I tried the game and made a screenshot from the video playback:

My main monitor is 2560x1440. Game resolution is set to 640x480.
dgVoodoo settings:

• Scaling mode: Stretch, keep AR
• DX resolution: Max

As you can see, dgVoodoo calculates the maximum resolution that has the same aspect ratio (4:3) as 640x480 (it's 1920x1440), renders the movie frames at that resolution, and copies it into the center of the 2560x1440 area, leaving two black bars at the sides. I can't see a problem here, it looks as expected.

Didn't you set the DX resolution to a forced static value (like 1920x1080)? Because if you did, then movie frames are rendered at that resolution, so the aspect ratio changes from 4:3 to 16:9 and the movie will indeed be stretched.

[rebb]

It's not what i'm seeing unfortunately :( I didn't force any resolution via dgVoodoo, as mentioned, only via the game's own config file.
I deleted that file now so it reverts to 640x480, but the video is still stretched.
I had unforced resolution before, but Max didn't help either.

I went through OBS to get a video capture, couldn't get fullscreen screenshot to work.
This is what i get with above settings and a default options.ini ( the one the game creates if the current options.ini is deleted/renamed ) of the game.

( It's a MKV video file - Takes a few seconds until the game appears )
2021-10-10 17-45-24.zip

The game actually switches to Direct3D/DirectDraw to display the cutscenes.
The default game renderer is Glide though ( can be changed in the ini, but doesn't help with the problem ).

This is using dgVoodoo2's x86 MS DLLs
GoG version with the latest 1.19h community patch.

dgVoodoo2 settings :

[dege-diosg]

Did you copy all dll's from dgVoodoo to the game folder?
Glide2x.dll, DDraw.dll, D3DImm.dll.

Because it seems that you might mix dgVoodoo with nGlide that comes by default with the Gog version of the game. My guess is, at game startup, glide sets the physical resolution to 640x480 (or some other 4:3 resolution) which appears stretched on a widescreen monitor. Right after that, dgVoodoo is initialized for the video playback but it detects that the desktop resolution is 640x480 so the video playback output is simply copied to the screen, no upscale or anything like that.

Btw, I use the Gamebar (Win+G) to capture videos and screenshots. Print-Screen doesn't work for fullscreen D3D11 output.

[rebb]

Gamebar doesn't exist in Win7 i guess, oh well.

You're right i was accidentally not using dgVoodoo's Glide DLLs for that video, but usually i do.
I copied them over now, but it doesn't change much, only that the 3dfx logo appears again after the cutscene is closed.

I can change the ingame renderer to use D3D via the ini file, but it doesn't fix the problem.

[dege-diosg]

It's really weird then.
I can't test it on Win7 for the time being but it should work the exact same way.