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
sgrunt wrote:
Nach wrote:
sgrunt wrote:
I
I view this as inconsistent with what I believe to be the primary purpose of providing encodes, which is to help those that don't have the technical skill or patience to configure emulators to play back our runs to be able to view them easily.
This isn't inconsistent with the view you post in the thread you linked to, which was:
Nach wrote:
For our primary encodes, we should make them accurate depictions of their output.
I view it as more or less implicit that our encodes should be aiming to capture the video we feed them as closely as possible - that is practically the definition of "[wiki EncoderGuidelines]good-quality multimedia files[/wiki]" that the site was founded to provide.
I am looking at the broader question of why we need to provide these encodes in the first place. The average viewer of our encodes (through the site or through YouTube or any other streaming site) is probably not going to be in a position to immediately view the run in an emulator, and it is therefore by our encodes that they are able to view the runs at all.
sgrunt wrote:
greatly varying resolutions even within runs
For games where resolution changes mid game, I believe we should be using the smallest resolution which is able to contain the largest of them throughout the entire video.
This is, indeed, an approach we take.
sgrunt wrote:
"maximum video/audio quality, except at the significant expense of console accuracy"
I'm not entirely sure what you mean by this.
At face value, it could mean our encodes should be at 2400 (inches) x 2400, because we can.[/quote][/quote]
Perhaps I need to amend this to read that the emulator output should be of maximum visual quality (except etc.). It is still in the guidelines that encodes should be done at the resolution of the emulator output, in falling with the "capture the output as accurately as possible" guideline that underpins much of our encoding and that I noted above.
dada wrote:
[SGB-related arguments]
I'm going to direct most of this post to the other thread, except for:
dada wrote:
Not providing aspect ratio collection would mean that the vast majority of runs on our site would look wrong.
This is subjective. I personally think that using the aspect ratio flag looks wrong, because through all my encoding practices I am more used to looking at the emulator output than at a TV screen. Most people probably do not have an old 4:3 CRT these days, remembering the appearance of a game running from them from memory.
Further, we don't presently use NTSC filtering, etc. which means that to a purist who wants the run to look as closely as possible to the console, it's inaccurate whether we use the flag or not (not to mention [post 278542]posts Lex has made indicating that 4:3 isn't the correct target aspect ratio[/post]).
dada wrote:
Furthermore it raises some serious questions about encodes that switch resolutions, like Final Fantasy VIII.
Such as?
I've already noted that this is a case that would require special care (which it does presently anyway).
dada wrote:
I think it's incongruent to recognize that we do these encodes to help people without the technical know-how view the runs, and then expect them to manually do aspect ratio correction every time they view one.
This assumes that the viewers in question prefer having AR correction (which is exactly what this thread is determine the answer to). It's also unfair to those such as myself who prefer not to view runs with AR correction and subsequently must do exactly what you're suggesting to play back the run in our preferred conditions.
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
Well, the gameplay itself does seem to display at the 320x224 resolution you'd expect, so I'd view the probability of there something being game-breaking on account of incorrect title screen display to be fairly low.
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: Rather than try to follow the confusing poll in the other topic, I present a much simpler option covering one of the core issues.
Original post below.
---
I'm going to spiral this off of [thread 11466]this thread[/thread], as I view it as a significant expansion in scope.
As I've stated elsewhere, I view the reason we use the 4:3 flag at all to be that our viewers have expected to see runs as they would be displayed on a CRT.
I view this as inconsistent with what I believe to be the primary purpose of providing encodes, which is to help those that don't have the technical skill or patience to configure emulators to play back our runs to be able to view them easily. By this logic, we should be showing the unscaled video. (There are some exceptions that would be need to be made for this - the best example I can think of is PSX, which has the greatest difference between native resolution and intended display resolution, and also has greatly varying resolutions even within runs).
If we accept this, we'd need a better guideline in place than "console accuracy". I'd suggest that what we should be aiming for is "maximum video/audio quality, except at the significant expense of console accuracy" (the exception allowing for cases such as Gens' PSG high quality, which is a significant and detrimental difference between the console and the emulator output).
Does any of this sound plausible?
(And please, keep it cool and calm.)
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
Can you give us a sense of the magnitude of the improvement and how long it's likely to take?
You may wish to cancel the submission if it's a large improvement and/or it will take a while to implement.
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
To be clear, I am impressed that someone can come out of nowhere and come within a few seconds of some of our highest-calibre TASers on a game as heavily contested as this.
I just don't think that attempting to obsolete such a heavily-optimised run in such a slightly unorthodox fashion is the best approach for you to get started with.
It might be a good idea for you to run your ideas by the rest of the fora before placing them on the workbench - it will help give you a sense of how technically sound your submission is and how well received it's likely to be.
I do encourage you to try working on something else.
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 watched this and the [movie 1590]current NES run[/movie] back-to-back.
Now, there may be subtle differences in how the game runs, but I find it telling that you're four in-game seconds slower at the end of the 1-1 compared to the NES run (ending time of 293 compared to your 289) despite the use of the glitch.
To continue the comparison:
Level
1590M
You
1-1
293
289
1-2
294
292
1-3
287
285
1-Fortress
292
292
8-Tank1
167
162
8-Battleship
200
197
8-Floating Ships
239
235
8-1
292
289
8-2
293
288
8-Fortress
380
376
8-Tank2
211
209
8-Castle
375
373
Thus, I doubt the level of optimisation that's been put into this, particularly in comparison to the long history of refinements SMB3 has on this site. There are a few instances such as the large obvious slowdown to pick up the mushroom that point to this being the case.
I also would like to dispute the level of entertainment present in the autoscrollers of - the current SMB3 run, as with many of its predecessors, take great pains to chain together long jumps and acquire large numbers of lives, which, for them, has been a key selling point (so to speak).
I therefore posit that this run fails to live up to the technical and entertainment merits of the run it intends to obsolete, and 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
I do not see the reported issue with either the encode that's currently present on the movie or the one that was there up until about three months ago, regardless of media player used.
I thus ask for the third time what media player(s) you are seeing this issue with and what type of hardware you are running them on.
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
For those wondering about the goal choice - this game apparently cycles levels after level 48 (so past that point can probably be considered "second quest / post-game completion").
EDIT:
It seems to me that the key technical merit of this run would be in the form of route-planning, and though I can't really comment on how well or poorly that was performed, it does nevertheless look as though there's a certain amount of technical care that was put into the run (cf. the timing of jumps in the bonus rounds to be at the peak of a jump at the last catch, and thus ending the round as soon as possible, though there are a couple of instances where this seems to be out by a frame or two).
That said, 48 levels of watching the player character go through the routes is mind-numbing.
I therefore give this a Meh.
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:
Therefore, I don't think 4:3, 8:7, and other display parameters are actually part of authentic hardware, since it's perfectly legal to plug an NES into a device with different video output parameters.
This is true; I posit, however, that the display most commonly used with these consoles (at the time of their peak popularity, at least, and thus resonating the most with our viewers) would be a CRT outputting at 4:3.
(This is the only reason I can think of that the 4:3 tag came into existence in the first place, as I mentioned earlier.)
Lex wrote:
SGB happens to run it on a TV, but that's not its main platform.
Perhaps not, but the run in question was explicitly made for the SGB.
Lex wrote:
Most viewers aren't going to expect SGB games to be displayed at a TV aspect ratio.
So... viewers don't expect a platform that by its very nature outputs to a TV to output to a TV. Right.
Lex wrote:
If you want the encodes to be so accurate, fix NES encodes since they don't display with a 4:3 aspect ratio even on a 4:3 TV (as I described in my previous post).
One of the finicky points about CRT displays (TVs in particular) is that they can be adjusted to display at smaller than the full screen size. I think it is reasonable to assume that most people using a CRT will have the screen adjusted to use, as closely as possible, the full screen size.
Unless, of course, you have a different idea of what the most common aspect ratio for, say, the NES would be.
(I admit that there are more fundamental differences than this. To the best of my knowledge, these have not widely been tested for encoding purposes, though I'd be interested in seeing the results.)
Lex wrote:
Also, it's not the SGB outputting the incorrect aspect ratio. It's the SNES.
Wrong - as Nach correctly points out above, the console itself has nothing to do with the aspect ratio being displayed. The TV / display, on the other hand, has everything to do with it.
Dada wrote:
The thing is that the SGB is really just an adapter for playing GB games on a SNES with some extremely minor differences.
"Displaying on a TV" is something I would consider to be a significant difference, and, indeed, is one of the major motivating factors for this discussion.
"Playing with colour graphics" is also something that I would consider to be a significant difference, but more on that in a few moments.
Dada wrote:
I would argue that the games we're playing have far more recognition in their original aspect ratio for that reason.
I admit that more people will have played the games in their original handheld form. If this was the sole motivating factor, however, we would have expected to see the run in question made for the GB or the GBC, which it was not - the run itself was made for the SGB, and the resulting encode should reflect what viewers would expect to see if the run were being played on that platform.
Would a viewer familiar with the game from the GB be expecting coloured graphics? No, they would not.
Would a viewer familiar with the game from the GBC be expecting the larger variety in coloured graphics that the SGB offers relative to it for these games? No, they would not.
You can't have it both ways - a run targeting the SGB platform should be encoded as though it was running on an SGB, just as with any other platform the site makes use of.
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've largely stayed out of the ensuing discussion to this point partly out of curiosity as to the direction it would take.
I now see that there's been very little discussion of the topic at hand other than by those who originally prompted this thread to be created again stating their arguments. This leads me to believe that either the average site viewer doesn't care one way or another or that this thread hasn't received sufficient attention for the average viewer to know about or comment upon it.
Thus, I'm going to inject a few arguments of my own in an attempt to spark further discussion on the matter at hand.
---
To begin with, one of the founding principles of the site was that the site's movies should look as though they could have been played with authentic hardware. This is reflected as far back as the very first draft of the movie rules:
The aforementioned draft wrote:
The movie should look like it could have been played with an authentic hardware. This makes it more familiar to the audience.
This is also given a nod in the [wiki WelcomeToTASVideos]site's Welcome page[/wiki]; prior to the introduction of [wiki ConsoleVerifiedMovies]console verification[/wiki] the relevant text stated "could theoretically be performed on the actual hardware".
This, in my view, has motivated past decisions such as not allowing settings such as FCEU/FCEUX's "allow more than 8 sprites per scanline" (noticeable in games such as [movie 1825]Pinball Quest[/movie]) or Gens' "PSG High Quality" (for most Sonic games) to be used for encodes in that they cause video/audio output to be distinctly different from actual hardware.
This is also, in my view, the reason that the aspect ratio flag came into use in the first place - most viewers familiar with the games in question are going to expect content that they would normally see on a TV screen to be displayed at the same ratio as they would on a TV screen - thus, it's more familiar to viewers.
Now, let me pose the question:
Is it possible for a game running on the actual SGB hardware to be displayed without borders, or with borders but at a 7:6 AR (i.e. no AR correction)?
It's possible to change the border on the fly of an SGB game, and it is possible to set it to one which is completely black, but that doesn't actually remove the border altogether - the video output of the console is still going to be the same size.
It may just be me, but I've never heard of a 7:6 TV (besides which most viewers are going to be familiar with TV-displayed content on a 4:3 display, as omnipresent as they are).
I submit that the answer to (both parts of) the above question is no.
Does the developer intent when writing the game have an impact on what viewers would expect to see when running the game with this hardware configuration? No, it does not.
From this perspective, does it make sense not to include the border and/or not to use AR correction for SGB runs? No, it does not.
The bottom line here is that I fail to see a meaningful difference between this case and the case of other platforms that the average viewer would, in the case of the platform / hardware conditions being portrayed by the run, expect to see displayed on a 4:3 CRT.
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 would like to see the result of setting the AR flag for that encode, partly as a basis for comparison to without using it, and partly to see if there is any difference in the audience reaction between the two possible settings.
(I may not insist that said flag be kept.)
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
You haven't really provided us with much in the way of new relevant information yet. In particular,
sgrunt wrote:
Also, let us know what media player you are using. Some media players have known issues playing back heavily processed videos in general, particularly on less powerful hardware.
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
Our encoders are tasked with creating videos with high visual and audible quality. What you're doing is encoding, in a sense, but it probably falls far short of the [wiki EncoderGuidelines]site standards[/wiki] for publishability of encodes.
You're still welcome to upload your own video rips, of course - it often helps for feedback purposes.
EDIT: fixed link.
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
Toad King wrote:
I remember sgrunt saying that he sometimes needed to delay the audio a second for some records. But yes, that is a bug we know about. It should be easy to manually fix.
If memory serves, the delay these days is consistently 0.25 seconds. It's easy enough to manually account for.
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 like to think of it as the judge saying, "I don't think this was seriously intended as a submission (but if it was, somehow, go ahead and uncancel it)."
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
Dacicus wrote:
What's the difference between primary and downloadable encodes in that designation? I thought both terms referred to the one available via BitTorrent, [incorrectly] also known as SD.
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, at the time, they were referred to as "encodes".
Why? The only encodes that were commonly produced at the time were intended for download.
The use of the term "HD" arose because when the technique was first introduced, it actually did target 1080p resolution specifically (this was back before Original mode existed, and videos were limited to 1080p). "SD" only arose locally for want of a term to describe encodes that weren't produced using those techniques, and no serious effort was taken at the time to correct the misnomer.
(I'll also point out that "512kb"s are referred to as such despite that being an incredibly long five characters!)
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
Re amount of typing:
What about "PE" for primary encode, "DE" for downloadable encode...?
Yes, everyone knows what SD means - but what it means to a specific person depends greatly on the context. If you talk to an encoder in the wide world of video encoding at large, 99% of them are going to assume you're talking about something with 480 pixels of vertical resolution, as that's the widely accepted definition of the term.
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... the total extent of this is entering in a password - the scene technically isn't part of the run at all.
So, really, it's to distract us all from the lack of content this has.
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
Welcome aboard!
Is your input plugin (Options -> Settings -> Config Plugins) configured to have a controller active on port 1? If not, the game isn't going to detect a controller.
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
Mister Epic wrote:
And also, why is it labeled as a Genesis game while it's a 32X game? (I know the 32X is an add-on for the Genesis.)
Bad detection on the part of the site.
Fixed, in any case.
EDIT:
It seems starting dumping from frame 145 (just before the first non-blank/non-quiet frame) will allow the game to dump properly. Getting a correct dump is thus a matter of pre-pending 145 blank frames to a dump made in this fashion. Simple, 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
To be fair, high definition can be used to refer to resolutions larger than the above-defined standard definition - that doesn't make it any less ambiguous, though.
As for "HQ" - well, I like to think that all videos we produce are high quality, so it could just as well apply to any video we produce here.
