|
interlacing
#377203 - 06/26/18 09:33 PM
|
|
|
MAME is supercool about interlacing, I don't know what magic are they using but the result is like a progressive image, no image jumping, no flickering.
Is it a complex thing to do?
I ask this because for whatever reason other emus insist in displaying interlaced signals in interlace format coupled with different de-interlacing algorithms but the result is bad.
I can understand ps2 field rendered games, where you basically have half height frames, but in games where you have full height buffers the ininsistence to display them interlaced just because to emulate 480i is strange.
mednafen on psx and saturn highres games is doing this, the same with xebra(psx emu), if iirc ssf(saturn emu) is doing it too
|
|
|
|
Re: interlacing
[Re: asasega]
#377204 - 06/26/18 09:42 PM
|
|
|
> MAME is supercool about interlacing, I don't know what magic are they using but the
> result is like a progressive image, no image jumping, no flickering.
> Is it a complex thing to do?
> I ask this because for whatever reason other emus insist in displaying interlaced
> signals in interlace format coupled with different de-interlacing algorithms but the
> result is bad.
> I can understand ps2 field rendered games, where you basically have half height
> frames, but in games where you have full height buffers the ininsistence to display
> them interlaced just because to emulate 480i is strange.
> mednafen on psx and saturn highres games is doing this, the same with xebra(psx emu),
> if iirc ssf(saturn emu) is doing it too
actually MAME is doing it *wrong* and will have to be fixed at some point.
right now MAME basically just treated interlace modes as having twice the resolution, and twice the pixel fillrate, which is incorrect.
there are systems and video effects that depend on it being done correctly so the current approach being used by MAME will have to go away at some point, at which point you'll get the expected interlace lines / flicker.
unfortunately you're praising MAME for one of the things MAME is getting very very wrong. Lack of proper interlace support is actually one of the biggest *problems* in MAME, and is requiring ugly work to hack around in all cases right now.
very few of the arcade games actually used Medium resolution monitors, so many of them should actually be rendered interlaced, everything from the PSX based titles, to Namco 3D systems, Hyper Neogeo, and a whole bunch of others, even some of the older 2D ones. The bonus is performance would increase as you're only rendering half as much data.
There were exceptions, like Sega System 24 and Model 1/2/3 etc. which used genuine Medium resolution monitors.
|
|
|
|
Re: interlacing
[Re: Haze]
#377208 - 06/27/18 02:27 AM
|
|
|
From what I've seen, most other emulators are doing it wrong too. With an interlaced signal, the raster beam should be striking the phosphor surface between the "lines" from the previous field. The beam has a "height" though, with a non-linear brightness from top to bottom, and unless there's really large scanlines on the monitor, the beam positions probably have significant overlap. Simply stacking rows of pixels from alternating fields isn't really that correct in this case either. In my opinion, we should probably be rendering at 5x the field output vertical resolution, with the beam center at full opacity in the middle row, and lower opacity at the two rows above and below the beam position, then effectively merge the two fields together at a .5 line height offset using alpha blending, to properly blend the fields together as your eyes would have on the real screen. Obviously there needs to be this kind of blending in the horizontal axis, as a horizontal line is simply an analog waveform and there's rise and fall time even with a supposedly instant digital transition from black to white for example, but the physical characteristics of an interlaced phosphor display mean there's also supposed to be significant blur in the vertical axis too, and I don't think that's as widely understood. With the wide availability of 4K displays now, there's actually an opportunity to do this properly, as it's more realistic to be able to do 10x upsampled output resolution to account for beam width. Scanlines can be properly generated too under this kind of approach.
Edited by Nemesis1207 (06/27/18 02:32 AM)
|
|
|
|
Re: interlacing
[Re: Nemesis1207]
#377210 - 06/27/18 03:19 AM
|
|
|
For a visual representation, here's basically what I think we should be doing:
Here we take scanlines from two fields with the idea of a beam height and opacity falloff, and blend them to create the actual image. We should be doing this at the field refresh rate, so each field is used in two successive images produced. The exact opacity values used for the beam edges would need some experimentation. Modifying the beam height and opacity would allow scanlines to be adjusted. Ideally this would all be configurable, but with some tweaking sensible defaults could be worked out, or at least a series of presets. That's the approach I'd use anyway, and it's what I'd always planned to add to my emulator.
EDIT: As an aside, the kind of blending we should use is also questionable. Here I've shown additive blending, but in reality it might be better to use a normal alpha blending approach, with the most recently drawn field "on top" of the other one. This would probably produce a more accurate "flicker effect" on the overlapping regions of the lines which would more closely approximate how it would have appeared on a traditional CRT display. All this would need testing though, I never actually tried this approach.
Edited by Nemesis1207 (06/27/18 03:28 AM)
|
|
|
|
Re: interlacing
[Re: Nemesis1207]
#377211 - 06/27/18 03:22 AM
|
|
|
> For a visual representation, here's basically what I think we should be doing:
>
> Here we take scanlines from two fields with the idea of a beam height and opacity
> falloff, and blend them to create the actual image. We should be doing this at the
> field refresh rate, so each field is used in two successive images produced. The
> exact opacity values used for the beam edges would need some experimentation.
> Modifying the beam height and opacity would allow scanlines to be adjusted. Ideally
> this would all be configurable, but with some tweaking sensible defaults could be
> worked out, or at least a series of presets. That's the approach I'd use anyway, and
> it's what I'd always planned to add to my emulator.
this kind of thing is no doubt where some HLSL / BGFX filters will come in handy, but yeah, in the end I can see it being something like this if anybody gets around to trying to do it properly :-)
|
|
|
|
Re: interlacing
[Re: Haze]
#377281 - 06/28/18 09:16 PM
|
|
|
>unfortunately you're praising MAME for one of the things MAME is getting very very wrong. Lack of proper interlace support is actually one of the biggest *problems* in MAME, and is requiring ugly work to hack around in all cases right now.
well, since MAME is about accuracy I'm sure it will be implemented sooner or later, but maybe the old method(which we have now) can be kept as an option, or no, seeing that requires so many ugly hacks. I'm curious what will be the consensus
|
|
|
|
Index 
Threaded 
interlacing
Reply
[Re: 
