Posts: 786
Threads: 9
Joined: Dec 2016
Reputation:
45
Location: Bottom of the Well
Most other emulators that don't have deinterlacing settings usually have some simple process that takes care of deinterlacing silently in the background for you. Gameboys have never had interlacing at all, the first Gameboy was actually a progressive scan LCD display, and all future iterations (while not always LCD) were still progressive. Other consoles, most notably the Gamecube, had extremely predictable graphics code and dedicated memory space for graphics, allowing emulator developers to effectively hijack control of rendering code, and force progressive scan from within the game. Newer systems such as the PS3 or Xbox 360 will just inherently allow progressive scan on anything; the systems were made for HDMI output (though still component and composite capable for TV compatibility), and progressive scan is actually a requirement for HDMI to work at all.
The PS2 is a special kind of hell for any graphics developer because outside of commands for "draw a triangle" or "draw a point", there was not much limitation in the official development kit. This led to a whole lot of ingeniously evil tricks and twists to make the PS2 do things that Sony themselves never even thought of, with game developers sharing tips and tricks on mailing lists on how they pulled off their awesome effects. Furthermore, the PS2 had only 4 MB of dedicated video memory, and on top of this, system memory was shared between the CPUs and GS (the GPU). This led to a lot of designs that make us question how much glue some game developers inhaled while making their code.
Progressive scan was available but it was completely up to the developer to choose whether or not to use it. Furthermore, if not progressive scan, the developer still had free reign to choose how to store the interlaced video. They could choose to use one solid block of memory, or they could arrange it into a mesh of seemingly random locations and then stitch it back together later. They could do things like "clear the screen" using completely disproportionate memory sizes, and it worked. For a lot of the ingenious effects developers were doing, some of these evil tricks were necessary to work properly.
What does this mean for deinterlacing? There is no one routine that works every time. Instead we've over the years curated a number of deinterlacing techniques that, collectively, can handle just about every interlacing design we've encountered to date. Furthermore the Automatic mode is smart enough to detect which one to use, probably 95% of the time, with only a few games not automatically using the best mode. Unfortunately this is the best we are ever going to get, unless there is a serious breakthrough in progressive scan patching.
Posts: 7
Threads: 3
Joined: Apr 2020
Reputation:
0
So, from that, what I understand is that ePSXe or Yabause or Dolphin or whatever, all still use a deinterlacing technique but keep it hidden from the user because they draw the screen in a more standardized way than PS2 and that we shouldn't bother changing it from Auto unless there is a problem with our games. Right?
And something more: Is there a possibility to add Vulkan support?
Posts: 786
Threads: 9
Joined: Dec 2016
Reputation:
45
Location: Bottom of the Well
I cannot confirm for ePSXe since it is closed source but as a general rule, if the console could be used on a CRT TV, then it was capable of interlacing. If the emulator for it can output to your screen correctly without a setting for it, they are either deinterlacing quietly in the background, or forcing progressive scan in the game's code. Dolphin actually does the latter.
There is a possibility but it means basically starting over on graphics. So far the only benefit would be for AMD users, but they already have Direct3D11 as an option, so no one is really concerned right now.
Posts: 7
Threads: 3
Joined: Apr 2020
Reputation:
0
Thank you for the answers!