Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I really don't like this "The improvement is too small, so I vote no" argument. You effectively have two movies competing for being displayed on the site: The existing movie (movie A), and the new candiate (movie B). I think one should judge these on their own merits, and not give movie A any extra credit just because it happens to be published. Saying that one shouldn't publish movie B because it improved on movie A, but not enough, is the same as saying that you think visitors to the site should see a slightly inferior one, instead of the current record.
If the publishing process has become so cumbersome that one rejects an improvement because it would be too much of a bother to publish it, then something needs to be done with it.
As for the entertainment argument, I more sympathetic to that, but I still think that speed should be the primary goal, since having entertainment as the primary goal makes things very subjective and unpredictable. If a faster movie is submitted, then the default should be to accept it, and only clearly inferior theatrics should change that. On the other hand, I think it should be possible to submit a movie with *ties* with the current movie, and then have them compete solely on entertainment value.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
kuja killer wrote:
I tried doing a test just to find megaman's HP. And it was a failure. I started with a "unknown" search for anything, and get 200 million results, i go to this one spot in chill man and take 3 damage from the sheild guy every time, and refine the search on the memory viewer thing with just "decreased since last search", (i didn't do the Less Than option, i didn't try it out just yet) about 8 times or so until i got down to less than 10 results. All of them show the very exact same value changing at all times nonstop. with negative 20,000-something hex. But there was only one address with negative 40 hex. So i added that to the other side of the window, freeze the address, get hit by the enemy again, but it didn't work. And i KNOW these other duplicate addresse's dont affect it either.
I haven't tried using MHS before, but I have some comments on your search procedure:
It seems like you searched for a long value. Mega man's health is probably a single byte. If you search for anything longer, you will be contaminated by neighboring addresses, and may wrongly exclude the right address when searching.
You ended up with a value that was changing nonstop? When searching for something like health, you should also do a few searches for when the value should be unchanged from the previous time. That will get rid of all the rapidly changing addresses.
You may also need to do the search twice, once for unsigned and once for signed values, since you don't know how the health is represented in memory.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Most emulators do not support rerecording (the ability to use savestates while recording a movie), and are also not made with the frequent use of savestates and movie playback in mind. This means that the normal versions of many emulators are not suitable for making tool-assisted speedruns. We therefore use special rerecording versions of the emulators. The list of the recommended TASing emulators can be found here: http://tasvideos.org/EmulatorResources.html
If you look at the snes9x section, you will see that there are two rerecording branches of snes9x: 1.43-rr and 1.51-rr (oh, seems there is 1.52-rr too). Notice the -rr part there. That is for rerecording. You should get the most recent emulator from each of the 1.43-rr and 1.5x-rr branches. You need both, since movies made with one of these is not compatible with the other.
In case you can't find it from the emulator resources page, this is the download page for snes9x-rr: http://code.google.com/p/snes9x-rr/downloads/list?can=2&q=&sort=uploaded&colspec=Filename%20Summary%20Uploaded%20ReleaseDate%20Size%20DownloadCount
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
WillDaBeast wrote:
Kirkq wrote:
MUGG wrote:
what about Mario Land 2
I think that the new run will either be published in its own category or not published at all.
It's own category? There's already like 5 different SMW runs on this site, if you include SDW/VIPs or other hack TASes of the nature.
Yes? Are you afraid that we will run out of categories? They aren't a limited resource. This would be significantly different from any of the existing SMW runs, and I think a new category is the obviously correct way of handling it.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Perhaps external references are off topic in this thread, but the gravitational field of a torus is discussed here: http://www.mathpages.com/home/kmath402/kmath402.htm
I recommend these math pages for interesting discussions on other topics in math and physics too.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Thanks for a short, fast and entertaining run, Saturn! Though this makes use of a debug code, I don't see a problem with allowing that as a separate category, since the end result was interesting. A few questions:
* Was it faster to only use one bomb on the wall in the room to the left of the ship?
* Is the plasma + X-ray techinque used here different from the normal version of the glitch, or does it just benefit that much from frame-precise control?
* What exactly triggers the stand-up glitch? Normally it doesn't work if you wear varia, right? Or is the mechanism instead that it is triggered if you have >= 100 energy left, but not enough to survive another attack, which is why it is easier to trigger without varia?
* Would you please submit your Super Metroid Redesign run, too?
I don't understand why people think a game can have too many categories. If you think it will be too confusing with many, just give a few representative ones a star or a moon, so that new visitors easily find them. I don't think the number of existing categories should enter into the equation at all when judging a submission, only quality and novelty, and this run has both.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
ICheatAtGolf wrote:
Amaurea, I really wanted to use your animated ghost script for Super Metroid to practice speedrunning against one of my runs. I was able to get the old version to work, but this new version (requiring the Lua GD Library) is beyond my area of knowledge.
It's been a long time since I installed gd for lua, but I think I downloaded lua-gd from http://luaforge.net/frs/download.php/1592/lua-gd-2.0.33r2.tar.gz, compiled it, and installed it in /usr/lib/lua/5.1/gs.so in my area for 32-bit programs. But that was for linux, and you're most likely on windows, so your best bet is probably following Nitsuja's instructions above.
If everything should fail, I should note that only the minimap and ghost graphics require gd, and if you turn those two options off, the script will automatically not require gd. If you look at the script, you will see that the top of it is a configuration section. For running in non-gd mode, you should turn off the minimap and ghost_gfx, and turn on ghost hitboxes. But it looks much better with proper graphics, so I hope you get that working.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
neo_omegon wrote:
People here are missing a lot of TASes there, imo.
Well, I think that the problem is that we cannot directly contact many of the authors. So we can’t get a movie file when we’d like to refer them.
Another problem is language version when it comes to submitting. They make runs for Japanese audience so Japanese version is preferable there. When we suggest their submitting, friction occurs. Those who don’t know the situation easily vote no while we suggest their submitting. It’s very rude.
I think our lack of contact with the large Japnese TASing community is a problem for both sides. And a large contributor to that is the TAS language rule, which basically guarantees that most of the Japanese TASers run's won't even be considered here. The recent Secret of Mana run is a good example. How about this as a replacement rule?
TASes should as a rule be made with the original language version of a game. However, as this is a mostly English website, we also allow the USA version of the game to be used. When a new run would obsolete one in another language, the judge should compensate for version differences such as text speed when considering fitness for publication.
This rule involves some fuzzy decision-making, but then, so does the current publication process, to just about the same degree anyway. The goal of this rule is to get more Japanese TASes submitted here. Yes, that means that most of us won't be able to read the text in all the games, but I don't really think that is a big problem. Firstly, to properly understand a tas, one should be familiar enough with the game that one doesn't need to read the text, and secondly, I think we win more by getting access to a large pool of Japanese TASers than we lose by having a lower English fraction in the TASes.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
That script looks not only useful, but also stylish! Thanks for making and publishing it!
I had a look at the source code, and I have a few comments:
* There is a lot of code duplication. Generally, when you find yourself wanting to make variables with names foo1, foo2, foo3, ..., that is an indication that you really want foo to be an array instead. That way you can loop instead of repeating code.
* The weapon ammo formulas were extremely complicated! I tried rewriting them using arrays and loops, but the formulas were too different. Are you sure those memory addresses are the easiest way of getting at the ammo?
* You said that the hitboxes were approximate? In what way are they approximate? Looking at your picture, they seem to have the right size and shape, but their location seems to be a bit off. Perhaps you are adding a Y value instead of subtracting it? It looks like the hitboxes for the bats would work better if they were flipped horizontally around their top. If that is not the case, perhaps you can look around at nearby memory addresses - they might contain extra information you need to make sense of the hitboxes.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
How big an improvement to the any% should this give? It seems like you get the cape at almost no cost, and you get it 3 stages earlier than normal, after all.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Do not redo at all. Just use the trick from now on. It is not uncommon for new tricks to be discovered during the making of long runs like this, and if one had to redo every time this happens, one would just get stuck redoing all the time. Instead, finish the run, and then leave the improvements of the early parts to a v2 run later.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
amaurea wrote:
However, even though this is enormously simpler than trying to brute force the shortest input for the game, I am afraid that this still is far too heavy to be practical. Responses from many inputs are delayed - sometimes by just a few frames, but sometimes by much more - and the time needed for this operation would be O(nframe*2^(nbutton*nlookback)), where nlookback is the number of frames typically needed to see the effect of a button press.
Warp wrote:
The major problem with this is that if there are some "invisible" key presses being done in the video (which affect the RNG or whatever), the difference they make might become apparent only much later, eg. hundreds or even thousands of frames later. The more frames between the "invisible" key presses and their effect, the (exponentially) longer the algorithm would take to find it.
Isn't that just what I said? Anyway, I agree, and I think this brute-force input recreation would only be possible on the very few games where every keypress has a quick, visual response.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I just had a go at this with Super Mario World, and got stuck when pressing start at the screen where you select the number of players, since there is a delayed fade-out there. And that was when I restricted the input to only the start button too. So the naive version of this seems pretty hopeless.
A possible improvement would be first search up to X frames back for a single frame with 1 button changed, and if that doesn't work, try to search some smaller Y frames back for 2 changed buttons, and so on. If none of those work, extend the search windows and continue. That would be much more difficult to implement, but I expect it would give a huge speedup. But probably still not enough to be useful.
Oh well, it was fun to think about, at least. What I really wanted this for was to recreate the input for the Super Metroid Redesign run, since Saturn has vanished after publishing only the videos.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Going from emulator input to video is easy, but being able to go the other way would be interesting too. This would be a much simpler problem than trying to brute-force the game, since one would have a large set of video frames to compare with - one knows the input is incorrect at the first video frame mismatch. So a brute force algorithm could be something like this:
* At a given frame, systematically select a test input for this frame.
* Compare the resulting screen with the corresponding frame from the video.
* If they differ, step back and try a new input. If all combinations have been tried for the frame, step back one more frame, and so on.
* Otherwise, keep the input for now and try the next frame.
However, even though this is enormously simpler than trying to brute force the shortest input for the game, I am afraid that this still is far too heavy to be practical. Responses from many inputs are delayed - sometimes by just a few frames, but sometimes by much more - and the time needed for this operation would be O(nframe*2^(nbutton*nlookback)), where nlookback is the number of frames typically needed to see the effect of a button press.
Still, it would be fun to try with a short game with fast responses to input. Any thoughts on this?
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Masterjun wrote:
So, in the video, I started the script one frame too late, or so...because of that, you must subtract all the frames by one...
A little question, how do I do the "no room sync" like in this video: http://www.youtube.com/watch?v=GZtEqONzuwk
Well, you still haven't told me which script you're using, but assuming it is mine, then there is a configuration section at the top of smwplayer.lua. The set the variable offset_mode to "none" instead of "room" to disable the room resync. Note that as a side effect, this will disable the calculation of the numbers at the top of the screen, since these are calculated each time the runs are synced.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Masterjun wrote:
Video Description wrote:
I don't really understand the number in the top left of the video... maybe that are the frames I'm faster... BUT, how do I get 1 frame before the 1. level O_o
What script are you using to make this comparison? The output looks a lot like that of my comparison script, but that only produces a ghost for mario, not for everything else on the screen too, which seems to be the case here.
Anyway, assuming this works like my script, the number at the top shows the number of frames the ghost had to be shifted earlier in order to match up with the current run at the start of the current room. So this would be 0 if they are dead-even, positive if you are ahead of the ghost, and negative if you are behind the ghost.
A simple consistency test would be to dump a ghost for your current run too, and use that as a ghost. This ghost should then always be exactly on top of the current run, and the number on top should show 0. If this is not the case, then the script has a timing problem.
I cannot watch this video, which video codec do I need ?
Why can't you watch it? What are you trying to watch it with, and in what way doesn't it work? This seems to be normal h264 in a matroska container. If you can't watch this, you should have trouble with most of the published movies. It workes fine here in mplayer. VLC can probably handle it fine too. With these, you don't need to worry about codecs.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
mmbossman wrote:
amaurea wrote:
Here is an example: A game has been frame-warred for a long time and is thought to be very close to perfect. Then, a novice taser discovers a marvelous new strategy for a course of the game. He cannot match the input precision of the previous movie, and the stage he is trying to improve is noticably less precise than the other stages. Still, the new movie is 1 minutes faster than the previous one, with an interesting new path nobody had thought about before. Should this new movie be published? Definitely!
I can see you weren't paying attention to the discussion when JNX submitted his Ocarina of Time run. Have fun reading :)
EDIT: Bonus reading from another submission that more matches your point.
In general, just because a movie uses a massive new trick (or several) does not necessitate that it be published, if the rest of the movie looks noticeably worse than the published movie.
The rest of the movie would look the same in this case, since we were talking about copying input. Also, I do not agree N 'optimal' frames are better than N-1 poor frames. The goal isn't to have as many optimal-looking frames as possible, it is to have as few frames as possible.
I guess this is a question of whether one sees a publication as a statement of "this is the best we can do" vs. "this is the best we have so far".
But really, I think TASvideos works just fine as it is right now - no new rules regarding this is needed.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I agree with moozooh here, but I think some of what nitsuja said needs commenting on:
nitsuja wrote:
If I am capable of improving the input that I copied, I would be submitting a movie that contains sloppy input compared to what I could accomplish. Therefore I clearly shouldn't copy the input.
If I am capable of exactly matching the level of perfection of the input that I copied, then it makes sense to not duplicate the effort and simply reuse the input. But, how could I know I fall into this category without trying it first? And if I try it first then I will have no need to reuse the existing input since I will already have my own, unless mine is actually worse in which case I'm really in category 3 below and not this one. Therefore I have no reason to copy the input if I want to be as sure as I can be that I've created the movie as well as I can.
If I am not capable of even matching the level of perfection of the input that I copied, then it's likely that I'm not qualified to meet the community's standards in creating a successor to a movie of whatever game it is. Therefore I probably shouldn't make the movie at all, or I should try harder until I fit into category 1 or 2 above.
If the new movie is better than the existing one, then it doesn't matter which category you are in, it should still be published. Here is an example: A game has been frame-warred for a long time and is thought to be very close to perfect. Then, a novice taser discovers a marvelous new strategy for a course of the game. He cannot match the input precision of the previous movie, and the stage he is trying to improve is noticably less precise than the other stages. Still, the new movie is 1 minutes faster than the previous one, with an interesting new path nobody had thought about before. Should this new movie be published? Definitely!
Why insist that a movie as a whole should be the smallest possible unit of improvement? Why shouldn't one be able to quickly improve a single stage? The easier it is to make improvements, the more people will do it. As a somewhat contrived example, imagine if we only accepted movies that complete two different games here. That would definitely put off everybody who only wants to work on one of those games.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Thanks for the great run, p4wn3r! And there is no reason to apologize for improving a run - we want the TASes here to be as good as possible, after all. Besides, seeing a run gradually improve is entertaining in itself. Finally, a whopping 10% improvment is far from frame-warring, and even if it were, I'm still all in favor of seeing a frame war squeeze the TAS even closer to perfection!
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Warp wrote:
amaurea wrote:
A common smaller one is a single CPU instruction, but actually, these instructions are built up by microinstructions, so one could use these as steps too.
Only perhaps the newest consoles. Certainly not the oldest ones. Dividing opcodes into microinstructions is a modern invention. Back then there weren't even pipelines or caches, much less "microinstructions". Each machine opcode took an exact amount of clock cycles to execute, so a clock cycle is the unit of time in older processor (in way, in modern ones too, although it's a bit more complicated).
I was thinking of the SNES when writing this, and it certainly isn't one of the newest consoles. Each opcode does not take the same time to perform, and for a given opcode the time is still not constant, and depends on various processor mode flags, whether page boundaries are crossed and what the lower bytes of the direct page base address is, the memory bank being accessed, and so on.
The work done for each opcode can be broken up into several small steps, which are reused between different opcodes, and how long each of these takes and what they do are well understood and implemented with the correct timing in bsnes. Perhaps this isn't as advanced as normal microinstructions, but the point is that it makes sense to be able to perform smaller steps than one instruction. As you say, the cycle is the smallest time unit you need (when you just care about a single processor, in reality there are several ones running at different rates, so the smallest time between relevant changes for the system as a whole may be much smaller), but there are many cycles per instruction.
I couldn't find the document I used when doing SNES programming myself, but here is another one which contains some information about this:
http://www.romhacking.net/docs/%5B117%5D65816info.txt
Actually, it seems that romhacking.net uses stupid referer checking, so here is a copy: http://folk.uio.no/sigurdkn/65816info.txt
And here is a relevant excerpt:
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
ElectroSpecter wrote:
How would frame advance work in real life? There are obviously more than 60 "frames" per second in real life, but the question is, are there infinitely many? I honestly don't know the answer, as I have never studied physics in great detail.
Actually, it is not like a console executes code at a 60 fps resolution either, and one frame is not the smallest timestep it is possible to take in an emulator. A common smaller one is a single CPU instruction, but actually, these instructions are built up by microinstructions, so one could use these as steps too. Also, a console contains numerous chips running at different rates, so the smallest useful step should match those too.
But in a console, input is usually checked no more often than 60 fps, so that makes it a useful step size, as does the fact that some of the output (the video) is displayed at this rate. So my point here is that a useful step size doesn't need to be the smallest possible one.
For the real world TAS, 0.01 second would probably be more than sufficient most of the time. If I were to implement the interface, though, I would make buttons for increasing or decreasing the step size. That way one would get high resolution when needed while avoiding needles tedium in sections that don't require as much precision.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
NrgSpoon wrote:
You wouldn't be able to rewind to build up knowledge, because once you DID rewind you'd lose that knowledge.
Imagine you're a character in an RPG. You can't just grind, then go back 40 hours, and still have all your experience.
This thought experiment breaks down totally if you take that argument to its logical extreme. You wouldn't be able to manipulate luck because you wouldn't remember what approaches failed. You wouldn't be able to use slowdown, as that would just slow down your brain too. You couldn't disassemble the workings of the world, since a character in a game wouldn't know how to do that. Etc. etc. So the 'real world TAS' would just be living normally! Realistic, but not much fun to think about.
No, for this thought experiment to work, you would need to be somehow sitting outside reality, controlling a character in the real world. Not very realistic, but at least then you can actually get some interesting situations.
If the character reads a book, he would forget the contents when rewinding, just as he would lose the benefit of exercising. But depending on whether the you, the player, can see the book as he is reading (sounds reasonable that you should be able to), then you would remember it, and be able to make the character act just as if he remembered it too.
