Posts for Zinfidel


1 2
9 10
Zinfidel
He/Him
Experienced Forum User, Player, Published Author (199)
Joined: 11/21/2019
Posts: 247
Location: Washington
Big huge obvious yes vote from me! Brookman is being very gracious by including me as an author and I'm honored to be listed. Very early on in this TAS's life when I saw some of the work that Brookman was doing to improve the Ravens' Test (first mission), I realized immediately that I was outclassed completely. I was actually very proud of how fast I was able to do that mission in my own TAS and considered it to be one of the most technically sound parts of it. Even Brookman's exploratory attempts at the mission were already 100s of frames faster than what I had put together. His level of polish and excellence continued throughout the project, long after I would have lost steam, and so I'm glad I could contribute to his project in other ways. There is some hidden excellence throughout the TAS I'd like to point out, since it's hard to spot it if you don't know the game very well.
  • Brookman discovered a new (to the speedrunning community so far as I can tell) trick that involves switching your back weapon with very specific timing during a laser sword strike, which causes the sword tracking to go wonky and give you a LOT more maneuverability as a result. Brookman uses this all over the place to deliver the very satisfying laser-sword-backhands that are the end of so many foes in this TAS. The air of casual disregard of these strikes belies that fact that they are actually very technically demanding to pull off and also very new technology. Laser swords in this game are already very deadly and the way they are wielded in this movie is even more deadly than usual.
  • He managed to kill the PLUS escapee on the skyscraper mission so quickly and fell for so long that he actually overflowed and wrapped back up to the top of the mission. Doing this is kind of a "thing" for AC1 speedrunning, with some nods to particularly old JP runs of the game aiming to do this.
  • The triple kill on Mop Up Chrome Remnants is a thing of beauty and needs more attention. Even a double kill with a laser sword in this game is absurdly difficult to pull off, TAS or not. Triple kills are basically unheard of or regarded as purely theoretical. It was not some serendipitous stroke of luck that lead to that hat-trick either - there is some serious AI manipulation that went into making that happen for the viewer's entertainment.
  • Wildcat being bullied like he got in the train mission is one of the most savage things I've seen done in an Armored Core game, all while being done in third-person camera no less. It is NOT easy to make the game do what you want in that mode, and Brookman pulling stuff off like landing on Wildcat and balancing on him while he's kneeling to shoot, and fast-dodging is just amazing to watch. The entire sequence is almost dreamlike in how absolutely absurd and out-of-reach to a normal player it is.
  • Some of the shots that Brookman landed are obscene. This game does not allow you to "aim smoothly" because the amount you can turn is sharply divided into big blocks of movement, so it's very hard to be precise at a long distance because you literally can not aim with enough granularity to hit anything at a distance. The rocket that opens the door in Rescue Survey Team, as noted in the submission notes, is eye-popping and I had to rewatch that segment a few times when I first saw it because I didn't believe it. The shot that breaks the lock in the recon mission is almost comically far away, very near or at the absolute maximum range of the weapon with the longest range in the entire game. I think that length of that shot is literally a multiple of the game's render distance.
Anyway enough out of me. I'm incredibly happy the day has finally come where I get to see this run up on the site - it's been a long time coming.
Zinfidel
He/Him
Experienced Forum User, Player, Published Author (199)
Joined: 11/21/2019
Posts: 247
Location: Washington
That new Dethro's skip is just something else, wow. I remember in my TAS that I had to conserve boost near the end of the lap for the straighter sections coming up, but without that conservation of boost maybe Mawhonic has the necessary speed. If someone in the community has a laptop with Intel UHD graphics (sync requirement), they should be able to use my movie file to experiment with this. It's not in the cards for me right to try unfortunately.
Zinfidel
He/Him
Experienced Forum User, Player, Published Author (199)
Joined: 11/21/2019
Posts: 247
Location: Washington
PoochyEXE wrote:
Cool to see my work finally complete and published! Thanks for the prompt judging and processing! I noticed the publication page says it obsoletes the previous run, even though this was meant to be a new branch (and Samsara accepted it that way). Was the decision changed, or is this an error? Also, if you'll excuse the nitpick, the description mentions stuff from the NES version that aren't in Round Game in the SNES version, namely minibosses and cutscenes of Wario trying to discourage Toad. The SNES version doesn't have minibosses, and the cutscenes are different -- in Round Game they just show Toad moving through the overworld map, and the cutscenes with actual dialogue were moved to the SNES-exclusive VS COM mode, with different dialogue.
The errors were a result of a lazy, good-for-nothing publisher. He's in the dungeon for his mistakes.
Zinfidel
He/Him
Experienced Forum User, Player, Published Author (199)
Joined: 11/21/2019
Posts: 247
Location: Washington
feos wrote:
Sorry I didn't mention it right away. The reason I suggested testing this on 512px mode of PSX and/or A2600 is to see how it compares after ARC. Because ARC is what makes them inherently not pixel-perfect. And heavy ARC is what may kill things really hard (slight fractional ARC too tho). But since we don't target 1x anymore, it also has to go 2x with pixel first, and then shrink or stretch width without changing height, because height isn't meant to be stretched by fractional factor. Finally, this test image has a lot of almost-white on a lot of almost-black, which means color changes are almost pure luma too. Good comparison would be going from chroma to no chroma (or vice versa), because detail loss is the most apparent there. As long as there's a lot of chroma, even changes from one chroma color to another won't make the loss apparent. EDIT: I'm switching between the 2 resulting images above at 1000% zoom I can't tell which one is better.
My turn to apologize: I was going to test chroma subsampling filters in the previous post but never got to it. That's why I've got the 512px game. The above tests were only to test if multiple color conversions were necessary any more (go through YV24 first, for instance).
Language: AviSynth

AviSource("kain.avi") # 560x240 (512,240 framebuffer) PointResize(1120, 480).LanczosResize(640, 480) one = ConvertToYV12(chromaresample="point", matrix="rec601") two = ConvertToYV12(chromaresample="lanczos", matrix="rec601") #Aktan's method ConvertToRGB64() three = ConvertToYUV420(matrix="rec601", chromaresample="point").ConvertBits(bits=8, dither=0) four = ConvertToYUV420(matrix="rec601", chromaresample="lanczos").ConvertBits(bits=8, dither=0) ExtractV()
Control YV12, Point YV12, Lanczos Aktan's Method, Point Aktan's Method, Lanczos After doing this, I realize that this game as probably a bad pick for this because it's dark and kind of dull. For this type of content (full 3D), the differences between point and lanczos sampling is nearly indistinguishable to me. Aktan's method vs straight to YV12 has differences that are a little more different though - if you zoom in a LOT, you can see that there seems like a very slight increase in contrast for the strictly YV12 route, vs smoother gradients in Aktan's (expected because of dithering). The difference is very small though and you've gotta squint. I think that this sampling may have a bigger effect for pixel-y games. Anyone want to recommend a 2D, 512px mode PS1 game? Someone should test A2600.
Zinfidel
He/Him
Experienced Forum User, Player, Published Author (199)
Joined: 11/21/2019
Posts: 247
Location: Washington
In response to changes being made to the official encoding package to make it simpler, here are some colorspace tests. Control image: Test 1: Do we need to convert from RGB to YV24 to YV12 to preserve quality, versus converting directly from RGB to YV12? The script has had this "double" conversion for some time now, and Aktan recalls that it was likely originally done because there was a bug in AviSynth that caused direct conversions to YV12 (4:2:0) to either ignore parameters, or suffer some other type of quality loss. There is mention of an issue that sounds quite similar in official Avisynth documentation on this page: http://avisynth.nl/index.php/Sampling#RGB_-.3E_YUY2_conversion. Relevate quote:
(In v2.58, the [0 1 1] kernel was used to interpolate chroma. This is technically wrong and results in a 0.5 pixel right shift of the chroma, but it was originally done for performance reasons.)
Language: AviSynth

wide = AviSource("E:\xtreme\2Xtreme.avi") wide1 = wide.ConvertToYV12(chromaresample="point") wide2 = wide.ConvertToYV24(chromaresample="point").ConvertToYV12(chromaresample="point") # Extract chroma planes for comparison since luma should remain unaffected and will make comparison more difficult. wide1.ExtractU() wide2.ExtractU()
RGB -> YV12,Point RGB -> YV24,Point -> YV12,Point XORing these planes together in Paint.net yields a uniformly black (0,0,0) image, meaning that the planes are identical, and the trip through YV24 did not make a difference. Let's test the internal order of operations of the convert functions to ensure that the transfer function is performed first, then resizing.
Language: AviSynth

wide = AviSource("E:\xtreme\2Xtreme.avi") wide3 = wide.ConvertToYV24(chromaresample="point").ConvertToYV12(chromaresample="lanczos") wide4 = wide.ConvertToYV12(chromaresample="lanczos") wide3.ExtractU() wide4.ExtractU()
RGB -> YV24,Point -> YV12,Lanczos RGB -> YV12,Lanczos XORing these planes together in Paint.net yields a uniformly black (0,0,0) image, meaning that the planes are identical, and that converting directly to YV12 preserves the desirable order of operations. Test 2: Increasing bit depth prior to color space conversion, dithering, and other assorted goodies courtesy of Aktan. Aktan provided a technique for colorspace conversion that might improve accuracy:
Language: AviSynth

AviSource("E:\xtreme\2Xtreme.avi") # Assume RGB32 source ConvertToRGB64() # ConvertToYUV444(matrix="Rec709", chromaresample="point") # Might be needed? Needs testing ConvertToYUV420(matrix="Rec709", chromaresample="lanczos") # Conversion from 16-bit RGB to YUV 4:2:0 16-bit ConvertBits(bits=8, dither=0) # Reduce back to 8-bit color with dithering, bits=10 for our encodes in 10-bit color ExtractU()
Code as posted produces: Code with optional conversion to YUV444 enabled: XORing these planes together shows that they are identical, so the trip to 444 (as with the previous test) appears unnecessary. Here is the full image using Aktan's method: Here is the full image, converted directly to YV12 with Lanczos: Here is the XOR of these two images: Very unsurprisingly they are different (there is dithering going on). No conclusion, subjective difference would have to be examined. Take the two images into paint.net, put them on separate layers, and switch between them if you want to try to determine which is subjectively better.
Zinfidel
He/Him
Experienced Forum User, Player, Published Author (199)
Joined: 11/21/2019
Posts: 247
Location: Washington
The publishing staff uses various methods to make those DS encodes, but you can find the AviSynth script that a few of us use here: https://tasvideos.org/HomePages/Zinfidel You can pass the results of that script to any tool that accepts frameserver input, such as FFmpeg or x264. Learning how to use AviSynth or those tools is a bit beyond teaching over a forum though, so be prepared to do some learning.
Zinfidel
He/Him
Experienced Forum User, Player, Published Author (199)
Joined: 11/21/2019
Posts: 247
Location: Washington
Awosomeandy wrote:
Sure, here's what I had in mind to add to it: "This new TAS of Doc Louis's Punch-Out!! improves sparring by incorporating a newly discovered Instant Knock-Out to the game. Saving 3 seconds from Sparring's previous TAS."
I've updated the description with a slightly reworded version of this, in order to stay consistent with site style.
Zinfidel
He/Him
Experienced Forum User, Player, Published Author (199)
Joined: 11/21/2019
Posts: 247
Location: Washington
Hey Awosomeandy, I wrote the publication text for this submission a bit generically as I had a hard time interpreting the improvements that were made. If you provide a very brief (1 sentence preferably, 2 tops) summary of improvements over the previous TAS, I can update the text! Of course it can also remain as it is if you are satisfied. And actually, it doesn't have to be me that updates it, but in fact any editor if you have someone in particular in mind.
Zinfidel
He/Him
Experienced Forum User, Player, Published Author (199)
Joined: 11/21/2019
Posts: 247
Location: Washington
I am quite pleased to see in the notes that there was in fact at least one less door in this submission! This is quite an improvement and although I didn't know what was going on a lot of the time, the run entertained me. Nice and easy sync as well:
Zinfidel
He/Him
Experienced Forum User, Player, Published Author (199)
Joined: 11/21/2019
Posts: 247
Location: Washington
This is just so cool. I love the breakdown of how the exploit was done and I'm amazed that there was somehow room for improvement at all.
Zinfidel
He/Him
Experienced Forum User, Player, Published Author (199)
Joined: 11/21/2019
Posts: 247
Location: Washington
A fast, glitchy take-down of a pretty difficult dungeon crawler. I quite enjoyed it, yes vote. Fun fact: The Moonlight Sword is referenced in just about all of FROM's IP. In the Armored Core series, it's always the heaviest, most-damaging laser sword available. A few of the AC Pilot's emblems are also ripped directly from the KF series' shield heraldry.
Zinfidel
He/Him
Experienced Forum User, Player, Published Author (199)
Joined: 11/21/2019
Posts: 247
Location: Washington
I never saw the original, but this run entertained me regardless. The improvements are quite large, so this is an easy yes vote from me. I guess I never really sat down and watched VBoy footage because I'm surprised at the graphical fidelity of the system.
Zinfidel
He/Him
Experienced Forum User, Player, Published Author (199)
Joined: 11/21/2019
Posts: 247
Location: Washington
mobilisq wrote:
just came across this, and am surprised to have not seen it materialize here yet https://www.youtube.com/watch?v=NuYGNlidKfw&ab_channel=Sample
I too was surprised when I didn't see it in the submission list! Maybe the author is taking their time on a submission? Not sure if they use the site or not.
Zinfidel
He/Him
Experienced Forum User, Player, Published Author (199)
Joined: 11/21/2019
Posts: 247
Location: Washington
A great run for this kooky game. I enjoyed watching your antics during the downtime, too! The submission notes were a good read too - I was surprised to learn how much was going on to speed this game up after watching it.
Zinfidel
He/Him
Experienced Forum User, Player, Published Author (199)
Joined: 11/21/2019
Posts: 247
Location: Washington
Impressive savings on the previous run, congrats to both of you. Contra as usual makes for a pretty good watching experience, so yes vote on entertainment. As a note, this movie syncs just fine on FCEUX 2.3.0, though the listed version is 2.03 - not sure if this is actually a different version or if it's just listed strangely.
Zinfidel
He/Him
Experienced Forum User, Player, Published Author (199)
Joined: 11/21/2019
Posts: 247
Location: Washington
I really rather enjoyed this run! Especially the second half of the movie because the game gets so incredibly hectic. You did a good job of making a game that might otherwise be uninteresting to watch enjoyable.
Zinfidel
He/Him
Experienced Forum User, Player, Published Author (199)
Joined: 11/21/2019
Posts: 247
Location: Washington
Just finished a Tifa exhibition: Link to video
Zinfidel
He/Him
Experienced Forum User, Player, Published Author (199)
Joined: 11/21/2019
Posts: 247
Location: Washington
nymx wrote:
When encoding a movie, does the starting frame and ending frame get captured. I often wondered this, since you start on frame zero, which isn't anything...so it makes me wonder if the encoding stops when it reaches the end frame, with nothing captured. I've tried to confirm this with visual queues but I guess I don't have a good playback app to look at individual frames.
The answer to this will be different for different emulators, so I'll just answer for BizHawk. BizHawk will record a frame when it gets rendered, and BizHawk starts movies before frame 0 has been rendered. So if you have BizHawk paused, restart a movie to its beginning, and start AVI capturing, you will capture frame 0. BizHawk will also capture the last frame in a movie so long as it gets rendered, which BizHawk will do even if you pause on last frame, since that last frame gets rendered then the emulator pauses. The only caveat here to consider is if you are paused on an arbitrary frame, and then turn on AVI capture. Since the frame you are paused on has already been rendered, it will not get captured in the AVI.
Post subject: Parallelizing Encodes
Zinfidel
He/Him
Experienced Forum User, Player, Published Author (199)
Joined: 11/21/2019
Posts: 247
Location: Washington
I've got an encoding computer with 20 CPU cores, and the speed gain per core at SD resolution drops off precipitously at around 8 threads or so. So while HD encodes could saturate as many cores as I threw at them, my SD encodes would use 40 threads and get nearly the same speed as just using 8. The reason this happens is because there is only so much work (lib)x264 is able to assign to cores for a single encoding instance, and that amount of work is tied to the resolution of the video. The trick to overcoming this limitation is to encode multiple sections of the video at once. I have come up with a way to fully automate this process of slicing up SD encodes, encoding the slices in parallel, then stitching them back together on the other side. It uses ffmpeg to accomplish the concat muxing. vidsplit.vbs
Option Explicit

Dim Frames, Segments, SegLength, i
Dim Output

If WScript.Arguments.Count = 2 Then
    Frames = WScript.Arguments.Item(0)
    Segments = WScript.Arguments.Item(1)
Else
    Wscript.Echo "Usage: vidsplit.vbs <frames> <segments>"
    Wscript.Quit
End If

SegLength = (Frames \ Segments) + 1

For i = 0 To Segments - 1
    Output = Output & vbCrLf & CStr(i * SegLength) & " " & CStr(SegLength)
Next

Wscript.Echo Output
Wscript.Quit
global.bat
set segments=6
set threads=16

echo Encoding video...
".\programs\ffprobe" -hide_banner -v error -select_streams v -of default -show_entries stream=nb_frames encode.avs >> ".\temp\info.txt"
for /f "tokens=2 delims==" %%G in ('FINDSTR "nb_frames" "%~dp0temp\info.txt"') do (set frames=%%G)

set concat=".\temp\concat_modern.txt"
break > %concat%

for /f "tokens=1,2" %%G in ('cscript -nologo "programs\vidsplit.vbs" %frames% %segments%') do (
    set start=%%G
    set length=%%H
    set name=video_modern_!start!.mkv
    set filepath=.\temp\!name!
    start "!start!" ".\programs\x264_x64" --threads %threads% --stitchable --seek !start! --frames !length! --sar "%VAR%" --crf 20 --keyint 600 --ref 16 --no-fast-pskip --bframes 16 --b-adapt 2 --direct auto --me tesa --merange 64 --subme 11 --trellis 2 --partitions all --no-dct-decimate --input-range pc --range pc -o "!filepath!" --colormatrix smpte170m --output-csp i444 --profile high444 --output-depth 10 encode.avs
    echo file '!name!' >> %concat%
    Timeout /T 3 /NoBreak > NUL
    set previous=!next!
)

:MODERNLOOP
tasklist | find /i "x264_x64.exe" >nul 2>&1
IF ERRORLEVEL 1 (
  GOTO MODERNCONTINUE
) ELSE (
  Timeout /T 300 /Nobreak
  GOTO MODERNLOOP
)

:MODERNCONTINUE
ffmpeg -y -hide_banner -safe 0 -f concat -i %concat% -c copy .\temp\video.mkv

:: Muxing ::
[....]
Explanation This technique is general in that it could be implemented for whatever encoding needs you have, but I'm presenting it as part of the encoding package because that's where I've got it. vidsplit.vbs is a script that lives in the programs folder. It's job is to calculate frame numbers that correspond to some splitting interval. It just spits out some text that gets later ready in by a loop. The section of code is global.bat is where the meat of this trick is. The segments and threads variables correspond to the number of segments the video will get split into, and the number of threads assigned to each encoding instance. What works here is really a dark art, and I had to spend a lot of time experimentally discovering what works best for my machine. I have 20 physical cores and it seems that 6 sections assigned 16 threads each was the sweet spot for performance. The loop makes use of the start command, which allows you to spin off a new process for a command. For each desired segment, an encoding instance is spun off in its own window, and x264 is told to start at a specific frame, and end at a specific frame. Notice the --stitchable argument in there - this argument is very important. It prevents x264 from doing some optimizations at the beginning and the end of the video segment that makes ffmpeg's life a lot easier later when it's putting them back together. Without it, I noticed a lot of error messages when ffmpeg was remuxing the videos, and sometimes it would outright fail. The "MODERNLOOP" thing is a process checking loop. While the encoding instances are doing their thing, the main global.bat file spins in this loop. Every 5 minutes, it checks to see if there are any x264 instances left running. If there are, it waits another 5 minutes. If not, then the videos are done and ready to be put together. You may have noticed a "modern_concat.txt" file that got created earlier in the process. This is a text file that gets built up by getting filenames during the encoder instance loop, and is later fed into ffmpeg. ffmpeg has a special muxing tool built in called a "concat demuxer". What this does is, rather than concatenating videos in a more traditional way and then re-encoding them as one video, you can take a bunch of videos that all have the exact same properties (dimensions, framerate, colorspace, encode parameters, etc), and just "play" them back-to-back into a container. This allows you to combine disparate segments into a single video without any extra processing. There is a little tiny bit of inefficiency here since the encoder will naturally have to stop the GOPs in each segment at the seams, but losing just 5 full-sized GOPs only ever accounts for a few hundred kilobytes in the end product (I've tested this). Should you bother with this? For fun I tested splitting videos up with an old 4-core intel processor from 2011, and found that doing it didn't provide any speed benefits at all. For native-sized encodes, x264 is able to fully saturate about 8 threads already, so splitting it up didn't help a ton in my case. If you have a normal consumer 4-core processor, this probably won't help you at all. I am interested in hearing from anyone with consumer-grade CPUs trying this out and seeing performance increases, though. If you've got a hexacore or octacore processor however, you might be able to use this to speed stuff up. I would recommend trying two segment encoding for either 6- or 8-core processors. You can set the threads for both higher than the actual amount of logical cores than you have available, like each instance could have 8 or even 16. Ultimately, you would need to test various parameter combinations to try and hone in one an effective combination. For HD videos, this probably isn't worth it unless you've got over 20 cores. On my machine a 4k encode with the right settings can saturate all 20 cores, and x265 can do that even more effectively. If you've got really serious numbers though, splitting up HD encodes will net exactly the same benefits as the SD encodes enjoy.
Zinfidel
He/Him
Experienced Forum User, Player, Published Author (199)
Joined: 11/21/2019
Posts: 247
Location: Washington
This is a really strange Pac-Man game, and I'm pretty sure I would not like playing it. It does however make for a pretty entertaining TAS! I especially enjoyed the abuse of moving platforms, and launching PM around borders that you weren't supposed to get around. Lots of fast, twitchy movement! A yes vote from me.
Zinfidel
He/Him
Experienced Forum User, Player, Published Author (199)
Joined: 11/21/2019
Posts: 247
Location: Washington
I was a bit more entertained than I would otherwise by a puzzle TAS because there were some fun bits of coordination, but it did start to feel repetitive after a while. Going with a 'meh' on this one. On the other hand, congrats on getting the first pcem TAS submitted! I'm excited for more DOS runs.
Zinfidel
He/Him
Experienced Forum User, Player, Published Author (199)
Joined: 11/21/2019
Posts: 247
Location: Washington
Guernsey wrote:
I learned that FFMPEG will default to YUV 4:2:0 as opposed to the newer 4:4:4 but how do you change it so that FFMPEG will use 4:2:0?
Add -pix_fmt yuv420p to your ffmpeg command somewhere after your video settings.
Guernsey wrote:
Edit: Should use x264vfw/x264 8 Bit-10 Bit for final encodes?
8-bit.
Guernsey wrote:
How do merge the split video files? I do not want it to remain split.
Use VirtualDub: https://www.makeuseof.com/tag/merge-multiple-video-files-with-virtualdub/
Guernsey wrote:
What is a good AVISynth/FFMPEG Command for Lanzcos resizing Sega Saturn footage?
This question is too broad. The Saturn has many resolutions and has a different pixel clock for low-res and hi-res mode. Borders will vary by emulator and mode. The best I can do is provide you with basic PAR correcting settings for any of the low-res resolutions, that wont' deal with borders in any way. Pixel clock: 7.16MHz means PAR of 6:7. ffmpeg -i saturn.avi -vf scale=iw*4:ih*4:flags=neighbor,scale=iw*4*6/7:ih*4:flags=lanczos,setsar=0 -c:v libx264 -crf 20 -c:a libvorbis -q:a 10 output.mkv This will scale footage 4x and correct for PAR. Change the 4s to something else if you want and use whatever codec settings you want.
Zinfidel
He/Him
Experienced Forum User, Player, Published Author (199)
Joined: 11/21/2019
Posts: 247
Location: Washington
Future encoders of this movie: In GLideN64 settings: - Disable LOD emulation (incorrectly renders character eyes) - Force bilinear filtering instead of N64 3-point (bug in this version of GLideN64 that causes 3-point filtering to instead become nearest neighbor scaling when LOD emulation is disabled) - Disable N64 depth compare (breaks camera movement) - Set Copy Depth to RDRAM to From VRAM/Video Memory (more camera problems otherwise) Dump using clock sync - alt sync causes progressive desync. Syncing scripts customized for this run are downloadable in my user files.
Zinfidel
He/Him
Experienced Forum User, Player, Published Author (199)
Joined: 11/21/2019
Posts: 247
Location: Washington
Masterful submission notes, and an excellent HUD to go with the run. I had a good time reading your explanations and the process you went through to trigger the ending is extremely interesting. The improvement over the old run is significant too. I always have a hard time with voting on runs like this. Purely from my perspective, this is S-tier material. Extreme technical quality and great technical explanation. But if I take the run on its own, without any commentary or notes, it falls into the category of entertainment that most ACE-type runs fall for me, which is that its entertainment value is diminished and is mostly from how strange or surprising the run is - or in other words 'meh' at best. I'm going to vote yes anyway just because of how impressed I am with the submission. Excellent job!
Zinfidel
He/Him
Experienced Forum User, Player, Published Author (199)
Joined: 11/21/2019
Posts: 247
Location: Washington
The Harvest Moon series is really close to my heart, so I am biased towards this TAS immediately. I have to reiterate what others have said of course, in that sleeping until Winter is an unfortunately boring requirement that greatly diminishes from the otherwise entertaining run. I also have a TAS that does this kind of thing and I feel for you, but it is what it is. After the fast-forwarding though, I love the route. The rock art was a great touch to pass the time, and the events that lead up to the marriage are amusingly non-sensical. Getting Karen to marry you via you d** is bizarre, I love. So, given the boring start but amusing finish, I must vote 'meh'. It is a shame that, as you pointed out, the more traditional categories for this game are unlikely to ever be produced and probably not acceptable, as I really like the idea of an HM TAS, but I think categories like this are probably what we're going to get.
1 2
9 10