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
Besides the visual glitching, is there anything that notably differentiates this from, say, watching the most recent SMB1 run at 4x speed?
I don't think so.
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 Wanderer wrote:
Has anyone else had any problems playing back the published encode?
The encode plays back fine with the media players immediately available to me - MPlayer (apparently a build dating from 22 March or so), MPlayer2 (built this morning from git), and VLC (1.1.10).
Essentially all of our modern encodes use duplicate frame removal and thus have variable frame rates, so hard-specifying a frame rate is not going to fix anything.
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
EDIT: As moozooh pointed out, and as has been done before for a handful of publications, the screenshot exceeded 256 colours (which is a major disadvantage for optimisation purposes), so better results can (and were) obtained by starting with an image that had been reduced to 256 colours. I've replaced the main screenshot with the thus-optimised image.
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 screenshot is a jpg because it was ~110kb in the form of an optimised png, which I considered to be unacceptably large. Comparing the jpg with its original image, there's essentially no visual difference, so if you're seeing problems they're likely present in the original screenshot.
Was there a specific problem you were noticing? It may be that it was present in the original shot.
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
Jungon wrote:
I think I chose the frames "onebefored" (??)... I remember choosing the first one where the character was ducking.. and the fourth one, the enemy was in front of the rock.. ? x_x
Might be a timing difference between what the emulator is reporting and what my video tools are reporting.
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
Encodes coming right up, for your viewing pleasure.
EDIT: 512 in the submission text; downloadable here.
EDIT2: I took the opportunity to capture the suggested screenshots:
I think the third of these is probably best without being too spoiler-y.
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
c-square wrote:
If you look at the first speed runs of games such as Deja Vu, Shadowgate and Uninvited, they suffer from the same criticisms. However, those TASses were accepted, and are now part of the TASVideos collection. Should they have been rejected? No. If you look at the current Shadowgate run, it manipulates RAM and relies very heavily on resources that only a tool can provide. If the original Shadowgate TAS had been rejected, or if the whole Storybook game genre had been rejected, such a TAS would never have come into being.
The same argument can be made for this TAS. Although it may only take advantage of tool assistance in a few parts of the run, it should be seen as a starting point. By publishing this run, it will encourage others to beat it, and to find more creative and tool dependent ways of optimizing the run.
I am only accepting of Shadowgate in its present form due to the memory abuse glitches that the run demonstrates in its latest iterations. I maintain that the main reason we have runs of those games at all is historical precedent, rather than any standard of entertainment or technical merit.
Radiant wrote:
Doesn't the same argument apply to any MetroidVania game?
A Metroidvania game's solution is not comprised solely of "click at this location, then click at this location, etc." - it's significantly more technically complex to run and optimise well than what we are dealing with here.
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
As against the grain as this is judging from the last two posts here, I'm going to have to vote No.
For the record, yes, this is a game I have played before (and yes, I'm familiar with the rest of the series as well). I happen to think that the charm of an adventure game is enjoying the storyline and puzzle-solving at a relatively leisurely pace. If you know exactly what it is that you have to do to reach the ending sequence and just blaze through the game as quickly as possible, you're losing a lot of the entertainment value inherent in the game.
What does the solution here amount to from a technical perspective? Basically, it's knowing where to click and when for a set (and relatively small) number of puzzles. The only aspects of this that I think would look to a casual viewer as though they could not have been done unassisted are playing at high speed (which isn't necessarily a benefit - see #3308: DarkKobold's DOS Mega Man in 02:23.55), adjusting the laser locks without the benefit of the cigar (which is something I've seen done unassisted before, albeit not on the first try) and dodging the security robots at screen transitions. Does this make up for the high-speed walkthrough feel of pointing and clicking through the rest of the run? I don't think it does.
Essentially, given the nature of the genre, and holding this up as a specific example, I don't think that classic adventure games are suited for speedrunning in any traditional sense.
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
Disclaimer: I have not yet watched this run.
I think that having one walkathon on the site is enough - the current warped run can be seen to largely be a subset of this run. Since this apparently improves on several of the levels that are identical in both runs, I think that if this run is accepted, it should obsolete the current walkathon.
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
adelikat wrote:
We have, by design, not had a definitive rule on when to end input despite our reported times being based purely on input length. Sacrificing completion time for the sake of input time is a debateable topic and thus I've left it up to the authors to decide this. However, the point is that doing one method over another is hardly an improvement. Nor is finding a trick to input sooner without increasing input time. It is certainly something nice to find I guess, but the end result is the same.
To summarise: this is a run which a) is a duplicate of a previous run b) by another author c) differing only in frames trimmed off the end.
Oh, look, we've [submission 2527]rejected[/submission] [submission 2708]submissions[/submission] on those exact grounds before.
This may not be a written rule anywhere, but we've certainly adhered to the spirit of considering fastest completion time in terms of when the final hit is delivered as opposed to when input ends when disputes like this come up.
I also recall that adelikat had come up with other improvements to this run previously, which, on the above basis, this run doesn't incorporate.
I therefore posit that this run should be rejected.
EDIT: I should note that this run was submitted without prior knowledge or consent of the primary author, and a good argument could be made for preemptively cancelling the run on that basis.
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
Assuming that the encode goes well here, I am planning on replacing the submission with the desyncless one in the interest of consistency.
If anyone has a major problem with me doing so, let me know here.
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
AngerFist wrote:
So far, of all the runs I've seen (obviously not all published DS games), the bottom screen has been absolutely unnecessary to me.
Respectfully, you are one viewer, and it's not going to be the case that a) every viewer is focusing exclusively on the top screen and b) every viewer is not going to find it detrimental to have only one of the two screens visible in the encode. I, for one, think it could be considered misleading to not show everything that the console itself is outputting.
Recall that the major purpose of our encodes is to provide high-quality videos for those unable or unwilling to view runs in the emulator itself, [wiki EncoderGuidelines]subject to the following to guidelines[/wiki]:
to inconvenience viewers as little as possible; and
to aim for video output that reflects what one would expect to see on an actual console.
Cutting any material at all in this fashion would go against these guidelines, besides which I do not think that it is our place as encoders as publishers to decide on our own what is important and what isn't important to viewers by doing so.
EDIT: I have to note that the 1x2 screen idea is what I would consider to be a reasonable compromise for games where one screen is obviously dominant, but only for streaming purposes - I do not think that a primary encode should ever be in that form (or any other form that's not as true to the emulator / console viewing experience as possible), though that's not to say that such a setup might be provided as a downloadable secondary encode if there's demand for such a thing.
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
Nach wrote:
There is however another difference which was rather noticeable.
The regular encode in MPlayer uses 5-10% CPU. In MPlayer2, 10-15%. The 10bit444 encode in MPlayer2 uses 35-40% CPU.
The large overhead makes it unfeasible to play back these files with older hardware. Not until they optimize it more, if possible.
Interesting - thanks for the feedback.
I suspect the difference in visual quality is not going to be noticeable for older platforms such as the NES/FDS, but encodes for more advanced consoles will show more of a difference.
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 have ready access to a Windows machine to be able to exhaustively test configurations, but perhaps the following suggestions will help:
I don't believe VLC has been built recently enough to have a new enough version of ffmpeg to decode the videos properly, and it's not going to depend on the rest of your system codecs, so it will probably not be usable to play this back until another release of it comes out.
I do not know if ffdshow(-tryout) implements YUV444 playback. Consider grabbing the latest SVN version from here (32-bit) or here (64-bit) and seeing if that works.
I have just been reading that LAVFilters seems to support all of the requisite codec features, so that may be worth trying as well.
I've been using mplayer2 to play back the video, but that's probably more relevant for non-Windows users.
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
Openness to Experience/Intellect
High scorers tend to be original, creative, curious, complex; Low scorers tend to be conventional, down to earth, narrow interests, uncreative.
You typically don't seek out new experiences. (Your percentile: 47)
Conscientiousness
High scorers tend to be reliable, well-organized, self-disciplined, careful; Low scorers tend to be disorganized, undependable, negligent.
You tend to do things somewhat haphazardly. (Your percentile: 30)
Extraversion
High scorers tend to be sociable, friendly, fun loving, talkative; Low scorers tend to be introverted, reserved, inhibited, quiet.
You are relatively social and enjoy the company of others. (Your percentile: 64)
Agreeableness
High scorers tend to be good natured, sympathetic, forgiving, courteous; Low scorers tend to be critical, rude, harsh, callous.
You are good-natured, courteous, and supportive. (Your percentile: 90)
Neuroticism
High scorers tend to be nervous, high-strung, insecure, worrying; Low scorers tend to be calm, relaxed, secure, hardy.
You probably remain calm, even in tense situations. (Your percentile: 3)
This is a bit of a shift from the last time I took this test.
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
<scrimpy> now this is kind of funny
<scrimpy> in Vampire Killer, I discovered that if you go too far up to the ceiling
<scrimpy> you die.
<scrimpy> turns out, the exact same thing happens in castlevania.
<ais523> vertical overflow into a bottomless pit/
<dunnius> bottomless pits in the ceiling
<Grunt> Clearly, getting that high means you've been granted the power of flight, which probably means you're a vampire.
<Grunt> <_<
<dunnius> Don't do drugs, kids. Getting high makes you a vampire
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
According to this, Subtitle() is inherently anti-aliasing.
Are you thinking of subtitles for the logo itself, or something else? If it's just for the logo and won't be changing, you could use an image editor to produce a still frame of the relevant anti-aliased text and Overlay() it on top of your logo.
I still think the third of these makes for the best shot.
EDIT: As moozooh pointed out, and as has been done before for a handful of publications, the screenshot exceeded 256 colours (which is a major disadvantage for optimisation purposes), so better results can (and were) obtained by starting with an image that had been reduced to 256 colours. I've replaced the main screenshot with the thus-optimised image.
I think the third of these is probably best without being too spoiler-y.