This topic is for the purpose of discussing #5035: TASeditor's A2600 FlapPing in 00:00.05

Here we go again. Giving this a Yes like before.

Too frames 2 far from ABSOLUTELY FASTEST POSSIBLE, voted No.

Yes vote for the unsurpassable run. What a stupid AI...

So far I am unable to reproduce this result in Stella. It is difficult to reconcile the different frames timings between the two emulators, so it may not be possible. I suspect very strongly that BizHawk is incorrectly managing frames that are shorter then normal, although I can't follow the code well enough to point out where. But, at least now it isn't (aside from the title screen) blatantly wrong so maybe it's close enough, although my personal opinion would be that it isn't. As a side note, I have never won a game in Stella with no input, despite numerous attempts. Obviously this isn't proof of anything, just an observation.

I almost gave this a yes because of that sick comeback.

Well done! I will try to console verify this, but I have other priorities this week (namely SGDQ 2016 submissions) so it might not happen before this is judged. I may even give a try at doing it by hand, but it would require frame precision that I don't think I can do.

Well I don't know how I didn't notice this before while meticulously studying pterry's movement, but he quite clearly also suffers from the 3-2-1 bug. This bug is a piece of code originally borrowed form the Atari 7800 emulator which was meant to model some curious behavior in a couple 2600 games. However it seems the code itself was just a hack, it has no discernible benefit and breaks several games (i.e. Smurfs and Halo 2600) and has bad effects in others (Dragster.) In this case what it does is push pterry towards the right one pixel when he reaches the left edge of the screen. You can see this happen around frame 290 in this movie. This changes the timing of when pterry reaches which side of the screen. Since it happens every time pterry hits the left side of the screen, the effect is cumulative over the the course of the movie. It causes the run to desync with Stella around Pterry's third loop. This bug also effects the published runs of Airlock and Bobby is Going Home. I think emulation still needs to be improved a bit more before this run will be a realistic representation of what would happen on console.

Why wasn’t this Stella implemented into BizHawk instead of whatever was done for the Atari core?

So I made a build of atariHawk that removes the 3-2-1 code from AtariHawk. Curiously, this fixes the problems in Smurfs, Halo2600 and Dragster, but Pterry still exhibits the exact same buggy behavior. So there must be something else at work that is causing problems that I have not found yet. Another thing I noticed is that the ball's initial motion is different in Bizhawk previous versions of bihawk compared to 1.11.6 for this movie. 1.11.6 agrees with Stella, while older versions do not. However, older versions agree with the build I just made removing the bug. Very strange. My guess is that all of these are ultimately interconnected but I haven't tracked down how yet.

Pretty optimized. Yes.

"The less effort, the faster and more powerful you will be." ~ Bruce Lee

So far neither the 6532 timing bug nor the RESP bug have solved the sync problem with this game. I am at least fairly confident that I am recreating the run correctly in Stella, simply by running each input for 262 scanlines and letting it go from there. The run desyncs around frame 956, where the collision with Pterry happens 1 frame earlier in BizHawk then in Stella. I thought the 6532 timing bug fix would resolve this but it happens the same way. The RESP bug has no effect since no collisions occur in that region of the screen between Pterry and the ball (close to the left edge.) I do end up losing in Stella, so just like for the last run this is a rather consequential desync. I'm still looking into it though.

I suggest that a new category is added to the yearly awards, i.e. "Game/Run that Contributed Most to Improving an Emulator".

I have finally found where the desync happens. Turns out it is very similar in nature to the title screen bug. What is happening is that the write to Enable Missile for Player 1 (ENAM1) is happening on the same pixel as it is supposed to be drawn. In BizHawk, we get an immediate draw, but in Stella we get a one pixel delay in registering the write. In this case the one pixel delay causes the collision with Pterry 1 frame earlier (since the effect is shifting the missile down one scanline) and this is where the desync happens. I implemented the delay and indeed lost in BizHawk in exactly the same manner as in Stella, 8-10 For this case I couldn't find any documentation I could quote, so micro500 will need to weigh in here, but this is the cause and effect anyway.

Why wasn’t this Stella implemented into BizHawk instead of whatever was done for the Atari core?

I am curious about this as well.

Why wasn’t this Stella implemented into BizHawk instead of whatever was done for the Atari core?

I am curious about this as well.

Post #430053

Stella is more high level and they use more hackish methods to implement some features, including this starfield. They only recreate the behavior, they don't try to simulate the low-level effects (search for "cosmic" in this source file). I wrote Atarihawk to be close to cycle-accurate, and I prefer to only implement changes if they are well understood, instead of doing something because "that's how stella does it." I wish I understood how this starfield works, but until I do I am unlikely to implement it in Atarihawk.

Here you go.

Thanks, jlun2. I had actually read that post before, but I forgot. And thank you for your efforts, micro500. I respect that you won't rush for the sake of superficial functionality.

Well, I can't condone publication of a run that relies on an emulator inaccuracy, but I really enjoy the run concept and also this thread :)

Well it looks like all my updates got committed, so I think all the questions related to this submission are resolved. ENAM delay does indeed change the outcome of the game and is confirmed on console, so this run is based on emulation error. A side effect of all this is that the game is confirmed to be beatable on console, without even picking up the controller, in under 0.5 seconds (TAS timing.) So I wonder if this category is still viable? Maybe it's time go for an ingame time run?

LOL disappointment of the year.

om, nom, nom... blech!

I suggest that a new category is added to the yearly awards, i.e. "Game/Run that Contributed Most to Improving an Emulator".

Mario land 2!