This topic is for the purpose of discussing #5195: Aglar's NES The Flintstones: The Rescue of Dino & Hoppy in 13:32.55

Nice improvement! This new boss-fighting method looks like what I would expect from a dumb caveman, swing fast and furious until the enemy dies. The water stage also looks a lot smoother without the awkward ledge-pulls near the end. One minor complaint: you didn't chase out the vampire boss in the way I suggested for adelikat's currently published run in its discussion thread :/ Also, I know that the glitching of the future stage's elevator saves tons of time, but I've sort of missed seeing speedruns play through that area. It's so much harder platforming than the whole rest of the game, and I remember having a lot of trouble with it playing this game when I was much younger.

GRAND DAD!? FLEENSTONES!? Nice improvement, yes vote.

NES TAS of the Year. Yes vote

TAS by Aglar 8-D

The music is horrible but the gameplay is good. A weak yes for you.

We discovered a new glitch that is effective in saving of time. 80 frames saved! Link to video After, Nice improvements, YES vote!

Will never understand how people find stuff like this :D Anyway, here's the run with the glitch included. Please replace the existing submission file with this one: http://tasvideos.org/userfiles/info/33056559340655847

PGCX864 says the screen-wrap saves 80 frames, but the new file is only 64 frames faster. Were those 16 frames unavoidably lost, or was it just a miscommunication in how much time is actually saved?

PGCX864 says the screen-wrap saves 80 frames, but the new file is only 64 frames faster. Were those 16 frames unavoidably lost, or was it just a miscommunication in how much time is actually saved?

The second form has a 64 frame rule for when it can be defeated :/

Miscommunication, then. Thanks for clearing it up!

Small timesaver found, relatively late in the run, so I'll add it in. Please wait with the publication.

Here it is: http://tasvideos.org/userfiles/info/33149401386582222 Sorry for the inconvenience!

This movie has been published. The posts before this message apply to the submission, and posts after this message apply to the published movie. ---- [3208] NES The Flintstones: The Rescue of Dino & Hoppy by Aglar in 13:32.55

Hey Aglar, with big 20 practice still going on it probably isn't a huge surprise that a new time save for this was found. I'm not sure if it will be allowed for the race since the rules tend to discourage using controller 2. Runner themotherbrain86 found that if he held B when going in the door to dracula he would just fly away and you don't need to fight him at all. As it turns out he had is B button mapped to both controllers. I'm not sure if there are other places in the run where controller 2 might influence things, but it might be worth trying some other experiments as well.

A new trick found after my submission - how unusual ^^. You can also push either of "up", "down", "B", "A" and "select" for the same effect. Anyway I don't know if this would be allowed on TASVideos either. Second controller inputs are often viewed upon as debug codes. It exists for example in The Legend of Zelda (allowed) and Mega Man 3 (not allowed). My spontaneus thought is that it shouldn't be allowed.

Here's some half-assed debugging. Frame references from this submission file. At 33015 it takes p2 input and stores it at $0367. Only B was pressed in this example:

07:F8E8:A5 10     LDA $0010 = #$40
07:F8EA:99 67 03  STA $0367,Y @ $0367 = #$40

Then at 33024 we get this:

07:E540:BC AB 04  LDY $04AB,X @ $04B0 = #$00
07:E543:B9 67 03  LDA $0367,Y @ $0367 = #$40
07:E546:A8        TAY
07:E547:D0 1D     BNE $E566

Meaning it will only branch to $E566 if there was p2 input at frame 33015. That eventually leads to here:

06:A768:BD 63 04  LDA $0463,X @ $0468 = #$40
06:A76B:29 C0     AND #$C0
06:A76D:9D 63 04  STA $0463,X @ $0468 = #$40

Depending on what p2 input was at 33015, that will result in storing either #$40 or #$C0 in $0468. #$C0 = drac stays, #$40 = drac goes. And I stopped looking at that point. Obviously, that's not a complete picture. but hopefully it's something to go on. Maybe a conditional (say, if $10 = specific p2 input) breakpoint on 07:F8E8 would turn up something else in another part of the game. Edit: I set p2 input to hold BTULR and set an execute breakpoint on $F8E8 with the condition K==#07 && $10==#5B and came up with this list of frames where p2 input might do stuff. Most of them seem to cause desyncs, but I didn't bother looking into why.

6
281
328
4260
4996
5043
7557
13162
13896
13943
16198
17093
21061
21108
22582
27591
27638
29890
29936
31806
31852
32969
33015

Surely more possibilities past that point too, but I'll leave the rest to somebody else. I'm leaning slightly less towards 'debug feature' now.