Aspect Ratio Correction on FM Towns Games

[ZvikaZ]

My work is finished here, until I will receive further bug reports / success reports.

The updated version:

Code: Select all

git clone https://github.com/ZvikaZ/scummvm
git checkout z_zm_height_200_v7

compile and run.

Let me summarize the FM-TOWNS situation now.
The newer games:

• Monkey 1
• Monkey 2
• Indy 4

Already worked with 200 pixels before I did anything.
Therefore, I just enabled aspect ratio correction option for them.

As for the older games, I added `Trim FM-TOWNS games to 200 pixels height (EXPERIMENTAL)` option, and enabled aspect ration correction.

• Indy 3 - it didn't (seem to) use the extra 40 pixels, so cutting it was safe
• Zak - used the extra 40 pixels for inventory
• Loom - used the extra 40 pixels for various things! For example, the items name line, the "note box" in practice mode, text on Cygna's grave. Who knows what else?

Loom is the weakest point here. I assume there are more things that use that 40 pixels, and I haven't reached them.
It's easy to fix, but I just need someone to play the game to end, and either report problems (with save games), or report that it was completeable without problems, and without warnings in the console.

Only then, I will submit this as Pull Request, to be included in the main ScummVM release.

Of course, if anyone plays any other game beside Loom with this version, I'd be happy to know - both of problems, and also the absence of them.

[almeath]

My work is finished here, until I will receive further bug reports / success reports.

Your hard work on this is greatly appreciated. Unfortunately I do not have time for full play-throughs, but I can confirm most of your above observations. Loom does seem to be the most heavily affected.

I also have a new problem in being unable to obtain pixel-perfect scaling when using your build. Even if I do not use the new trim and/or aspect ratio correction settings, I see very slight bleeding around the edges of pixels (with full screen OpenGL scaling in effect), which does not occur with the same default FM Towns settings in standard ScummVM. I cannot understand why this is occurring because I thought the default scaling would work the same way in your build. My output in the config file is normally set to 'opengl' and filtering is off.

I will see if I can show the issue in some screen shots later.

[ZvikaZ]

I also have a new problem in being unable to obtain pixel-perfect scaling when using your build. Even if I do not use the new trim and/or aspect ratio correction settings, I see very slight bleeding around the edges of pixels (with full screen OpenGL scaling in effect), which does not occur with the same default FM Towns settings in standard ScummVM. I cannot understand why this is occurring because I thought the default scaling would work the same way in your build. My output in the config file is normally set to 'opengl' and filtering is off.

I will see if I can show the issue in some screen shots later.

Please check this with git master (*). Maybe this problem was inserted by some other change between the last official release and the updated master, and it's unrelated to my changes.

BTW, do you have a mac?
There have been discussions in Discord regarding similar effects in Macs.

EDIT
====
(*) Please check it with:

Code: Select all

git checkout z_zm_height_200_base

That's the point where I started my changes.
Hopefully, it will be blurry there as well, meaning that the blurriness isn't related to my changes.
If indeed it will be blurry there, try with:

Code: Select all

git checkout master
git pull

Maybe it has already been solved.
If this solves this, I will issue a new version, with the updated master containing the fix.

[almeath]

(*) Please check it with:

Code: Select all

git checkout z_zm_height_200_base

That's the point where I started my changes.
Hopefully, it will be blurry there as well, meaning that the blurriness isn't related to my changes.
If indeed it will be blurry there, try with:

Code: Select all

git checkout master
git pull

Maybe it has already been solved.
If this solves this, I will issue a new version, with the updated master containing the fix.

Actually, it is blurry in the master branch as well. So something has happened with OpenGL output in macOS and it is unrelated to your changes. All I can confirm at this stage is that the problem does not affect the 2.1.1 official release. Thanks for pointing me in the right direction.

How extensive are your changes across the code base? Is there a chance of providing a few replacement files that I could add to a 2.1.1 clone and build against that?

[ZvikaZ]

How extensive are your changes across the code base? Is there a chance of providing a few replacement files that I could add to a 2.1.1 clone and build against that?

It's possible, but I think a better approach would be to try to solve the blurriness in master...
Maybe you can jump into Discord and ask what's the status of this issue, or even better, open a bug.

[criezy]

The known issue on Mac with blurry is specific to macs with a retina screen that run on macOS 10.14 or above (Mojave or Catalina). It is not related to changes in ScummVM itself, but is related to the way ScummVM is built. Apple made changes related to OpenGL and Retina display in macOS 10.14 which result in blurry display on said retina screens when running on macOS 10.14 and above, but only when ScummVM has been built using the 10.14 or 10.15 SDK. This appears to be a bug in macOS itself. You can find details in bug #11430.

The reason why the 2.1.1 (or any other release) version is not blurry is because I am building them on a slightly older system using the 10.13 SDK. The daily build from buildbot however is impacted as it is built using the 10.14 SDK.

The only known workaround for this issue is to build ScummVM with an older SDK, or to trick macOS to think it has been built with an older SDK (i.e. even if you build with the 10.15 SDK, if you just change the two bytes in the resulting executable that indicate the SDK version, this is sufficient for the blurriness to go away).

Edit: I forgot that a change we made to the ScummVM Info.plist to opt in to the dark mode support also resulted in the blurry display even when building with an older SDK. The 2.1.1 and 2.1.2 release (but not 2.1.0) were impacted by that. The change has since been reverted. But if you do not see the blur issue with the 2.1.1 release, maybe your issue is a different one.

[almeath]

Edit: I forgot that a change we made to the ScummVM Info.plist to opt in to the dark mode support also resulted in the blurry display even when building with an older SDK. The 2.1.1 and 2.1.2 release (but not 2.1.0) were impacted by that. The change has since been reverted. But if you do not see the blur issue with the 2.1.1 release, maybe your issue is a different one.

Thanks criezy - I have confirmed that the issue does not affect my copy of 2.1.1 downloaded pre-built from the ScummVM website back in January. It only affects my own recently compiled executables under Mojave 10.14.16 from the master branch and forks. Will take this conversation off this thread to keep things on-topic.

EDIT: Correction - it does affect both the 2.1.1 and 2.1.2 downloaded pre-compiled, and also the versions I compile myself. So this does appear to be related to the reported bug. The 2.1.0 executable I have from October 2019 works fine.

[elvisish]

Is there a binary available for testing?

[ZvikaZ]

I can upload one.
Windows or Linux?
(Hoping that my CentOS compilation will work on your distro...)

EDIT
====
Uploaded both
https://github.com/ZvikaZ/scummvm/relea ... ght_200_v7

[elvisish]

I can upload one.
Windows or Linux?
(Hoping that my CentOS compilation will work on your distro...)

EDIT
====
Uploaded both
https://github.com/ZvikaZ/scummvm/relea ... ght_200_v7

Thanks, that's perfect! Works great so far!

[vanfanel]

Will this feature go upstream, please? A simple PR will do... I do not want it to get lost here in the forums.

[ZvikaZ]

Will this feature go upstream, please? A simple PR will do... I do not want it to get lost here in the forums.

I intend to send this as PR, of course.
As soon as someone will play Loom from beginning to end and report that it's OK, I will happily send this.

[ZvikaZ]

Thanks, that's perfect! Works great so far!

Good to hear.
Please update here what game(s) have you tried, and how far you got in them.

And BTW, what's your OS?

[filipetolhuizen]

This is really great. It should be implemented at least as a switchable option in the official version.

[ZvikaZ]

This is really great. It should be implemented at least as a switchable option in the official version.

I'm glad to hear that you enjoy this feature.
I have enjoyed implementing it .

However, in order to add this to the official version, I need a volunteer to test this in Loom.
See detailed explanation at viewtopic.php?p=88663&sid=1ba9bed289e83 ... b02#p88663
The short explanation - I'm afraid that there are bugs in Loom with this feature, and I don't want to add buggy feature to the official ScummVM version.
Therefore, I need someone to play Loom from beginning to end, and either report bugs (with savegames), or update that it's great, and there are no problems.

Playing Loom with a walkthrough should take less than 3 hours. Coding this took much more than 3 hours, so, I think it's a fair bargain