Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
Nach wrote:
I don't understand how people come to this "obvious" conclusion.
Well, you did start off the Judgment section with the words "Armed with all the aforementioned information, [...]", implying that the comparison was used as well. In retrospect, I can see that you didn't mean it that way, but it wasn't clear when initially reading it.
Nach wrote:
Nobody paid attention in the discussion, because nobody posted any hard numbers, just kept on going on and on about faster real time, which is never how we compare changes across versions.
I don't think it's fair of you to expect this to just naturally come up in the discussion. I had no idea it was relevant, and nobody even questioned the timing in that direction. If this is a relevant part of how the run will be judged, I think it's also partly on you as the judge to bring this up before the final verdict hits people with this unexpectedly. I completely understand why you wouldn't want to just blindly trust other people's numbers though.
Speaking of trusting my numbers, the table I posted is a straight export of a spreadsheet with only formatting adjustments. The times are rounded to the nearest millisecond. The frequencies used are 60.0988138974405 for NTSC and 50.0069789081886 for PAL. Can you point to one of the inconsistencies you saw? I'm happy to take a look and file a bug against Google Sheets. I can also provide higher-precision times if that helps clear things up.
Nach wrote:
Although from the conversation we had, he is strongly attempting to argue based on a ratio between different engine numbers being relatively proportional to each other, with those same numbers being present in level design by area. That proportion according to him does not align correctly in the PAL version (I did not even attempt to verify any of this data myself).
That sounds interesting, but I don't quite get what specifically adelikat means with the same numbers being present in the level design. I'd be interested to hear him elaborate on this.
Nach wrote:
It's hard to claim PAL is original when it came out about 3 years after the NTSC version. Nintendo wasn't even sure they were going to do Europe at all at first, and wanted to see if things caught on in the US prior.
Additionally, if you're correct that the PAL changes are intentional (bug fixes aside), why don't those changes appear in SMB2j?
I know it's a stretch, and I'm not claiming that this is exactly what actually happened. It could have happened for any single part of the game though, or for other games, my point is that the current guideline of always preferring the original is presumptious.
Regarding SMB2j, that's a trick question, it's because SMB2j came out in 1986, the PAL version only in 1987. Maybe they realized their mistakes only after SMB2j's release ;)
Overall, while this submission didn't go as I expected in more than one way, I'm happy with the result. Thanks Nach for putting up with me, and again sorry for overstepping in my initial reaction (although from reading from your last correspondence in this thread you also seem to enjoy this kind of thing a little).
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
Sorry Nach, my intention was not to attack you personally, I may not have spent as much time as I should have formulating my points, so it ended up a rougher than I intended.
I can only go on what you wrote though, and my comments reflect the impression it had on me (and possibly other people). When you write a long paragraph about debunking that PAL is faster then NTSC, and then present a "before" and "after" judge voting, the obvious conclusion is that you used the material you presented in previous paragraphs in your discussions.
Similarly, if you write the cited piece without any clarification or context, people will read into it.
I'm happy to hear that this is only a matter of miscommunication, and also that the rules this judgement was based on are being reassessed.
You're also not innocent in this, though. I didn't gather this data yesterday, I have a spreadsheet with more detailed frame comparisons (also for the non-playable parts) which I created when investigating the feasibility of this run. Just because I didn't write about it doesn't mean nobody paid any attention. I just didn't think it was relevant to the conversation until you brought it up in the verdict, with numbers that didn't match mine. I still don't think it's a fair way to time the versions, but I think we're on the same page there.
Regarding the original vs. non-original discussion, I admit I didn't read all posts in the thread in detail. I did however read all your responses (except the small-print you clearly don't want me to read), and you pointed to the Judging Guidelines, and gave an example of how acceleration changes difficulty in some sections. The difficulty argument is frankly debatable, you are assuming intention where none may exist. Just because you experienced the difficulty in NTSC a certain way, doesn't mean they specifically designed each jump to have a certain difficulty. Of course a certain progression was clearly intended, but not everything that's different is automatically "non-original". If I wanted to play devil's advocate here, I could claim that the PAL version is the true original, and they just didn't get it right the first time with the NTSC version, so they tweaked it intentionally for PAL.
My point is not that this is unknowable (you could ask someone who worked on it), my point is it should be irrelevant, they are no more than differences, not making one version intriniscally better. You don't want to go out of your way tracking down what the actual developer intentions were for each section of each game to judge a submission for how true it is to the original intentions, and you can't assume just because it came out first that this must be the intention (if that were the case, no 1.1 versions would exist), so you can only see them as what they are, differences without any preference. If the differences are large enough, a new category might be warranted, and if they are not, obsoletion might be warranted. That is why I think the originality argument based on "indisputable authenticity" (source: Judge Guidelines) is flawed and not actually that indisputable.
Don't get me wrong, I think there are valid reasons for sticking with the NTSC version (authenticity is just not necessarily one of them), and I agree with your ruling based on the current rules. My main goal with the submission I didn't end up having to do myself was to strike a blow for PAL games, and I'm happy to see the larger issue is being looked at more closely.
I didn't disagree with the verdict, I disagreed with the way it was presented, which is what I think the main reason for the small outrage has been. I'm sure you thought about this thoroughly, but the judge's notes didn't reflect all of that properly.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
It's probably no surprise that this is not the verdict I expected. If I didn't see merits in the publication, I wouldn't have spent multiple months investigating the game and creating a TAS for it.
I have read the judgement, and considering the information presented and the line of reasoning, the verdict is reasonable.
However, I'm afraid the information the ruling is based upon is wrong, and it may have had an adverse impact on the verdict.
The times presented to "debunk" that PAL is faster than NTSC are all wonky. Here are some accurate numbers, extracted from the current NTSC TAS and my PAL TAS, with frame numbers for reference. They are based on the 15 distinct sequences when the player has control over Mario ($000E = 8):
As noted in the judgement, the large difference in 8-2 is because NTSC wastes time in the playable part to gain time in the non-playable part. What is not mentioned though is that the same applies for the PAL version as well in 8-2 (to avoid fireworks).
So the updated table looks like this:
There are more things that are not recognized that would favor PAL. The suspicious time gain of NTSC in 8-3 is caused by the fact that doing the flag pole glitch costs (playable) time, and NTSC doesn't do one in 8-3, so these would be another couple frames gained by PAL in this calculation.
My main point though is that the PAL version is faster than the NTSC version, not only on technicalities, even when only considering the actual gameplay. The individual level times show that PAL is consistently a tiny bit faster. And the only reason it is even that close overall is because of the water section in 8-4, PAL is significantly slower while walking or swimming (they used a factor of 7/6 instead of 6/5). The ruling misrepresents the facts by how they display the data.
This doesn't invalidate the reasoning in the ruling, according to the helpful decision tree the same path still applies. So why is this relevant at all then? The reason it is relevant, the reason it was probably included in the ruling to begin with, is that it makes the decision much less defensible.
When you can show that PAL is only faster based on a technicality, it is easier to discount it as a port that doesn't reach the glory of the true original. It demonstably convinced other judges into changing their opinion. However, if that isn't actually true, you're not left with much to justify the decision.
I can understand why people are upset about this decision. The way it looks like to me is that you have a submission on a different version of the game than the currently published one. It is faster than the currently published run no matter how you slice it, and also well-liked. It has been rejected because it is apparently too different to allow obsoletion, but simultaneously too similar to warrant its own category (source: decision tree). This is a middle ground I don't think should exist, at least not for a high-profile game like SMB.
And the decision relies heavily on the "original" vs. "non-original" distinction, which I don't understand at all. Whether or not something was on the market first has no relevance by itself. Actual possibly valid reasons are usually only results of this fact, like when the original was significantly more popular than later versions, or when later versions were poorly made compared to the original. It'd be great to get some elaboration on this point. The way it stands now it sounds like a handwavy way to justify a biased opinion about PAL games being intrinsically inferior due to being "not the original". The way Nach describes it as "Having a non-original game replace a perfectly valid original seemed lunacy to me, [...]" suggests that not much thought went into why that would be the case. Being the original doesn't make it better by itself.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
jlun2 wrote:
MrWint wrote:
(Actually, they patched out some glitches in the PAL version, but none of the ones that are beneficial in any current category)
Are there some examples please? That sounds rather interesting.
Sure, happy to oblige:
The most obvious one is that the 1 tile gap over the exit pipes in water levels have been fixed, which you could get stuck in as big mario and softlock. See 8-4 as an example:
http://imgur.com/oAMjAVG.png
There are also less obvious changes. For example, it fixes spring objects being loaded into the special item slot. Some background: SMB has 5 enemy slots, and a sixth special item slot. That means there can only ever be 5 enemies on-screen, any more just won't load. It also means there can only be one special item on screen (these are things like powerups or the flag at the end), you may have seen one powerup disappearing when you activated a second one. Most objects you see take up one of the enemy slots, including springs, vines and firebars.
In the NTSC version, they forgot to check whether all enemy slots are taken, so a spring can load into the sixth slot, overriding or being overridden by any other special item. In the PAL version, they fixed that so the spring won't load instead if there's no available slot.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
andypanther wrote:
electricslide wrote:
From what I'm seeing, here's the problem.
PAL is of lesser quality than the NTSC. This has nothing to do with Europeans saying, "but you hate us". FFS. It's got nothing to do with that. NTSC was done first because it is higher quality than the PAL port of this game.
The object is to ultimately showcase the best the game has to offer under the best conditions. That's been done, and for this game, has been done a long time ago.
This video, while done well, still uses a lower quality version of this game. It exploits a loophole available only to this version and the physics apparent only here. The loophole doesn't show up in the NTSC and can't be used to shave time there.
Bad game version has been used pretty much forever to put runs in Gruefood. I don't see the issues behind putting this particular run in Gruefood. Yes, it's well done, but that doesn't mean that it should be published.
Publishing this in any way shape or form is going to lead to PAL versions of every game being submitted regardless of quality.
Have you read this excellent post by MrWint that goes into deatail about PAL just being a "bad port"? The situation isn't as simple as you might think it is.
I didn't go into the technical nitty-gritty of the individual glitches and how they play out in different versions, why some of them are exclusive to one version or the other, but I'm happy to provide that information if it helps clear things up about the relative quality of the NTSC and PAL versions.
The TL;DR is that they are not a sign of one of the versions being intrinsically better or worse than the other, it's the same flaws existing in both versions that just happen to be more or less exploitable by pure chance. (Actually, they patched out some glitches in the PAL version, but none of the ones that are beneficial in any current category)
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
Well, where do I start?
Unfortunately for me, I was just about to sumbit my own SMB1 PAL TAS (my version here), and HappyLee beat me to it. Mine is faster in a few places and contains a different technique for 4-2, but that doesn't matter due to the frame rules, they end up with the exact same time.
Sucks to be me I guess.
But that at least gives me the opportunity to weigh in here.
Firstly to vouch for how optimized this submission is, it's on the same level as the current NTSC TAS. I could go into detail on how I created my version using exhaustive search and literally billions of automated rerecords, but the short of it is that this is very well optimized.
More importantly, I have spent some time comparing the two versions, precisely to get some facts to the matter at hand: Is the PAL version just a "bad port"?
I feel like part of the discussion so far was based on wrong information, misconceptions, and personal biases, and it would be helpful to provide some factual basis and clear some things up.
To that end, I have disassembled the PAL version to compare it with the NTSC version (a disassembly of which already exists as a reference).
You can find both disassemblies as well as a diff here, and it is the basis for most of the claims and dispelling thereof below. They compile into the exact NTSC and PAL ROMs respectively, so they are guaranteed to be accurate.
So, is it a poor port of the NTSC version?
In general, it actually looks to be a rather well executed version of the game, more akin to a v1.1 of the NTSC version fixing some of the bugs and issues.
For example, they fixed the 1-tile gaps above the exits in water levels (code), they fixed two issues with the spring object you probably weren't even aware existed (code 1, code 2).
They were also quite thorough when adjusting the physics parameters to accomodate the FPS difference. E.g. they updated some enemy hitboxes (code) and made the floor hitboxes larger (code).
But the physics are all screwed up to accomodate for the 50fps vs. 60fps difference!
The physics are different no doubt, but they are not more screwed up than before.
All physics changes are changes to parameters, the actual physics engine is the exact same. And you need to realize the parameters for the NTSC version were chosen arbitrarily to begin with, it's not like they were fine tuned to exactly fit the SMB1 physics engine.
All the resulting differences are not inherent to one version or the other, they just turned out that way by pure chance.
For example, the floor clip shown is this run can technically be done in the NTSC version as well, the same bug in the physics engine exists, it just turns out that due to a parity issue, you can't align the subpixels in the way you'd need to. This is not something the developers planned, they just got lucky in the NTSC version and less lucky in the PAL version.
The same goes for the flag pole glitch, all you need to do is hit the pole at the right height. The fact that this isn't possible easily in NTSC is pure luck, just how the arbitrary parameters play out.
But the physics are more exploitable since you more farther each frame!
That's actually not always true, the differences can work for you or against you.
For example, wall clips are significantly harder in the PAL version. The main contributor to make the glitch work is a bug in the wall ejection logic, which pushes you into the wall instead of out. But since Mario moves more each frame in PAL, there is less time for the ejection logic to affect you, making some wall clips which are possible in NTSC straight up impossible in PAL.
But the sound doesn't even match up in the same way!
The sound timing is different, but not because the developers were lazy.
All sound timing was adjusted for the PAL version (code), so you can safely assume that the way it sounds like is the way they wanted it to sound like.
Maybe the NTSC sound timing was wrong all along, and they fixed it in the PAL version to what their vision was from the start *dramatic reveal*.
But it's a different game!
It cetainly is. But so are different language versions of games. Or v1.0 vs. v1.1 versions of games. Or the Yellow and Red version of Pokemon, and still one can obsolete the other.
Having different categories for all versions which are technically different is just not feasible, you'd end up with dozens of nearly identical runs.
The deciding factor in my opinion is whether they provide different viewing experiences.
That is why e.g. Pokemon Green is a legitimate separate category, but Yellow and Red can obsolete each other.
If you were to create a Green run using the same route as the Yellow/Red runs, it would obsolete the Yellow/Red run, not the other Green run.
It's not about the version that is used, but about what it looks like to the viewer in the end.
But the easy full flagpole glitch trivializes the game, I like the complicated setups!
I fully agree, the crazy setups is what makes the warpless run so entertaining, and a warpless PAL run would be significantly different.
However, I don't think this is much of a factor for the warped run, just because there are no such setups, except for a single level. And to compensate, the PAL version has nice tricks of its own, like the floor clip.
But won't accepting this be a slippery slope, the warpless run will be next, then other games. We'll end up with all these PAL runs!
Firstly, I doubt a PAL warpless run would actually be faster than the NTSC version. PAL has many areas where it is significantly slower than NTSC, and I don't think it can make up enough time to compensate.
More generally: There's nothing wrong with using different versions if they provide advantages, and most of the time PAL will just be slower.
This is a rare case where it isn't, and the fact that they are so close is amazing actually, e.g. a single new NTSC flag pole glitch could make NTSC faster again.
But I like the NTSC version more!
I understand, but I don't think that should be much of a factor in this decision.
SMB1 is special in the minds of many people, since it is so iconic and recognizable, and I think this blinds many people to the facts.
NTSC is the version most commonly used, by casual players and speedrunners alike, but that doesn't change the fact that there are faster official versions of this game, and they have just used a slow version all this time.
For most other games, this would be an easy decision, just use whatever version is fastest, but for SMB1 people are too fond of their childhood memories.
Whether SMB1 is "special enough" for the NTSC version to receive its own category is up for the judges to decide, but IMHO it should be clear that PAL is the main version for warped runs, and NTSC is the side category because it's a popular but slower version of the game.
PAL versions of games have a bad reputation on this site, they are treated merely as second class, poor ports, cheap knock-offs of the "original" game. This may be true some of the time, but certainly not always, and I think this is a case where the PAL version should be treated as equivalent.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
jlun2 wrote:
Does the game still work after the credits? lol
Either way, that was the best ACE TAS so far for pokemon. Amazing work! 🙂
Edit: I just realized rather late you have 0 pokemon when at the Hall of Fame. How much of the story flags does this break? Would the game still allow you to grab a starter post credits?
It resets all the flags (and generally most of the memory) when giving control back to the game, so you can in fact play the game normally as if nothing ever happened after the credits. You'll get Pikachu as your starter as usual, fight your rival, etc. It's not perfect (e.g. you'll find multiple Oaks roaming in Pallet Town), since I just clear the memory instead of resetting it to its original state, which would have been possible as well but would have involved many more inputs for little added benefit.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
The game link port has a transfer rate of 1kib/sec, which would be significantly slower that what you can achieve using joypad inputs with a theoretical maximum of ~200kib/sec. The limiting factor is not really the joypad inputs, but the CPU speed to process all that incoming data and do something useful with it.
EDIT: out of curiosity, I calculated the bit rate of the SpongeBob sequence, which turns out to be ~95kib/s of useful A/V data. The other time is either used for transferring auxiliary control information or spent processing the incoming data or maintaining the HiColor image.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
Nach wrote:
I dislike the focus on technical qualities. As for visual audio, it shouldn't just be about being "new". Any game can be turned into a jukebox and display the player's name in their favorite color, I don't think that should be a goal though, and it gets awfully repetitive fast.
Our players should muster their creativity and provide something fitting for the game at hand, to alter the existing story in funny ways, or add on fun and entertaining abilities. This run is terrific because it took Pokémon, and added on more Pokémon-related things, and did other things within the setting the game already has. It was an extension of the story, and it's entertaining. The payload here could be ran on other games too, but it wouldn't have the same impact if this is what we saw in say Link's Awakening DX. If someone was looking to run something crazy on LA DX, they should choose things more fitting for that game.
That was my biggest fear in creating and submitting this run: Now that I have powerful tools to take control and do whatever I want, I will be measured not on how great these tools are, but what I made out of them. The crispest audio and video isn't worth much when the entertainment value of the content isn't there, and that entertainment value does depend on the base game as its context.
I confess I was more interested in the technical side when I started this (which probably shines through in my submission comments), and never thought of myself as a creative person, so the prospect of being judged based on my creativity to come up with an entertaining storyline with virtually no restrictions imposed by the game scared me greatly.
That's why I'm relieved to see all the positive feedback in this thread, especially the ones about the content rather than the technical implementation.
Ferret Warlord wrote:
I have to ask, it the viewer were to stop playback at any point, how far into the respective game could the player get, IE how many screens of Link's Awakening were programmed?
It is emulating only the A/V of the game, not the game itself, and will crash immediately when you try to take control.
DrJones wrote:
Is it possible to hardware verify TASes in the Game Boy Color?
Hardware verification at least for this TAS is very unlikely, the precision required to sync the inputs it up is likely to great. In general, I think it's a reasonable question though whether an actual Game Boy could do what this run did, at least in principle (i.e. rule out that emulator inaccuracies were exploited). The best you can do to test that would probably be to create a custom ROM that does these things without any inputs and flash it onto a cartridge that you can play in a Game Boy. That isn't really a fair test, since the cartridge itself is part of the system under test, and you exclude the whole joypad input side, but it would at least determine the plausibility that GB hardware can achieve what is seen here.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
got4n wrote:
EDIT: I guess the portal sounds were edited in? Doubt the GB can support that
There is no editing whatsoever in that video, exported straight from lsnes. To be fair, the GB was not *meant* to support that, but that doesn't mean it can't.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
Spikestuff wrote:
I kinda don't want to be a jerk but you left a blank input at the very end. :V
That is actually an intended part of the input. It's the last sub-frame input of the last frame. Afaiu lsnes uses the last sub-frame input for all remaining joypad polls in that frame if it runs out of sub-frame inputs to use, so removing it would result in different behavior.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
partyboy1a wrote:
I found a minor mistake: at 1:48:34 you are caught by Team Rocket, instead of going one step left and talking to them. It's only two extra steps, and you told us that up to three would be faster, so that wastes potentially about a fraction of a second. Or would they turn around and still catch you?
This is on purpose, getting seen is actually faster in this case. You need to consider that you are one tile further up in relation to the rocket, so when it walks away after the fight it has one less tile to walk before it leaves the screen, making it faster overall.
The optimal route with these rockets is not obvious, but it turned out just heading straight up is the fastest.
Pokota wrote:
There's no turning npcs that do on-sight battles in Gen 1, so the next question is "do the runs no longer sync properly at the next trade point without that wasted time?"
You cannot sync them back up at any point, you'll always need to do everything again for both games after the next trade. The only bit you can re-use is the other game's run until the next set of trades.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
Even with the long credits sequence at the end, the Elite Four are a very good place to get XP, because trainers give 1.5 times the XP you get compared to wild encounters. There are a few faster ways to gain XP in the game, but most of them involve Cerulean Cave (a wild L64 Chansey is 2331 XP, which is the best you can get repeatably afaik).
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
Kara Jade wrote:
I wonder if there are any more Pokémon that Red could have caught or evolved in order to save a trade or two? Obviously, three limiting factors are the amount of XP attainable in the run, how much cash is available for evolution stones, and how much time would be needed to catch another Pokémon. Something to roll around in my head, I guess :)
There are, notably Butterfree, Tentacruel and Sandslash, but trading from Blue to Red is not the limiting factor, but trading from Red to Blue. These trades from Blue to Red are just fillers to balance out the trades, Red could have easily obtained them itself. But Blue is the side that needs to be faster, so Blue does not do anything to obtain a Pokémon that would be slower than trading it, including in-game trades (Mr. Mime, Lickitung, Jynx) or the Old Amber, which is why more trades than absolutely necessary are made.
In the first two attempts, I optimized by the number of trades, and had a whole set of trades less. I assumed that less trades means a lower time, but that's not always the case.
Kara Jade wrote:
I hadn't realised that the link cable had been successfully emulated yet. What a pleasant surprise!
The link protocol (if you even want to call it that) of the Gameboy is very crude and low-level. It's basically swapping bytes one at a time on a clock. It's easy to emulate since the game actually needs to do all the hard parts of the communication protocol.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
Bobo the King wrote:
This is a very minor point, but I'm still curious. You comment that it saves time to approach trainers by up to 3 steps (7 if bicycling). Does this include the additional time it takes to step around them afterwards? I know it's standard procedure to approach trainers, but it just seems fishy to me that you'd want to walk up and back rather than wait for the exclamation mark to pop up, especially if they're already next to you.
It is the total number of additional steps compared to getting spotted, so the ones you need to trigger the fight plus the ones you need to get back on track afterwards. This does not however count the amount of steps the trainer needs to get to you after being spotted. Each step they need to take add two additional steps (4 on a bike) you can take (since npcs move half your speed; also being at point blank takes slightly longer than the rule of thumb would suggest iirc).
boct1584 wrote:
Here's another question from me. After the diplomas, how much more time would it take for both games to go fight the Elite 4 and plus Rival? I feel like doing that would provide a better ending point.
Fighting the Elite 4 would be surprisingly hard, since you don't have the PP to OHKO your way through like the first time, and there aren't too many available high level Pokémon to fight with.
You could probably make it work by assembling some party with effective moves for both games, but the actual reason I didn't do it is that it would make an already long run even longer without really adding anything to it.
MUGG wrote:
boct1584 wrote:
Here's another question from me. After the diplomas, how much more time would it take for both games to go fight the Elite 4 and plus Rival? I feel like doing that would provide a better ending point.
Didn't watch, but I thought you need to fight rival to unlock Mewtwo. Is that not part of this run?
Maybe what I have in mind is a Pokemon Yellow thing...
You're right. Only Blue fights the Elite 4 though, and then trades the Cerulean Cave encounters to Red later.
Masterjun wrote:
How is the re-record count calculated?
Great question! Defining what counts towards the re-records is not as obvious as it first seems. (Consider: if you scrap a whole section you did, do they count towards the rerecords? What if you majorly re-route? What if you start from the beginning? What if you are doing some testing purely for science? Where do you draw the line?)
When generating the run, I used a pretty narrow definition of what counts. It counted every load of a savestate made in the same session as the savestate that ultimately became the final product. That means a whole lot of rerecords I did (including explorations, testing, and the many half-finished and discarded runs) are not counted. The two games were run and optimized separately, and their rerecords were summed to get the final result (which are ~150m for Blue and the rest for Red; Blue got some more optimization since it is the bottleneck).
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
Fishaman P wrote:
MrWint wrote:
It will likely be faster. Note that the amount of trades each of the games has to do will not actually increase (ideally they do half of them with each of the other two games), and you save like half an hour from Red not needing to restart.
This makes it sound like the goal is to collectively complete the Pokédex, but not necessarily a single game registering all 150. Is this what this submission does, or am I missing something?
I think you are thinking about the trades the wrong way. Say for simplicity, each version needs 30 Pokémon traded to it that it won't catch itself. For two games, this would mean that they need to do 30 trades, which are beneficial for both sides. For 3 games, each of the three games can do 15 trades each with the other two games, and as long as they're all mutually beneficial, all of them complete their trades and their Pokédex, and still do only 30 trades each like before. The number of games is irrelevant, the number of necessary trades each game has to do is constant.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
It will likely be faster. Note that the amount of trades each of the games has to do will not actually increase (ideally they do half of them with each of the other two games), and you save like half an hour from Red not needing to restart.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
Pokota wrote:
subtitle 500 130 322 324 FFFFFFFF This is a tool-assisted run of Pokemon
subtitle 500 110 337 324 FFFFFFFF Blue (on the left) and Red (on the right).
I presume the first number is the frame the subtitle appears on, and the 4-byte value is the color information (probably ARGB since the first byte never changes). Are the 2nd and 3rd numbers positioning, and the 4th duration?
subtitle 272650 115 322 336 FFFFAAAA In addition to knowing Teleport, Abra can
subtitle 272650 110 337 336 FFFFAAAA conveniently also be traded for Lickitung.
You trade the Abra for a Mr. Mime, not Lickitung. The Lickitung trade comes later with a Slowbro.
You're absolutely right, my bad.
Fortranm wrote:
The subtitles mention that Abra is important for Red to skip getting Cut, but couldn't you just go through the tunnel after leaving Magikarp in Day Care? What's the difference other than having a chance to capture Diglett and Dugtrio?
There are two mandatory trainers on Route 6 that are avoided by using Teleport. Also, it offers a convenient opportunity to trade for Mr. Mime.
Fortranm wrote:
The subs also mention that Blue skips the abandoned Power Plant because it's too out of the way, but how is it more out of the way than the Seafoam Islands? Is it because there are too many Pokemon that have to be caught in Seafoam Islands so trading all of them is not worthy?
Yes. In the Powerplant, Blue is only missing out on 4 Pokemon: Elektabuzz, Voltorb, Magnemite and Zapdos, whereas in Seafoam Islands there are 13. Trading them all is more work. Also Powerplant is actually objectively more out of the way than Seafoam Islands :)
Fortranm wrote:
The last one is about the emulator. Does the dual Gameboy mode of Bizhawk support only two games running at the same time? Is it possible to run, say, Yellow, Silver, and Crystal at the same time and trade between different games at different time?
I could actually create a run like this with more than 2 games with the tools I used, but you wouldn't be able to play back the result in BizHawk.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
Mr. Pwnage wrote:
In the third series of trades, wouldn't it be better for Red to send over a Wigglytuff instead of Pikachu? That would let Blue trim out the Wigglytuff encounter in Cerulean Cave, and let Red skip catching a second Pikachu at the Power Plant, since it still has the first one and can just evolve that instead.
You have a valid point, but there are some problems. Blue still needs to get a Pikachu somewhere, and since Blue doesn't visit the Powerplant and hasn't bought any Poké Balls when crossing Viridian Forest, that's not so easy. Blue would either need to buy some in Viridian (but then still need to visit the Mart in Pewter for Escape Ropes), or collect it in Viridian Forest, which is very much out of the way. And since this run ends up being bottlenecked by Blue and not Red, Trading the easy Wigglytuff encounter for Blue against an additional Pikachu encounter for Red made sense.
That doesn't mean that this is strictly better, it just turned out to be better for this route.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
Nicos wrote:
hi, i'm still 40 Min in,
but wouldn't it be faster to invert the starters ( charamander in blue and squirtle in red) and trade them right after the first fight ?it would allow you to not stop the first evolution and save frame for every levels , or is it longer to initiate a first trade ?
This wouldn't work, you can't evolve them even after trading them, since Red will still need to restart, wiping Red's Pokédex. And trading them only for boosted XP is likely only making the problem worse, since you'll gain more levels you need to cancel the evolution for, on top of the time it takes to do the trade. Still, I must confess I didn't properly consider this when making the run. There are just too many possible things you could do.
Twisted Eye wrote:
Only bummer is that choosing to make Red's audio the main source of the encode prevents us from hearing the awesome Champion battle song,but that's superficial.
I had to make a choice, I'd have chosen Blue's sound if it weren't for the gambling. The constant jackpot sounds gets old very quickly.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
Lex wrote:
Is it a sort of brute-force input algorithm, or does it know a lot about the game?
It knows a lot about the game mechanics and makes assumptions based on that. It basically has an internal state about what it thinks the game state is, presses buttons blindly trusting that the game will behave in the way it expects. E.g. in battles it calculates the min and max damage you can do with each attack based on your and your opponents stats and plans the turns of the fight according to this. This may sound brittle and unreliable, but is useful to test your assumptions, because your route likely relies on them. For example if your calculation of how much damage you can do is off, you want to know that since it may mean your route as a whole is flawed.
I had the whole run planned out in a spreadsheet before starting, with all fights, which attacks to use, how much damage they will do, which trades to make, etc. Without that knowledge, you can never be sure that the route you chose will work out in the end, since there's a lot that can go wrong: You're missing items you didn't buy, you ran out of PP for a move you need, your box is full when you want to catch something, etc. (these are all things that actually happened to me despite the planning by the way).
and to mix the audio streams (hearing one game in each stereo channel is not the most pleasurable experience)
Would it be better if the default sound output from bizhawk dual gb worked differently?
No, I think this is fine, because it allows you to extract the isolated audio streams and manipulate them as you want. It's hard to assume anything about how to best setup the audio mixing.
For this encode I ended up mixing them into a single mono channel with Red in the foreground and Blue more quiet in the background (-af pan=1:c0=.015*c0+.085*c1), but that may not at all be what you want for other instances.
The comment was more about that you need to do something when encoding, because while the default output is convenient for post-processing, it's not easy to listen to in that state, at least when you constantly hear two slightly offset overlapping versions of the Pokémon tune.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
Spikestuff wrote:
Aw.... no subtitles, even though the YouTube got annotated, that's fine.
I do have the subtitles, but I decided to not include them in the submission. Subtitles in BizHawk are specified in client coordinates, which means they shift around depending on how you scale the game. I didn't want to assume things about how the movie is played back, so I left them out and created an encode for them instead.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
I have no experience with the select glitch, so I can't say anything about whether it's used appropriately in this run, but I noticed a couple of other things:
- For the Bulbasaur fight, you don't need the crits, 4 non-crits (with 5 dmg each) are sufficient and save you the "Critical hit" text.
- Your movement on Route 1 is suboptimal, you are taking several unnecessary steps both on the way down and on the way up again.
- Fighting the Caterpie in Viridian Forest takes three turns, but you can get away with only two if you fight a weaker enemy, like a L2 Rattata.
- Getting spotted by the Bug Catcher is slower than talking to him directly.
- The Bugcatcher's Weedle can be beaten in 5 turns instead of 6.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
I'm happy to take a look at your WIP, but it may take a while until I come around to looking at it closely. I'm sure others are happy to help you, too.
ALAKTORN wrote:
MrWint why don’t you make your code public so other people can use it to make Pokémon TASes?
The code is hacked together for my personal use, I didn't bother make it any pretty or easy to use. If I published in its current state, I'd need to do constant tech support duty for all the quirks it has. Tbh I'd like to keep it as a personal project, not extend into some fully supported piece of software that I have to spend time maintaining. I originally planned to pretty it up in the end but never came around to doing it (making new TASes is just more fun than refactoring old code). With the comments I saw in leopo89's last submission though, I see that it may be necessary. It seems I created unreasonable (and wrong!) expectations for TASes of these games. I'm glad that my submissions were well-liked, but execution is only a small part. You can optimally bot all you want if your route is suboptimal, a few lost frames are irrelevant compared to the seconds or even minutes you can easily lose/gain in these games (im)proper routing.
I'll make it public, but don't hold your breath for it. In the mean time, please don't judge submissions purely on the fact that it doesn't have millions of automated rerecords :).
