In the first room, you seem to hit a corner before the last door, making you lose your speed. Can this be avoided? Or doesn't it matter because you need time to shoot the door and wait for it to open?
Are you sure you are entering the doors with top speed as early as possible? In the third room it looks like you are doing this properly, by backing up from the door and starting to move so that you reach the door with full speed on the first frame it is open (or perhaps one frame to late? It is hard to see on the video).
In the last room, you roll towards the door, unmorph and shoot the door, and then hit the door before it opens, robbing you of your speed. Then you have to wait for the door to open. Couldn't you have unmorphed and shot the door earlier, so that you don't have to wait for the door, and don't loose your speed by running into it? If not, it should at least be possible to enter the door at higher speed by backing up from the door and starting to move towards it slightly before it opens, so that you go through it at top speed on the first frame possible.
In the third room you stop moving while scanning the target. Is this necessary? And can't you get a boost out of the target?
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Ilari wrote:
creaothceann wrote:
So it might be as simple as setting the first 2 bytes of CGRAM (and writing to register $2132 for the color constant if necessary).
Writing to CGRAM from Lua script is possible, but unfortunately read/write to registers is not implemented.
When you implement read/write to registers, it would be nice to have both realistic and non-modifying reads available. Many readable registers change their state when read from, and only only sometimes want that to happen. For example, you might want to dump the bg1 tilemap without disturbing the game. To do this, you need to be able to read the tile map address, the tilemap size, etc. as well as the being able to read vram istelf.
When I needed to do this in snes9x I had to implement my own non-modifying reads to support this, either because registers were write-only or because they modified their internal state when read. Some registers only provide useful information after something has been written to another register. To handle cases like this, one can add that extra information as extra arguments to the read instead.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
hegyak wrote:
Can we get a report this post button? So I can help report flame wars (I know they are rare here but still)?
This sounds pointless. We already have moderators whose job it is read all posts and keep things civilized. Adding a button people could click to get rid of posts they don't like would just increase the moderators' workload - now they'd have to read all posts *and* respond to such reports.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
itsPersonnal wrote:
www.youtube.com/watch?v=-pU1q3nSf-k
This "hopping" dash trick is awesome ^_^
Edit: I'm roughly 2.5 seconds ahead of mrspeedrun and I'm going to redo the end of this room so save about .3 to .5 seconds, I enjoy destroying his "TAS"
Finally an optimized take on Metroid Prime! Keep up the good work, and keep us posted on your progress. I've been looking forward to a good Metroid Prime TAS for a long time, and it looks to be in good hands now. :)
Edit: Are you using memory watch to keep a track on your position and velocity, by the way? Directly watching your speed makes it much easier to keep the highest speed possible, and may help you discover tricks similar to super mario world's jumping trick.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I, too, hope he's working on a super metroid redesign improvement (and then proceeds to make both the new and old .smv available so I can make a comparison encode for them!). I have heard a few rumors that he's working on an improvement. But then, I also heard that Taco and Kriole were working on the same thing from the same source, so I don't think that source is very reliable. Still, I'm sure either the current or an improved super metroid redesign tas would be a strong contender for TAS of the year if submitted.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Sorry for the long delay. The script did not handle the resets correctly, and had to be fixed, which I've done now. Anyway, here is a comparison video comparing this video with its two predecessors.
Link to video
Note that like the other comparison videos, this one also uses in-game frames instead of real-time frames. Since most of the gains in the TAS are optimized room transitions, which are invisible when non-in-game frames are skipped, and thus can't be seen in this video. Still, there are about 2.5 seconds worth of in-game frame gain in the video too, so it still looks impressive.
I guess I could make a real-time oriented encode too, but it's boring to see all those room transitions. Another possibility would be to use a hybrid approach, with real-time synchronization but only displaying in-game frames. But that looks a bit strange too. A third possibility would be to display the offsets at the top of the screen both in in-game frames and in real-time frames.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I have ported my comparison script to super mario bros., and the result can be found here: http://folk.uio.no/sigurdkn/smbghost.zip
It works the same way as the super mario world version: You first create a dump file for each TAS you want to compare with by using smbrecord.lua, which produces a file ghost.dump. Rename this file to something meaningful, and repeat for as many TASes you want. I included some example dumps in the zip file.
Once you have the dump files, you can compare them with any TAS by using smbplayer.lua. It consists of a short configuration section at the top followed by lots of things you don't need to care about afterwards. Open up smbplayer.lua and edit the line with ghost_dumps = { ... } to indicate the dumps you want to use. Then just load the script in fceux together with the fm2 you want to play.
There are some other options at the top of smbplayer.lua too, such as whether to show the status line, how to display the offsets, etc. These are also the same as in super mario world.
The level transition detection could perhaps be improved a bit (the address changes at a different time than when one gains control, and there is a variable delay between these (perhaps due to the frame rule?)).
Edit: Here is a video comparing the 5 most recent super mario bros any% tases:
Link to video
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
This sounds like a good idea. Svn is a bit old, but I guess it is best to use in the interest of compatibility. I am looking forward to seeing the repository.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I agree that the "bad game choice" should be removed as a reason for rejection. Our goal should be to have as good as possible a TAS for every game, as even the most boring games will have somebody who played it at one time and wonder how fast it can be done, and the games may turn out to only look boring for people who aren't familiar with them. When somebody bothers to make a TAS for a game, that shows that there is at least one person who is interested in seeing such a TAS.
Allowing TASes of such games isn't going to make it harder for first time visitors to find interesting TASes to watch, as we already have the starred movies list for that. When I first came here, I first looked up all the games I enjoy playing, and then browsed the starred movies for other interesting games. I think this is pretty representative for what others do too, and it wouldn't be affected by allowing more games.
The whole "bad game choice" thing reminds me of editors on Wikipedia who keep deleting useful articles because they are "not notable". What they don't realize is that the threshold for notability depends on your number of articles: If you can only have 1000 articles, you should cover the 1000 most important topics. But if you aren't bound by an article limit, you do not need a notability limit either.
Thankfully, deletionism isn't as bad here as in Wikipedia yet, but if it gets to the point where people can't reasonably expect a good TAS to be accepted, we're going to both deprive viewers of runs to watch and ourselves of TASers who are willing to submit new runs.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Warepire wrote:
When I tested the feasibility of this I copied Gambatte's CPU core and allowed for input before I entered an opcode execution, I did not set up sound or graphics. (For those who are unaware: Gambatte is a GameBoy emulator, it has a 4 MHz CPU, most opcodes take 4-8 cycles to execute). This means I let the emulator poll for input up to 1 million times per emulated second, when you step through the game to figure out when to enter input, this becomes really really slow and monotone, it could take hours to TAS a single frame even for the simplest of games. This is for the GameBoy, now consider if this was done on say the Nintendo64 which has a ~90 MHz CPU, of course most CPU instructions take a bit longer to execute than on the GameBoy, but in general you will most likely be polling for input 5-10 million times per emulated second (there are of course exceptions like Super Mario 64).
I don't think SmashManiac wanted this to be done by opcode-stepping through whole frames. Rather, one would probably use frame-stepping normally, and when one needs higher resolution, one would set a breakpoint based on the position of the instruction counter or for reads/writes of an address, and then possibly do some opcode-stepping before providing the input. This is probably what was done for the subframe chrono trigger TAS, demonstrating that this is practical.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Mr. Kelly R. Flewin wrote:
Wish there was a quicker way to defeat Mother Brain though. I mean outside of a Murder Beam. Too bad it'd be pointless to shoot anything but beams.. or lack of time to fire off a power bomb if that did anything. That'd be cool if it was some delayed reaction affair could take place and it go off as Samus stands up from being healed. Impossible, but interesting to visualize
Murder beam is obsolete for Mother Brain, isn't it? I'm pretty sure the stand-up glitch is faster, and gets rid of all of Mother Brain's hp before Samus gets the hyper beam. So you don't really need any delayed reaction affair there.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Though I am not familiar with the game, this looks well played, and encounters seem to have been well manipulated too. I vote yes. Is this our first Wii submission, by the way? And is the tasability of this game an exception, or is Dolphin good enough to tas many games now?
On an entirely unrelated note, this game is really beautiful, and looks like it might be fun to play too. But I won't let that affect my vote - I would have voted yes even if the game had looked boring.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
bahamete wrote:
Do we use Chuck-Eat glitch?
This was discussed somewhat previously but we really need a solid answer as we'll be started soon. We'd love a judges opinion but anyone can throw their opinion out.
This would mean maybe 15 or more exits will be beaten using a goal sphere, and water levels (we're currently thinking Soda Lake) will be skipped by holding a key. Things like this.
I personally believe that using the bug will make the run look boring to some, but fresh and original to others. It's a grey area.
I think you should use this glitch. It is not so glitchy that it enters "glitched" territory, and it would add some nice variation to a long run. I do not think skipping a few stages this way is any worse entertainment-wise than flying over stages with the cape is.
bahamete wrote:
Do we use secondary results of Chuck-Eat glitch?
According to antaasas and others, we can write to any address possible by eating a chuck with OAM in a correct order.
I'm not too knowledgable but from preliminary thoughts, we could manipulate which overworld Mario is on, the powerup we currently have, which item is in reserve, etc.
It gets a little hazy when you realise that using this method, we can trigger the credits, or even write 96 to the exit counter and consider that a "finished" run. We don't want to do this; so which is acceptable?
This one is difficult. The optimal solution would be to do both, of course, as separate categories, but a 100% run is such a heavy undertaking that I won't demand that you do it twice in a row.
Manipulation of which overworld you are on sounds like it would open up many fun new routes. But one needs a strict definition of the category to avoid jumping directly to the end, as you say.
What exactly is the mechanism for the chuck glitch? (preferably with lots of assembly in the answer :)).
bahamete wrote:
Do we use "stun any sprite" bug?
Recently, we've found a way to stun any sprite. To people who aren't obsessed with SMW this basically means we can put sprites into a position where they will spawn something, similar to how an overturned Koopa shell spawns a koopa.
Think in the glitched run, where fishes are spawned. This bug has been known for a while but now any sprite is possible. Thanks to ISM and antaasas, so far we can spawn Koopa Kids (more or less instant level enders) and goal tapes. I'll detail this bug later, though. I will mention this bug will only be useful in a maximum of maybe 5 levels.
Definitely use this one. Sounds really fun!
bahamete wrote:
What constitutes all-exits?
Using goal sphere in Bowser's Castle, Back Door and Funky, we can in fact get 99 exits. So should we? This is a tough one to answer, I guess :p
This sounds like it will involve some backtracking (to get goal spheres) for not much gain, so I'd say no.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
P.JBoy wrote:
In that case: NewRandomlow = 5 x Randomlow + 17, NewRandomhigh = (5 x Randomhigh)low + 1
Here's the RNG routine:
EDIT: code-spoilers didn't work
http://codepad.org/tuBSLYKP
Thanks. Reading the code, I see that what is actually done is tmplow = 5*Randomlow, tmphigh = 5*Randomhigh + 1 + (5*Randomlow)high, NewRandom = tmp + 17. Which is exactly equivalent to what I originally wrote: NewRandom = 5*Random + 0x111 (which isn't that strange, since I tested my version on 20-30 numbers).
P.JBoy wrote:
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
P.JBoy wrote:
The routine that generates the new random number: NewRandom = 5 x Randomlow byte + 5 x Randomhigh byte + 18.
This doesn't seem quite right - the formula as written above can never have a larger result than $210, while actual random numbers in the game use the whole range up to $ffff. What works for me is this:
function get_rng(old) return AND(old*5+0x111,0xffff) end
P.JBoy wrote:
First: the routine subtracts the sum of the chances of supers and bombs from 0xFF; and sums the chances for energy, nothing and missiles; and calculates the former divide the latter. The routines then multiplies the chance of small energy by this fraction and checks if it's greater than the 'target', making the enemy drop it if it is; if it's not, it multiplies the (original) fraction by the chance of big energy, making the enemy drop it if it exceeds the 'target'; then with nothing, and finally missiles.
It actually divides? That will throw away a lot of precision, and is not necessary, since one can rewrite the operation with multiplications instead. But the way the rounding is done is important, so if it really uses division, a lua script should do so too. What would help a lot is if you had disassembly of what the game does.[/quote]
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
crollo: I agree that your reception has been a bit harsh. While a massively parallel bot will still not be able to brute force more than a handful of frames, I am sure there are interesting things that could be done with a parallel bot which is too slow on a single core, and I would therefore welcome even a simple demonstration of an MPI parallel lua script if you are interested in making one. Just be aware that this won't make the process of writing a useful bot any simpler - it will just make that bot more powerful.
As others have pointed out, the bot will have to make enough assumptions to get its scaling down from O(exp(n)) to something more manageable for this power to be of use, and those assumptions will make it hard for the bot to discover things we don't already know about. But if you put enough effort into it, I am sure it is possible to make something worthwhile. Our tool-assisted laboratory forum is far too quiet for my tastes, so don't give up!
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
The Nicovideo rankings are full of new stuff I've never seen before, as usual. It is sad that the majority of japanese TASes never find their way here.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Glitcher wrote:
amaurea wrote:
Secondly, about the name of the category (which is much less important): Almost all our TASes are glitchy to some extent. And all whales are big. Still, a phrase like "big whale" is easily understood to mean a "whale which is even bigger than normal". Our "glitched" category name is entirely consistent with this usage, and I know to expect game-breaking glitching that skips most of the game when I see it. It is easy enough to understand for it not be worth it to rename our existing categories.
But a "glitched" category is redundant. Almost every run on this site uses glitches in a speed run! It's like if you created a "manipulates luck" category or a "skips bosses" category, or better yet, a "runs through the game" category. Do you see my point?
I addressed this in the exact text you quoted. But I'll try to make it even more explicit, then. What you're saying is equivalent to saying that the term "big whale" is redundant, because all whales are big, so it doesn't add any information. Which isn't true at all - some are bigger than others, and those are the ones we call "big". Similarly, all tases use glitches, but some use more severe glitches than others. We call these runs "glitched" because they are far more glitched than the average. Just imagine that there is a "very" or "extremely" or "even more than normal" in front of the "glitched" in the category name, since that is what is meant.
Glitcher wrote:
Take the Rockman TAS for example. The player corrupted the memory to end several levels early and skip a large portion of the game. According to your definition, that should be put in a "glitched" category, yet it obsoleted the previous run as usual. All it did was use a new glitch to reach the game ending faster, and a SMW credits glitch TAS does the same thing.
The motivation for having a glitched category is to avoid only having runs which skip all the interesting parts of the game. In the case of Rockman, the glitches are definitely severe, but the fraction of the game that is outright skipped is still pretty low.
DrJones wrote:
Fewer categories = better. In any competitive environment, when the best categories are already claimed, the people that arrive later start coming up with their own arbitrary goals, with each new one being more stupid than the previous one, and dilluting the meaning of all the others.
Your argument applies just as well to games as categories. When the most popular games have been claimed, people start looking at less popular games. You don't think this is a problem do you? The quality of the publications is upheld by judging each submission by its own merits, and as long as they are good, the number of published games or categories should not matter.
Taking your argument to its logical extreme, we would only allow a single game (Super Mario World) with a single category (any%), since anything else would dilute the competition. Of course, if we did that, we wouldn't get very impressive records even for that game, as people would just do their TASing somewhere less restricted.
Having more categories does not have to divide up a fixed amount of effort so that each category gets a smaller part of the share. Instead, I think the total amount of effort will increase with the number of categories, because different categories may appeal to different people, who may then go on to try another category after they have proven themselves in their favorite category. So I don't think we have to worry about too many categories resulting in sloppy runs. As a concrete example, the least popular super metroid category (low%) is probably more optimized than an average single-category game here.
