Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Wow, that was very impressive! The quick-save system seems to make segmented runs much more efficient than with normal saves, where you have to go through loading screens etc. every time you retry. If someone had made a fully tool-assisted speedrun of portal, this is pretty much what I'd expect it to look like: Fast precision shooting, continuously flying through portals at high speed, and out of bounds glitching. I definitely didn't expect to see something of this execution in a non-assisted speedrun.
On the other hand, the quicksaves and very short segments (~10 s or so) puts this somewhat closer to tool-assisted runs than with most other games. Do you have any estimate of the number of times you attempted each stage before achieving this result? I.e. an effective rerecord count?
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Wow, thanks for the information! Here is a link to the thread on metroid2002, by the way: http://m2k2.taigaforum.com/post/glitch_topic_701.html
The glitch finder thinks this is a debug code, and not a glitch, though, and the effect seems a bit too neat to have been caused by a programming error.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
It is good to hear that the authors have started on a new run already. But what does that have to do with this run? Publish this, and then let the improved version be submitted as a new movie. This one has been stuck in the queue for long enough, and is publication worthy as it is.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Warp wrote:
Btw, I have always wondered why gamma radiation "sticks" to objects (although I think a more proper term is "contaminates"), making them radioactive as well. Whenever there's a nuclear accident, the surroundings will be highly radioactive for a long time (even decades).
But why? I thought gamma radiation is just high-frequency photons. If enough gamma radiation hits a surface, it will "contaminate" it and make it radioactive as well, thus making it emit those same high-frequency photons as well, for a rather long time. I don't really understand why. How can material that is naturally non-radioactive become radioactive?
The only mechanism for gamma radiation to make a material radioactive I can think of is photodisintegration, where the gamma ray has enough energy to knock out a nucleon (proton or neutron) from an atom. This could produce free neutrons, which are good at activating (making radioactive) materials, and what is left of the original atom will also often be unstable, and thus radioactive. Photodisintegration requires very high energy photons, so I do not think this will be the dominant factor for making i.e. reactor walls radioactive.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Warp wrote:
amaurea wrote:
The problem is that you are considering the universe from the outside, as a spectator of an expanding ball of matter, with vacuum outside. If that were the situation, the universe would indeed be inside its own event horizon. But the actual Big Bang model is about a very homogeneous gas filling everything, so there is no outside point from which to observe this.
You don't need to be "outside" the Universe (if that concept is even possible) for the problem to happen. Just take a portion of the Universe at its initial stages. The majority of the energy in the Universe was certainly within its own Schwarzschild radius even while the Universe itself was already bigger than that (even if by a small margin).
Yes, you could easily find regions inside their own Scwharzchild radius in the early universe. The problem is what that implies. It does not imply that each of these regions will quickly collapse into a point.
There are two important effects involved here: The first is gravitational acceleration. This cancels out due to the homogenity - every direction pulls as much as every other direction. The gravitational acceleration has no local effect in this case, but globally it acts to slow down the expansion.
The other effect is gravitational time dialation. The further into a gravitational field, the slower time moves. But again, this is the same for all points, so it has no effect.
Warp wrote:
Besides, I don't think you need any external observer for a mass to collapse because of reaching the critical density needed for that to happen. It's not like the external observer somehow triggers the collapse due to the observation.
Right, the observer does not trigger anything, things do not need to be observed in order to happen. There is one true space-time, but different observers slice it into space and time in different ways, due to the relativity of simultaneity. In the case of strong gravitational fields, this effect is extreme. For example, an observer far away from a black hole will observe that an infalling particle uses an infinite about of time to fall into the black hole, due to the strong time dialation. On the other hand, an infalling observer finds the same fall to take a short time. Even though they are describing the same underlying process.
Furthermore, it is possible for a region to be expanding on the inside, but contracting on the outside. Consider a sub-balloon expanding from the side of another balloon, with the sub-balloon itself growing bigger, but the contact point shrinking. Depending on the configuration, this could look like a black hole from the outside, even though it is expanding on the inside. Another example would be a house shrinking on the outside but growing larger on the inside.
The point of this digression was that even though observers don't cause things to happen, you still need to take care which observer you are making predictions for. Specifically, just like "will fall to the left" and "will fall to the right" depend on the motion of the observer, "will proceed quickly" and "will proceed slowly" also depend on the observer's position in the gravitational field, and even things like "will collapse" and "will expand" can be relative to the observer, as in the example above.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Warp wrote:
There's one thing that it's not at all clear to me about the Big Bang theory, and I can't find an answer to it.
There was a time in the beginning of the Universe when all the energy in the Universe was inside its own Schwarzschild radius. This would mean that the energy should have been incapable of escaping that radius, and instead collapsed back to a singularity (or whatever is happening inside a black hole). However, it expanded beyond this radius nevertheless. I don't understand how.
That is an interesting question, one I hadn't thought of. I will try to give a better answer than just "it comes out of solving the Einstein equation", but my physical intuition for this case isn't very good, so take it with a grain of salt.
The problem is that you are considering the universe from the outside, as a spectator of an expanding ball of matter, with vacuum outside. If that were the situation, the universe would indeed be inside its own event horizon. But the actual Big Bang model is about a very homogeneous gas filling everything, so there is no outside point from which to observe this.
Imagine that you are some observer in the very dense gas during the early phases of the big bang. You consider some spherical region somewhere, calculate its mass compared with its radius, and conclude that it would be inside a deep gravitational well. And if you let the radius be big enough, you might conclude that this region should be a black hole.
But this is wrong. You could make the same argument for any spherical region, *including the one centered on you*. I.e. you and every other point is equally deep into the gravitational field as the region you first considered.
Time moves slower the the deeper in a gravitational well you are, and near the event horizon, it moves infinitely slow relative to some point further away. But since you are just as far down in the field as every other point, your time is just as slow as theirs, and everything seems normal to you.
What would an outside observer see? Well, you can't be outside the whole universe, so let us modify the situation a bit: A huge region of the universe is filled by a hot, dense, homogeneous gas like in the Big Bang, but it is surrounded by a large area of vacuum (unlike the Big Bang). In this case, the inside observer would still see mostly the same situation unless he is near the edge. This time, an outside observer is possible, and he would indeed see the part of the universe with all the gas as being inside a black hole - no information from inside this region would be able to reach him, as long as the gas is sufficiently dense and covers a large enough area.
By the way: In the discussion above, I neglected the expansion of the universe. If you solve things properly, and take this into account, you will find that every point in the universe won't be equally far into the gravitational well as yourself after all - every observer will see himself in the center of a gravitational field which points away from him and which grows stronger with distance - it is like he is inside an inverted black hole. No matter which direction he looks in, he sees an event horizon far away. This corresponds to the point where space is expanding away from him at the speed of light. Nothing further away can reach him, as the expansion is carrying it away faster than it can approach.
I hope this helped (and that it was correct).
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Speed Man wrote:
Good news everyone!
http://www.youtube.com/watch?v=XS4zPKU6yBU
YouTube recommended me this video today. It described the X3 Glitch I remember almost perfectly. It has nothing to do with the Vile fight but it is a glitch to warp to later stages.
I still try to find confirmation for the Megaman 6 one but no luck so far.
What does that level select code have to do with the glitches you were talking about? I wouldn't call this an 'almost perfect match' with what you described.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
@Moozooh: Ouch, that was a harsh read. But rerecording support in bsnes is not very far away. Sync wise, what needs to be done is put a runtosync in a given function (byuu has already pointed out which one), and then make the savestate format contain a copy of the movie. Oh, and support for recording reset must be added. But basically, this is a relatively small task - making bsnes rerecording will be much less work than what was put into making many of our other emulators rerecording.
I can't volunteer to do this myself, though (sorry AngerFist) - It would be fun to do, but I am swamped in too many projects. But our experienced emulator coders (nitsuja, mz, gocha, etc.) could probably do this relatively quickly (still not a trivial job, though).
For anybody feeling tempted, let me say that the bsnes source code is a quite pleasant read, being quite tidy, especially compared to other emulators I've seen the source of. The main source of confusion is the use of co-threads, but you mostly shouldn't have to care about those when adding rerecording support (except for that one thing about adding runtosave somwhere).
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Mothrayas wrote:
In the future, all TASes will be made using bots that brute-force for the best possible input combinations.
wimbledonswirl wrote:
How many more or less rerecords will be used?
Several billions of rerecords.
More like 10100000 rerecords for brute force. If it were just a few billion rerecords, we could conceivably do brute force TASes now. I am pessimistic about brute force TASes myself. I think TASes in the future will be done with much more script assistance than now, and perhaps be done completely by a computer, but I do not think they will be provably the optimal solution.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Drewseph: Do you have a link to the smv file for your TAS of the game? I'd like to make a comparison video when Saturn submits this. The more runs compared the merrier, so if you know of any other good runs of the game, I'd be glad if you could point me at them.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Well done! This has been an excellent series for WIPs, and I definitely hope you submit this for publication - this has been one of my most anticipated runs for several years. I have no doubt this would be accepted, and you have my yes vote at least!
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
You might soon see more of the fire flower in SMW, as there is a useful glitch involving yoshi eating an enemy while it is turned into a coin by a fireball, which I expect we will see in upcoming runs.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Wow, what a huge improvement! I've grown used to improvements of tens to hundreds of frames with well-run games like this, and suddenly this comes along! Very impressive! I vote yes.
Looking at the justification people give the no votes, I have to say:
*Is this movie faster than the movie it would obsolete? Definitely - a large improvement.
*Is this movie more entertaining than its predecessor? I think so, it has new impressive tricks, and is faster, which is entertaining in its own right.
*Would we want a viewer who has never seen a SM64 any% TAS to see this movie or its predecessor? This one of course.
These are the questions that are relevant to the judgement of this movie. Here are some that are not relevant:
*Would you rather have seen a submission for another category (non-glitched, 100%, etc)?
*Would you rather have seen a submission for another game?
*Would you rather have seen a traditional speedrun?
*Has this game been improved too many times?
But the no votes seem to be justified by pointing at the the sort of irrelevant criteria below. At least they are in minority; imagine an impressive improvement like this actually being rejected due to reasoning like this!
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
You didn't say exactly how they don't work, but I tried one of your encodes, and it looked fine to me with both mplayer and vlc. I also had an old version of mplayer at hand, and that one failed straight away, complaining about missing video frames. So it sounds like this is an issue with missing support for variable frame rate in older players. But how many people does this really affect?
Here is (or will soon be) a comparison between the new wip and Namespoofer's previous RBO, as well as Kriole's non-glitched any%:
Link to video
The changes show up quite clearly. Note: In-game frames were used for timing here.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
By using lua instead of the memory viewer you get full control of things like this. You can even have the hp display above the enemy it belongs to, etc. Try looking for LUA topics in the emulator part of the forum, or ask on IRC.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
The sheer brokenness of this run was mind-boggling and very entertaining. This should be published, and may take the place as the most glitched run on the site, and all without using sram corruption! And it kept entertaining even during the ending, too! What's not to like?
btw i think we should also replace the " fastest time possible" goal by "longest time possible" because even i can do a better time than 999:59:59
Or how about "Longest time possible in shortest time possible"? :P
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Patashu wrote:
-Doesn't enter walls
I agree - this rule is just what is needed to get the sort of Sonic run people want when they say 'glitchless', and also works for many other games. Is is also non-ambiguous. (It might need small clarifications as walls are 'entered' by a few pixels quite frequently, but this shouldn't be a big problem.)
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Yes, it has been done, and all in LUA. I made a script for super metroid and another one for super mario world for this. There is, sadly, considerable work involved in proting these to new games.
The super metroid version can be found here: http://tasvideos.org/forum/viewtopic.php?t=6539&postdays=0&postorder=asc&start=168 and a video showing it in action can be found here: http://www.youtube.com/watch?v=0y0-73n5BE8
The super mario world script can be found here: http://tasvideos.org/forum/viewtopic.php?t=6539&postdays=0&postorder=asc&start=175 and an example video is here: http://www.youtube.com/watch?v=yEJhrU1EAhk
These scripts aren't supposed to be that hard to use, so I encourage you to give them a try.
Edit: I reread what you said, and I see that your suggestion is much closer to what I first thought I'd do to implement this. What you said can be done, and it wouldn't be too hard, but it requires rewriting the emulator, adding some inter process communication etc to keep them in sync. It would not be quite as good at comparing the runs visually (it is much easier to see where they are relative to each other when they are in the same window), but it would let one have a memory viewer open for each, giving much more information.
It sounds useful, so give it a try if you want. It would especially be nice if you added support for superimposing a (transparent?) version of the sprite layer form one on the other, with proper scrolling offsets taken into account.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I enjoyed both the glitches and the very high average velocity with the bat and wolf, even when having to fly in a zig-zag pattern. I haven't played this game before though, so I wonder: What exactly makes Alucard say "What?!"? It really did sound like he said it only during large wall-ejections. And I hope we'll see an explanation of all the glitches! Yes vote.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Oddity wrote:
Is there a way to load up a batch of SMVs into some program, that can convert all of them to uncompressed AVI (or anything else)? I just recorded an SMV for each room in the water dungeon, though only for the purpose of showing off what can be done in real time runs.
To get an answer more quickly, I'll show off this, which has TAS potential?
Aside form the batch part, snes9x does this for you. I hacked up a an automatic web encoding service which is somewhat like what you're looking for, but it is buggy (only works for snes9x 1.43, and only with the most common options). It should work for your smv. Here it is:
http://84.208.73.47/~sigurdkn/cgi-bin/smvlist
Note: In addition to the other caveats, my IP address is not constant either. So this service is rather useless overall. At least it is easy to use.
Edit: Oops, I had deactivated the service since it hadn't been used for so long. I have turned it on again now. Sorry about that.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I usually put my videos in an mkv container when I encode them, and then use the program mkvmerge to split them (it doesn't just do what its name implies).
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Squ4ll- wrote:
Sort of a necro post here, figured this would be the best place asking for this.
Currently playing through this game again and I'm looking for some memory adresses, especially the adress which contains the health for most of the bosses.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Here is the most common memory layout of a snes game: http://en.wikibooks.org/wiki/Super_NES_Programming/SNES_memory_map
As you can see, not everything needs to start with 7e. For example, the address 0 is a faster way of accessing the memory at 7e0000 (faster for the game, not for LUA, of course). The only suspicious address he gives is 19731, which would be 0x4d13, which is a hardware register. It doesn't seem likely that you could read out the boy's item from a hardware register.
What I would do is to take a few of these addresses, search for them myself, and see if they agree with that table or not. And if they don't, try to find a translation that does make them agree.
