Very short run, shorter than short. The game is beaten by simply starting it.
Game objectives
Emulator used: BizHawk 1.11.4
Win in shortest time on any mode
Comments
On frame 0 I needed to decide between pressing select or not to win. It changes the initial movement of the ball.
Other comments
Sub-frame wars go!
Noxxa: Delaying, pending investigating of accuracy between Atari 2600 emulators.
Noxxa: This run has been proven to be the result of emulation errors, which are being corrected in newer revisions of BizHawk. As such, rejecting this run for being invalid.
@FractalFusion: thanks for clarifying that, yeah I was wrong there as well, it does in fact go to the proper hard difficulty in both cases.
As for IRC, I tend to only be online for sporadic periods of time, but if it will help get this cleared up then I will make an effort to go there, I'm definitely at my limits of being able to follow what Bizhawk is doing in terms of the C# code, and a simple 1 frame movie is definitely the time to get these things sorted out, maybe even finally solve that old dragster problem!
You mean still?
I discovered horrendous issues months ago with the way Bizhawk emulates the 2400! The Smurfs game for the 2400 is completely unplayable in Bizhawk last I tried (probably more than a few versions ago) because it is utterly impossible to get to the next screen. There are also weird objects blocking pathing in Yars' Revenge; in Stella as well as on an actual machine, no such objects exist at all. Dragonfire causes the hero to teleport behind the door in the treasure rooms under conditions I was never entirely clear on; on an Atari 2400 or on Stella, the hero would have to run all the way back to the door to hide behind it.
So while I try to get visual studio working so I can try working with Bizhawk, I decided to work the other direction and see if I can make Stella match Bizhawk results.
Turns out, it is easy, and it resolves a lot of the mystery.
The key difference is that Stella assumes a 'Frame' is 262 scanlines+extra scanlines. So when you hold a button down and 'Frame Advance' in Stella, it holds the button until we are back at line 1 again. But, Bizhawk (apparently, I haven't found the code where it says so) counts a frame of input as 262 scanlines ONLY, so only holds the button down for that long. So I released the button in Stella after 262 scanlines and like magic I got the same results as in Bizhawk! Mystery solved!
EDIT: Actually, this seems like a glitch in the game code since way more scanlines are being used then 262. I'm still looking into it.
Well, part of the mystery. The movie starts the same but diverges shortly after. And this doesn't effect visual or audio glitches as far as I can tell.
So I guess the question is which is correct? The game is certainly checking whether a button is held down or not during VBlank, so that seems right to me.
Emulator Coder, Site Developer, Site Owner, Expert player
(3571)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
Both are correct! Typically emulators define a frame based on a video frame but that is arbitruary. In AtariHawk, a "rounded" frame approach is taken where each "frame" is sliced evenly rather than by video which can be variable in length.
This is all independent of when input can actually be accepted. So the bizhawk method is perfectly acceptable and so would the "sella method" of defining a frame.
And so would other methods that slice even smaller and allow for for sub-frame input.
You can get this result in real time, because it doesn't happen only if you start the game in the first frame, but you can't do it with only 1 frame of input, obviously.
Since the TAS movie would look quite indistinguishable from Alyosha's RTA, the question then becomes does the fact that there's only 1 frame of input enough to justify the TAS being on the site?
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
c-square wrote:
BrunoVisnadi wrote:
You can get this result in real time, because it doesn't happen only if you start the game in the first frame, but you can't do it with only 1 frame of input, obviously.
Since the TAS movie would look quite indistinguishable from Alyosha's RTA, the question then becomes does the fact that there's only 1 frame of input enough to justify the TAS being on the site?
I'd actually say it's alright. We have real-time speedrunners skillfully reproducing tas-only (as it was believed) strats, and we don't unpublish such tases just due to that. Because tases still differ by precision. If you think about a 1-frame movie, it might seem that it's too similar to the slightly longer real-time run, but now even Gimmick's tas strats are reproduced, and for some reason no one thinks Gimmick is not worth having a tas for. Because of precision. And in this particular case, 1-frame movie is just simply fantastic to have!
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
You can get this result in real time, because it doesn't happen only if you start the game in the first frame, but you can't do it with only 1 frame of input, obviously.
Since the TAS movie would look quite indistinguishable from Alyosha's RTA, the question then becomes does the fact that there's only 1 frame of input enough to justify the TAS being on the site?
Yes, I agree. As our guidelines state, a run must beat all known unassisted records and be distinguishable from the best real-time speedruns. This run does neither.
feos wrote:
We have real-time speedrunners skillfully reproducing tas-only (as it was believed) strats, and we don't unpublish such tases just due to that.
I fail to see how that's an example, considering the RTA you link takes about 11 minutes, whereas the TAS is twice as fast ([1543] NES Gimmick! by Aglar & Hotarubi in 05:11.49). If a new TAS were submitted wit the same length as an RTA (or close to it), it would be summarily rejected for being suboptimal.
Perhaps this can be put in Gruefood Delight for the novelty of having a one-frame input, but otherwise I don't think this should be published.
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Radiant wrote:
feos wrote:
We have real-time speedrunners skillfully reproducing tas-only (as it was believed) strats, and we don't unpublish such tases just due to that.
I fail to see how that's an example, considering the RTA you link takes about 11 minutes, whereas the TAS is twice as fast ([1543] NES Gimmick! by Aglar & Hotarubi in 05:11.49). If a new TAS were submitted wit the same length as an RTA (or close to it), it would be summarily rejected for being suboptimal.
First of all, it's a 100% speedrun. If you watch this and the RTA, you'll see how similar the strats are. And it's not about total time, it's about precision.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
I agree. As our guidelines state, a run must beat all known unassisted records and be distinguishable from the best real-time speedruns. This run does neither.
So this 1 frame movie doens't beat all known human records? Nor is it distinguisable from unassisted play?
If you look a little bit into the movie, there's a major glitch used: while the game lags for a few frames on startup, pushing B as soon as the game is started immediatly starts the game. This is a one frame window. So while it is trivial to reproduce on emulator, by simply holding the keys before the game starts, I'd like to see an human power on an Atari 2600, then press Reset and Select on the console and Button on the controller immediately after, all in a one frame window.
If we went with all modern speedrunning timings, the run would aim for fastest completition of the game, not least frames of input - so this would be irrelevant. And this would mean the game would have to be played; a major difference from a real-time run.
Radiant wrote:
feos wrote:
We have real-time speedrunners skillfully reproducing tas-only (as it was believed) strats, and we don't unpublish such tases just due to that.
I fail to see how that's an example, considering the RTA you link takes about 11 minutes, whereas the TAS is twice as fast ([1543] NES Gimmick! by Aglar & Hotarubi in 05:11.49). If a new TAS were submitted wit the same length as an RTA (or close to it), it would be summarily rejected for being suboptimal.
Perhaps this can be put in Gruefood Delight for the novelty of having a one-frame input, but otherwise I don't think this should be published.
TASes aim for fastest time overall. This means that with very tightly optimised RTAs, it won't beat it by much (or even tie it, in some cases.) But this hasn't been ever grounds for rejection, as this is tasvideos.org - a site where we publish the fastest TASes, no matter if they are only even a frame faster than a RTA run. Even in extreme cases such as these, this movie is the fastest way to beat the game.
I should stress that the different timing only solves the problem up to the end of the input frame. (I.E. the ram states match and the ball actually starts off going in the right direction.)
I still lose the game in Stella, even starting from what is now the exact same state.
But at least now it will be easier to find out what's gone wrong, can't get much simpler then watching 2 games play out with no input and spotting the difference.
Well, this has been quite a treasure hunt!
After a lot of time staring at code and Atari documents and looking at many frames and scanlines, I think I understand what went wrong here.
All of this comes down to a color clock delay in drawing double sized players. Bizhawk misses this delay and thus double sized objects, such as Pterry and the countdown numbers in Flapping, are drawn one pixel too far to the left compared to real hardware. Those interested can download the neat test ROM from this thread and compare BizHawk and Stella, pretty neat demonstration!
http://atariage.com/forums/topic/239890-respx-nusizx-and-player-positioning/
Anyway, this is not simply a graphical glitch, for the TIA also does hardware level collision detection, and in a literal case of threading the needle, this is where things go wrong.
After I understood the difference between inputs in Stella and Bizhawk, I was able to compare frames and see where things went wrong, and it all comes down to that one pixel shift. Illustrated below is the frames right where the game diverges between Stella and BizHawk:
Stella:
BizHawk:
So in Stella we see that, in an amazing coincidence, the ball moves directly into the birds eye! So the TIA does not count this as a video collision, and the ball carries on for one more frame. But, this isn't the case in BizHawk, that one pixel shift means that the ball and the player collide 1 frame earlier, and everything diverges from there.
In the end, the Stella game goes on to lose, while the BizHawk one goes on to win, all because of 1 pixel of shift due to an obscure hardware level delay.
there is still more to research and AtariHawk is doing several other things differently from Stella, but for this game this is the deciding factor.
Huh. Completely unrelated to this game, but I wonder does the difference between stella and AtariHawk also affect other games? I recall 2 incidences of AtariHawk being different:
River Raid:
A commented disassembly by Thomas Jentzsch was helpful in figuring out how to manipulate enemy movements. Not sure why, but the memory addresses in the source don't match what's used in the emulator.
Not sure about river raid, but Atari's memory has lots and lots of mirrors so that could be it.
Dragster probably has something else going on that I haven't gotten to yet, possibly related to how the paddles act a little differently here in BizHawk then Stella.
But, the reason 'O' in POWER in the game H.E.R.O. isn't properly drawn is probably the same reason the title screen here isn't correctly drawn. In that case writing to the GRP0 register is happening at the same time it's being drawn, when there should be a one cycle delay.
Emulator Coder, Site Developer, Site Owner, Expert player
(3571)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
Alyosha's digging around led to some real improvements to the atari2600 core! With this commit the double and quad size player timing bug has been fixed.
As speculated, this fix breaks sync with this "TAS". It no longer syncs and like in stella, the opponent wins. I think this is definitive proof that this submission relies on an emulation error to achieve its results.
Future TASes of this game, of this nature, should use this fix. Also there are more to come so no one should rush into TASing with this change.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Being accepted or rejected is not a matter of fault.
The movie relies on emulation errors and is therefore rejected.
If a player wants to know for certain, they can study the emulator, compare against a console and so on. However, this is not a requirement in making a movie.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 8/14/2009
Posts: 4089
Location: The Netherlands
ALAKTORN wrote:
It’s unfair that a user can get a rejected movie mark through no faults of his own. How was he supposed to know BizHawk was inaccurate?
If he really wanted to avoid the "rejected movie mark", he could have cancelled the movie any time after it was revealed that the movie didn't sync on a fixed BizHawk version. Which was around five days ago, so it's not like he didn't have the chance either.
Submissions that depend on emulation inaccuracies are rejected, regardless of whether the author was aware of it or not before it was submitted. It happens sometimes.
http://www.youtube.com/Noxxa
<dwangoAC> This is a TAS (...). Not suitable for all audiences. May cause undesirable side-effects. May contain emulator abuse. Emulator may be abusive. This product contains glitches known to the state of California to cause egg defects.
<Masterjun> I'm just a guy arranging bits in a sequence which could potentially amuse other people looking at these bits
<adelikat> In Oregon Trail, I sacrificed my own family to save time. In Star trek, I killed helpless comrades in escape pods to save time. Here, I kill my allies to save time. I think I need help.
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
I'd point out that runs aren't rejected just because they desync on console/more accurate emulator. It has to be a deep bug preventing theoretical console replication entirely.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
It’s unfair that a user can get a rejected movie mark through no faults of his own. How was he supposed to know BizHawk was inaccurate?
I don't think it's unfair that this movie got rejected due to innaccurate emulation, this movie didn't take a long time to make anyway. And having rejected movies is not the end of the day.
With the current build the fastest I got so far is 3 frames.
BizHawk:
So in Stella we see that, in an amazing coincidence, the ball moves directly into the birds eye! So the TIA does not count this as a video collision, and the ball carries on for one more frame. But, this isn't the case in BizHawk, that one pixel shift means that the ball and the player collide 1 frame earlier, and everything diverges from there.
In the end, the Stella game goes on to lose, while the BizHawk one goes on to win, all because of 1 pixel of shift due to an obscure hardware level delay.
there is still more to research and AtariHawk is doing several other things differently from Stella, but for this game this is the deciding factor.
