I think I'll produce the official encodes for this. As TASBlend is still slightly controversial, do people think I should use it for this run? Primarily, does it have any flicker? Is the flicker excessive?
When one character dies, the other character starts flickering (2 frames on, 2 frames off) and takes over. Apart from that it doesn't have much flicker (iirc).
The game displays text boxes using the SNES' hi-res graphics mode (512 horizontal pixels instead of 256). Try disabling any filters and setting the window size to at least 2x.
I made the mistake of thinking that reducing the framerate to 30fps would reduce the filesize, but another encode showed that the 60fps size is almost identical (100 KB more).
It's the encoding bitrate that counts (or whatever amounts to the effective bitrate with the more advanced encoding options), not the framerate. A higher framerate (while keeping the same bitrate) might or might not reduce the visual quality of the encode (because you are effectively compressing more data into the same space; however, if it does reduce the quality, it's not by much; the correlation is certainly not linear).
Yeah, I forgot that I was encoding with a fixed kbit/s setting and not a certain quality setting...
The quality difference isn't even visible, but 60 fps looks just smoother and the mirror effect isn't broken.
http://www.megaupload.com/?d=TJXTDUB0
I made the mistake of thinking that reducing the framerate to 30fps would reduce the filesize, but another encode showed that the 60fps size is almost identical (100 KB more). Uploading the other version would take another 2 hours... might not be worth it if OmnipotentEntity's version is better.
Would someone from 1811 want to live today? (Or even further back (e.g. 1611) because the rate of social/technological advancement is exponential)
There would be some interest from historians, but apart from that one would be quite isolated.
It might be interesting to see how far humanity has come, but I'd only do this near the end of my current lifetime.
Does this work with the translation? (probably not...)
EDIT1: Dumped data (compression=Lagarith) is ca. 40 GB! :o
EDIT2: I'll upload a 900 MB file (video = 256x224 @ 30 fps in 400 kbps h264; audio = 160 kbps MP3), this will take a while.
Well, there has to be a trade-off somewhere.
It would be possible to use the sequence [67;33][67;33][67;33][...], but the flickering objects would look different depending on what frame the effect starts (even or odd).
Which might also be fixable, but only manually:
AVISource(...)
shifted = DuplicateFrame(0).Blend_67_33
Blend_67_33
Replace(100, 200, shifted)
# ...
function Blend_67_33(clip c) {
c
Layer(SelectEven, SelectOdd, level=round(1.0/3.0 * 257))
}
Warp:
It wouldn't be arbitrary. One is skipping gameplay that the viewer wants to see; the other is skipping non-gameplay that the viewer doesn't want to see (non-skippable movies are are a bad design choice for a reason, after all).
The purpose of a run is to be enjoyable, and the rules should follow that goal. Look at the result, not the means etc.
Looking over the blended Alisia Dragoon TAS again, I notice there are parts where the flicker appears as it does in game, but much of it where it does not. Between 7:50 and 8:20 of the encode, the flashing of the charged Thunder in the top left looks correct.
Would there be any way to find out what is different to the rest of the video where there is more blurring there, and apply it correctly throughout the encode? I suspect getting the right timing would also fix the flickering on enemies that warp in, as well.
Assuming that it can be fixed (flicker starts at the "wrong" frame or something like that) you'd have to do that by going through the clip frame-by-frame and adding instructions to your script that fix the issue.
It's a really subtle effect. It doesn't seem to be done for flicker effects.
I don't think most viewers will notice an improvement - in fact it looks worse because details are smeared together.
(EDIT: There are almost no stars in the background of the motion-blurred clip.)
In some emulators, mostly SNES9x 1.43, the HDMA effects (which control the HUD display) are occasionally one line too soon or too late, resulting in screens like this.
That's what the Fix_HUD function is for. It should only be used in those parts of the recorded video that contain actual gameplay. To see where they begin despite fade-in or fade-out effects, set the brightness with the SetGamma function.
The AviSynth script would then look like this:
AVISource(...)
SetGamma(10) # disable when done
Replace(1000, 2000, Fix_Hud) # Space Colony
Replace(3000, 100000, Fix_Hud) # Zebes
# ...
function Fix_HUD(clip c, bool "HUD", bool "Main") {
# clears the first line of the screen's HUD and main playing area
# optional parameters control which parts are cleared
HUD = default(HUD , true)
Main = default(Main, true)
c
p1 = Crop(0, 0, 0, 31)
p2 = Crop(0, 31, 0, 0)
p1 = (HUD ) ? p1.Crop(0, 1, 0, 0).AddBorders(0, 1, 0, 0) : p1
p2 = (Main) ? p2.Crop(0, 1, 0, 0).AddBorders(0, 1, 0, 0) : p2
StackVertical(p1, p2)
}
function Replace(clip c, int i, int j, clip d) {
Assert(i >= 0, "Replace: parameter i is negative")
Assert(j >= 0, "Replace: parameter j is negative")
p1 = c.Trim(0 , -i)
p2 = d.Trim(i , j)
p3 = c.Trim(j + 1, 0)
p1 = (i == 0) ? c.Trim(0, -1).DeleteFrame(0) : p1
p3 = (j == 0) ? c.Trim(0, -1).DeleteFrame(0) : p3
p1 + p2 + p3
return (c.HasAudio) ? last.AudioDub(c) : last
}
function SetGamma(clip c, float Gamma) {c.Levels(0, Gamma, 255, 0, 255, true)}
