TASVideos

Posted: 8/6/2014 6:14 PM

Quote

MrWint

Experienced Forum User, Published Author, Skilled player (1020)

Joined: 7/24/2013
Posts: 175

I just noticed that Ilari added an option to the lsnes a couple of months ago to support BizHawk's (old) GB timing (with a totally appropriate flag name: http://repo.or.cz/w/lsnes.git/commit/b14bc7a3a71214ce8e7fb0a8326a5753743ccd9a). Now lsnes is imitating BizHawk, while BizHawk imitates lsnes. I wonder if the two are compatible in both frame timings now...

Posted: 8/5/2014 6:44 PM

Quote

MrWint

Experienced Forum User, Published Author, Skilled player (1020)

Joined: 7/24/2013
Posts: 175

natt wrote:

As of r7519, you can have both options; that way no one is happy. This will be in the next release; which probably won't happen anytime soon.

That's awesome. So basically you also have backwards compatibility to pre-1.7 movies again (except for those who use the RTC, but hey). I feel kinda obligated to use this and create more GB movies now that my whining about the frame timing was successful...

Posted: 7/30/2014 8:22 AM

Quote

MrWint

Experienced Forum User, Published Author, Skilled player (1020)

Joined: 7/24/2013
Posts: 175

I don't have any plans for future projects, yet. There are improvements to make on the Gen I any% which can bring the time down to about 20-22min, but I probably won't do that, at least not right now. I'll probably look out for a different game. I like the automated approach I used for the Pokémon games, and I'm sure there are other games that could benefit from that as well, it's just hard to find a good target. It can be difficult to justify spending that much time on a game. The Gen I and II Pokémon games had probably the ideal preconditions: They have an active community, the GB platform is comparatively easy to understand, use and automate, the games have been largely disassembled (which is a big deal for automation), it benefits greatly from the automated approach, GB has the best debugging emulator I've seen so far (praise the bgb :D), I felt nostalgia since I played them as a kid, the games are rather popular, etc. It's hard to find a game that compares to that.

Posted: 7/29/2014 8:45 PM

Quote

MrWint

Experienced Forum User, Published Author, Skilled player (1020)

Joined: 7/24/2013
Posts: 175

Nice graph :) I didn't do the math before, but since catching or evolving costs around 17 seconds each and stuff like wrong warps cost around 12 seconds, there's definitely a theoretical minimum in terms of total time to catch all 151, especially since all of that is not including travel time, and not considering the extra amount of time spent for setting up glitches for otherwise unobtainable Pokémon. I assume the most time can be saved by managing to break the game faster than in 43min, the actual catching simply can't be sped up indefinitely.

Posted: 7/29/2014 8:25 PM

Quote

MrWint

Experienced Forum User, Published Author, Skilled player (1020)

Joined: 7/24/2013
Posts: 175

zeromus wrote:

imho, theres no solution to this which will please everyone. Until what I think is the long term solution (allow user to independently control options which affect when frames are displayed, what frame-advance hotkey does, and when input is consumed from input log) is in place, chasing a theoretical dragon will only bring grief.

You're right, there's no frame-based timing that will fit all games, since GB games can use joypad interrupts (well you could make inputs accurate to the CPU cycle, but that's not practical). But the old timing was fitting some if not most of the games, and my point is that the slight timing accuracy gain is not worth making the frame timing fit literally none of the games, especially when the accuracy could be achievd in a different way that doesn't have this drawback. I don't want to force some immediate changes here, I'm happy to continue using BizHawk 1.6.1, and as long as this is seen as an issue and there's a solution to it planned in the future, everything is good. All I want is to point out that the new frame timing is not strictly better than the old one, infact it has major drawbacks which may cause players to continue using the old timing, and that's probably fine, there are no emulation accuracy differences involved, it's strictly about timing. And even the timing can be compensated for by actually counting the CPU cycles in a run, which makes both frame timings comparable in terms of total time. Of course this raises the question why you would want to bother with the new frame timing in the first place, but I guess it's too late now, it's released and runs created on it must be dealt with. Reverting the timing change won't do much about this.

Posted: 7/29/2014 6:06 PM

Quote

MrWint

Experienced Forum User, Published Author, Skilled player (1020)

Joined: 7/24/2013
Posts: 175

jlun2 wrote:

jlun2 wrote:
1. Regarding CPU cycles, isn't that what Dolphin now does? How difficult would it be to implement something like that in BizHawk as well?
Uh....now that this is published, has this been addressed yet? :o

I created a thread to discuss this: Thread #15618: New libgambatte frame timing

Posted: 7/29/2014 5:53 PM

Post subject: New libgambatte frame timing

Quote

MrWint

Experienced Forum User, Published Author, Skilled player (1020)

Joined: 7/24/2013
Posts: 175

As this came up in my recent submission (#4376: MrWint's GB Pokémon: Red/Green/Blue/Yellow Version "Gotta Catch 'Em All!" in 1:54:56.62), I feel the need to discuss this a bit more: As of version 1.7.0, the frame timing has changed, forcing all frames to have the same length. Since these frames determine when you can do your inputs, this changes the input timing (and is therefore incompatible with input sequences recorded on the old timing). The pre-1.7 timing allowed individual frames to be shorter and tried to end the frame at VBlank (this is where the new frame gets drawn). This way the input frames always stayed in sync with the video frames of the game, at the cost of having very few single shorter frames to sync them up again when e.g. the LCD was turned off by the game. The new timing ignores video frames, so that the input frame boundary and the video frame boundary get out of sync. Let me illustrate the different behavior with a graphic (note that this is a simplification): http://pastebin.com/sjETYLAW The problem I have with this new frame timing is this desync of input frames and video frames. The game I was working on, and I assume many other games, fetch their input at VBlank. With the old frame timing, this was ideal, since you had an input frame on every VBlank, so you can literally do all inputs that are possible on a real Gameboy, which was great. Moreover, if you want to do an action in frame X, you know exactly that the corresponding input frame where you need to make your inputs is also X. With the new timing, this doesn't work anymore. If you e.g. want to close a textbox, and the game tests this during input frame 7, you can't be sure when you need to do the inputs: If it's after the VBlank that occurs somewhere during frame 7, you need to input it at frame 7, but if it's before the VBlank you already need to press the buttons in frame 6. This is highly confusing, and can (in rare cases) even lead to inputs not being possible at all, if multiple VBlanks occur quickly after another. To put it in other words: You set a breakpoint where the inputs are used, and run the game until it stops at the breakpoint. Now you want to know when you need to press the joypad to set the inputs at that breakpoint. In the old frame timing, this was easy, just go back to the last frame boundary and press the buttons there (this is how I created aforementioned run btw). With the new frame timing, it's not that easy: It may be the last frame, or the frame before that, or even no frame at all. It's a mess. I assume you were trying to fix timing accuracy issues with this, since you determine the movie length by multiplying the frames with the frame rate, and some individual frames were shorter than the rest, resulting in a slightly too-high total time. The main problem here lies in the assumption that the frame rate is constant, because it just isn't. Well, it is under normal circumstances, which is 99.9% of the runtime, but not always. It may be better to measure the time in terms of CPU cycles, which are in fact constant, and accept that some video (and therefore input) individual frames are shorter. Forcing all frames to be the same length causes issues as described above, and at least for me makes the way I create TASes impossible. I hope there is a chance to rethink this change, or I'm probably forever stuck with BizHawk version 1.6.1 for GB games... Note that I had this discussion (with a slightly different focus) before for lsnes (Thread #14274: lsnes (libgambatte core): Frames don't end on VBlank), which does the same thing. I'm running out of usable emulators it seems...

Posted: 7/27/2014 7:42 PM

Quote

MrWint

Experienced Forum User, Published Author, Skilled player (1020)

Joined: 7/24/2013
Posts: 175

mklip2001 wrote:

Is it the JACK glitches that cause a whole wall of sprites on the left side to appear?

Yes. As I mentioned in the submission text, the game doesn't reload the map sprites after using JACK, the sprites on the left is the residue of the party menu, where all current party Pokémon sprites are arranged vertically. Only the player sprite gets loaded at all, which in most cases replaces one of the visible sprites in the list.

Posted: 7/27/2014 9:20 AM

Quote

MrWint

Experienced Forum User, Published Author, Skilled player (1020)

Joined: 7/24/2013
Posts: 175

Chamale wrote:

However, the Pidgey/Jynx encounter at 1:50:43 (in the temp encode) does look a bit slower than it could be, is there a reason it wasn't possible to get an earlier encounter and/or a Rattata there?

I'm not 100% sure why it's not possible for Jynx to be caught in the first patches of grass, and it's very hard to debug because of the unpredictable nature of the 20 bytes that are chosen for the invalid move's name. It just turns out to always end with a EOS properly. It's something I didn't mention in the submission text, but it in very rare circumstances it can happen that you just can't get the Cooltrainer to trigger because of the state of your RAM, and pointing out the exact cause of it is almost impossible. It happened twice in this run, with Jynx and with Gengar (I walk an extra step in Saffron City because of this). All I know is that it's not random, for specific combinations of Cooltrainer locations and encounter locations (possibly also dependent on other factors), it just won't work. As to Pidgey/Rattata, I took whatever is faster overall for the current situation, i.e. what is faster after their cry has played.

Posted: 7/26/2014 7:40 PM

Quote

MrWint

Experienced Forum User, Published Author, Skilled player (1020)

Joined: 7/24/2013
Posts: 175

ALAKTORN wrote:

“Note that not only the number of caught and seen Pokémon is 151, the game time ends up being 1:51 as well, which was of course totally planned and not just pure coincidence.” what does that mean? did you slow down on purpose?

Erm... no. Actually, the 1:51 is pretty close to being a 1:52, even if I were 30s faster, it would still be a 1:51. It just worked out that way. I'll take this as a reminder on how bad sarcasm translates to writing.

Posted: 7/26/2014 3:19 PM

Quote

MrWint

Experienced Forum User, Published Author, Skilled player (1020)

Joined: 7/24/2013
Posts: 175

p4wn3r wrote:

These optimizations almost always required us to manipulate a pokemon's stats in a wild battle, which was extremely annoying, especially when lua scripts in the emulator always desynched, unless you reloaded a savestate manually (btw, has this bug been fixed?)

I have no idea, I don't like lua scripting too much. As with previous runs, I used libgambatte directly to emulate the GB, mimicked BizHawks frame timing and went from there writing a program to do the input presses and re-records, which gives you more flexibility than using lua can. BizHawk is merely a playback device the produced input sequence happens to sync on.

p4wn3r wrote:

Now, kids these days can just read the following:
Submission wrote:
Since the goal is to catch all Pokémon in the least amount of time, we want to utilize the fastest way for obtaining each Pokémon. [...] A Trainer-Fly encounter is the most flexible way, especially when combining with Ditto's Transform ability, but is by far the slowest due to its elaborate setup.
And now Mukki and I look stupid. Why are you so mean? :(

That's not true, the "faster" glitches just weren't discoverd at the time of your TAS. I remember watching it when it was released, I was amazed by the sheer possibility to catch all of them in one game, let alone the speed in which it was done. It just shows how much has changed.

p4wn3r wrote:

Just one question, MrWint, when you were making the run, did you need to redo long segments because of some stupid reason? In our run, the most ridiculous redo was because the game soft-locked when we tried to withdraw a lvl 1 pokemon from the PC >_>

I had multiple of these in fact in my test run (I made an un-optimized run to check the route before starting the luck-manipulation for nothing). For example, I went to Cinnabar lab with all three fossils, just to realize that the Old Amber is unusable because it happens to have a quantity of 0, so I needed to do it all over from Digletts cave. But the worst one was at the very end, when Oak examined my Pokédex and it showed only 150 Pokémon. I thought I've missed one and my whole route would fall apart over this mistake. The truth was I messed up the Rhydon glitch at the very start (I wasn't aware that you'd need it in your party for it to work), which meant re-doing 3/4 of the run. Oh well, that's what test runs are for, right? ><

Posted: 7/25/2014 6:17 PM

Quote

MrWint

Experienced Forum User, Published Author, Skilled player (1020)

Joined: 7/24/2013
Posts: 175

natt wrote:

Yay, at least one person liked my original choice of frame timing for the GB core.

There was a whole section of text with me ranting about the new frame timing, which I cut out for being inapropriate in the last second. Seriously though, I hope there is a chance to overthink the current solution. I think forcing all frames to be of equal length is just not the way to go, it's not how the GB works. It'd be better to just accept that frames have different lengths and solve the timing accuracy problem my measuring the CPU cycles, which have a constant frequency, whereas video or input frames don't. And while you can argue that not all games fetch their inputs a VBlank, some (if not most) of them do, whereas the new timing fits none of the GB games. The discussion about this should probably not be held here, though...

Posted: 7/2/2014 11:54 PM

Quote

MrWint

Experienced Forum User, Published Author, Skilled player (1020)

Joined: 7/24/2013
Posts: 175

Dyshonest wrote:

I wonder how far into the game you have to get for it to jump to useful bits of RAM?

That question is still unanswered. I couldn't make it work in Viridian Forest when I tried it previously (which doesn't mean it's impossible), and it's the only useful place for any% (It's impossible in Mt. Moon, since the stored text is reset in Route 3 (as well as all other routes that have trainers on them)). Due to a lack of use, there hasn't been much exploration of other potential areas.

Dyshonest wrote:

To what extent are you using them that has nothing to do with ACE though? Making sprites disappear? Making a walk-through-walls item? I'm just a bit confused here as to how those glitches are useful outside of ACE potential considering 90% of the time they fry the save file or just crash the game.

I feel there a misunderstanding on which glitches involve ACE. Both things you mentioned can be achieved by conventional means. The (glitch) item which does these things exists in the game, we know exactly why it works and how, and there's no ACE involved at all. All you need to do it grab it. Manipulating RAM areas (e.g. in the inventory screen) is not ACE. The program counter stays where is should be, in the inventory screen routine, we're just accessing "items" the game doesn't expect. Also, if you crash the game while doing some glitch, you basically failed due to a lack of understanding on how the glitch works. None of them involve any RNG, the inner mechanics are just tricky at times, and doing something "bad" let's you lose control. Most instances of "the glitch craches the game" is actually due to a lack of knowledge. Take for example the transform glitch. It was known for a long time that it exists, and what it looks like when you do it (dubbed the "TMTRAINER effect") and that it likely crashed your game, but nobody cared to investigate why these things happen. Now that we know what happens internally (it overwrites certain RAM segments due to a missing EOS marker), we can prevent it from crashing by setting it up correctly, and even do useful things with it (like manipulating your opponent's Pokémon by overwriting its stats).

Posted: 7/1/2014 9:04 PM

Quote

MrWint

Experienced Forum User, Published Author, Skilled player (1020)

Joined: 7/24/2013
Posts: 175

ALAKTORN wrote:

MrWint wrote:
If you ban everything that can be used for ACE, there won't be much game for you left to play.
…don’t you mean the exact opposite? if you ban all glitches, you’ll only be left with how the game was meant to be played, lol

Sure, if you call that a game... :P

Posted: 7/1/2014 6:29 PM

Quote

MrWint

Experienced Forum User, Published Author, Skilled player (1020)

Joined: 7/24/2013
Posts: 175

Chamale wrote:

MrWint wrote:
jlun2 wrote:
On another note, how does trainer-fly manage to get that glitched? :o
The ID of the text box displayed before the Trainer-Fly fight is stored and can be manipulated by various actions like talking to NPCs. If you set it to an ID which doesn't exist in the Trainer-Fly map, you can get the text pointer into ram. Texts have the awesome feature of inline assembler (byte 0x8) which lets the game execute everything after it. Hard to set up, but probably the fastest ACE in the game (without save corruption).
Do we know any more about setting that up, by the way? I know I made a run that causes a crash in Viridian Forest when it starts reading some invalid text, but I don't know where the pointer ends up in that RAM or whether it can be manipulated.

I have not yet seen or done a concrete example of this doing something useful, but I have executed parts of RAM with it during some testing I did some time ago. I made a list of destination addresses for different text IDs in Viridian forest (this map is especially interesting for the any% category), there are a few useful ones (e.g. ID 0x10, 0x16 and 0x1c jump to 0xd7f3), setting the RAM up to do useful things for you is the hard part, especially early in the game. That's why it is of limited use in the any% category as of now, but it's definitely possible to do.

Dyshonest wrote:

Uh....save corruption isn't the same as ACE.
What happens afterward though, is ACE, and doesn't necessarily need save corruption, it just makes it faster obviously as it's quicker to use save corruption than item underflow.

That's exactly the point. All runs you have seen (especially for any%) use the glitches to trigger ACE. But you don't have to, they can be useful even if you don't.

Dyshonest wrote:

One can argue that the stuff that happens with item underflow isn't ACE, but CoolTrainer? No, that's definitely ACE. Executing arbitrary things in the RAM as "valid" code.

Again (assuming you are referring to the use of the transform glitch in my any% run), ACE is only one application of the transform glitch. It's the one you may have seen almost exclusively until now, since this is what you want to do when you do any% or break the game completely. There are more subtle way to use it, which don't involve ACE. I admit it's a bit counter-intuitive, but the trick is not to use the glitch to its fullest (ACE is far too powerful for anything else than any%), but to control it and let it do something useful in a more conventional way. If you ban everything that can be used for ACE, there won't be much game for you left to play.

Posted: 6/30/2014 5:58 PM

Quote

MrWint

Experienced Forum User, Published Author, Skilled player (1020)

Joined: 7/24/2013
Posts: 175

jlun2 wrote:

On another note, how does trainer-fly manage to get that glitched? :o

The ID of the text box displayed before the Trainer-Fly fight is stored and can be manipulated by various actions like talking to NPCs. If you set it to an ID which doesn't exist in the Trainer-Fly map, you can get the text pointer into ram. Texts have the awesome feature of inline assembler (byte 0x8) which lets the game execute everything after it. Hard to set up, but probably the fastest ACE in the game (without save corruption).

jlun2 wrote:

Infact, how many methods are known for the english releases that allow ACE?

Erm... all of them. Probably every glitch powerful enough to be useful can also be extended to ACE in this game.

Posted: 6/30/2014 3:39 PM

Quote

MrWint

Experienced Forum User, Published Author, Skilled player (1020)

Joined: 7/24/2013
Posts: 175

Dyshonest wrote:

Regardless, 151 runs shouldn't use CoolTrainer/item underflow (our Pokemon Red/Blue "game end glitch" run already does that) or ACE/save corruption (both Yellow runs use these).

Just to be clear here, I plan to use both the CoolTrainer and the item underflow glitch. While both of them can be used to trigger arbitrary code execution (ACE) (like my Blue any% run shows for CoolTrainer), they aren't inherently based on ACE, that means you can use them for useful stuff without triggering any ACE, and we do know the inner workings of the glitches well enough to distinguish. Otherwise there would be no line where to stop (e.g. you can trigger ACE even using a simple Trainer-Fly. Does that mean you need to forbid them as well?), and you would end up with an awfully defined pseudo-glitchless category. That means that there are exactly two things that are explicitly forbidden: - any form of ACE (more specifically, executing any line of assembly that you can influence the value of) - Manipulating the Pokédex caught entries by other than the intended means (i.e. catching, trading, gifts, prizes, evolutions). That means no tricking the game into generating Dex entries without actually obtaining them. Everything else may be used. The run is considered completed when Oak admires your 151 Pokédex count in the Hall of Fame and the credits roll. I spent a good amount of time making sure that these rules are still creating a sound category, i.e. not allowing to break the game to a point where the task is trivial. All available glitches are limited in some way and there is no single best way of catching Pokémon offered by any of them. Maybe I overlooked a glitch that trivializes the game, if anyone know one please point it out, I can spare myself from spending my time on a non-category then.

Posted: 6/30/2014 12:11 AM

Quote

MrWint

Experienced Forum User, Published Author, Skilled player (1020)

Joined: 7/24/2013
Posts: 175

I'm infact planning on using Red, since Blue's version exclusives seem a little easier to get in Red than vice versa. Both versions are surprisingly close, though, I'm still not entirely sure which version is the faster one overall.

Posted: 6/29/2014 11:26 PM

Quote

MrWint

Experienced Forum User, Published Author, Skilled player (1020)

Joined: 7/24/2013
Posts: 175

I did some research on the 151 category in the past few weeks, and it seems the category is indeed still well-defined and reasonable. What I mean by that is that it's not broken to a point where there's a single trick you can use to catch every Pokémon with easily, which would create a fast but incredibly monotonous run. This is excluding arbitrary code execution of course, which by definition allows you to do literally anything. Using new strats and glitches will result in a huge improvement over the current run, saving 1 hour or more is quite possible I think. I started working on a new possible route, and it seems to work out nicely, so I'll be doing a new run of the 151 category (I actually found myself somewhat in the middle of it already, so I might as well finish it before someone breaks the category for good with some new discovery). Don't hold your breath for it yet, though, there's still a lot of work to do, but the chances are good that I will get to finish it in the coming month or so. As a teaser: There will also be a new trick used in the run to catch some of the otherwise unobtainable Pokémon in a faster way, but I won't spoil it yet, you can read all about it in the new run's submission text in a couple of weeks ;)

Posted: 4/26/2014 6:43 PM

Quote

MrWint

Experienced Forum User, Published Author, Skilled player (1020)

Joined: 7/24/2013
Posts: 175

I did a quick search in the disassembly (which btw you can do too, it's available at https://github.com/iimarckus/pokered). The linked site is correct. The badge boosts function is at 0x3ee19, and what it does is using every other badge (the 1st,3rd,5th,7th) to increase the stats in order (that is ATK, DEF, SPD, SPC), which results in the stated listing. The second statement on the other hand is not correct. The move effect of lowering a stat (function at 0x3f54c) triggers no general stat re-evaluation, but calls 0x3ee19 (the badge boost function) directly at 0x3f63e (call nz, 6e19). Also, this is only done if it's the opponent's turn, that means using your stat-lowering moves won't do anything. The same goes for raising a stat (function at 0x3f428), which covers both moves and X-Items and is only triggered when it's your own turn (at 0x3f511).

Posted: 4/26/2014 6:05 PM

Quote

MrWint

Experienced Forum User, Published Author, Skilled player (1020)

Joined: 7/24/2013
Posts: 175

First of all, I approve of your name :) And yes, your're right, I missed that. After the "and..." there is a text command 0x0A, which delays the game by 30 frames (roughly half a second) unless A or B are currently pressed, and I failed to do so in the movie. Good catch.

Posted: 4/5/2014 6:30 PM

Quote

MrWint

Experienced Forum User, Published Author, Skilled player (1020)

Joined: 7/24/2013
Posts: 175

FractalFusion wrote:

Though I kind of wish the poisonwarping route was faster.

I did, too, it was such a nice addition to the route. Apparently many others felt like that too, considering all the suggestions to make it faster somehow. Sadly, it seems it just isn't, as long as you can't skip catching a wild mon with Tackle. if you only needed *a* third Pokémon, getting Randy's Spearow ("Kenya") in Goldenrod City might be faster than catching a wild one, plus you don't need a Pokéball, so you can use poison warp.

Posted: 3/31/2014 3:38 PM

Quote

MrWint

Experienced Forum User, Published Author, Skilled player (1020)

Joined: 7/24/2013
Posts: 175

Mr. Pwnage wrote:

Does it gain more than 4 seconds if you get into the poison fight before going to Rival 1, instead of backtracking afterward like the Pi run does? The 2 poison damage you'll incur during the Rival fight this way should be easy to work around with potion timing, and while the messages may take a couple seconds, this is surely less time than retracing those 60 steps.

You can't. The game automatically heals you after the rival fight, so you need to backtrack in order to poison warp (Route 29 has no wild Pokémon that can poison you). For the same reason, poison warping back from Oak to Cherrygrove doesn't work, you'll be healed by Oak's assistant.

Posted: 3/30/2014 8:01 PM

Quote

MrWint

Experienced Forum User, Published Author, Skilled player (1020)

Joined: 7/24/2013
Posts: 175

It would. Poison warping gains less than 4 seconds, and talking to the aide would cost more than that. As soon as you get the balls from the Aide, walking is faster than poison warping in any case.

Posted: 3/29/2014 6:20 PM

Quote

MrWint

Experienced Forum User, Published Author, Skilled player (1020)

Joined: 7/24/2013
Posts: 175

ALAKTORN wrote:

question: that fat guy before the Union Cave, is it slower if you talk directly to him from the left instead of making him talk to you?

Unlike trainers, this guy does not show the (!), which costs around a second and makes it faster to talk to trainers directly instead of letting them spot you. I ran a quick test, talking directly seems to be slower by 9 frames, not sure where the difference comes from.

Posts for MrWint