Could we please stop using the term time-attack at last?
A tool-assisted speedrun is not a time-attack. Just look at http://en.wikipedia.org/wiki/Time_attack to see what a time attack is. It's different from a tool-assisted speedrun.
I don't know who first started using this term, perhaps Morimoto himself, but it's just wrong.
EDIT: This timeattack/speedrun discussion should be continued at this thread: http://tasvideos.org/forum/t/2349
Does anyone know if there are any good rerecording spectrum emulators in existence?
Spectrum (128) was the computer I played with as a kid, so if there was such an emulator I would make some tool-assisted speedruns with it right away.
Many games didn't have really fancy graphics (many of them were just monochrome) but there are some games which are pretty good even graphically.
but take a look at Super Metroid as well. Things like the Murder Beam and the Mockball are cleanly glitches that can be used. And while it does not so spectacularely shorten the movies time, it is very interesting to see the glitches especially when one had played the game back in the time.
In my opinion if supermetroid is nominated it's not because of the murder beam glitch. Glitches should be entertaining, surprising and fun to watch. The murder beam glitch is nothing of those, it completely ruins the watching experience and it doesn't even speed up the run at all.
To give an analogy, imagine that someone discovers a glitch in a game that garbles most of the graphics and sounds of a level but does not help making a faster run. Why would anyone want to use such a glitch? It ruins the watching experience for no good reason.
Well, the murder beam glitch is exactly that.
I would nominate it as the most horrendous and useless glitch ever.
What does "unbelievable" mean in this case?
Does it mean "if you don't know that it is tool-assisted, the movie which would cause greatest disbelief"? I hardly find that as a good category.
Why do I suggest that? Because, come on, supermariobros3? Yes, if you don't know it is tool-assisted then it looks like superhuman crazy-skills, but we know better, don't we? It's a cool movie, but hardly "unbelievable" by TAS-runner standards. Yes, it caused tons of confusion and the whole "these movies are fake" wave begun with this morimoto movie. But is that really an award category?
So, what does "most unbelievable" mean?
Why is this movie encoded with a completely different codec than all the other 200+ movies here? Why does it have to use a weird codec which the average people do not have? What was the problem in using XviD or DivX like everyone else? Why force people to download an obscure codec for one single video (specially since some versions of that codec demonstrably cause crashing and other problems)?
I'm really not in the mood of downloading some odd codec for this one single movie. I really hope this will get re-encoded like all the other movies here.
uuuuuuuuuuuh!!!!.
this is the worst dragon warrior of all the time. 1, 2 and 3 are wonderful, but this is baaaad ):.
belleive me.
I have played DW2, 3 and 4 through, and in my opinion DW4 was the best of all those (DW3 being a good second).
So no, don't believe that. Play the game and decide yourself. I loved it. It's incredible how some 3-color sprites can make you sentimental at times... (something the previous two DWs didn't achieve).
To beat this dead horse some more: they don't like the term 'timeattack' because they think it is their term (even though I have yet to see a site use the term timeattack to mean speedrun, aside from morimoto's site). For now, the preferred nomenclature for emulated timeattacks are "tool assisted movies", "emulator movies", or "quarkers".
The standard term in the speedrunning community for what we are doing is tool-assisted speedrun. This is a common term. Just see for example http://www.doomworld.com/tas/main.shtml
Tool-assisted speedruns of games like Doom are quite common, as we can see from that site. It gives an example of how TASs are a normal variety of speedrunning. Do you see anyone shouting "fake!" there?
Could we finally please stop using the term "timeattack"? I don't know where this term comes from (did Morimoto use it for the first time in this context?) but it's just not accurate enough. I know that "tool-assisted speedrun" is longer, but it is more accurate and, most importantly, a standard term.
As I said, you should perhaps try some other language than C++. If you want to do something non-standard (such as graphics), there will be dozens of different ways to do that, most of which will completely depend on which compiler you are using. Specially in Windows there are myriads of different compilers, most of them commercial and in most of them getting graphics on screen is just plain complicated.
Which C++ compiler do you even have, by the way?
By the way, if you really, really, REALLY want to code something graphical with C++, try googling for "qt tutorial". I have never used qt myself, but from what I have heard it should be one of the easiest to use graphical libraries (which I suppose means that it's only very hard to use instead of extremely hard as all the others).
Edit 5: The best way to find such an example might actually be downloading the source code of some software that really interests you, and studying it. Just don't choose something too big.
This is actually how I have learned. The first big'n difficult subject was Microsoft Nibbles (made with QuickBASIC).
Actually IMO that's one of the worst ways. Source code is not a beginner's tutorial and there will be no-one explaining you what all those things are doing and why, and you will be learning all kinds of bad habits due to misunderstandings and misconceptions. Worse yet, the code might be crappy because the programmer was inept, and if that is the case you will be learning doubly-bad habits. The other extreme might also be bad: If the programmer was an expert, he may be using fancy tricks which other experts understand right away but which confuse the beginner completely and who might start copying things he doesn't understand how or why they work.
Beginners need a tutorial. Do you think an architect learns to design buildings by simply watching buildings? Watching buildings is important, of course, but learning should not be based on that (it should only be a secondary aid to the studying).
Yeah! Makeing a small nibbles game would be of great fun!
To learn how to use keyboard/mouse inputs etc.
Paint beutiful 16 colors of joy! :D
Implant music in my program.
Then you should use something else than C++. Perhaps VisualBasic or Python. If you can find something to make Flash applications, you could try that. Java might be a bit too complicated.
C++ has no standard ways of, for example, drawing graphics because portability is one of its main issues. Whichever way you manage to get graphics on screen with C++ it will be non-standard and non-portable (and in most cases more difficult than it should be because, for whatever reason, perhaps complete incompetence of the authors of the libraries, most C++ graphics libraries out there are extremely hard to use).
Yaya this is true, proofs are not my thing. My original statement was something like "... but on average it will finish in a finite amount of time."
Since there exists an infinite amount of sequences which do not contain the desired subsequence, it is possible that the generator will go through all those other sequences before going through one which does contain the desired subsequence (but since there's an infinite amount of other sequences it may never happen).
How do you calculate an average if some of the times are infinite?-)
Also like you say truly random number generation is a problem because it is theoretically impossible
One has to also define which kind of randomness we want. A sequence may be truely random, but its distribution might not be even.
Someone has said something along the lines of "if a million monkeys hammer on a million typewriters for a million years, they will at some point write the entire works of Shakespeare" (different versions of this circulate with varying amounts of monkeys and time). This is a wrong statement. The statement implies that they will eventually reach a certain given sequence (eg. the works of Shakespeare). That is just wrong. They might reach that sequence, but there's nothing which guarantees that. In fact, I would say it's extremely improbable.
Firstly, using monkeys is a very bad choice. A monkey hitting a typewriter will have an extremely uneven distribution. It's extremely improbable that all possible sequences of keys are ever typed. Most likely very regular patterns will be typed, and those will never end up in such a large sequence as the works of Shakespeare.
Secondly, even if instead of monkeys some truely evenly-distributed random generator was used, it still doesn't guarantee that the sequence will be reached in a finite time. In fact, it doesn't even guarantee that the sequence will be reached in an infinite time (because there's an infinite amount of sequences not containing the wanted subsequence and thus it is possible that all those are gone through before a correct sequence is reached).
but you can always write one that is random for a desired number of times before repeating, the one I provided in the code for that algorithm repeated something like every 10^17 numbers.
That is still only a pseudorandom generator. The reason is that it is completely predictable: Knowing the algorithm you will know what will be the next random number generated. That is certainly not randomness... :)
It looks random for the casual viewer, but isn't. :)
Lastly, the randomness is teh_stupid in this game and I'm not really sure what triggers items to drop. It is however not possible to manipulate something small and exchange a health potion for a star.
Tell me about that! In one of my runs I definitely wanted to change a bottle to a star and I had to remake two entire levels for that to happen. No smaller amount of change seemed to have any effect. It almost feels like the makers coded an extremely-hard-to-affect random number generator just to make the life of tas-runners more difficult.
Also it seems that you can't affect too much the frequency of the item drops. It's probably something like "10+rand(5) kills until next drop" or similar.
One has to also take into account that most people who watch these movies have never played the games. If the thing being skipped with a reset (or other type of trick) is so relevant from the game story point of view that skipping it will make the viewer confused because he doesn't understand what the heck is happening, one should seriously consider not using the trick.
Granted, the vast majority of intros and middle animations are irrelevant and don't really add anything to the watching experience, but there are exceptions, of course. A perfect example of this is the murder beam glitch in supermetroid (which effectively skips the final boss battle, although not in duration but in action, which is even worse).
I think that would be a good idea only if it really makes an interesting video. Otherwise it feels just too artificial. A limitation should not make the video boring, but on the contrary interesting.
Actually I think the idea in this video is not bad at all, even though it was made as a joke. I downloaded it when it was available and I actually enjoyed it.
I was wondering: Would be a crazy idea to create some type of "fun section" or whatever in the site where other types of interesting or funny videos are published, such as this one? They don't necessarily have to be complete runs through games, but something funny or interesting. But of course complete runs using some type of limitation (such as no running here) could sometimes be cool, specially if that limitation introduces extreme difficulties in completing the game.
Well I originally stopped using C++ a few years ago because I preformed some efficiency test and C++ was slower.
I hope you realize how silly that sounds... :)
Since you can do exactly the same thing in C++ which you can do in C, it's just impossible to claim that C++ is slower than C (at least not if the compiler is doing the same thing for both). Whichever speed test you are making in C, you can just compile the exact same code (assuming you are not using reserved C++ keywords, but that's irrelevant) as C++ and the result should be equally fast. There's nothing in C which could not be replicated exactly in C++ (usually with the exact same code).
Now, C++ adds some libraries not available in C (even though it still offers the same ones as in C). While some of these libraries can be used for the same tasks as their C equivalents, they usually are still different libraries with different capabilities and features. If your speed comparison is based on comparing the old C libraries with new C++ libraries providing similar functionality, then if and when you get a speed difference, making a general claim that one language is slower than the other is just misguided and wrong. One could say you are comparing apples with oranges. The fact that C++ offers some new libraries doesn't make C++ slower than C. It just makes C++ to offer new libraries.
For instance, C streams are usually faster than C++ streams. While the latter can be used for the same purposes as the former, they can be used for more, and there are technical reasons why they can't achieve the same speeds (or at least it's quite difficult). However, that doesn't make "C++ slower than C", it just makes "C++ streams slower than C streams". And nothing stops you from using C streams in a C++ program (even though if you do so, you have to be aware of some OOP limitations they impose).
C coders often have wrong prejudices about C++ simply because they don't know how it works internally. When things are done right, C++ code can be much cleaner, easier to use, easier to understand and safer than equivalent C code, usually with no penalty in speed whatsoever (in fact, in some cases the C++ version can even be slightly faster). However, C coders are sometimes intimidated by the pretty interfaces the C++ standard libraries offer because they don't know what they are doing internally and they form all kinds of wrong assumptions.
Personally I love C for tiny projects, I completely detest it for larger projects, I love C++ for most projects, and I hate Java for all projects (even though if I had to choose between C and Java for a large project, I would go for Java... or kill myself, whichever causes less pain).
Guys, drop the re-record feature. I know it is the better option but it is too late. I've put in way too much time and I'm not going to start over again. My schedule is getting increasingly busy and I'm doing my best just to finish this thing. Sorry :O( As for editing the avi, I'll again say just wait and see what I do with this. I know editing like the back of my hand. There is a large audience here who really wants the feel of the original game to be intact but I feel there is a larger audience out there who would appreciate what I'm doing more. I'm also strapped for hard drive space and honestly don't think I can hold 2+ hours of HQ avi on my two drives. If I didn't edit out all the waiting in this game I'd have to make quality sacrifices.
I think that the problem with what you are doing is that this is the wrong site for it. You are making something completely different than what this site is about.
The movies in this site have certain principles. One of the strongest principles is that videos (ie. the avi files) are genuine unedited screen captures of what the emulator is showing (except for the few textual warnings at the beginning of each video). That is, the videos show that "this game can theoretically be played like this in an original game console if we assume a human would have superhuman reflexes and could see into the future". In other words, these are tool-assisted speedruns.
What you are trying to do is basically a music video, not a tool-assisted speedrun. Take some cool shots of the game, piece them together, replace the audio track with a cool piece of music and presto, we have a nice music video based on a computer game.
That may be nice, but it's not what this site is about.
You can't blame people for not liking this idea at all. It's basically an affront to all that this site is about. It does exactly what this site is trying so hard to prove wrong: That we are not editing the videos and that they are genuine tool-assisted runs.
It's not about "waiting to see how it turns out". It doesn't matter how it looks. What matters is that it's against the fundamental principles of tool-assisted runs.
Please, no murder beam. It SUCKS. BIG. FREAKING. TIME.
It also makes the run slower, so if nothing else, that alone should be a reason to not to use it.
