video: Wide HV-Integer should use ideal scaling when possible

[nanoant]

Hi @sorgelig. Here's another one I was asking on Patreon. I hope with this change HV-Integer Wide/Narrow choice makes more sense, since this should produce different scaling only for non-square pixel modes e.g. default 80x25 text mode using non-square 720x400 4:3. Please let me know what do you think. Feel free to propagate this to other cores.

I tested it both in DOS text modes, couple of games and in Win95 OSR2.5.

I understand that technically auto-selection of wide/narrow is still there, but SCALE=4 is not exposed in settings.

---

In previous implementation wide integer scaling factor was always narrow+1, even when ideal scaling existed, e.g. with source square pixels 640x480 [4:3]. Now in such case both wide and narrow should produce same scaling.

Only with non-square pixel source e.g. 720x400 [4:3] narrow should be less than wide. To achieve this we store and check against ideal target width when computing Wide HV-Integer.

This change also fixes the case when computing narrow flag did not make sense with div_num[11:0] coming from state cnt=7. We should always compare to stored previously target width.

[sorgelig]

This is incorrect PR. If you want to make changes in sys folder then you need to make PR to Template repository, otherwise changes will be vanished with the next framework(sys) update. To make changes in Template you need to test with other cores to make sure it will work well too, not only ao486. Generally speaking, multi-resolution systems such as ao486 aren't good with integer scaling. It's better to find a good video filter with may be proper mask to make non-integer scaling look good.

[nanoant]

This is incorrect PR. If you want to make changes in sys folder then you need to make PR to Template repository, otherwise changes will be vanished with the next framework(sys) update. To make changes in Template you need to test with other cores to make sure it will work well too, not only ao486.

Understood. I can work on proper PR then, but I need need your green light that you agree on the principle of this change. (see below)

Generally speaking, multi-resolution systems such as ao486 aren't good with integer scaling. It's better to find a good video filter with may be proper mask to make non-integer scaling look good.

Not sure if I understand that. Such video filter (e.g. Catmull–Rom interpolation) can only approximate the effect achieved by aligning source image to target HDMI pixel grid, but it cannot be perfect.

Just to recap in sys/video_freak.sv we have 1 - V-integer, 2 - HV-Integer-, 3 - HV-Integer+, 4 - HV-Integer integer scaling methods. HDMI has square pixels by definition, so in principle all 1-4 scaling methods should produce same thing for square pixel source resolutions such as 640x480 4:3 VGA graphics mode. Can you agree with this? Unfortunately they don't, because HV-Integer+ is too wide.

Someone back in 1987 figured that having 720x400 4:3 VGA text mode is a good idea (backwards compatibility), despite that LCD screens did exist back then. Then laptops, e.g. my Toshiba 430CDT had to deal with this somehow. AFAIK most of them simply ignored weird pixel proportion of 80x25 text mode and forced it to align with LCD grid, preferring making it wider than narrower. And this is exactly equivalent of HV-Integer+ method of MiSTer that is only method that produces decent text mode if you use it a lot, e.g. RHIDE, Borland IDEs.

This IMHO only way to make some text interfaces using extended ASCI characters (see below) look reasonably on HDMI screen. So I simply want MiSTer to work well both for text mode and graphics without reinventing the wheel.

Does it make sense to you? If not then I'll drop this effort.

[sorgelig]

Integer scaling takes aspect ratio in account, so it's not always obvious how it should be scaled. That's why HV- and HV+ are added. And it's more or less set-and-forget option for single resolution cores such as console. For multires cores it's not so obvious.

As for filters, besides the video filter, MiSTer offers shadow masks to simulate CRT where mask granularity hides uneven scaling. Basically you can set your modern TV to display like a CRT where non-integer scaling will looks very good.

[nanoant]

@sorgelig I found I can simplify the code achieving same effect, without any extra states, so now it is mostly about extra comments to check different cases.

Integer scaling takes aspect ratio in account, so it's not always obvious how it should be scaled.

I understand this. But it is not obvious only when PARs of emulated system and host are different and not multiple of each other, assuming distinction between PAR, SAR and DAR defined as e.g. at https://en.wikipedia.org/wiki/Pixel_aspect_ratio.

I am aware and cautious of VGA 320x200 mode 13h, 80x25 720x400 VGA text mode and X68000 512x512. But my change does not affect these.

However when single ideal solution exists e.g. when source and output are both 1:1 PAR like HDMI and square pixel VGA graphics modes, I want to ensure all integer scaling methods produce exactly same thing - the single ideal obvious solution. Currently it is not the case Wide is always far too wide, which is illogical.

TL;DR

80x25 VGA text mode 720x400 4:3 DAR has 20:27 PAR ≈ 0.740 740 740 7 PAR can be mapped either to 1:1 = 1 (wide font) or 1:2 = 0.5 (narrow font), and since it is right in the middle there is no obvious choice like you wrote. It is personal preference. Nevertheless since VGA fonts are pretty narrow already, wider option makes visually more sense and this is what laptops with LCD displays did in the past.

Similar story can happen with X68000 512x512 4:3 DAR has 4:3 PAR, and again ideal mapping does not exist, but 4:3 ≈ 1.333 PAR is closer to 3:2 = 1.5 (wide) than to 2:2 = 1 (narrow). Hence for X6800 Wide HV-integer is also working better and is actually closer to too to desired aspect ratio.

[sorgelig]

Open PR in Template with your final code, so i can see in a single commit what has been changed.