Yeah, its slower than the qsort provided because it tries to hard to avoid worst case scenario.
std::sort() from the C++ standard library is, at least in gcc, pretty fast. Faster than anything I have came up with (yes, it's faster than quicksort-only-partitions-bigger-than-n-items-and-run-insertion-sort-to-the-rest, even if the quicksort part is done with a median-of-three pivot choice which is one of the fastest). Of course it's a generic algorithm, so a specialized algorithm which takes advantage of some certain property of the data can be made faster for that particular data.
Because the copyright holders don't care. But even if the holders don't care, it doesn't make distributing said material legal. You could get sued with copyright infringement, but most likely the company that hosts this page gets a mail from a legal firm asking to the page be shut down.
The videos already infringe copyright, but so far no-one seems to care. (Which copyright, you might ask? Music, of course. The music of the games is copyrighted like any other music. Being played by a game console doesn't make it any less copyrighted. Also the question whether the graphics of a game are copyrighted is an interesting one...)
But anyways, the solution which would give best graphical quality (ie. the original non-lossy graphics of the original game) with the smallest possible file size would be to make a specific video codec. The video file would contain all the sprites and tiles of the original game (perhaps packed with zlib or whatever) and the video file would be basically just screen coordinates and timings to show these graphics.
Or course implementing this idea is far from trivial, even though the idea itself is simple. The emulator would have to be modified so that it can output the graphics of the game and their positions at each frame, and the codec itself would have to be programmed, naturally. This is in no way an easy task.
I'm totally amazed that those "discussions" still go on... (or rather, stomp still)
Many people are willing to see tampering and fakery in the video (and I'm talking here about claims that the video has been literally faked with image manipulation and video programs, not that it just has been created with an emulator instead of having been played like the real thing in realtime) and many people are eager to believe that in the same way as they are willing to believe any cheap conspiracy theory out there, and this regardless of hard proof of the contrary.
It all is a question of laziness. Anyone could take the emulator, see how the replaying works (by eg. studying the fmv file format), take the unmodified original game rom and then replay the fmv and see that there's no fakery: It really is the original game being played genuinely (in the sense that the emulator is only reading key presses from the file but otherwise emulating the game exactly as it should). However, this is of course too much trouble for most doubters to do, even if they are told they can do it. They will just be too lazy to actually check the proof and dismiss it as irrelevant.
This is how all conspiracy theories and hoax claims work: Make claims that sound believable to people who don't know how the thing works and hope that nobody will actually check the facts for themselves. Just look at the moon hoax theories: People are willing to believe the most ridiculous "signs of fakery" in photographs without actually verifying any of them (or even wanting to think logically about it, which all by itself would dismiss more than half of the "proofs" of image tampering).
It is simply that no one has had the good idea to pit a computer against another computer, have them play "suboptimal" moves at random, and anaylze the win-loss patterns over several thousand games to learn their own strategies.
One idea which has been brought is to a chess or go program which uses a neural net (for some games neural nets are incredibly powerful; for example, if I remember correctly, a program using a surprisingly small neural net can easily beat the best players in the world at backgammon) and put this program to play against itself. Before each game some change is made to the neural net (random change or whatever) and an evolution algorithm is used to select and combine best neural nets found this way. In theory if the program plays millions of games this way, it will come up with a neural net which is extremely strong at the game.
However, if it worked, it would certainly had been made already, so one has to conclude that at least for chess and go it doesn't work.
Entirely untrue. Deep Blue could think 5 billion positions in 5 minutes but lost to Garry Kasparov who thought 10 positions in 5 minutes. Reti, who was once one of the strongest players in the world, thought in general, no more than 2 moves ahead. Computers are horrible chess players, that is why they have to think so many moves ahead just to compete with the world's strongest.
I did say that small-scale strategies can be found in chess as well. This is, naturally, the reason why the strongest human players can compete almost equally with the strongest computer programs even though humans can't read as far as the programs.
However, go is different from chess in that this kind of brute-force approach made by computer programs is not enough. For a chess program it's enough to code some basic principles on how to evaluate the position and then implement some minimax or other similar bruteforce algorithm to search moves forward. In go, however, this is not enough at all.
That is one of the main differences between chess and go, with regard to computing: In chess it's moderately easy to evaluate the value of a position, while in go it's extremely difficult. Humans are strong at go because they have developed something which could be called intuition (something along the lines of "if I make a strong shape here facing that part of the board, it may help the fight that could ensue there; I have yet no idea how the fight will develop there or even if there will be a fight at all, but it doesn't hurt"). This kind of "intuition" (which is based heavily on experience) is quite hard to convert to an algorithm.
And it's not just about board size. Even at smaller board sizes, such as 9x9, in which complexity is approximately equal to chess, computers are weak. Although brute force is more helpful with this size, it's somehow still not enough. It's still very difficult to come up with an algorithm to estimate the value of a position. The regular 19x19 board is a whole different world in itself, where the strategical consequences explode compared to the small board, making it even more difficult to come up with a decent evaluation algorithm.
Yes, of course a human can sometimes beat a computer in chess if he can find some strategic innovation in that specific game which fools the program. However, this happens only now and then, most often not. In go strong human players beat computers in a regular basis just because they are stronger at strategy. It's not like humans were struggling to beat the computer and succeed in it sometimes through hard work; they don't even break a sweat.
I personally prefer Go to chess. For a good article about go, see wikipedia's go page.
I'm not saying that chess is bad or boring. It's just that Go, once you get to see all of its strategical depth, is so much more interesting.
Chess is all about hard thinking work and basically nothing else: It's reading, reading and more reading moves ahead, on each move. Naturally there are certain principles and small-scale strategical heuristics which can be applied, but basically it's just more or less mechanical reading moves ahead. This is the reason why computers are so good at chess.
In go you do also need to often read tons of moves ahead, and go does not lose in any way to chess in tactical complexity, specially at certain local life&death situations.
However, what IMO makes go more interesting than chess is that it's strategically much deeper. While chess is basically just a big local fight, go has also much more large-scale strategy concepts. In go it's not enough to just read, read and read moves ahead, but you need to know much more high-level whole-board strategical concepts if you want to be any good. One good example of this is that moves made in one end of the board may have surprisingly strong effect in a seemingly independent other end of the board a hundred moves later. If you were able to foresee a fight in that other end of the board and you made preparatory shapes and took key points in the other end, you may be able to use them for your advantage. This is the reason why computers are so weak at go. In chess there may be some smaller versions of this, but they pale in comparison.
From the minimal amount of "votes" on this subject and in general the amount of discussion I assume we will not see the run without using the glitch... *sigh* A pitty. It would be so much better without it (and faster too).
Do you know Mr.Morimoto?
His record of SMB3 has benn already beaten by Mr.Genisto.
Do you think why?The answer is easy. Mr.Morimoto's record is slower than Mr.Genisto's record.(of cource, and more entertainment;).Please don't forget, you(or anyone) can't guarantee anything,about my movie.
I don't think Genisto's version of the movie is less entertaining than Morimoto's. In my opinion Genisto achieved the same level of entertainment but also succeeded in making the run faster. It's not like he sacrificed entertainment for speed.
But I wonder why you can believe so. >Extremely confusing~
If you use the murder beam glitch in the final boss it's very difficult to understand what is going on, and the whole battle is very confusing. Someone who hasn't seen the normal battle has no way of knowing what is happening. Also, the graphics engine of SNES bugs when the glitch is used, making it even more confusing and ugly.
When I submited this movie, nobody asked me about "murder-beam". And most people voted 'YES'.
I assumed, and I'm sure most of the other people also assumed that the murder-beam glitch saves so much time that it's simply the only option. Thus it's natural that nobody questioned it. However, given that it doesn't really save any time at all and it's so ugly, I have completely changed my opinion on it (and I suppose some others have too).
I'm not saying it should have not been published. I'm saying that I would so much prefer if the glitch was not used.
In SuperMetroid, I happened to meet trouble.
>being fast while doing the toughest and unexpected things
'Using Murderbeam' is fastest.
'Not Using Murderbeam' is not fastest.
But many people said "Not using 'Murderbeam' is good."
So, I was confused "Which is the one, I must take precedence?"
I think that in this case you need a sense of proportion.
I believe that everyone agrees that an optimally played regular battle against the final boss (ie. not using the murder beam glitch) is immensely more entertaining than using the extremely confusing and ugly glitch. While it is of course subjective, I don't think it would be an exaggeration to say that it's at least 100 times more entertaining (with whatever subjective measure you want to use).
And how much does the glitch save in this 40+ mins movie? 1 single second.
I really believe we can sacrifice that 1 second to make the final battle 100 times more entertaining.
This is not the case in most movies. This situation is actually quite rare. I honestly believe we can make an exception with this one for the sake of entertainment.
If I take precedence "entertainment", I don't need to remove "HiJumpboots",2times.
It's not about "speed should take precedence at all costs, regardless of the means" or "entertainment should take precedence at all costs, even if it means making a slower movie". You should not think so radically.
The main goal of these movies is, of course, completing the game as fast as possible. Usually this means that the resulting movie is very entertaining.
However, this is not an all-or-nothing rule. There are certain situations where small compromises can and should be made to make the movie more entertaining even if it means that it will be one second slower. Sometimes you should find a compromise.
In many games where the sole fact that you complete it as fast as possible produces all by itself a very entertaining movie. And in fact, supermetroid is for the most part such game. However, I would say the final boss battle is an exception: Using the murder beam glitch for getting a 1 second faster run literally spoils the run, which had been quite excellent so far: It makes it extremely confusing and plain ugly.
In a 40+ mins movie 1 second is nothing. If compromising 1 second makes the end battle 100 times more entertaining, I would definitely say that you should go for the regular battle.
In no way this means you should start compromising anywhere else. As I said, it's not a question of "only entertainment" or "only speed". However, in this specific single situation sacrificing 1 second for a battle which is 100 times more entertaining is definitely worth the price.
At position 11:47 of this movie the hero jumps twice. As I understand it, it's not possible to jump in this game, which would make the single most impressive manouver in this video.
How was the jumping done?
So, who votes "yes" for replacing the current Super Metroid movie with the one where murder-beam is not used (linked in some previous post in this thread)?
However, If I didn't use that 'Bug', (perhaps)some people will say to me 'Why did you not use murder-beam?'
So, I had a only one-way. I must use it, then.
How about a poll? How many would like the movie to not to use the the final battle bug and how many think it should definitely be used?
By the way, how much does the bug really save time compared to an optimal regular fight against the final boss? If we are talking about a few seconds, I definitely see no reason to use the bug. After all, making good and entertaining videos has pretty high priority, sometimes even at the cost of being some seconds slower.
If, however, we are talking about something like 1 minute, then I suppose it can't be helped.
Personally I find it a really big bummer that the final-boss-bug exists in this game. It would be so much better if this bug didn't exist at all.
The bug is in one word, to be honest, ugly. It makes the snes graphics engine to bug (the leg of the monster blinks and is almost constantly not drawn) and makes the whole end battle extremely confusing. For someone who has never seen the end battle played the normal way (as in the 14% version of this video) it's very hard to understand what's going on. It also makes the video to miss an important story in the game (the friendly alien helping). The bug isn't even cool, it's just plain ugly and confusing.
What makes it a really big bummer is that since it exists, it just has to be used. It wouldn't really make much sense to not to use it because the goal is to complete the game as fast as possible. It's a shame.
I would so much prefer that this bug didn't exist at all. The video would be a lot nicer to watch with the proper final battle. In this regard the 14% version of this run was very welcome because the bug was not used (I suppose because it was not possible).
I personally would certainly not complain if in this video the end was changed to have the "regular" end battle (as optimally as possible).
Apparently length is only part of the problem: Each controller which snes9x emulates increases the size of each frame of the movie record. That is, disabling unneeded controllers makes the record smaller and thus it doesn't take as much space and can be longer.
Super Metroid and MegaMan X have probably been recorded with less controllers (probably one?). I had for some reason all five controllers configured and thus the movie record took five times as much space as with a single controller.
So this seems to be a good hint: Turn off all unneeded controllers. It will allow making longer movie records
I am having a weird problem with the snapshots.
I'm making a video of gradius3 and everything went just fine until approximately minute 27 (where I'm stuck now). My re-record count is currently 1080 (much higher re-record counts have been seen in snes videos, so it can't be a problem of having too many of them).
Anyways, the problem is that now suddenly quicksaves don't work. Whenever I try to make a quicksave and then quickload it, it says "snapshot not from this movie".
Old quicksaves (from before approx. minute 27) work fine, but any newer quicksave I make does not work, no matter where I take it from (even right at the beginning of the movie).
The quicksaves work when playing normally the game, but they don't work with the movie.
The smv file plays just fine up to the point where I got stuck, and I could probably continue it if I used an old quicksave (redoing the tens of seconds made after the last working quicksave), but I can't undo anymore because every new quicksave I make and try to load just causes the "snapshot not from this movie" error, so I'm basically stuck.
This happened during the original recording of the movie, and it happens when I play the movie and make quicksaves during it (and then try to continue recording by quickloading).
I don't understand what's going on, but it would be nice if I could get this working. I have spent at least 20 hours total making this movie and it has been extremely laborious, and I wouldn't want all that go to waste...
Any ideas?
Could someone please lock this thread (or delete it completely) and ban that troll?
The videos are not illegitimate: They do exactly what they promise.
The videos are not a hoax: A hoax is an attempt to deceive people by lying to them and trying to make them believe something that is not true. These videos are not trying to lie: They are genuine tool-assisted speedruns which do not show anything that couldn't be achieved in the real game in theory.
The videos do not need a nag-screen. If someone is unable to understand what a tool-assisted speedrun is, that's their problem. And if speedrunners don't like tool-assisted speedruns, that's their problem as well. Screw them.
Illegitimate hoax? Isn't that like a double-negative?
True. Technically it is saying "this is not a fake".
I have a counter-proposal: In speedrun videos where no aiding tools were used, add the following disclaimer as a 10-seconds screen at the beginning of the video:
"Warning: This is an imperfect run of the game. It's full of mistakes and the game could be completed much faster than this."
All I'm saying is that you'll never please everyone, so you might as well call the movies whatever the frick you want.
I don't agree.
If we call them "tool-assisted" and someone complains that they are "fake", we can always say "we said it was tool-assisted, didn't we? What are you complaining about?". However, "timeattack" doesn't tell anything. It's not descriptive and can be considered fraudulent. "Tool assisted" is a descriptive and honest term. It's also a term which has existed earlier for this exact purpose.
I personally will not use the term "timeattack" anymore. I will be using "TAS" instead.
I prefer tool-assisted speedrun instead of timeattack. The former is an already-used term for the exact thing we are doing and is a whole lot more descriptive than the latter.
