Wouldn't "intended route" be too limiting though? I mean what happens if you gather so much speed that you go off a ramp and fly clear over a tunnel? Should you have to slow down there?
Well, what if you can enter a wall just right, and because of that you zip at enormous speed through the entire level to the boss? That's exactly what runs do now.
I'm not arguing against that, because that's the essence of TASing, and that's exactly why TASes are so cool. I'm just proposing a kind of rational compromise which would satisfy those wanting to see a more "normal walkthrough" of the game using tool assistance.
Plus how would you enforce "intended route"?
In the same way as how you define what constitutes a "low glitch" run and what doesn't.
Well I still stand by my opinion that the rules state that once a japanese run was submitted the next run has the right to use a japanese rom, too.
Care to give a reference to that?
(Besides, what is important is not what the letter of an obscure rule might say when sufficiently interpreted to support your personal opinion. What truly is important is what the spirit of the rule is, in other words, what its intended meaning was when it was written. If the letter of the rule is ambiguous, the proper action is not to start rule-lawyering, but to fix the rule to be less ambiguous. It has been expressed many, many times in the past that the general rules is to prefer the English version of a game, and that exceptions can be granted in very special circumstances, and that such exceptions do not nullify the generic rule.)
Doesn't H.264 always perform the yuv transformation before encoding, regardless of which compression method is used? Wouldn't that mean that the above artifact would be shown in a regular published encode as well? Does it?
I was more interested in seeing snapshots of OoT because that was the topic of the discussion, but anyways:
I don't know if it's just me, my monitor, or a combination, but I just can't see a visible difference between the images, even when zoomed.
The differences are probably there (and could probably be corroborated by checking the actual pixel component values), I don't doubt that, but I just can't see any difference. If there is a difference, it's practically indiscernible. And this was with an example image which ought to best show any coloration difference. I can only imagine that with something like OoT any difference is going to be even less visible.
So my question is: Why such a huge worry about a possible minuscule difference in coloration which nobody is going to notice even if you put the original and the transformed images side by side (much less if they look at the transformed image all by itself)? Everybody talks about the H.264 lossless compression is if it was changing all the colors around, turning bright blues into aquamarines and reds into magentas. I just don't see that.
If the goal is "get to Ganon without using the sword, and only then use it", I'd say anything goes which achieves that goal. It doesn't really matter what you do, as long as that goal is strictly achieved.
However, I don't think that the choice of how to achieve that should be based on how many frames each option takes; which seems to be what Baxter is implying.
Why not? What else, then? Wouldn't it be sloppy play if frames were wasted?
Not only save a lot of space, but also lose a looooot of color! =p Yea I figured it was something like that. Oh well, lossless H.264 is NOT an option.
Everybody complains that H.264 loses color information ("loooot of color" information). Yet I have never seen an actual example of this.
Could someone make a short encode of the beginning of the run in both raw RGB and lossless H.264, take a snapshot from the same frame and put them side-by-side so that we can see some actual evidence of this "huge" color information loss?
I'm thinking: What would be the relevant difference between "low glitch" and "uses the route intended by the developers"? Personally I just like the latter more as a concept because it's, at least in principle, less ambiguous.
Or maybe a better term than "less ambiguous" would be "expresses better what the goal of the run is". It tells the viewer "so, you want more of a 'regular walkthrough' of the game, but with tool-assistance? This is it." The term "low glitch" doesn't convey that meaning so clearly.
1) Collecting one or more heart containers
2) Collecting other items, such as boomerang, magic key, bracelet etc.
3) Collecting the sword earlier, but still using it only for Ganon
4) Not collecting the sword but freezing the screen at Ganon with the freezing glitch
Personally I greatly dislike the idea of freezing the game before it's completed. TASing is about completing games (which can be completed).
If the goal is "get to Ganon without using the sword, and only then use it", I'd say anything goes which achieves that goal. It doesn't really matter what you do, as long as that goal is strictly achieved.
Recently both Lord Tom and I were interviewed by Gamer's Global. He had an interview about his Super Mario Bros 3 TAS, and I had an interview about TASVideos and administrating the site/community.
I like those interviews. They are easy to understand and straight to the point, without going too much into technical details, but still providing interesting tidbits of information.
I'd say the two most requested ones that aren't already done are low glitch Megaman, and Sonic 3. Someone doing those is virtually guaranteed strong audience support and publication (given that the technical quality is still on par with the glitched versions).
I'm still concerned about the heavy arbitrariness of the author defining at his own whims what constitutes a glitch to avoid, and which glitches are ok to use. "Low glitch" is such a vague and ambiguous term. It doesn't really define anything. How many glitches need to be avoided for it to be considered a "low glitch" run?
And most importantly, if after accepting such a run someone else submits a run which is slightly faster and which uses one type of glitch more, will it be accepted as the new "low glitch" run or not? Who exactly defines which glitches are ok and which ones break the category, making the run unacceptable? More importantly, how can an author know which glitches he can use and which are out of question (so that the run will be accepted)?
There has been some discussion, if not even minor controversy, over what constitutes "arbitrary goals" recently, and IMO "low glitch" is far on the wrong side of arbitrary goals.
I see no need for additional categories. 'Route intended by programmers' sounds like a most terrible idea. Who's to say what they intended,
I'd say with many games, such as Megaman, it's pretty obvious what the route intended by the developers is.
and more to the point, why do we care what they intended?
Quite many people seem to care, as there has been regular demand for such runs for years. My suggestion is intended to be a rational approach to this request many people have.
Route used by SDA? I see what you are getting at with this idea, but it still doesn't work for obvious reasons.
Yeah, that's not a pretty good idea. It would mean that the goalposts will shift as the runners at SDA get better at speedrunning a game and learning how to use new shortcuts and glitches.
I agree with adelikat, you have to think about the site as a whole, not just what OoT fanatics want. In this situation, best to go with 320x240, and also whatever other size the fans agree on.
I think 640x480 is better. It's not such a postal-stamp-size as 320x240, but it's still small enough to be playable even with quite old PCs.
I actually wouldn't mind trying my hand at Sonic 3 glitchless if there's enough interest (which I'm fairly sure there is).
The problem with "glitchless" is that it can become quite hard to define what constitutes a "glitch" and what doesn't. Almost invariably any "glitchless" run will end up forgoing certain glitches (mostly the major ones), while other "minor" glitches are ok, hence technically speaking breaking the premise. Personally I don't think "glitchless" is a sensible category because it's extremely ambiguous and, basically, arbitrary (iow. the author himself decides what he personally thinks constitutes a "glitch" that must be avoided and what is ok to use).
Many runs, instead, don't even claim to be "glitchless", but instead something along the lines of "forgoes using warps" or "does not use death as shortcut", etc. However, there isn't a sensible category for "avoids 'scrolling' glitches", because that's really hard to define accurately in a completely unambiguous way.
Naturally my proposal of "uses the route intended by the game developers" could be somewhat ambiguous as well (as there may be many places in a game where it's up to opinion whether a minor shortcut constitutes breaking the intended route or not), but at least it's, IMO, much less ambiguous than "glitchless", while achieving what people usually mean by that term (ie. avoid major route-breaking glitches, but allow minor ones).
A category like "uses the route intended by the game developers" has been suggested several times in the past (directly by me and indirectly by several other people), to be applied to many games (such as megaman), but the suggestion has never caught on.
Should Tetris fast 999999 take the Arkanoid star (puzzle star), or should they coexist?
Arkanoid is one of those games where tool-assistance is very easy to see and appreciate even for a non-gamer. Also arkanoid is a pretty well-known game type (even if not as much as tetris). I think it should retain its star, unless there are very good reasons why it should lose it.
If increasing the total amount of starred movies by one is completely out of question, I unfortunately don't have a good suggestion on which one of the existing starred movies should lose it...
I don't know if this is completely true since I don't have the means to verify its veracity, but:
Did you know that combos in fighting games is an example of serendipity?
I read somewhere that combos began as a programming oversight in the first Street Fighter II (IIRC). It was not the intention of the programmers for combos to be possible (or, more precisely, they did not deliberately program support for combos), but due to how the program was written, combos were possible by "mistake" (in other words, hitting the opponent while his previous "got hit" animation is still going on, thus without the opponent being able to react to it). In a way, it was a bug. However, it resulted to be such a cool feature that they left it. Combos have since then become such an ubiquitous part of fighting games that a fighting game without combos is practically unthinkable.
Personally I would prefer even 640x480 over 1280x960. (My PC could most probably play the latter, but I believe there are regular visitors who have slower computers than mine.)
Please note that not everybody has a top-of-the-line computer, and that playing a very high-resolution H.264 video is a very heavy operation. Only the fastest 32-bit PC's (eg. 3+ GHz Pentium4) are able to play HD-resolution H.264 videos without lag. Get any lower than that in CPU processing power, and you won't be able to watch the video. The resolution you are voting for there is above that critical limit.
Is there any rational reason to use such a high resolution? It's not like it adds much to the video quality.
Btw, why are 320x240 and 1280x960 the only available options? There are many usable resolutions in-between those two, such as a good compromise of 800x600, which is relatively high-res but still playable even with older computers.
The pages in this thread might get quite heavy if people start embedding all the videos inline. I think it might be a good idea to keep posting just the links.
