Emulator Coder, Experienced Forum User, Published Author, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
Obviously, your hits are landing so fast and furious that they're breaking the game itself.
This was a hilarious and systematic teardown of the game well deserving of publication.
Emulator Coder, Experienced Forum User, Published Author, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
Hello, and welcome to the site.
Sadly, this submission isn't up to our standards, for many, many reasons.
To start with, the [wiki MovieRules]Movie Rules[/wiki] state the following, which the movie does none of:
"The movie must be complete[...][i]t must beat the game" - this run does not.
"A speed-oriented movie must beat all existing records" - it is slower than [submission 952]this submission[/submission] during the same time span.
The [wiki Guidelines]Guidelines[/wiki] state: "Select those games which give you a chance to make a TAS that entertains viewers. Just because a game is popular, difficult, or is entertaining to play or run or TAS, does not necessarily mean that it is entertaining to watch." The previously linked submission was rejected for being a bad game choice, and I believe that still holds here.
Most fundamentally, it does not appear that you employed rerecording to correct mistakes; this is one of the most fundamental techniques to achieve the above goals.
In the future, I would suggest you post your runs to the forum for feedback and further discussion so that you can get a sense as to whether your runs live up to the site's expectations.
In the mean time, however, this run fails to live up to several key criteria set by the site and should be rejected.
Emulator Coder, Experienced Forum User, Published Author, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
creaothceann wrote:
sgrunt:
Could you change part of the TASBlend page, please?
"creaothceann suggests using this in the following fashion to select only certain segments of the clip for blending" -> "If only certain segments of the clip are to be blended, creaothceann suggests using this in the following fashion"
Emulator Coder, Experienced Forum User, Published Author, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
Hello!
What you're looking to do is create an image (at least the size of the movies you're going to be encoding, if not larger; you may want to create an image for each resolution you'll be encoding at) with:
An indication that the run is tool-assisted, along with a link to the site (these should be the most prominent parts of the logo); and
Some means to identify you as the encoder ("encoded by [...]" and an image are often used).
You don't necessarily have to use GIMP to do this; any image editor will suffice.
Was there something more specific you needed to know?
Emulator Coder, Experienced Forum User, Published Author, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
In my view, votes are taken rather less seriously (by the majority of us) than they have been in the past.
That said, I don't think that making three posts is much of a barrier to entry for someone who's really interested in involving oneself in the community.
Think of it as "show you're really interested before you get to play with our toys".
Emulator Coder, Experienced Forum User, Published Author, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
The morning TAS has vanquished the horrible TAS!
*cough*
...Yes, this is a worthy and entertaining improvement. I'm skeptical about the use of the J ROM, given the reason cited for its use, but I don't think that that should have any strong weight in the decision.
Thus, yes vote.
Emulator Coder, Experienced Forum User, Published Author, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
Flygon wrote:
It's not possible to DeDup a video twice.
Actually, surprisingly, it is possible - you just need to pass DeDup the timecodes file you generated in the first round as the "timesin" parameter to generate a correct timecodes file as output
I don't recommend going much beyond the usual limit DeDup sets, however, on the basis of diminishing returns from a file size perspective - very few segments in the clips we normally work with will have very large numbers of consecutive duplicate frames - and from a usability perspective, as removing too many duplicate frames affects seekability in the resulting encode.
Emulator Coder, Experienced Forum User, Published Author, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
Actually, what you'd need to do is truncate that length of audio from the beginning of the file (normally, the first part of audio is silence anyway, particularly where we have our ~2 second encoder logos attached); the encoder then introduces the delay to have the audio start at the correct time.
Now, let's decode this again using some representative piece of software. ffmpeg is a good candidate for this, as it powers a lot of media players / decoders our viewers are using:
ffmpeg -i encoded.mp4 output.wav
Now, comparing the resulting waveforms in Audacity:
The output shows a significant delay. QED.
Incidentally, you can inspect the three files here if you don't have the means to generate them yourself.
Emulator Coder, Experienced Forum User, Published Author, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
This desyncs for me in 1-2 in the versions of v1.43 that I've tried playing it back in (v13 and v17). (Yes, the movie file indicates it was done in a v1.43 revision.) Can you tell us what version of snes9x you used
Nevertheless I can see that even if the full run were to sync, it would not be very impressive. Why not?
There are point where you appear to move backwards for no adequately explained reason.
You hit the top of the flagpole in 1-1, wasting time as compared to the bottom...
...and end up with fireworks, also wasting time.
Were the run to sync, I note that even accounting for the 648 frame delay to the title screen, this run fails to beat the [movie 1715]currently published SMB1 movie[/movie].
I do not believe 361 rerecords constitutes "lots of Rerecords", in your own words, besides which rerecords don't necessarily correlate to the amount of effort to this run. Note, however, that [movie 1715]the currently published SMB1 movie[/movie] quotes 9739 rerecords.
I've [post 275523]twice[/post] [post 275937]advised[/post] you to run your runs by the community (i.e. post them in the fora) *before* placing them in the queue to check if what you're doing lives up to the site expectations. Clearly, you haven't understood this.
We may consider removing your ability to make submissions until such a time as you have put together a submission worth our consideration. In the mean time, this run gets a No for continually failing to understand the purpose of the site.
Emulator Coder, Experienced Forum User, Published Author, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
creaothceann wrote:
or example SNES9x v1.43 rr17 uses 60.038, but still sets the AVI framerate to 60/1. This causes the video to lag behind the audio, which becomes noticeable in long movies (>15 minutes).
It is true that SNES9x has audio issues, but your comment is based on a false premise - having just inspected the relevant source code, at NTSC speeds, snes9x aims for an approximate framerate of 60fps but really ends up at (1 frame/16.667μs)~= 59.9988 fps.
The actual cause is [post 218066]32kHz sound output[/post] (I think there's a more recent explanation for the issue than that, but that was the one I could most readily find). In practice, we avoid this by using 48kHz sound output.
Emulator Coder, Experienced Forum User, Published Author, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
partyboy1a wrote:
SD encode[...]
[thread 11466]I presume you mean "downloadable encode" or "primary encode" or similar.[/thread] </minor_nitpick>
Anyway, that's reasonable quality, but I think it could be done better:
Logo is a bit on the long side; I'd *prefer* two seconds with a hard upper limit of five seconds.
Ending could probably have been cut short sooner.
The encode is constant frame rate; you'd be able to save a significant amount of space by using duplicate frame removal.
Could probably use an audio encoder capable of outputting HE-AAC (such as Nero's).
I'm sure you've seen the [wiki EncodingGuide]Encoding Guide[/wiki], which has details on how to achieve the latter two - or you could ask over in the encoding corner for more info.
Emulator Coder, Experienced Forum User, Published Author, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
DarkKobold wrote:
strangely, youtube's suggested lists always catch my attention (because you watched list, not the list next to every video) and I end up watching more videos than I planned to. Damn you tube!
Emulator Coder, Experienced Forum User, Published Author, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
Santiago wrote:
I have been made aware of the new --deldup feature but it doesn't seem to be available in x264 but in other codecs.
--deldup is specific to the direct264 build of x264. It has been known to be problematic (in particular, it can remove non-duplicate frames).
Santiago wrote:
the muxed audio was out of sync and I couldn't find out why.
Out of curiosity, how was it out of sync? I know that tc2mp4 does not take into account some audio-related fixes that NHMLTransform and NHMLFixup both do.
Santiago wrote:
I understand that there are two tools authored by people on this site, NHML trasnform and NHML fixup. I have no idea how to use fixup because the post assumes I'm familiar with Lua, which I'm not.
NHMLFixup doesn't really require you to be familiar with Lua, just that you have it installed and available.
Santiago wrote:
WIth NHML transform I have been getting a "bad parameter" error, first with audio in my ninja gaiden encode and then with video on dragon warrior encode.
Speak to Aktan (as he offered above).
Santiago wrote:
please return the guides to how they were, simple and step-by-step, not the confusing and fragmented mess it is now.
Is there anything in particular, aside from the above, that is confusing? We've tried to present the guide in a fashion that helps you understand why you are doing what you are doing, and we aim for it to be as clear as possible.
Emulator Coder, Experienced Forum User, Published Author, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
creaothceann wrote:
Identical frames would be caught by the codec.
Not true, in x264's case. Allow me to illustrate.
(Most of the files I refer to in the following are available here, for the curious.)
I made this image while [thread 11511]testing media player colour spaces[/thread], and converted it into a ten second, 60fps test clip in FFV1/BGR32 (cc10.avi).
From here, I applied two workflows.
First, I used ffmpeg to directly convert the AVI into a raw YV12 input to be used with x264:
ffmpeg -i cc10.avi -pix_fmt yuvj420p -vcodec raw -f rawvideo cc10raw.yv12
I then encoded this losslessly with x264:
x264 --fps 60 --input-res 256x256 --demuxer raw cc10raw.yv12 --crf 0 --fullrange on -o cc10nodedup.mp4
For the second, I used my [wiki DedupC]dedup filter[/wiki] in conjunction with ffmpeg to generate a dedupped raw YV12 for input to x264:
x264 --input-res 256x256 --demuxer raw cc10dedup.yv12 --crf 0 --fullrange on --tcfile-in times.txt -o cc10dedup.mp4
The resulting cc10dedup is 26047 bytes, and the resulting cc10nodedup is 87956 bytes. There's a clear benefit.
EDIT: In the interest of full disclosure,
Emulator Coder, Experienced Forum User, Published Author, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
So, a bit of research suggests that this hack is supposed to be a more difficult (yet much shorter) version of Air, by the same author as the original Air, by all appearances.
I posit that we only have room for one Air run (of any variety) on the site, as the game play between the various versions is going to look rather similar (vicious SMB1 glitch abuse at all turns).
Should this run replace the one we already have? Despite the (hack) author's intent of this being more difficult, the resulting run makes the game seem less challenging and more amateurish than either of the runs of Air or Air 2 the site has had to this point.
Thus, I don't think this run of this hack has a place on the site and I vote No.
Emulator Coder, Experienced Forum User, Published Author, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
OmnipotentEntity wrote:
Just fyi, 444 isn't lossless, but rgb is. Colorspace conversion.
Where the final result is going to be YUV and there isn't any down-sampling involved (as with YUV444), there's probably not going to be much of a difference (if any) when re-encoded to something in YUV420.
Emulator Coder, Experienced Forum User, Published Author, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
I don't quite know what to make of this. It probably speaks volumes to note that the two most interesting things I saw in this run not already covered by other material currently or about-to-be published were the speedboost-in-water oddity and the fact that the Etecoons now introduce themselves with a rendition of the item collection theme...
Without outside reference, I'm not really in a position to comment on the technical aspects of this run, but some of your comments allude to your own thoughts on the matter:
Run comments wrote:
If this run's fall into Cpadolf's or Kriole's hand, I'm sure it will be better ;)
This is basically a big red flag saying "I think this run can be improved". Why would you not have run this by one or the other of them before submitting it?
(Incidentally, looking into the thread for the hack turns up "[post 281277]it's not optimized at all[/post]". I don't think there's any real excuse to submit a run you don't think is optimised.)
Run comments wrote:
Yeah, I didn't take full advantage of "14 frames countdown" Speed Booster trick
According to the input file, you started creation of this run on 6 July; this was after at least [post 277291]one oddity in speed booster behaviour[/post] was drawn to your attention, and after cpadolf had started work on his own run (which apparently incorporates the trick).
I ask: when was this drawn to your attention, and how far in making this run were you when it was? If it wasn't too long after you started, I don't see why you would not have began to incorporate it into your own run once you were made aware of it (possibly even before you reached the point of having the speed booster in the first place).
Given that the author of the run is probably in one of the best positions to comment on level of technical skill, I think it's safe to say that this run can be done better than this shows.
Thus, to my eye, the run fails on technical and entertainment merits and I must vote No.
Emulator Coder, Experienced Forum User, Published Author, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
ALAKTORN wrote:
I seriously don't understand how people can consider taking damage in a TAS to be sloppy.
Intentional or otherwise, I'd prefer that as much as possible that's done in a TAS have a clear purpose towards achieving the objectives thereof. Taking damage is something you'd normally only done by an experienced player if it's meant to save time, which clearly isn't the case here; thus, doing so without the clear purpose I, at least, have come to expect looks uncharacteristic of our favourite hypothetical perfect player.
Emulator Coder, Experienced Forum User, Published Author, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
This has the look of a considerably-less-polished version of the full SM64 run, both in terms of hack content and general style of play (for example, taking the hit immediately after the second Bowser fight was probably meant to be entertaining, but just looks sloppy instead).
This may or may not be considered an achievement in the SM64 community, but I do not think this run has a place here.
Voting no.
The output shows a significant delay. QED.