So what happens if you were to hook it up to an LCD display?
The same what would happen if you run your LCD monitor not at its native resolution: depending on how it's configured, it either blurs the image over the entire area, or only a few lines are duplicated (like this (background) or this (text)).
Scepheo wrote:
You may consider "what you would see" to be the most authentic. But, considering no encode so far has used filters to make it look like it was being played on an actual television set, it appears that the main view is that the signal, as produced by the graphics card, is the most authentic. And this signal does not contain the scan lines.
On a TV there's always the NTSC standard which defines the maximum number of lines, so in the worst case parts of the recording can be upscaled to that height. Usually that's when interlaced and progressive are used in the same game, and the progressive parts can just be doubled vertically.
The problem is that the PC allows very different vertical resolutions. All resolutions must be converted to a common one. (This was discussed here before.) Even DOSBox doesn't encode them into the same AVI file. You either have to apply some stretching or add black bars, and I think there is another, better alternative.
If the following points apply:
- the TAS is on the PC
- the TAS includes [200 or 400 lines] AND [240 or 480 lines] graphics modes
- the final encode will be a HD encode
...then the method posted above could be used.
I doubt sometimes having scan lines would improve the movie.
But that's what you see on a real CRT.
Scepheo wrote:
Also, if you're going for authenticity, how does the computer deal with it? I'm pretty sure it uses a stretching algorithm, so we should use it as well.
What computer - the emulated one? It doesn't stretch at all, it just writes to the graphic card's video memory. The graphic card generates a signal that contains the brightness information for each electron cannon (R, G & B), and the CRT distributes that evenly across the surface. The lines aren't stretched at all; they just have more or less space between them.
Scepheo wrote:
Scan lines occur due to limitations in the monitor, and don't have anything to do with the actual image displayed.
They increase the image height a bit. Without them the video would have to add black bars at the top and bottom.
Just a bilinear stretching from 400 to 480 doesn't look that good, imo.
Note: Some games use different resolution in menus and in actual game. One should look what the resolution is in actual game.
Yeah, my bad. The menu was 320x200 while the game is 320x240.
This also explains why some pixels in the video file seemed a bit off.
So this filter doesn't have to be used for most of the run, but it might still be useful for the lower-res parts to make the video uniformly 4:3.
Wait, how does just setting the aspect ratio flag to 4:3 not fix this?
A CRT screen has a certain look that I want to preserve/emulate. It leaves a bit of space between the drawn lines, so that the aspect ratio becomes 4:3. These "empty" lines are only 20% as high as a drawn line.
Aktan wrote:
After talking to Ilari on IRC, apparently the native resolution is 640x480. [...] There is no need to add scanlines!
Text mode is 640x400: 80x25 characters, each 8x16 pixels in size.
Afaik the game runs in Mode 13h, which is 320x200. A video of the game recorded in DOSBox has that resolution.
DSS2("dwangoAC-WIP-Epic-Pinball-05.mkv")
Add_PC_Scanlines(960) # only for 640x400
function Add_PC_Scanlines(clip src, int LineCount, bool "spline") {
src
PointResize(Width, Height * 6)
Mask = mt_lutspa(false, "y 6 % 0.01 < 0 255 ?")
mt_lutxy(Mask, "x y * 255 /", U=2, V=2)
y = LineCount
x = y * 4 / 3
return default(spline, false) ? BilinearResize(x, y) : Spline64Resize(Width, y).Spline36Resize(x, y)
}
Needs the MaskTools plugin.
Also instead of 600 MB RAM it takes much less now, though there may be a memory leak - not sure yet.
EDIT: No leak, just the frame cache filling up - use SetMemoryMax to restrict it.
To specify the correct aspect ratio. Both values will be reduced to the user's screen size anyway, unless the user has deactivated that option.
(1200 is the number of encoded lines)
You could also just define an aspect ratio and let the player figure out the correct width, but there was one converter (Youtube) that re-calculated the height instead when I uploaded such an MKV. :/
EDIT: Converting a 320x200 RGB source to 320x1200 and encoding that with ZMBV could be the best solution. The user's gfx card could stretch that without speed penalty.
While I do think that scanlines are a nice alternative to the usual stretching algorithms used in media players (if only because they look closer to how it's actually supposed to be displayed), ZMBV is clearly an excessive measure. There is barely any speed penalty for hardware-accelerated stretching, and all popular systems and stand-alone devices can take advantage of this.
ZMBV was just mentioned for its potential of decreasing the file size. :)
moozooh wrote:
In any case, won't upscaling → adding scanlines → downscaling be a saner option?
Well, MKV (and maybe other containers) can specify a playback size of 1600x1200, which would be automatically reduced by sane players. It'd be the encoder's decision if s/he wants to offer these kinds of files.
DirectShowSource("dwangoAC-WIP-Epic-Pinball-05.mkv") # YV12 640 x 400
ConvertToYUY2 # Crop can't do odd numbers in YV12
PointResize(Width, Height * 5).Scanlines # add scanline after every 5 lines
#BilinearResize(1280, 960) # resize to final video size (optional)
function Scanlines(clip) {
clip
top = Crop(0, 0, 0, 5).AddBorders(0, 0, 0, 1)
bottom = Crop(0, 5, 0, 0)
bottom = (bottom.Height > 5) ? bottom.Scanlines : bottom.AddBorders(0, 0, 0, 1)
StackVertical(top, bottom)
}
This is the AviSynth version; a custom plugin could be much more optimized.
EDIT: Converting a 320x200 RGB source to 320x1200 and encoding that with ZMBV could be the best solution. The user's gfx card could stretch that without speed penalty.
I'd say only allow frequency changes if they're possible from within the game.
(Turrican II was one of those games. Original ran at 50 Hz with the Amiga monitor; on the PC the default was 60 Hz, iirc. Made the space shoot'em up sequences a bit harder.)
AVISource("00.avi") # recorded with fceux-2.1.4a
TimeStretch(rate = 100.0 * 60.0 / FrameRate) # adjust audio speed
AssumeFPS(60) # adjust video speed
Trim(221, 0) # trim frames recorded before TAS was loaded
Intro = Trim( 2, 4687) # cut & splice parts into final movie
Title = Trim( 4789, 5193)
TAS = Trim( 5860, 40366)
Intro + Title + TAS
ConvertToRGB32 # a bit faster than RGB24
PointResize(512, 448) # double width & height
BilinearResize(640, 480) # 4:3, size required for YT's HQ mode
ConvertToYV12 # Overlay uses YUV internally, not RGB
BlendFields
function BlendFields(clip) {
clip
(FrameCount % 2 == 1) ? DuplicateFrame(FrameCount - 1) : nop
SelectEven.Overlay(SelectOdd, opacity=0.5)
}
Is there a script to suppress the HUD line flickering in Super Metroid when you play it with SNES9x 1.43? I think this was already mentioned somewhere, but I can't find it...
