Posts for Dada


Experienced Forum User
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
Kuwaga wrote:
Using Youtube means being signed on on Google and I guess the development could go into a direction where they outo-sign-on me onto Google+ as well.
As far as I know you need to have a public Google profile in order to be part of Google+.
Experienced Forum User
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
I didn't get an invite yet, but I think it's because Google Apps accounts (business Gmail/Calendar/etc under your own domain name) don't have the capability. Which is weird. Could be wrong though, in that case I'm just a really unpopular guy. To me, Facebook is just a giant party calendar. And a place for me to post pictures of what I've cooked. I doubt I would use Google+ any differently.
Experienced Forum User
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
It should be noted that videos can't be published on our site unless they follow the encoding guide (so VirtualDub can't be used) but for your own purposes it should be good enough.
Experienced Forum User
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
Virtualdub is easy, if you get ffdshow you should be able to encode in x264 from there as well.
Experienced Forum User
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
Aktan wrote:
This is another reason why I asked, "Are you sure YT quality is great?" YouTube has been known to cut the vertical resolution in half, and then up scaling it again, effectively losing 50% of the vertical resolution.
You mean it erroneously determines the video to be interlaced and deinterlaces it? That's weird. I wonder what system it uses to determine that.
Experienced Forum User
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
I'm not sure I agree on point resize support. That's only useful with super high quality encodes (otherwise the pixel art gets mangled anyway, even with quality on par with 480p) that don't use (significant) upscaling, and Youtube doesn't provide them right now anyway. Going down from any large size to the native screen size with only point resizing would introduce artifacts (some pixels being larger than others). In that case, using a bilinear scale is better.
Experienced Forum User
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
Aktan wrote:
moozooh wrote:
With regards to video quality/convenience/freedom of input/output formats, 30 fps is YouTube's one and only disadvantage by now. Everything else has been fixed.
I disagree. The quality is still subpar. I rather have more control on what bitrate I can use.
Are there any other video hosting sites that do allow finer control, though? I presume most of them just encode everything to conform to similar standards, with decent quality for most people, good quality for those who want it (480p) and the optional HD resolutions as well. I don't know any site that allows resolutions over 1080p.
Experienced Forum User
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
DarkKobold wrote:
A quick question - all of this seems to be based on the fact that youtube... sucks. Seriously, seriously, sucks. Is the only reason we focus on youtube is due to its popularity?
I think Youtube isn't that bad. It's too bad that it doesn't support 60fps, which is a major advantage of DailyMotion, but personally I'd prefer to use Youtube since that's where the audience is. It has about a 43% market share (followed by Hulu which has barely more than 3% market share). So in terms of getting our runs to people, there's really no alternative.
Experienced Forum User
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
For beginners, it's best to stick to only this part of the guide, assuming you don't need a logo or subtitles. It can be quite simple. If you're using Windows you can download the x264 encoder (x264.exe). Then go to Start > Run... and type in "cmd" (without quotes) and press enter. Then type something like this, in your x264.exe directory (assuming your movie is also there). Of course, it may be easier to just use VirtualDub... since that has a GUI and allows you to encode the audio as well in the same pass. Even easier is just uploading the whole thing to Youtube, which is really what you should be doing unless you want to learn all about encoding. edit: by the way, you can't make something higher quality by encoding. You can only make it (approximately) the same quality at lower filesize. :)
Experienced Forum User
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
Mister Epic wrote:
Nahoc wrote:
Agreed! I love the first one. This should be tested with some Megaman X flicker too.
Take a look at this. So yeah, I've applied the TASBlend function on Mega Man X. Again, it looks good. The AVS script for this clip is here.
What's weird is near the end, during the boss fight, in some cases the boss flashed with 33% and at other times with 66% opacity. I guess there's no way around that though. The blurriness from screen scrolling seemed to be most pronounced in the outside part of the level due to how bright it was.
Experienced Forum User
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
Looks a lot better than I expected. Though, it would be nice to have another example that uses a bit more scrolling at higher speeds.
Experienced Forum User
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
Let me make this whole discussion a lot less brief by just stating that I can live with not using aspect ratio correction for consoles from before the PSX era. Even if I think it's a bad idea. To me, it's developer intentions that matter the most. I will never be convinced that an entire industry, spanning multiple consoles, was ignorant of how their end users were using their products. Using a console meant using a 4:3 TV: that's how it was for the entirety of console gaming history until the first 16:9 TVs started popping up in the late 90s. And yes, some artwork, such as circles in NES games, look squished when displayed on 4:3, but you must remember that it's close to impossible to make a circle that still looks good after correction at such low resolutions. Later consoles, such as the PSX, did correct circular content because anti-aliasing made it possible at all. So, to summarize: it seems most people that I know of are on board with not using aspect ratio correction, and that's fine with me as long as games that clearly do need it, such as Abe's Oddysee or Medievil, still get it.
Experienced Forum User
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
Nach wrote:
roxahris wrote:
Nach wrote:
For the games where it looks ugly not to stretch it, you still want #2?
Can you point to a specific example?
Unfortunately, I don't have enough sample data on hand. But I imagine Space Invaders would look quite weird.
It wouldn't be such a big deal to make exceptions for specific cases, if a good case can be made. I still voted for #2 because I think we should cross that bridge when we get there. EDIT: by the way, I assume that option #3 would entail turning aspect ratio correction off for the vast majority of games (and indeed all SGB games we currently have on the site). So in practice #3 is almost the same as #2, except it explicitly allows for possible exceptions in the future.
Experienced Forum User
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
This is a very confusing poll. I don't think we should be using the SGB because it offers very little extra and adds hideous borders to the output, but I also think it's important we don't stretch the output for the SGB specifically. So which one do I vote for? #9 or #2? Multiple options would be useful in this case. Or just remove #9 entirely because it's mostly a separate discussion. edit: I guess I'll just vote for #2 because of the numerous reasons outlined in this topic. However, that does not mean I support removing the aspect ratio correction for all other consoles. We can reasonably expect that all other consoles were made with a 4:3 output in mind. The SGB was not because the SGB just plays GB games, and practically all GB games were primarily made with a square pixel aspect ratio in mind. Therefore we should make a special exception (which is option #2). The important thing to realize here is that there are no SGB games, there are only GB games that the SGB displays incorrectly (barring an extremely low amount of exceptions).
Experienced Forum User
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
Nach wrote:
Dada wrote:
Because the SGB was an afterthought.
Quit it with this "afterthought" business, some games show clearly otherwise.
Then we can encode those "some games" with a 4:3 aspect ratio. But you haven't shown me one single game that actually has two sets of main artwork (beyond just the borders, that is) with one of them being specifically made for 4:3. Remember, we're talking about the geometry of the artwork here. Can you show me even one game that specifically has a SGB-only function that corrects the artwork? For all games that don't have this and that don't explicitly seem to be made with SGB as its primary (not just plain old support) output, we must assume they were in fact made for the GB in the first place and SGB in the second place and that the GB pixel aspect ratio should therefore prevail. Unless you can somehow prove that the SGB was in fact more popular than the GB/GBC. edit: by the way, there have been calls on IRC to just make a poll out of this. It makes sense to me. This is an end user issue, after all. They're the ones who watch our encodes. I'd be on board with settling the issue that way. There's enough popular support for a special exception for the SGB for it to be on the table.
Experienced Forum User
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
Nach wrote:
Dada wrote:
Honestly? Do you really think that the developers intended for their games to be shown at BOTH this and this? At the same time? They are both 100% correct, even though they're A and B, completely different?
So, they're different, how does that make one more correct than the other?
Because the SGB was an afterthought. The GB is what these games were primarily built for. Sure, some games may have SGB support, but that doesn't mean they weren't primarily designed for the GB. 16:10 monitors were around even in the DOS era. Does that mean it's right to display 320x200 games at a 16:10 aspect ratio? No. They were built for 4:3 because that's what consumers had. You cannot reasonably expect anything else.
Experienced Forum User
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
I'm kind of stunned. It seems pretty clear to me that Nach personally likes the 4:3 ratio and will come up with any argument, no matter how contrived, in order to defend that. Including ignoring the fact that the SGB was just an afterthought and claiming that the stretched GB artwork was actually how the developers intended it. That's right. You made the artwork for a GB game and we just stretched it by 16.7%. But that's just how the developers intended it. Honestly? Do you really think that the developers intended for their games to be shown at BOTH this and this? At the same time? They are both 100% correct, even though they're A and B, completely different?
Experienced Forum User
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
So in other words, you're against using a square pixel aspect ratio for SGB games. Geez, you could have said that with a whole lot less words.
Nach wrote:
Dada wrote:
But the point that others and I have been trying to make is that the games themselves were made for the GB, and that therefore it would be better to use a square pixel aspect ratio.
The games were made for both, if they weren't, you wouldn't see the SGB logo on the gamepak, or have specific SGB features in the game.
Just because they have SGB support doesn't mean that the artwork was made specifically to be stretched to a 4:3 ratio. The games were made for the GB in the first place--that's what the art was optimized for. SGB features were built in, but those are just extras, they're not the raison d'etre.
Experienced Forum User
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
Nach wrote:
moozooh wrote:
Nach wrote:
The aspect ratio set should be the most common one for the use case as explained above.
And what should that be then in the SGB's case?
Whatever is the most common aspect ratio for the SGB.
That's slightly confusing. The SGB passes games through to the SNES, which displays a 256x224 image meant for 4:3 output. There are no variations. But the point that others and I have been trying to make is that the games themselves were made for the GB, and that therefore it would be better to use a square pixel aspect ratio. Do you mean that we should decide on a case-by-case basis? Because if so, all cases that I know of should not have aspect ratio correction because all games were undoubtedly made with the GB in mind in the first place. The SGB's aspect ratio correction is solely a result of the fact that 4:3 is a necessity when not providing a custom display.
Experienced Forum User
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
I don't think we should be making such a major change to our video encoding practices. The reason why the SGB topic became so big and is arguably a good reason to have an exception is that its games all expect a square pixel aspect ratio. That's because it plays GB games. Games that were not built with a TV output in mind. However, all other consoles that we provide encodes for do undoubtedly have a TV output in mind. After all, these consoles were specifically made to be used with a TV. Not providing aspect ratio collection would mean that the vast majority of runs on our site would look wrong. You can't expect people to correct the problem on their end, and not correcting the video's aspect ratio doesn't make it look better. Furthermore it raises some serious questions about encodes that switch resolutions, like Final Fantasy VIII. I honestly don't get why anyone would come up with a solution like this which puts the entire burden on the end user. It strikes me as the kind of autistic "not my problem" ivory tower attitude that's indicative of a highly technical community that, frankly, doesn't care if others can't figure out how to do it. This is specifically something that we should fix on the encoding end.
Grunt wrote:
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.
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.
Post subject: Re: reset to 0: savestate
Experienced Forum User
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
antd wrote:
i also found that a region of memory is reset to zeros if cloud runs in a certain pattern for ~500,000 frames on the world map.
Isn't that more than 2 hours? I'm curious, how did you figure this out?
Experienced Forum User
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
Kiwi wrote:
Btw, I downloaded the file supermarioworld-tas-ismmister.mp4 from archive.org directly, if that helps in your troubleshooting isolation.
Worked perfectly on my end as well. Maybe whatever player you're using doesn't support dedupped encodes? You should let us know exactly what you're using, hardware as well. Try using something like to see if that helps.
Experienced Forum User
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
Brandon wrote:
In the meantime, does the community prefer the processed run of Dada's, or the stretched one?
We can probably publish this as soon as this gets resolved.
Experienced Forum User
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
Noob Irdoh wrote:
Dada wrote:
It's like you're saying that the runners should have consciously chosen to use the GB/GBC instead of the SGB, if we were to expect to be allowed to encode it without aspect ratio correction.
I have to agree with Dada, if we know that SGB encodes will MUST be stretched, then players should deliberately choose to use GB/GBC modes instead to keep them not stretched.
Actually, I think it's unfair to expect the runners to make this decision. That's why I don't really buy the argument that "if the runners had made the conscious choice not to use SGB, things would be different".
Experienced Forum User
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
sgrunt wrote:
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.
The fact that it outputs to TV is not insignificant, but my point is that it's basically a slightly augmented Game Boy. It was meant as a secondary console for people who wanted to play GB games in a different setting. Since there was no point in including a display (since that's what the original GB is for) they made it output to TV because that's the most convenient. But it's not like it was designed specifically to screw over the aspect ratio of every game ever released; that was just a consequence. Aside from minor extras, the GB is the one that sold 118 million units worldwide: that's the platform the games were made for.
sgrunt wrote:
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.
I would posit this wasn't on the runners' mind. And frankly, I think this is an awkward argument. It's like you're saying that the runners should have consciously chosen to use the GB/GBC instead of the SGB, if we were to expect to be allowed to encode it without aspect ratio correction.
sgrunt wrote:
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.
This run doesn't target the SGB. It targets a game that was made for the GB, that people have mostly played on the GB and was specifically designed to look best with a square pixel aspect ratio, as on the GB. Besides, colors are far less important than the geometry.