People can post comments on a submission regardless of whether they can vote about it or not. However, the vote is an easy and quick way of seeing if there are negative opinions about the submission. This may be especially relevant if the submission thread is very long. The judge can see at a quick glance if there are any negative opinions or not, and if there are, then he can try looking for them in the thread. (Not that he shouldn't read the thread anyways, but a quick&short summary of opinions at the beginning shouldn't hurt.)
Ultra was a pseudoname of Konami because of Nintendo of America's stupid 10 game/company/year limitation, if my memory serves me correctly.
I don't think it was a stupid limitation. It had a rational basis.
It stems from the Atari2600 fiasco: Since developing games for that console was completely unlimited, and tens of millions of consoles had been sold, everyone wanted a share of the pie and every opportunistic coder out there started making crappy games coded in 1 week for it in order to get a quick buck.
This caused the market to be flooded with completely sub-par atari2600 games, sinking the value of the entire console. Buyers couldn't distinguish anymore the few good games among the hundreds of crappy coded-in-1-week games. This is one of the reasons of the great console game crash of 1983 in the US.
Nintendo, unlike many companies (regardless of the field of industry), learned a lesson from this, and instead of making the same mistake with their hugely-successful NES, they wanted to keep the problem in control. One method for this was to force game companies to put more effort on fewer games, increasing their average quality, than to release tons of poor-quality games. Quality over quantity.
I would estimate that, in average, they succeeded in their goal. If one would estimate the average quality of all existing Atari2600 games and the average quality of all existing NES games, the latter would win hands down. (This doesn't mean that crappy NES games don't exist. I'm talking about the average quality of them.)
Personally I have never understood the attention some people pay to the in-game time of this game. Who cares? The only thing I look towards in such a video is a completion which is as short as possible. I don't care what some number reads in the game, I only care how long the movie is. Why should I care about anything else?
What if someone submits a 2-hour movie of this game which, according to the in-game clock, completes the game 2 seconds faster than the previous publication? Should it be accepted? The answer is naturally "no". It should definitely not be accepted.
So if a movie which is over 1 hour longer than the currently published movie is not acceptable, why would a movie which is 25 seconds longer be acceptable?
Could a TAS creator trick somehow the Automatic Screenshot feature to take a screenshot at his favourite scene in the movie?
Actually instead of a trick I think it would be a cool feature if the author could put some special code in his submission text which bot interprets as a frame number (or a series of frame numbers, up to a certain limit) and then includes that frame (or frames) with the others. (Or, even better, the submission form could have a field for suggesting snapshot frame numbers. Leave blank if there's no suggestion.)
I think that the basic idea of the poll is that the actual judges, those who actually decide if the submission is accepted or not, can get second opinions and points of view from other people. This can be very helpful because they can miss something important. 30 eyes see more than 2. If a submission gets a considerable amount of "no" votes then the judges will look more closely at what could be the problem people are seeing with the submission. This probably helps increasing the average quality of publications.
I have the opposite suggestion (only half-seriously presented, but something to think about): Not only change the question, but also offer more than 3 choices.
I have seen several times people commenting that they are not voting at all (ie. not even "meh") even though they watched the submission, for a multitude of reasons. Perhaps these people should be given more options to vote.
Perhaps one of the options could be something which means about I'm not completely happy with it, although if I would be forced to decide I would have to opt for the 'yes' vote", and the opposite. Or whatever.
One relevant question: Which one, v19 or v20, emulates more correctly in this regard? Are those additional frames correctly emulated in v20 (ie. they do happen in the original console), or is it some kind of bug in v20?
The algorithm used by the emulator for determining the beauty of a particular screenshot is written hoping to meet the following guidelines.
It doesn't sound to me like it calculated the "beautiful" the frame is but how "busy" it is. In other words, the more color variation and movement there is, or in other words, the busier the image is, the more points. :P
Yes, as Bisqwit pointed out, it's not enough to be able to write something to RAM and that the console supports running code from RAM, you must somehow be able to modify the existing game code. The very minimum you need is to add some jump to your new code somewhere in the existing game code. (I assume that in most console games all jumps are hard-coded into the machine code, ie. they do not contain jump addresses read from a variable or such, which could be abused.)
And of course even if you find a memory-corrupting bug in some game, the chances that it's such a bug that you can abuse it to write any values you want to the desired memory address are rather small. :)
Well, if everything you need a PC for is posting here, ircing and making TASes, then a rather old PC would be enough for that. If you can find an old used PC somewhere which you can buy half-free...
I'm not saying it's impossible, but writing functional code completely by chance is about as likely as a human being eating a bag of Lays and crapping out Chuck Norris.
I don't think the idea was "find a bug which corrupts memory in different ways and see if by chance it produces runnable code". I think the idea was "find a bug which corrupts memory in *predictable* ways and then abuse this on order to write machine code (byte values of some routine you have written and compiled beforehand) which produces some runnable routine". In other words, if the compiled machine code you want starts with the sequence 120, 56, 38, 251, find a bug in the program which corrupts the memory in a way that you can create that sequence. This could in theory be achieved, for example, by a selection and ordering of inventory items, etc.
Of course, as has been pointed out, most consoles don't run code from RAM, so this is just not possible.
There's a small difference between the "tricks&tips" pages and the submission text: The former present generic tricks appliable to any run. The latter describes exactly what was done in *this* run. Things like "at 12:34 notice how I fooled the NPC to look the other way", or "at 01:23 there's a small graphical glitch which looks funny" and such tidbits of interesting info which might be missed by the viewer otherwise..
You say you are annoyed if someone improves a movie, says how much time he improved it, tells how many frames he saved at what places, and what he did to save these frames...
Actually he didn't say that. He said that he is annoyed when the submission text includes no explanations of the tricks used to make the run (simply because the tricks were mentioned 10 obsoleted submissions earlier).
Like you said, a trick that was already present in the previous version can easily be found in the previous submission text
I think that was the whole point of the original post: It can't be easily found. It's cumbersome. You have to browse in the worst case through half a dozen of old submissions to gather the information you want instead of the relevant information being nicely presented in one page.
If not, it's also easy to check what input is used to do it.
I don't believe the point is "how can I replicate this?". The point is "I watched the avi and it looks really cool, I wonder what and how the tricks were done".
Besides, I wouldn't say that checking the input used to do it is "easy".
If I'm not completely mistaken, there's no limit on the motherboard side on how many keys are pressed at once. In fact, the motherboard doesn't see keys "pressed" in a contiguous fashion. What it sees is that the keyboard sends it atomic codes which tell "this key was pressed" and "this key was released". In other words, when you press a key, and keep it down, only one atomic code is sent by the keyboard to the computer (ie. it doesn't send a signal in a contiguous fashion for as long as the key is pressed). That is, keys are not switches which are on or off, they simply trigger the chip inside the keyboard to send a certain code to the computer.
Thus, in theory, there doesn't have to be any limit on how many keys can be pressed at once. You could press all 100+ keys at once and the keyboard could simply send a "key down" signal for each one to the computer, and when you release them, it could send a "key up" for each one.
The problem is that building a keyboard which actually can detect all possible combinations of simultaneous keypresses would be quite expensive, as it would need quite a lot of components and logic. Instead, cheap keyboards use electronic shortcuts which require less components and less logic, and which keeps the price of the keyboard at a reasonable level. The drawback of these shortcuts is that the keyboard cannot detect all possible combinations of keypresses.
In many cases it's not just limited to how many keys you can press at the same time, but also *which* keys can be pressed at the same time. For example, it may be possible to press 10 certain keys at the same time without problems, but some 4 other keys may trigger the limitation. It all depends on how the keyboard electronics has been designed.
I have a very old (>10 years) KeyTronic, and this handles quite a lot of simultaneous key presses at the same time. I suppose that newer and cheaper keyboards may be more limited.
OTOH, to be fair, it's usually much easier (and cheaper) to upgrade the amount of memory than its speed. Sometimes you can replace a memory chip with a faster one, but quite rarely. More often than not, if you need faster memory you will have to buy a new motherboard which has a faster memory bus and supports the faster memory. Of course buying a new motherboard is only a little less than buying a whole new computer. Thus it's usually unreasonable to expect anyone to even be able to upgrade the speed of the computer's memory without actually buying a new computer (or at least a new motherboard+CPU).
Anyways, RAM speed can indeed have a quite drastic effect on things like real-time video capture. I think you have some first-hand experience on this? Just the memory type can make the difference between barely being able to capture 20FPS and being able to capture 60FPS without problems, even if the entire rest of the hardware is identical.
This might be a problem too:
"The SecuROM content protection system has also caused reported problems with running systems software such as Microsoft's Process Explorer and other games that use similar content protection systems. Microsoft's RootkitRevealer software tool also identifies SecuROM as a rootkit due to insertion of null keys into the registry that cannot be removed via normal means such as Registry Editor. These registry keys remain on the system even after BioShock and SecuROM are uninstalled. SecuROM currently provides no support for completely uninstalling the application.
The Bioshock demo also installs Securom DRM management software. The Securom software remains on the end users system with no option for
uninstallation, even if the demo itself is uninstalled."
So basically there are four possible opinion on publishing this run:
1) Definitely not. It contains glaring errors and sloppy playing which amount to considerable time which could be optimized (several minutes probably?). The fact that it's faster than the currently-published run is irrelevant.
2) Definitely yes. It's not only faster than the currently-published run, but it's a lot faster (something like 40 minutes). Even if it contains mistakes it still represents the state-of-art of TASin this game because we don't have anything better and nothing better will be ready in the near future (probably many months).
3) Yes, it might not be optimal, but we could still publish it as a temporary update to this game TAS, especially since no improvement is coming in the near future. Many people are interested in seeing this and it will most probably be very popular.
4) What do you mean? This submission *is* better than the currently-published run and thus should be published. The currently-published run has mistakes too (even if they are because the author didn't know back then about all the tricks).
In short: 1) We aim for perfection, 2) we aim for fastest time, 3) we aim to entertain people, 4) this submission simply *is* better than the old one.
Minimum requirements: "DirectX 9.0c compliant card with 128 MB RAM (NVIDIA 6600/ATI X1300 or better, excluding ATI X1550), *must support Pixel Shader 3.0*"
So that's a no for me, then.
Lastly, please never use "argumentation" again. The word is argument.
Shouldn't you say something like 'btw, it's not "argumentation", the correct word is "argument"'? The way you worded that sentence makes it sound like you were offended by me using the wrong word.
I guess the thing I've been protesting is the notion that a run being suboptimal would somehow automatically place it in the rejection bin.
Perhaps you meant that, but your posts made it sounds like you wanted submissions to be automatically accepted if they were considerably faster than the existing publication regardless of how suboptimal (according to current knowledge) they are.
Think about this: If this was the very first OoT submission (ie. the currently-published one didn't exist) and you knew all the flaws explained in this thread, would you still vote yes? I think "beats previous published movie" should in no way be an argument pro publication. The main affecting factor should be "is this close to optimal, as far as we can see?", "could it be done considerably better?"
Instead, what I feel is the right approach is to compare run A to run B, then decide which one you like best (=is better), and publish that one.
I understand the point "if we don't publish this and keep the old one, we are saying that the old one is better than this one". However, personally I think that the old one should be obsoleted with a near-perfect improvement, not a half-assed one which just relies on a newly-discovered trick to get a considerably faster playthrough.
Overall I'm going to guess this run is better than Guano's, hence it should be published imo.
I haven't seen this run nor studied the problems and virtues of both runs in detail, but from what I have read in this thread it seems that this submission suffers from sloppy play at places, and relies only on a newly-found trick to get the faster time, while the currently published run tries to avoid sloppy play (but is slower because the author didn't know about all the tricks at the time).
The point is we'd be publishing something we know can easily be beaten and optimized. Goes against what the site is here for, does it not? Aiming for perfection I mean. With more time and care spent the run could be much more impressive.
Then you'd have to introduce arbitrary slippery slope arguments which just opens up a can of worms. Most submissions have known improvements in them, some signficant, some not so significant
moozooh wrote:
I think the point isn't that it can be improved, but the fact that it can be improved by a lot, and that the unoptimized parts are clearly visible.
Fabian wrote:
slippery slope arbitrary bla bla
I'm sorry, but your argument above doesn't make too much sense. You are arguing that this kind of thinking will introduce slippery-slope type of argumentation. However, quite ironically, it's *you* who is making a slippery-slope argument here.
Basically you are saying that since movies with known minor improvements have been published, then *any* movie (faster than the previous publication) should be published regardless of how large the known improvements are. That's exactly slippery-slope argumentation, something you wanted to avoid in the first place.
You have to understand that there's a difference between very minor, probable improvements, and major blatant deficiencies. It's a completely different thing saying "it might be possible to save a few frames at this point if I had done this instead of that" than saying "the unoptimization was glaringly obvious, you could have made it significantly faster".
Sure, the line between the two things is extremely fuzzy and very subject to debate, and nobody admits this more than me, but just because the line is fuzzy doesn't mean that the *extremes* are fuzzy too. One extreme is "probably a few frames could be improved" and the other is "this is clearly suboptimal". I don't think there's any problem in these extremes: The former is ok (unless the author cancels the submission to make the improvement) while the latter is not. Just because runs which are suboptimal by few frames are published doesn't mean that we should start publishing runs which are suboptimal by minutes. Heck, as far as I know, submissions with much less suboptimality have been rejected.
Publishing the currently-published OoT run was dubious at best, and it got some heavy critique from being suboptimal. Do we really want to repeat this mistake? People expect us to publish runs which are close to perfection. If we start publishing runs with glaringly obvious suboptimalities, that's not going to do any good for those expectations. If we publish, we will simply be saying "we don't aim for perfection, it's ok to publish any run which is faster than the previous". The latter type of thinking is ok for regular speedruns because there indeed the only thing that matter is who can complete the game faster. However, TAS publication is not a competition. We are not competing on who can make the faster run. We are trying to achieve near perfection (as close as we can get to it).
Sure, sometimes suboptimal runs are published (for whatever reason), but that doesn't mean we should not aim for perfection.
