Castlevania Speedrunning - User contributions [en]

Cv1/level2

2025-07-18T19:59:28Z

K c r: /* [Show/Hide] Stage 06/Medusa Boss */

{{Infobox level
| image = CV1 Level2.png
| game = Castlevania
| level_name = 2
| level_sections = Stage 4, Stage 5, Stage 6/Medusa Boss
| previous = [[cv1/level1 | Level 1]]
| next = [[cv1/level3 | Level 3]]
}}

== <span class="mw-customtoggle-0" style="font-size:large; display:inline-block; float:right;"><span class="mw-customtoggletext">[Show/Hide]</span></span> Stage 04 ==
<div id="mw-customcollapsible-0" class="mw-collapsible mw-collapsed">

{{#ev:youtube|WfmgpQEv6yI|550}}
=== Standard ===
*Once you gain control of Simon either walk or jump to the base of the stairs, climb the stairs and then jump to the next platform. Either when jumping (or after landing on the top platform) jump and activate the stop watch. Walk past the frozen knight and bat. The difference between activation during the jump from the first platform to the second is just comfort.

*Walk up the stairs after the bat and knight. Once at the top of the stairs jump to the platform. Jump up so your head at the peak of the jump is at the candle, once you land take a step or two and jump again to jump over the bat and land on the lower small platform after the knight.

[[File:CV1 Stage4 BatJumpStart.png|550px]]

If you do this correctly you will not touch the edge of the next platform, if you do not bump into that edge then you should be able to hit the framerule at the door.

*After jumping to the next platform, jump over the knight and onto the moving platform get to the door. You can optionally whip the candle before the door mid jump.

=== Axe Backup ===
*If you have the axe instead you can immediately throw an axe to hit the knight from below this will collect the cross from the first candle. Then throw a cross when jumping to the upper platform to kill both the knight and the bat.

{{#ev:youtube|uzc_okzIhac|550}}

</div>

== <span class="mw-customtoggle-1" style="font-size:large; display:inline-block; float:right;"><span class="mw-customtoggletext">[Show/Hide]</span></span> Stage 05 ==
<div id="mw-customcollapsible-1" class="mw-collapsible mw-collapsed">

===Standard===

*Watch for control of Simon (I usually look at the candles) after the door. Jump immediately to have the medusa hit spawn above Simon's head level so you can just walk to the left. You need to collect 6 hearts (5 to use the watch and 6th for a holy water throw in stage 6) - you can either collect one from a candle and then get the big heart after the knight.

{{#ev:youtube|d5DQsvkB6Qg|550}}

*Otherwise you can do the candle lottery. Similar jump immediately after the door but whip as well, collecting hearts from the higher candles. If you are not at 4 by the time you hit the raised platform it might be best to just grab the big heart.

{{#ev:youtube|YBW1UOnO3wE|550}}

*Once you go up the stairs do a whip buffer then jump over the two pits. Attempt to land as far to the left as you can on the second platform, pause and when the second medusa spawns jump backwards out over the pit taking a boost from the medusa to the upper platform. From there walk to the left and jump when your foot hits the following area:

[[File:CV1 Stage5 DoorJump.png|550px]]

===Advanced===

*You can make the frame rule at this door but it is tight. You need to not do a whip buffer, walk as far to edge of the first platform as you can without falling, then jump, move to the second block on the middle platform, do a jump to have the medusa head spawn higher, hesitate, jump to the next platform, then jump up and backwards to get boosted to the upper platform. Then walk left, and jump to the lowered platform at the door. Keep in mind this saves not a huge amount of time and if you miss you will fall into the pit. Credit evadecpatcha's pb video

{{#ev:youtube|CKzZM5mKg4g|550}}

</div>

== <span class="mw-customtoggle-2" style="font-size:large; display:inline-block; float:right;"><span class="mw-customtoggletext">[Show/Hide]</span></span> Stage 06/Medusa Boss==
<div id="mw-customcollapsible-2" class="mw-collapsible mw-collapsed">

NOTE: there is now an RTA viable Scroll Glitch in 6 - please see [[Cv1/ScrollGlitch | Scroll Glitch]] for more info.

===Standard===

{{#ev:youtube|ua2rLsdhSUM|550}}

*Walk off the very first ledge, then jump off the next one. Activate the watch when you go to jump up to the crushers platform and collect the Holy Water from the first candle. Walk under them and while holding left jump up to call the bat down, immediately jump again to boost up to the bone pillar platform. With the remaining heart, jump and throw a holy water at the next bone pillar. This allows you to walk through it but also hits the enemy enough times to get a 2x multiplier off of the next candle you break. IF the 2x multiplier falls in the bone pillar keep moving the candle at the top of the stairs should give you give you one as well.

*You can grab the rosary from the third candle in the hallway to Medusa. Grab the big heart from the candle last before Medusa's room, jump and throw two waters so you have 3 waters left.

===Lag Reduction===

{{#ev:youtube|TbDskup7FYY|550}}

*Alternatively when under the crushers and after collecting the water from the first candle jump and whip the remaining candles on the way to the bat boost. This should help reduce the lag in this area due to the number of sprites on the screen. The crushers won't kill you when frozen but once they become un-frozen it is instant death.

===Without Stopwatch===

{{#ev:youtube|uMw1digj2lE|550}}

*If you have been using Axe strats from Level 1, have lost the stopwatch by this point, or are attempting a category that doesn't employ subweapons, you can manipulate the crushers so that you can proceed quickly without dying. It requires one whip buffer before the third crusher has loaded (ideally between the second and third candles on the screen) then wait for the first crusher to hit the ground and jump up and forward after the second "tick" of movement up from the crusher. Be sure to whip while jumping so that you can get the holy water.

===Item Table Considerations===

*IF when boosting off of the bat up to the bone pillar platform you get a money bag you have just moved the item table. This means the first drop you get in the next level will be the money bag as well. If you want to again move the item table value you are on you can toss a holy water through two candles (after the rosary candle) and hit one of the medusa heads in the hallway to Medusa. This will Drop the cross and you will then be on the first rosary for level 3. Credit 2snek pb video

{{#ev:youtube|S5AeS9GScjg|550}}

*Also if you see either a cross or triple multiplier drop during the Medusa fight - in the case of the cross you have moved the item table - in the case of the multiplier you may or may not have.

===Medusa Boss===

===Standard===

*When entering Medusa's room have 3 hearts (3 Holy Waters) and walk all the way to the door on the other side of the room. Turn around and immediately walk till Simon's front foot is here:

[[File:CV1 Stage6 MedusaStandardKillStart.png|550px]]

*Throw a Holy Water and whip 3 times, throw another water and whip 3 times, then throw your last water and whip 3 times you should kill Medusa without too much if any, movement from her.

{{#ev:youtube|9MoSSOfl8S8|550}}

===Advanced===

*Below is the video from Shockra Tease on the different pixel set ups to crit Medusa.

=== Medusa Crit Setups by Shockra ===
{{#ev:youtube|2UF1ogovioQ|550}}

=== Medusa Crit Guide by Mister Kimble ===
{{#ev:youtube|WoFpZFBv7Js|550}}

</div>

== <span class="mw-customtoggle-3" style="font-size:large; display:inline-block; float:right;"><span class="mw-customtoggletext">[Show/Hide]</span></span> 2snek Beginner/Race Video Guide ==
<div id="mw-customcollapsible-3" class="mw-collapsible mw-collapsed">

{{#ev:youtube|2WcxqAZ-qIY|550}}

</div>

Cv1/dracula

2025-07-18T19:58:09Z

K c r: /* [Show/Hide] 2snek Beginner/Race Video Guide */

{{Infobox level
| image = CV1 Drac.png
| game = Castlevania
| level_name = 6
| level_sections = Dracula
| previous = [[cv1/level6 | Level 6]]
| next = None
}}

This article is a heavy WIP - for anything beyond basic to intermediate strategies please refer to SBD Wolf's World Record strat video https://www.twitch.tv/videos/1048136981

== <span class="mw-customtoggle-0" style="font-size:large; display:inline-block; float:right;"><span class="mw-customtoggletext">[Show/Hide]</span></span> Phase 1 ==
<div id="mw-customcollapsible-0" class="mw-collapsible mw-collapsed">
=== Simple ===
<span style="color:#00FF00">Recommended to newcomers</span><br />
(Video Link)

Please refer to 2snek video below

*3-cycle attempt with 5-cycle backup
*Explain left-right switching, how spawns and fireball patterns work

=== 2-Cycle: Descending Crit ===
{{#ev:youtube|o31bSltaYh0|550}}
*Easier to learn
*Thoroughly explain movements and visual cues
*Optional whip buffer (not recommended)
*Frame perfect descending crit variant to keep it simple and let people focus on movement
*3-Cycle backup (maybe put this section under backups?)
*Refer to backups if missed backward jump
*If fast pattern, either fall back on old school 3-cycle attempt, or refer to the Pause Buffer Section

=== 2-Cycle: Ascending Crit ===
{{#ev:youtube|QHU4UGNDVII|550}}
*More difficult to learn, but more lenient
*Thoroughly explain movements and visual cues
*Optional whip buffer (not recommended)
*Explain Ascending Whip setup (aim for 2-frame stagger pixels)
*3-Cycle backup (maybe put this section under backups?)
*Refer to backups if missed backward jump
*If fast pattern, either fall back on old school 3-cycle attempt, or refer to the Pause Buffer Section

=== Fast Pattern 2-Cycle: Pause Buffer ===
{{#ev:youtube|XwwtLf4ptXg|550}}
*Give frame number
*Append this chart:
<div class="toccolours mw-collapsible mw-collapsed" style="width:560px">
'''Pause Buffer Patterns'''
<div class="mw-collapsible-content">
"x frames pause" means pressing start once, and repressing it to unpause x frames later.
These spawns happen if Simon does the 2-cycle movement after a pause buffer on the fast pattern.
-2 frames pause: normal 2-cycle spawn that we're used to, but attack speed seems RNG.
-3 frames pause: Dracula spawns just left of the mid-left candle.
-4 frames pause: Dracula spawns just right of the leftmost candle.
-5 frames pause: Dracula spawns on top of Simon, hitting him.
-6 frames pause: Dracula spawns on top of Simon, hitting him (same as 5 frames pause).
-7 frames pause: Dracula spawns just right of the leftmost candle.
-8 frames pause: Dracula spawns just right of the mid-left candle.
-9 frames pause: Dracula spawns on the far right. Attack speed seems RNG.
-10 frames pause: Normal 2-cycle spawn. Fixed attack speed. Aim for this one.
-11 frames pause: Dracula spawns just left of the mid-left candle.
-12 frames pause: Dracula spawns just right of the leftmost candle.
-13 frames pause: Dracula spawns on top of Simon, hitting him.
-14 frames pause: Dracula spawns on top of Simon, hitting him. (same as 13 frames pause).
-15 frames pause: Dracula spawns just right of the leftmost candle.
-16 frames pause: Dracula spawns just right of the mid-left candle.
-17 frames pause: Dracula spawns on the far right. Attack speed might be fixed here.
-18 frames pause: Normal 2-cycle spawn.
Seems to continue on this pattern.
</div>
</div>
*Explain how to go about the fight if missed pause buffer

=== Hitless 3-Cycle ===
{{#ev:youtube|v_QSCyZhVYs|550}}
*Explanation

=== Backups ===
==== Missed Crit on 2-Cycle Strat ====
{{#ev:youtube|c9K-M_DSRqI|550}}
*Refresh rate in the video makes it a little unclear where Simon should be positioned for the backup. Here is the general location.
[[File:Drac_2-cycle_backup1_position.png|280px]]

==== Missed Backward Jump on 2-cycle Strat ====
{{#ev:youtube|-iMQ7BA1KpE|550}}
*Ideally you react in time to missing the backward jump and you stop throwing crosses, which would break the candles on the left. If you do break those candles, you will have to fight the cookie monster with a single shot holy water or even with the cross.
==== Death Recovery ====
(Video Link)

</div>

== <span class="mw-customtoggle-1" style="font-size:large; display:inline-block; float:right;"><span class="mw-customtoggletext">[Show/Hide]</span></span> Phase 2 ==
<div id="mw-customcollapsible-1" class="mw-collapsible mw-collapsed">
=== Standard After 3-Cycle ===
{{#ev:youtube|-BPHCKCNeLE|550}}
*You ideally want to have 12-14 hearts at the beginning of Phase 2 for this strat
*Pickup holy water and triple multiplier and position yourself approximately 1 whip length from Dracula
**The whip before the transformation is used to both gauge this distance and for a timing mechanism
*You can get 2 jump whips in before the first available jump
**Be sure to hold B after the 2nd whip. This will manipulate Drac into a quick short hop.
*Once landed, stun Drac with a holy water while it is in the crounched position
*Begin with a jump whip followed by a holy water while falling to chain the stun lock
*The holy water will deal damage to Drac as long as it passes through its head
**If you miss a jump whip, ensure that you still throw a holy water to maintain the stun lock

=== Standard After 4-Cycle or higher ===
*Same strat as Standard After 3-cycle, you will just be setting up wherever you end up killing Drac in Phase 1

=== Standard After 2-Cycle ===
==== Simple Opening ====
{{#ev:youtube|sMh89DRJDIs|550}}
*Easy 2-hit cross opening. Hold B after throwing the second cross to force the early jump.
==== Intermediate Opening ====
{{#ev:youtube|Cy8WFw0gDjc|550}}
*3-hit cross opening. For the second cross throw, press right, release, then jump to avoid getting a forward jump towards Cookie. Hold B after the second cross.
==== Optimal Opening ====
{{#ev:youtube|TbAekcTp7ww|550}}
*4-hit cross opening. Requires a just-frame backjump input for the first cross. Hold B after whipping the Holy Water candle.

=== Drac Crit Chart ===
[[File:Dracula_rising_crit_map.png|thumb|500px]]

=== Tyson Cookie ===
{{#ev:youtube|JyGAiRkEcmY|550}}
*This can be done after any Phase 1 and after any opening.
*Requires fewer hearts. You can skip a big heart at the end of Stage 17 if good pattern on 17-2 fleamen.
*Think of each jump whip and falling whip as a set. Each whip input of each set of whips (jump whips and down whips) are frame perfect.
**The first whip needs to be staggered 1 frame after your jump input, and the falling whip needs to be input exactly 22 frames after the first whip input in order to connect.
**If you jump and get no whip, your jump and whip inputs were on the same frame
**If you input a second whip, but it did not come out, your input was early.
*Note the pink hit markers for each whip. If you do not see a hit marker for your falling whip, it did not deal damage and was too slow.
*Only worth going for if you can consistently get 4 or more sets of tyson whips, otherwise this loses time over the standard (Machine gun) strat.

=== Backups ===
==== Double Shot Fight ====
<span style="color:#00FF00">Recommended to newcomers</span><br />
{{#ev:youtube|x-RYQRIkWMk|550}}
*This can also be used if you lack the hearts for the Standard Kill (Machine Gun)
*You can get in 2 jump whips per holy water

==== Single Shot Fight ====
{{#ev:youtube|szRuYKjnzwU|550}}
*Recommend stunning immediately
*You can get in 3 jump whips per holy water
*When attacking, tap B for as little as possible to reduce the chances of the Cookie Monster jumping.
*If Cookie Monster poises to jump (raises arms/one leg), do NOT finish your current set of jump whips. Move to a safe distance and re-apply holy water stun lock.
</div>

== <span class="mw-customtoggle-2" style="font-size:large; display:inline-block; float:right;"><span class="mw-customtoggletext">[Show/Hide]</span></span> 2snek Beginner/Race Video Guide and Dating 2 cycle Guide ==
<div id="mw-customcollapsible-2" class="mw-collapsible mw-collapsed">

{{#ev:youtube|ZZ4LA2dM5Ro|550}}

{{#ev:youtube|y2qXAY10BE4|550}}

</div>

Castlevania (NES)

2025-05-13T19:51:48Z

K c r:

[[file:Cv1.jpg|right]]

== Information ==

:* '''[[cv1/general| General Information]]'''
:* '''[[cv1/tricks| Tricks and Game Mechanics]]'''
:* '''[[cv1/ScrollGlitch| Scroll Glitch Technical Information]]'''
:* '''[[cv1/ACE | Arbitrary Code Execution]]'''
:* '''[[cv1/tutorials | Video Tutorials]]'''
:* '''[http://www.speedrun.com/cv1 Leaderboards]'''


== Any% ==

=== Individual Stages ===

:* '''[[cv1/level1 | Level 1: Stage 1-3]]'''
:* '''[[cv1/level2 | Level 2: Stage 4-6]]'''
:* '''[[cv1/level3 | Level 3: Stage 7-9]]'''
:* '''[[cv1/level4 | Level 4: Stage 10-12]]'''
:* '''[[cv1/level5 | Level 5: Stage 13-15]]'''
:* '''[[cv1/level6 | Level 6: Stage 16-18]]'''
:* '''[[cv1/dracula | Dracula]]'''

== Easy Mode ==

Cv1/dracula

2025-02-05T05:09:08Z

K c r: /* Simple */

{{Infobox level
| image = CV1 Drac.png
| game = Castlevania
| level_name = 6
| level_sections = Dracula
| previous = [[cv1/level6 | Level 6]]
| next = None
}}

This article is a heavy WIP - for anything beyond basic to intermediate strategies please refer to SBD Wolf's World Record strat video https://www.twitch.tv/videos/1048136981

== <span class="mw-customtoggle-0" style="font-size:large; display:inline-block; float:right;"><span class="mw-customtoggletext">[Show/Hide]</span></span> Phase 1 ==
<div id="mw-customcollapsible-0" class="mw-collapsible mw-collapsed">
=== Simple ===
<span style="color:#00FF00">Recommended to newcomers</span><br />
(Video Link)

Please refer to 2snek video below

*3-cycle attempt with 5-cycle backup
*Explain left-right switching, how spawns and fireball patterns work

=== 2-Cycle: Descending Crit ===
{{#ev:youtube|o31bSltaYh0|550}}
*Easier to learn
*Thoroughly explain movements and visual cues
*Optional whip buffer (not recommended)
*Frame perfect descending crit variant to keep it simple and let people focus on movement
*3-Cycle backup (maybe put this section under backups?)
*Refer to backups if missed backward jump
*If fast pattern, either fall back on old school 3-cycle attempt, or refer to the Pause Buffer Section

=== 2-Cycle: Ascending Crit ===
{{#ev:youtube|QHU4UGNDVII|550}}
*More difficult to learn, but more lenient
*Thoroughly explain movements and visual cues
*Optional whip buffer (not recommended)
*Explain Ascending Whip setup (aim for 2-frame stagger pixels)
*3-Cycle backup (maybe put this section under backups?)
*Refer to backups if missed backward jump
*If fast pattern, either fall back on old school 3-cycle attempt, or refer to the Pause Buffer Section

=== Fast Pattern 2-Cycle: Pause Buffer ===
{{#ev:youtube|XwwtLf4ptXg|550}}
*Give frame number
*Append this chart:
<div class="toccolours mw-collapsible mw-collapsed" style="width:560px">
'''Pause Buffer Patterns'''
<div class="mw-collapsible-content">
"x frames pause" means pressing start once, and repressing it to unpause x frames later.
These spawns happen if Simon does the 2-cycle movement after a pause buffer on the fast pattern.
-2 frames pause: normal 2-cycle spawn that we're used to, but attack speed seems RNG.
-3 frames pause: Dracula spawns just left of the mid-left candle.
-4 frames pause: Dracula spawns just right of the leftmost candle.
-5 frames pause: Dracula spawns on top of Simon, hitting him.
-6 frames pause: Dracula spawns on top of Simon, hitting him (same as 5 frames pause).
-7 frames pause: Dracula spawns just right of the leftmost candle.
-8 frames pause: Dracula spawns just right of the mid-left candle.
-9 frames pause: Dracula spawns on the far right. Attack speed seems RNG.
-10 frames pause: Normal 2-cycle spawn. Fixed attack speed. Aim for this one.
-11 frames pause: Dracula spawns just left of the mid-left candle.
-12 frames pause: Dracula spawns just right of the leftmost candle.
-13 frames pause: Dracula spawns on top of Simon, hitting him.
-14 frames pause: Dracula spawns on top of Simon, hitting him. (same as 13 frames pause).
-15 frames pause: Dracula spawns just right of the leftmost candle.
-16 frames pause: Dracula spawns just right of the mid-left candle.
-17 frames pause: Dracula spawns on the far right. Attack speed might be fixed here.
-18 frames pause: Normal 2-cycle spawn.
Seems to continue on this pattern.
</div>
</div>
*Explain how to go about the fight if missed pause buffer

=== Hitless 3-Cycle ===
{{#ev:youtube|v_QSCyZhVYs|550}}
*Explanation

=== Backups ===
==== Missed Crit on 2-Cycle Strat ====
{{#ev:youtube|c9K-M_DSRqI|550}}
*Refresh rate in the video makes it a little unclear where Simon should be positioned for the backup. Here is the general location.
[[File:Drac_2-cycle_backup1_position.png|280px]]

==== Missed Backward Jump on 2-cycle Strat ====
{{#ev:youtube|-iMQ7BA1KpE|550}}
*Ideally you react in time to missing the backward jump and you stop throwing crosses, which would break the candles on the left. If you do break those candles, you will have to fight the cookie monster with a single shot holy water or even with the cross.
==== Death Recovery ====
(Video Link)

</div>

== <span class="mw-customtoggle-1" style="font-size:large; display:inline-block; float:right;"><span class="mw-customtoggletext">[Show/Hide]</span></span> Phase 2 ==
<div id="mw-customcollapsible-1" class="mw-collapsible mw-collapsed">
=== Standard After 3-Cycle ===
{{#ev:youtube|-BPHCKCNeLE|550}}
*You ideally want to have 12-14 hearts at the beginning of Phase 2 for this strat
*Pickup holy water and triple multiplier and position yourself approximately 1 whip length from Dracula
**The whip before the transformation is used to both gauge this distance and for a timing mechanism
*You can get 2 jump whips in before the first available jump
**Be sure to hold B after the 2nd whip. This will manipulate Drac into a quick short hop.
*Once landed, stun Drac with a holy water while it is in the crounched position
*Begin with a jump whip followed by a holy water while falling to chain the stun lock
*The holy water will deal damage to Drac as long as it passes through its head
**If you miss a jump whip, ensure that you still throw a holy water to maintain the stun lock

=== Standard After 4-Cycle or higher ===
*Same strat as Standard After 3-cycle, you will just be setting up wherever you end up killing Drac in Phase 1

=== Standard After 2-Cycle ===
==== Simple Opening ====
{{#ev:youtube|sMh89DRJDIs|550}}
*Easy 2-hit cross opening. Hold B after throwing the second cross to force the early jump.
==== Intermediate Opening ====
{{#ev:youtube|Cy8WFw0gDjc|550}}
*3-hit cross opening. For the second cross throw, press right, release, then jump to avoid getting a forward jump towards Cookie. Hold B after the second cross.
==== Optimal Opening ====
{{#ev:youtube|TbAekcTp7ww|550}}
*4-hit cross opening. Requires a just-frame backjump input for the first cross. Hold B after whipping the Holy Water candle.

=== Drac Crit Chart ===
[[File:Dracula_rising_crit_map.png|thumb|500px]]

=== Tyson Cookie ===
{{#ev:youtube|JyGAiRkEcmY|550}}
*This can be done after any Phase 1 and after any opening.
*Requires fewer hearts. You can skip a big heart at the end of Stage 17 if good pattern on 17-2 fleamen.
*Think of each jump whip and falling whip as a set. Each whip input of each set of whips (jump whips and down whips) are frame perfect.
**The first whip needs to be staggered 1 frame after your jump input, and the falling whip needs to be input exactly 22 frames after the first whip input in order to connect.
**If you jump and get no whip, your jump and whip inputs were on the same frame
**If you input a second whip, but it did not come out, your input was early.
*Note the pink hit markers for each whip. If you do not see a hit marker for your falling whip, it did not deal damage and was too slow.
*Only worth going for if you can consistently get 4 or more sets of tyson whips, otherwise this loses time over the standard (Machine gun) strat.

=== Backups ===
==== Double Shot Fight ====
<span style="color:#00FF00">Recommended to newcomers</span><br />
{{#ev:youtube|x-RYQRIkWMk|550}}
*This can also be used if you lack the hearts for the Standard Kill (Machine Gun)
*You can get in 2 jump whips per holy water

==== Single Shot Fight ====
{{#ev:youtube|szRuYKjnzwU|550}}
*Recommend stunning immediately
*You can get in 3 jump whips per holy water
*When attacking, tap B for as little as possible to reduce the chances of the Cookie Monster jumping.
*If Cookie Monster poises to jump (raises arms/one leg), do NOT finish your current set of jump whips. Move to a safe distance and re-apply holy water stun lock.
</div>

== <span class="mw-customtoggle-2" style="font-size:large; display:inline-block; float:right;"><span class="mw-customtoggletext">[Show/Hide]</span></span> 2snek Beginner/Race Video Guide ==
<div id="mw-customcollapsible-2" class="mw-collapsible mw-collapsed">

{{#ev:youtube|ZZ4LA2dM5Ro|550}}

</div>

Cv1/level3

2024-04-24T23:53:16Z

K c r: /* Ouijawii Bridge and Mummy Fight */

{{Infobox level
| image = CV1 Level3.png
| game = Castlevania
| level_name = 3
| level_sections = Stage 7, Stage 8, Stage 9/Mummies Boss
| previous = [[cv1/level2 | Level 2]]
| next = [[cv1/level4 | Level 4]]
}}

== <span class="mw-customtoggle-0" style="font-size:large; display:inline-block; float:right;"><span class="mw-customtoggletext">[Show/Hide]</span></span> Stage 07 ==
<div id="mw-customcollapsible-0" class="mw-collapsible mw-collapsed">

=== Stage 7 first screen ===

==== Standard ====

{{#ev:youtube|1yI1AnXJWAw|550}}

*After gaining control of Simon, immediately jump off of the current platform and throw a holy water to hit the second candle, this should drop triple multiplier. Walk under the first fleaman (you can try to whip him to practice for the advanced strat) and when about the middle of the two raised platforms, jump and do a delayed holy water toss. If done correctly it should allow you to keep moving and kill the first two fleamen.

*Next jump onto the slightly raised platform and head towards the skeleton, turn and come back to the first block and jump up and into the now jumping third fleaman. This should boost you to the next platform, turn toss a holy water at the candle, grab the big heart and proceed up the stairs.

==== Advanced ====
*After gaining control of Simon, immediately jump off of the current platform, and walk towards the fleaman. When Simon's head almost reaches the candle prior to the fleaman jump and whip - this should kill the first fleaman. If it does not after you walk under the platform jump and throw a holy water. This should be an earlier toss than the standard and not a delayed toss, you want to keep the second fleaman alive to boost off of.

*Walking under the second fleaman you can stop and turn at the candle at the right side of the pillar or the left side of the pillar. You need to time this turn around with the fleamans jumps or bounces, this should cause him to jump high giving enough time to turn back to the left walk and jump onto the raised platform. Immediately turn back and jump boosting you from the second fleaman onto the raised platform.

{{#ev:youtube|Gm28dC9Vpjw|550}}

*Above is whipping the first fleaman and doing the turnaround at the left side of the pillar

{{#ev:youtube|3DS7GAAaflg|550}}

*Above is missing the first fleaman whip and throwing the water

{{#ev:youtube|CGDcE_HkiZ8|550}}

*Above is turning at the candle at the right side of the pillar

*Additionally, if you moved the item table and are now on money bag, you can manip a drop here by throwing the water after the first fleaman
NOTE: need to grab screen shot

=== Stage 7 second screen ===

==== Standard ====

{{#ev:youtube|yrbFYlgIO-M|550}}

*Walk up the stairs and jump off of the raised platform as far right as you can. You should "clunk" meaning there is a sound effect and Simon kneels for a moment. This causes the bird pattern coming up to be consistent and the only pattern you have to worry about being the skeleton. The skeleton will either jump towards you or jump towards you and throw a bone. If the skeleton jumps towards you whip him, if he jumps and throws a bone throw a holy water at him.

*After dealing with the skeleton walk and jump as late as possible over the pit, while in the air do a delayed holy water throw this should hit the first bird. Jump from the lower platform to the next platform instead of walking up the stairs.Walk towards the edge of this platform and when Simon has one foot off of the platform throw a holy water so it lands on the edge of the next raised platform. This should kill the upper and lower birds, allowing you jump to the next two platforms.

*As you jump to the highest platform (the one with the stairs on the right side) toss a holy water down so it hits the candle and the skeleton below. Jump and when Simon is coming down do a whip to cancel the clunk here, as you land you should collect the cross from the candle at the bottom. Jump to the next two platforms and then proceed to the door.

==== Advanced ====

*Walk up the stairs and jump off of the raised platform at the top of the stairs. Whip buffer on the way down so you do not clunk. From here you have to deal first with the skeleton, which has two patterns. Jump forwards and if the skeleton just jumps at you, you whip him in the air. If he jumps and throws a bone you do a delayed holy water throw. This needs to be almost as late as possible.

*After dealing with the skeleton walk and jump as late as possible over the pit, while in the air do a delayed holy water throw this should hit the first bird. Jump from the lower platform to the next platform instead of walking up the stairs. If done on the right frame you will get the next item drop, so if you entered level 3 on potion and have not gotten any other drops you will get the potion in mid air, otherwise it will be a rosary or bag - again depending what item you are on.

*There are 3 patterns the birds will give you next. High, mid and low. If you just got a potion or a rosary you proceed by jumping up to each raised platform. Throw an early water as you jump to the highest platform, this should cause the skeleton to walk towards the water as it falls and can give you the next drop. This is optimal if you got the potion and now are on bag, because if you get the bag on this screen you can force a rosary drop in stage 8 which helps you get through the screen faster.

{{#ev:youtube|COSqFULLTnY|550}}

*If you do not get a potion or rosary drop off of the first bird then you have to read the pattern in mid air.

{{#ev:youtube|I0ilG7vkddg|550}}

*High bird - if you get high bird throw a water forward onto the middle raised platform to kill the bird coming from below and immediately jump and whip the high bird.

{{#ev:youtube|jrlSIbBEVxA|550}}

*Mid bird - the mid bird pattern strat is the same as the standard strat so walk towards the edge of this platform and when Simon has one foot off of the platform throw a holy water so it lands on the edge of the next raised platform. This should kill the upper and lower birds, allowing you jump to the next two platforms.

{{#ev:youtube|Zh4T4QL_m_0|550}}

*Low bird - this is the pattern when you see the bird from above dive down super fast and below Simon. You quickly pause and unpause, what this does is slightly delays the bird from below from quickly flying up and hitting Simon.

*As you jump to the highest platform (the one with the stairs on the right side) toss a holy water down so it hits the candle and the skeleton below. Jump and when Simon is coming down do a whip to cancel the clunk here, as you land you should collect the cross from the candle at the bottom. Jump to the next two platforms and then proceed to the door.

</div>

== <span class="mw-customtoggle-1" style="font-size:large; display:inline-block; float:right;"><span class="mw-customtoggletext">[Show/Hide]</span></span> Stage 08 ==
<div id="mw-customcollapsible-1" class="mw-collapsible mw-collapsed">

=== Stage 8 first screen ===

==== Standard ====

{{#ev:youtube|X_MBCJd-nXw|550}}

*Once you gain control of Simon after the door take a step and do a jump delay whip, this will manipulate the skeleton later on this screen to jump down from the platform as you approach. Keep walking right and the medusa heads will not hit you, jump and throw the axe to hit the upper candle to get the cross to drop. Continuing walking to the right collect the cross and walk up the stairs.

==== Advanced ====

{{#ev:youtube|I4C0wsueWLM|550}}

*If entering stage 8 on bag in the item table and you have 3 or more hearts there is a spot to jump and throw the cross that will force a drop and advance the item table. The video above shows a potion drop but if you were on bag it would be a bag. This is important because it sets you up for the second screen of stage 8 to be on rosary and make it easier to move through that screen.

=== Stage 8 second screen ===

==== Standard ====

*There are a number of ways to move through this screen. For beginners you can walk up the stairs, head to the right, jump and throw a cross at the bird and candle. Then stop and whip down the bone pillar. Afterwards jump across the first pit, stop and whip the two birds, then jump the second pit, whip or jump the fireballs and then jump the second bone pillar.

{{#ev:youtube|W__Q1fNpMlU|550}}

*Alternatively, the easiest is to jump and throw a cross to hit the bird and the candle for the 5 hearts. Jump over the first fireball shot at you, and when you land whip the second fireball. Then jump and land on the right side of bone pillar to damage boost over the pit. As Simon stands up from the boost landing, throw a cross to protect you from the birds, continue to walk to the right. Then jump over the next pit, you can whip or jump the fireballs from the next bone pillar, and finally jump over the pillar and proceed to the door. The clip shows the player getting a potion drop but you can jump or whip the fireballs still.

==== Advanced ====

{{#ev:youtube|7C0m0RFlgWE|550}}

*The optimal way to move through the second screen of stage 8 is to force an item drop off of the bird. This is done by jumping and throwing a cross on the way down from the jump that hits both the candle and the bird. Depending on which item you are on this allows you to move through this screen very quickly. Potion for this screen allows you to walk through everything except the final bone pillar which you want to jump as your invincibility may run out. If you are setting up for god bridge in stage 9 you'll also want to force a bag drop off of the second bird on this screen so that you are on rosary going into stage 9.

{{#ev:youtube|1wksJqlIb0A|550}}

*Another way to move through this screen is to jump and throw a cross at the bird and the candle. Jump the first fireball and whip the second fireball then completely jump the bone pillar. There is enough room to land, then jump the pit whipping the second bird when coming down in the air (or throwing a cross) and either whipping or dodging the second bird. Jump the fireballs and then jump the bone pillar and proceed to the door.

{{#ev:youtube|Jcsn4rZxLMQ|550}}

*If you do hurdle the first bone pillar and are worried about the jump (it is easy to hit right too early and walk off into the pit or do a neutral jump), then walk to the left into the bone pillar, it will damage boost you across the pit. This is the Perfect Fin boost - great for races as well!

</div>

== <span class="mw-customtoggle-2" style="font-size:large; display:inline-block; float:right;"><span class="mw-customtoggletext">[Show/Hide]</span></span> Stage 09/Mummy Fight==
<div id="mw-customcollapsible-2" class="mw-collapsible mw-collapsed">

Stage 9

===Ouijawii Bridge and Mummy Fight===

*Stage 9 can be difficult but if you move through it consistently you'll get the same enemy pattern AND you'll get a consistent boss pattern. The way to do this is to intentionally lose 66 frames - meaning 3 whips or cross throws.
[[File:Ouijawii-low-bird.png|400px|thumb|right|If you did not lose frames during the Ouijawii bridge, the bird immediately following this bone tower will swoop low. Plan to set up on the right side of the mummies.]]
{{#ev:youtube|Ak7L-zhDSak|550}}
[[File:Ouijawii-mid-bird.png|400px|thumb|right|Losing frames before this point will result in different swoop patterns, which indicates that the mummy pattern will not be consistent. Plan to set up on the left side and react to the mummy pattern.]]

*Moving to the right, jump and whip the first two birds in the air, then when you land after the second bird throw a cross at the bone pillar. Remember to keep holding right for this whole screen. After you throw the cross walk forwards and jump over the bone pillar. You're going jump the next two birds but pay attention to where they fly, you want them to fly down from the statues and hover right around Simon's waist level. IF they dive much farther below mentally note this, this impacts your boss fight.

*After jumping the second pair of birds whip the first fireball from the bone pillar and jump over the next fireball. You then immediately jump the bone pillar. This is pretty tight jump and looks like you're about hit the top the pillar with your feet. There is a bird right after this bone pillar, you are going to jump and throw a cross above the bird. This bird should dive really low - again if it does not note this mentally, your boss fight just changed.

*Your cross should hit the skeleton jumping towards you, and then you whip the second skeleton mid air as he jumps towards you. Jump the next pit and keep heading right - the medusa heads won't hit you if you just walk right. You'll reach the final bone pillar - throw a cross at the fireballs. This should take care of both fireballs and go through the bone pillar to the candle behind the pillar - this should drop the 2x multiplier.

*Jump from your current platform to the middle block of the "steps" into the boss room. If all of Stage 9 went correctly you can walk all the way to the right. The Mummies will activate and the right mummy will hit Simon once and then turn and walk towards the center of the room. Walk left, the Mummies should overlap in the middle of the room, throw 2 crosses at the center of the next background pillar - this should cause the Mummies be killed instantly.

*One note if the candle after the bone pillar doesn't drop the multiplier you can throw a cross in the Mummy room on the way to the right and should get it. If not you can also throw a cross and jump and whip the Mummies on the way down.

===God Bridge and Mummy Fight===

*If you are on money bag entering Stage 9 you can force a drop off of the first bird with a well timed cross.

{{#ev:youtube|MHEIK0v5hGc|550}}

*The above isn't needed if you are on the correct item.

{{#ev:youtube|T1CErdxSyVk|550}}

*God Bridge is when you do not stop moving for all of Stage 9, forcing drops from the item table to allow Simon to not have to stop.

*The first drop is done by throwing a falling cross at the second bird, this should drop either a potion or a rosary depending on what item you are on in the table.

[[File:GodBridge Bird1.png|550px]] [[File: GodBridge Bird2.png|550px]]

*Above are screen shots from the Human Theory TAS - the next step taken starts a jump - the first bird jump and whip, the second jump and throw a delayed cross.

*The second drop is done by throwing a falling cross at the fourth bird, again you should get a rosary or potion.

[[File: GodBridge Bird3.png|550px]]

*Above are screen shots from the Human Theory TAS - the next step taken starts a jump and throw a delayed cross.

*There is a third drop on the fifth bird that you may or may not need to get. You then whip the skeletons mid air and keep moving to the bone pillar. You want to jump the first fireball and as you land whip the second fireball or throw a cross. Since you have not lost 66 frames the Mummy pattern is now one of four patterns - you'll need to line up on the left side by walking to the center of the room then walking back to left, jump + whip the final block of the "stairs" into the room and turn back to the right. The left Mummy will walk through Simon and then you'll have to read the pattern.

[[File: GodBridge Bird4.png|550px]]

*Above are screen shots from the Human Theory TAS - the next step taken starts a jump and throw a delayed cross.

== Boss ==
=== Mummy patterns ===

{{#ev:youtube|7O3-0UNAFIY|550}}

</div>

== <span class="mw-customtoggle-3" style="font-size:large; display:inline-block; float:right;"><span class="mw-customtoggletext">[Show/Hide]</span></span> 2snek Beginner/Race Video Guide ==
<div id="mw-customcollapsible-3" class="mw-collapsible mw-collapsed">

{{#ev:youtube| KhYKgpyZbVw|550}}

</div>

Cv1/level3

2024-04-24T23:45:28Z

K c r: /* Ouijawii Bridge and Mummy Fight */

{{Infobox level
| image = CV1 Level3.png
| game = Castlevania
| level_name = 3
| level_sections = Stage 7, Stage 8, Stage 9/Mummies Boss
| previous = [[cv1/level2 | Level 2]]
| next = [[cv1/level4 | Level 4]]
}}

== <span class="mw-customtoggle-0" style="font-size:large; display:inline-block; float:right;"><span class="mw-customtoggletext">[Show/Hide]</span></span> Stage 07 ==
<div id="mw-customcollapsible-0" class="mw-collapsible mw-collapsed">

=== Stage 7 first screen ===

==== Standard ====

{{#ev:youtube|1yI1AnXJWAw|550}}

*After gaining control of Simon, immediately jump off of the current platform and throw a holy water to hit the second candle, this should drop triple multiplier. Walk under the first fleaman (you can try to whip him to practice for the advanced strat) and when about the middle of the two raised platforms, jump and do a delayed holy water toss. If done correctly it should allow you to keep moving and kill the first two fleamen.

*Next jump onto the slightly raised platform and head towards the skeleton, turn and come back to the first block and jump up and into the now jumping third fleaman. This should boost you to the next platform, turn toss a holy water at the candle, grab the big heart and proceed up the stairs.

==== Advanced ====
*After gaining control of Simon, immediately jump off of the current platform, and walk towards the fleaman. When Simon's head almost reaches the candle prior to the fleaman jump and whip - this should kill the first fleaman. If it does not after you walk under the platform jump and throw a holy water. This should be an earlier toss than the standard and not a delayed toss, you want to keep the second fleaman alive to boost off of.

*Walking under the second fleaman you can stop and turn at the candle at the right side of the pillar or the left side of the pillar. You need to time this turn around with the fleamans jumps or bounces, this should cause him to jump high giving enough time to turn back to the left walk and jump onto the raised platform. Immediately turn back and jump boosting you from the second fleaman onto the raised platform.

{{#ev:youtube|Gm28dC9Vpjw|550}}

*Above is whipping the first fleaman and doing the turnaround at the left side of the pillar

{{#ev:youtube|3DS7GAAaflg|550}}

*Above is missing the first fleaman whip and throwing the water

{{#ev:youtube|CGDcE_HkiZ8|550}}

*Above is turning at the candle at the right side of the pillar

*Additionally, if you moved the item table and are now on money bag, you can manip a drop here by throwing the water after the first fleaman
NOTE: need to grab screen shot

=== Stage 7 second screen ===

==== Standard ====

{{#ev:youtube|yrbFYlgIO-M|550}}

*Walk up the stairs and jump off of the raised platform as far right as you can. You should "clunk" meaning there is a sound effect and Simon kneels for a moment. This causes the bird pattern coming up to be consistent and the only pattern you have to worry about being the skeleton. The skeleton will either jump towards you or jump towards you and throw a bone. If the skeleton jumps towards you whip him, if he jumps and throws a bone throw a holy water at him.

*After dealing with the skeleton walk and jump as late as possible over the pit, while in the air do a delayed holy water throw this should hit the first bird. Jump from the lower platform to the next platform instead of walking up the stairs.Walk towards the edge of this platform and when Simon has one foot off of the platform throw a holy water so it lands on the edge of the next raised platform. This should kill the upper and lower birds, allowing you jump to the next two platforms.

*As you jump to the highest platform (the one with the stairs on the right side) toss a holy water down so it hits the candle and the skeleton below. Jump and when Simon is coming down do a whip to cancel the clunk here, as you land you should collect the cross from the candle at the bottom. Jump to the next two platforms and then proceed to the door.

==== Advanced ====

*Walk up the stairs and jump off of the raised platform at the top of the stairs. Whip buffer on the way down so you do not clunk. From here you have to deal first with the skeleton, which has two patterns. Jump forwards and if the skeleton just jumps at you, you whip him in the air. If he jumps and throws a bone you do a delayed holy water throw. This needs to be almost as late as possible.

*After dealing with the skeleton walk and jump as late as possible over the pit, while in the air do a delayed holy water throw this should hit the first bird. Jump from the lower platform to the next platform instead of walking up the stairs. If done on the right frame you will get the next item drop, so if you entered level 3 on potion and have not gotten any other drops you will get the potion in mid air, otherwise it will be a rosary or bag - again depending what item you are on.

*There are 3 patterns the birds will give you next. High, mid and low. If you just got a potion or a rosary you proceed by jumping up to each raised platform. Throw an early water as you jump to the highest platform, this should cause the skeleton to walk towards the water as it falls and can give you the next drop. This is optimal if you got the potion and now are on bag, because if you get the bag on this screen you can force a rosary drop in stage 8 which helps you get through the screen faster.

{{#ev:youtube|COSqFULLTnY|550}}

*If you do not get a potion or rosary drop off of the first bird then you have to read the pattern in mid air.

{{#ev:youtube|I0ilG7vkddg|550}}

*High bird - if you get high bird throw a water forward onto the middle raised platform to kill the bird coming from below and immediately jump and whip the high bird.

{{#ev:youtube|jrlSIbBEVxA|550}}

*Mid bird - the mid bird pattern strat is the same as the standard strat so walk towards the edge of this platform and when Simon has one foot off of the platform throw a holy water so it lands on the edge of the next raised platform. This should kill the upper and lower birds, allowing you jump to the next two platforms.

{{#ev:youtube|Zh4T4QL_m_0|550}}

*Low bird - this is the pattern when you see the bird from above dive down super fast and below Simon. You quickly pause and unpause, what this does is slightly delays the bird from below from quickly flying up and hitting Simon.

*As you jump to the highest platform (the one with the stairs on the right side) toss a holy water down so it hits the candle and the skeleton below. Jump and when Simon is coming down do a whip to cancel the clunk here, as you land you should collect the cross from the candle at the bottom. Jump to the next two platforms and then proceed to the door.

</div>

== <span class="mw-customtoggle-1" style="font-size:large; display:inline-block; float:right;"><span class="mw-customtoggletext">[Show/Hide]</span></span> Stage 08 ==
<div id="mw-customcollapsible-1" class="mw-collapsible mw-collapsed">

=== Stage 8 first screen ===

==== Standard ====

{{#ev:youtube|X_MBCJd-nXw|550}}

*Once you gain control of Simon after the door take a step and do a jump delay whip, this will manipulate the skeleton later on this screen to jump down from the platform as you approach. Keep walking right and the medusa heads will not hit you, jump and throw the axe to hit the upper candle to get the cross to drop. Continuing walking to the right collect the cross and walk up the stairs.

==== Advanced ====

{{#ev:youtube|I4C0wsueWLM|550}}

*If entering stage 8 on bag in the item table and you have 3 or more hearts there is a spot to jump and throw the cross that will force a drop and advance the item table. The video above shows a potion drop but if you were on bag it would be a bag. This is important because it sets you up for the second screen of stage 8 to be on rosary and make it easier to move through that screen.

=== Stage 8 second screen ===

==== Standard ====

*There are a number of ways to move through this screen. For beginners you can walk up the stairs, head to the right, jump and throw a cross at the bird and candle. Then stop and whip down the bone pillar. Afterwards jump across the first pit, stop and whip the two birds, then jump the second pit, whip or jump the fireballs and then jump the second bone pillar.

{{#ev:youtube|W__Q1fNpMlU|550}}

*Alternatively, the easiest is to jump and throw a cross to hit the bird and the candle for the 5 hearts. Jump over the first fireball shot at you, and when you land whip the second fireball. Then jump and land on the right side of bone pillar to damage boost over the pit. As Simon stands up from the boost landing, throw a cross to protect you from the birds, continue to walk to the right. Then jump over the next pit, you can whip or jump the fireballs from the next bone pillar, and finally jump over the pillar and proceed to the door. The clip shows the player getting a potion drop but you can jump or whip the fireballs still.

==== Advanced ====

{{#ev:youtube|7C0m0RFlgWE|550}}

*The optimal way to move through the second screen of stage 8 is to force an item drop off of the bird. This is done by jumping and throwing a cross on the way down from the jump that hits both the candle and the bird. Depending on which item you are on this allows you to move through this screen very quickly. Potion for this screen allows you to walk through everything except the final bone pillar which you want to jump as your invincibility may run out. If you are setting up for god bridge in stage 9 you'll also want to force a bag drop off of the second bird on this screen so that you are on rosary going into stage 9.

{{#ev:youtube|1wksJqlIb0A|550}}

*Another way to move through this screen is to jump and throw a cross at the bird and the candle. Jump the first fireball and whip the second fireball then completely jump the bone pillar. There is enough room to land, then jump the pit whipping the second bird when coming down in the air (or throwing a cross) and either whipping or dodging the second bird. Jump the fireballs and then jump the bone pillar and proceed to the door.

{{#ev:youtube|Jcsn4rZxLMQ|550}}

*If you do hurdle the first bone pillar and are worried about the jump (it is easy to hit right too early and walk off into the pit or do a neutral jump), then walk to the left into the bone pillar, it will damage boost you across the pit. This is the Perfect Fin boost - great for races as well!

</div>

== <span class="mw-customtoggle-2" style="font-size:large; display:inline-block; float:right;"><span class="mw-customtoggletext">[Show/Hide]</span></span> Stage 09/Mummy Fight==
<div id="mw-customcollapsible-2" class="mw-collapsible mw-collapsed">

Stage 9

===Ouijawii Bridge and Mummy Fight===

*Stage 9 can be difficult but if you move through it consistently you'll get the same enemy pattern AND you'll get a consistent boss pattern. The way to do this is to intentionally lose 66 frames - meaning 3 whips or cross throws.

{{#ev:youtube|Ak7L-zhDSak|550}}

*Moving to the right, jump and whip the first two birds in the air, then when you land after the second bird throw a cross at the bone pillar. Remember to keep holding right for this whole screen. After you throw the cross walk forwards and jump over the bone pillar. You're going jump the next two birds but pay attention to where they fly, you want them to fly down from the statues and hover right around Simon's waist level. IF they dive much farther below mentally note this, this impacts your boss fight.

*After jumping the second pair of birds whip the first fireball from the bone pillar and jump over the next fireball. You then immediately jump the bone pillar. This is pretty tight jump and looks like you're about hit the top the pillar with your feet. There is a bird right after this bone pillar, you are going to jump and throw a cross above the bird. This bird should dive really low - again if it does not note this mentally, your boss fight just changed.

Examples of the correct bird heights

Middle set of birds

Last bird

Examples of frames lost bird heights (line up on the left for the Mummy fight)

Middle set of birds

Last bird

*Your cross should hit the skeleton jumping towards you, and then you whip the second skeleton mid air as he jumps towards you. Jump the next pit and keep heading right - the medusa heads won't hit you if you just walk right. You'll reach the final bone pillar - throw a cross at the fireballs. This should take care of both fireballs and go through the bone pillar to the candle behind the pillar - this should drop the 2x multiplier.

*Jump from your current platform to the middle block of the "steps" into the boss room. If all of Stage 9 went correctly you can walk all the way to the right. The Mummies will activate and the right mummy will hit Simon once and then turn and walk towards the center of the room. Walk left, the Mummies should overlap in the middle of the room, throw 2 crosses at the center of the next background pillar - this should cause the Mummies be killed instantly.

*One note if the candle after the bone pillar doesn't drop the multiplier you can throw a cross in the Mummy room on the way to the right and should get it. If not you can also throw a cross and jump and whip the Mummies on the way down.

===God Bridge and Mummy Fight===

*If you are on money bag entering Stage 9 you can force a drop off of the first bird with a well timed cross.

{{#ev:youtube|MHEIK0v5hGc|550}}

*The above isn't needed if you are on the correct item.

{{#ev:youtube|T1CErdxSyVk|550}}

*God Bridge is when you do not stop moving for all of Stage 9, forcing drops from the item table to allow Simon to not have to stop.

*The first drop is done by throwing a falling cross at the second bird, this should drop either a potion or a rosary depending on what item you are on in the table.

[[File:GodBridge Bird1.png|550px]] [[File: GodBridge Bird2.png|550px]]

*Above are screen shots from the Human Theory TAS - the next step taken starts a jump - the first bird jump and whip, the second jump and throw a delayed cross.

*The second drop is done by throwing a falling cross at the fourth bird, again you should get a rosary or potion.

[[File: GodBridge Bird3.png|550px]]

*Above are screen shots from the Human Theory TAS - the next step taken starts a jump and throw a delayed cross.

*There is a third drop on the fifth bird that you may or may not need to get. You then whip the skeletons mid air and keep moving to the bone pillar. You want to jump the first fireball and as you land whip the second fireball or throw a cross. Since you have not lost 66 frames the Mummy pattern is now one of four patterns - you'll need to line up on the left side by walking to the center of the room then walking back to left, jump + whip the final block of the "stairs" into the room and turn back to the right. The left Mummy will walk through Simon and then you'll have to read the pattern.

[[File: GodBridge Bird4.png|550px]]

*Above are screen shots from the Human Theory TAS - the next step taken starts a jump and throw a delayed cross.

== Boss ==
=== Mummy patterns ===

{{#ev:youtube|7O3-0UNAFIY|550}}

</div>

== <span class="mw-customtoggle-3" style="font-size:large; display:inline-block; float:right;"><span class="mw-customtoggletext">[Show/Hide]</span></span> 2snek Beginner/Race Video Guide ==
<div id="mw-customcollapsible-3" class="mw-collapsible mw-collapsed">

{{#ev:youtube| KhYKgpyZbVw|550}}

</div>

Cv1/ScrollGlitch

2024-04-18T06:03:59Z

K c r: /* Training Resources, Starting Pixels and Timings */

== Breaking Dracula’s Castle 101 ==

Before delving into why the scroll glitch works and how to execute it, I recommend understanding how castlevania updates its background tiles. Once we understand this, we can find various ways to break it, as well as diagnose when the scroll glitch fails.

=== How are background tiles updated? ===

Castlevania graphics are made up of foreground sprites (simon, candles, hearts, enemies) and background tiles. The game is building up these background tiles ahead of what is actually on the screen behind the scenes so that it can scroll smoothly as Simon moves. Around half a screen offscreen, the game is drawing a column two blocks wide. When that is complete, the game moves onto the next column. It looks something like this:

[[File:CV1_ScrollGlitch1. updated.png|550px]]

=== Tile Update Algorithm ===

Step 1: Should the update algorithm run?

There is a framecounter that starts at the beginning of every screen. This is the same framecounter that powers the item drops throughout the game. The update algorithm ONLY runs every other frame. I am not certain as to why, but I would guess this is because the Nintendo is not a very powerful system and this gives it time to do other work. Even if Simon is moving forward on a non updating frame, no tile will be updated.

Step 2: Is Simon moving (left or right… doesn’t matter)?

If Simon is moving (and we are on an even frame as discussed above), the tile upgrading algorithm will run and update a tile. Otherwise, the tile updating process is skipped.

Step 3: Determine which vertical column is going to be updated

If Simon is walking left, we will select a column on the left to update. If he is walking right, the column will be to the right. Every column is 32 pixels wide. For every column, there is another set of 32 pixels around 1.5 screens away that map to that column. When Simon is walking over this set of pixels in the direction towards that column, that column will be updated. See the section “How Background Tiles are Updated” for a picture that corresponds to this mapping.

I will refer to this 32 pixel walking space as the Column Update Window.

Step 4: Determine which tiles will be updated

We are now going to choose which actual blocks on the column will be updated. The game manages a special variable called the Block Counter that determines that location. This variable maps to the tiles vertically like so:

[[File:Block_Counter_mapping.png|550px]]

The block counter has a value between 0 and 7, inclusive; however, only the values 1-6 actually map to blocks.

Here is how the algorithm works:

# Did I just enter a new “Column update window”? (One of those 32 pixel spaces you walk over)
#*If yes, no matter WHAT ( even overriding the every other frame rule described above), reset the Block counter to 0
# Update the blocks in the selected column (the direction Simon is facing) at the vertical level marked by the block counter.
#*If the counter is 0 or 7, this does nothing.
# Increment the block counter by 1
# If the block counter > 7, set the block counter to 0

=== How non-glitched walking normally works ===
A player usually just walks in one direction for a while. As they walk through a new Column Update Window, the column 1.5 screens away starts getting updated. The Column Update Window is 32 pixels wide and we update tiles every other pixel, so we will run the tile upgrading algorithm 16 times (32/2). This will cause the block counter to go from 0 -> 7 and then 0 -> 7 again. This updates every tile value twice. Updating it twice doesn’t cause any harm - it just puts the same value there.

''NOTE - Technically there is a 50% probability of it being 15 times, not 16. This is because the first value is always overridden to 0. If that happens on the tile updating frame, the counter will still be held at 0. ''

=== What causes the scroll glitch to happen? ===

This algorithm manages tile drawing in BOTH the left and right direction. However, there is only ONE block counter. If you are walking left and the tile counter is at 4 but then turn right while the block counter turns to 5, then turn left again as the block counter changes to 6, you skipped a block on the left side. You updated blockset 4 and 6 but skipped 5.

The algorithm has a correction mechanism though. Notice that we normally iterate over the blocks twice for one column update window. That block 5 will get corrected as you continue to walk left… unless you do the same turnback again. Keep repeating this turnback until you have exited the column update window and you have successfully skipped updating the block, performing a “scroll glitch”.

This glitch does not let you put any tile value you want there. You are only skipping writing a value. This means the value will be whatever was there last.

=== Removing Tile Updating RNG ===
If the block counter is only updated every other frame, it seems impossible to actually make the trick predictable. Luckily, there is a neat math trick that solves this. This is best explained with an example:

If you move 1 frame, did you move the block counter? You don’t know. There is a 50% probability you did. If you move 2 frames, did you move the block counter? You moved the counter one and only one time with 100% certainty. This is because you either updated on the first frame or the second frame. It can’t be both or neither!

The above generalizes as you walk forward more pixels. If you move an even number of pixels without stopping, you are 100% certain to have moved the block counter the number of pixels moved divided by 2. If you moved an odd number of pixels, you don’t know what the block counter is incremented to.

As a concrete example, if you walk 6 pixels forward without stopping, you definitely moved the counter up by 3. If you moved 7 pixels, you have a 50% probability of moving it by 3 and a 50% probability of moving it 4.

=== Turnback Requirements ===
As you walk through a Column Update Window, you update each block in a column twice. Given this, it would seem like you will need to execute two turnbacks. Unfortunately, this is not always the case.

When you execute a turnback, you go back two pixels, then forward two pixels. You have now incremented the block counter twice. However, you are also on the same pixel in the Column Update Window as you were before you started the turnback. This means you have essentially added two extra counter updates than a normal walkthrough. Since you have to execute the turnback a second time, you are incrementing the block counter a total of four extra times. Those four extra increments will cause you to start updating some of the higher blocks a third time!

In practice, if you execute 2 frame turnbacks, you need to do three turnbacks unless you are targeting blocks at the 5th or 6th height index in the above diagram, in which case you can continue doing 2 turnbacks.

If you execute 4 frame turnbacks, you need to do 4 turnbacks for block indexes from 1 to 3, and 3 turnbacks for indices 4-6.

Note that these are simplifications. There are scenarios where you can do fewer turnbacks if you get lucky ( a combination of turnbacks being too short but getting lucky with the frame counter). In addition, you often want to execute extra turnbacks to raise consistency (discussed later).

''TECHNICAL NOTE - This is oversimplified. There are some details around having an odd number of pixels on the last walk forward that leads to one extra counter iteration. I don’t think this is a missing aspect of the algorithm, just some tricky off-by-one math. I got frustrated and stopped trying to nail it down exactly. ''

=== Scroll Glitch Execution Approaches ===

For all strategies, there is an important starting pixel where you want to start your turnbacks. This is the pixel that will have the block counter 1 below your target block regardless of whether. You can find this pixel with visuals for each of the level 5 tricks further down this page.

=== 2 - 14 Turnback Method ===

The 2-14 method is the first RTA viable method used by runners and is still used by most. We will do a series of 2 pixel turnbacks followed by 14 pixel walk forwards.

==== Beginner Approach ====
The easiest, although slowest, method is to find a launch point to predictably get to your starting pixel. This is usually done by back jumping and changing direction midair by ducking the opposite direction. If the backjump succeeds, you will have always landed on the right starting pixel. This gives you plenty of time to make sure you pick the right jump point without breaking the glitch.

Once you have gotten to the first pixel, you need a consistent way to go back two pixels. This is usually done by turning in the backwards direction and whipping on the next possible frame. If you are late on the whip, Simon will visibly walk further. If you are early, you will move only 1 pixel back but simon will still be facing forward.

After this, walk forward 14 pixels, rinse, and repeat. Most runners learn the proper 14 pixel visual at each turnback point and practice going to each one. Pictures are on the wiki for this.

This is a slow method, but it is easier for beginners to learn, execute, and diagnose. This slowness will limit the RTA viability of the trick to stage 13, stage 14 standard, and stage 14 advanced. The others are either too risky or the time savings are largely negated by the setup time.

==== Advanced Approach ====

There are two approaches to speed this up. The first is to pick a proper jump point to land on the right starting pixel. If you recognize that you jumped a pixel early, you can duck to move one extra pixel on landing to compensate.

The second approach is to just push back for two frames and push forward for fourteen frames repeatedly without whipping. You can use the jump setup described above or just hit back on the appropriate first frame. This is currently only being executed by Jay_Cee and I don’t have good advice for how to do this outside of lots of practice.

=== Corrections and Reliability Improvements ===

==== Adjust Pixels ====

Most runners learn to target each turnback pixel. If your turnback or turn forward is off by one pixel, the trick now has a 50% chance of success. This is because you now how much you have incremented the Block Counter (see the even-odd rule in the “Removing Tile Updating RNG” section).

HOWEVER, if you proceed as normal and target the same pixels afterwards, you now cut your probability of success down to 25%. For example, if you walk backwards 3 pixels instead of 2, your walk forward will now be 15 pixels if you keep your same target. That is now effectively one more area where you may have moved the counter an extra time.

You instead want to keep your existing movements the same and only move forward 14 pixels. You should either adjust your visual cue or use a rhythm method to feel what 14 frames of movement is like and ignore all pixel targets outside of the first one.

If you moved backwards more than 3 pixels, you definitely moved the counter more than you wanted. It can be saved but only by switching mid-run to the 4-12 turnback method (discussed later).

If you walked forward 2 pixels beyond your target pixel, unless you messed something earlier, the tile you wanted has been locked into a new value and the trick is dead.

==== Extra Turnback ====

As you get closer to the end of the Column Update Window, there are a few additional tweaks that can help save a dead scrollglitch attempt. For example, you may want to consider adding a 3rd turnback for the stage 14 scrollglitch.

For that glitch, unlike stage 13, the block counter doesn’t loop around for a 3rd time to that lower tile, so only two turnbacks are necessary. However, the counter ALMOST makes it there. If you have 3 pixel turnbacks instead of 2 or start the turnbacks slightly early, you are walking more in the Column Update Window after the final turnback. This can increment the block counter more and update your tile, even if you succeeded on the first two turnbacks.

Given this, you can consider adding one extra turnback as an insurance policy. For the 2-14 turnbacks, this is usually most relevant for the stage 14 wall glitch. For higher blocks like the stage 13 glitch, it is very unlikely that it will be able to make an extra loop, so I would not recommend it there.

=== Lenient Final Turnback ===

The above extra turnback is valuable when the normal final turnback is far away from the end of the Column Update Window. However, for some tricks, the final turnback is very close to the end of the Column Update Window. Stage 13 is a great example of this. That closeness creates extra leniency that we can take advantage of.

When normally doing the scroll glitch, let's assume you make a mistake. Instead of going back two pixels, you go back four. You have moved the counter two times. Your target block was not updated, so the trick is still alive; however, the trick is now out of alignment. If you move forward the normal 14 pixels, the trick will be ripped. HOWEVER, if this turnback was close to the end of the Column Update Window, you will escape before you walk 14 pixels. This means a 4 pixel turnback will not rip the final turnback on stage 13!

In fact, I would RECOMMEND doing a 4 pixel turnback on your final turnback here. The reason is you are skipping over two blocks on that last turnback. So if, for example, the block counter is 1 behind due to an earlier mistake, your run would normally be ripped on the final turnback. However, by moving the counter twice at the end, you protected yourself. In fact, this can move the 50% probability of success back to 100%. The block counter could have one of two possible values, and you handle both cases with one turnback.

You should do the 4 pixel turnback after walking 14 pixels if you think the counter is one behind. If you think the counter is one ahead, you should walk forward 12 pixels and then do the 4 pixel turnback. I highly recommend adding one of these approaches to your final turnback on stage 13. If you are adding an EXTRA turnback, as discussed above, the same leniency rule will apply there.

=== 4-12 Turnback Method ===

The leniency property on the last turnback can actually be applied to all turnbacks. Instead of doing 2-14 pixel turnbacks, you can execute 4-12 pixel turnbacks everywhere. This is my preferred technique.

By going back 4 pixels, you are actually skipping two blocks, not one. You don’t need to move two blocks; however, this can provide an extra buffer in case you make a mistake. For the 2-14 pixel approach, if you are off by 1 pixel, the success rate drops to 50%. If you are ever off by more than 1 pixel, the success rate is 0% unless you get lucky and make a countering mistake elsewhere.

For the 4-12 approach, if you are off by 1 pixel, you have a 50% probability for one of the blocks to be overridden. However, assuming the direction you are off is random, you have a 50% chance of that block being the one you care about. So now you have around a 75% probability of success even if you make a 1 pixel mistake. Furthermore, if you make a 2 pixel mistake, you still have a 50% probability of success. A 3 pixel mistake lowers you to around a 25% chance.

While the above math is just a rough approximation, this method has generally seemed more lenient than the 2-14 approach. In addition, if you are doing the whipless turnback technique, at least for me, it is much easier to consistently do a 4 pixel turnback instead of a 2 pixel one. You learn the back and forth d-pad rhythm and the trick can become quite consistent.

Unfortunately, this approach does have a few downsides. First, each turnback will cost an extra 4 frames. In addition, you will often have to do one extra turnback relative to the two pixel turnback. If targeting block 2 or 3, I would recommend 4 turnbacks. Anything below that, I would recommend 3 turnbacks.

=== Training Resources, Starting Pixels and Timings ===
ROMHack - A romhack is available on the CV1 discord. When used, it will print out Simon’s pixel coordinates. In addition, it will print the Block Counter.

The starting pixel coordinates for the scroll glitches are:

{| class="wikitable" style="margin:left"
|+
|-
! Stage Number !! Pixel !! Savings**
|-
| Stage 6 Crusher || 1D9 & 1B9 || ~ 9 sec
|-
| Stage 7 Coffee || 255 & 1F9 || ~ 1.4 sec
|-
| Stage 13 Griddle || A4 || ~ 12.5 sec
|-
| Stage 14 Bacon || 45C or 43D || ~ 3.5 sec
|-
| Stage 14 Egg || 2C4* || ~ 6 sec
|-
| Stage 14 Cheese || 328 || ~ 8 sec
|-
| Stage 14 Race || 21C || ~ 8 sec
|-
| Stage 17 Clocktower || 219 & 1FB || ~ 6 sec
|}

<nowiki>*</nowiki>Touching pixel 2B9 is needed before turning around

<nowiki>**</nowiki>Timings are approximate, also you may not see the same time savings if you don't play the rest of the level as optimal as your prior splits, example the 12 second saving of Stage 13 might turn into 6 seconds if you missed other things in level 5.

Stage 13:

Start on 7A turn around, backwards jump and turnaround to land on A4 -> A1. The a 14 frame Walk to B0 then B0 2 frame turnaround AE. Then a 14 frame walk end on BC quick left turn around (between 2-5 frames?) and then walk right.

[[File:CV1_13-SG-1.png|250px]]
[[File:CV1_13-SG-2.png|250px]]
[[File:CV1_13-SG-3.png|250px]]
[[File:CV1_13-SG-4.png|250px]]

Stage 14
Start on 2FE then backwards jump and turn and land on 328. Whip turnaround 328 -> 326, then move to and do a whip turn around 334 -> 332.

[[File:CV1_14-SG-1.png|250px]]
[[File:CV1_14-SG-2.png|250px]]
[[File:CV1_14-SG-3.png|250px]]

=== Emulator Training Tools ===
I have created a set of scroll glitch training tools (along with other cv1 helper tools). These currently require using bizhawk, although I will likely port to other emulators in the future.

https://www.speedrun.com/cv1/resources

Helpful tools included are:

1. Create lines onscreen to show turnback locations
2. Auto-death tool - kills you if you miss a scroll glitch
3. Turnback-Turnforward diagnostic printout (to highlight if you really are hitting 2-14 or 4-12)

Note, if you are using original hardware, the above tools may be a little annoying as the input latency is different. I would still recommend trying them though as many scroll glitch execution strategies are not latency sensitive.

=== Rhythm Sounds ===
If you are trying to learn a whipless rhythm approach, sounds can also be a helpful aid. You hit the buttons on the appropriate beat. Every frame is 1/60th of a second (technically 1/60.09), so you can use that to create a beat. One style is to do 4/60th of a second followed by 12/60th of a second. Another is to just have a metronome set to 16/60th of a second and time either your forward or backward presses to that beat.

Below are two videos with rhythm of whipless scroll glitch turnbacks for 4-12 pattern. To execute 4-12 wiggles, do a turnback on the short note, and move forward on the long note.

{{#ev:youtube|Zn2FFhDc5WE|550}}

{{#ev:youtube|-WG7e4nAnp4|550}}

=== Acknowledgements ===

InfoManiac
Originally discovered the scroll glitch. The initial method only worked on TAS

Challenger
Implemented almost all the current scroll glitches in TAS that have since been ported to RTA by others.

NatGoesFast
Accidently did a scroll glitch on stream. An investigation of this led to the whip based RTA strategy discussed above.

SBDWolf
Found the whip based RTA viable approach for stage 13 and stage 14. Also figured out probably 75% of the basic block updating algorithm and RTA strategies such as odd/even frames approach. Also was the first person to use these scroll glitches to get WR. (May have also found the crusher room scrollglitch).

Shockratease
Along with SBDWolf, did extensive investigation and teaching on the scroll glitch. Suggested using 16/60th beats instead of two-part beats.

Kajong0007
Created the Romhack mentioned above, which has been used extensively by runners to better learn the trick.

JayCee
First person to remove whips for turnbacks and use it in runs. The removal of whips also enabled a lot of additional scroll glitch areas (crusher, clocktower) which did not seem viable otherwise. This inspired additional scrollglitch innovations.

Trisk (tr1sklion)
Wrote this document. Found the Block Counter and Column Update Window in the game bytecode. Validated and enhanced the earlier algorithm approximation SBDWolf modeled. Wrote the Bizhawk training tools. Pioneered the 4-frame turnbacks strategy and most correction strategies.

== Videos ==

SBDWolf talking about the scroll glitches

{{#ev:youtube|rmlBCzdVlOc|550}}

{{#ev:youtube|yaRmDa_T-oo|550}}

Here's Shockra Tease talking about both Scroll Glitches

{{#ev:youtube|Dw7NkOzp8tE|550}}

Advanced Stage 14

{{#ev:youtube|zxLs7h2cL6Y|550}}

Displaced Gamers Video on the code

{{#ev:youtube|wd18YNZB0D4|550}}

Cv1/ScrollGlitch

2024-04-17T21:59:00Z

K c r: /* Training Resources, Starting Pixels and Timings */

== Breaking Dracula’s Castle 101 ==

Before delving into why the scroll glitch works and how to execute it, I recommend understanding how castlevania updates its background tiles. Once we understand this, we can find various ways to break it, as well as diagnose when the scroll glitch fails.

=== How are background tiles updated? ===

Castlevania graphics are made up of foreground sprites (simon, candles, hearts, enemies) and background tiles. The game is building up these background tiles ahead of what is actually on the screen behind the scenes so that it can scroll smoothly as Simon moves. Around half a screen offscreen, the game is drawing a column two blocks wide. When that is complete, the game moves onto the next column. It looks something like this:

[[File:CV1_ScrollGlitch1. updated.png|550px]]

=== Tile Update Algorithm ===

Step 1: Should the update algorithm run?

There is a framecounter that starts at the beginning of every screen. This is the same framecounter that powers the item drops throughout the game. The update algorithm ONLY runs every other frame. I am not certain as to why, but I would guess this is because the Nintendo is not a very powerful system and this gives it time to do other work. Even if Simon is moving forward on a non updating frame, no tile will be updated.

Step 2: Is Simon moving (left or right… doesn’t matter)?

If Simon is moving (and we are on an even frame as discussed above), the tile upgrading algorithm will run and update a tile. Otherwise, the tile updating process is skipped.

Step 3: Determine which vertical column is going to be updated

If Simon is walking left, we will select a column on the left to update. If he is walking right, the column will be to the right. Every column is 32 pixels wide. For every column, there is another set of 32 pixels around 1.5 screens away that map to that column. When Simon is walking over this set of pixels in the direction towards that column, that column will be updated. See the section “How Background Tiles are Updated” for a picture that corresponds to this mapping.

I will refer to this 32 pixel walking space as the Column Update Window.

Step 4: Determine which tiles will be updated

We are now going to choose which actual blocks on the column will be updated. The game manages a special variable called the Block Counter that determines that location. This variable maps to the tiles vertically like so:

[[File:Block_Counter_mapping.png|550px]]

The block counter has a value between 0 and 7, inclusive; however, only the values 1-6 actually map to blocks.

Here is how the algorithm works:

# Did I just enter a new “Column update window”? (One of those 32 pixel spaces you walk over)
#*If yes, no matter WHAT ( even overriding the every other frame rule described above), reset the Block counter to 0
# Update the blocks in the selected column (the direction Simon is facing) at the vertical level marked by the block counter.
#*If the counter is 0 or 7, this does nothing.
# Increment the block counter by 1
# If the block counter > 7, set the block counter to 0

=== How non-glitched walking normally works ===
A player usually just walks in one direction for a while. As they walk through a new Column Update Window, the column 1.5 screens away starts getting updated. The Column Update Window is 32 pixels wide and we update tiles every other pixel, so we will run the tile upgrading algorithm 16 times (32/2). This will cause the block counter to go from 0 -> 7 and then 0 -> 7 again. This updates every tile value twice. Updating it twice doesn’t cause any harm - it just puts the same value there.

''NOTE - Technically there is a 50% probability of it being 15 times, not 16. This is because the first value is always overridden to 0. If that happens on the tile updating frame, the counter will still be held at 0. ''

=== What causes the scroll glitch to happen? ===

This algorithm manages tile drawing in BOTH the left and right direction. However, there is only ONE block counter. If you are walking left and the tile counter is at 4 but then turn right while the block counter turns to 5, then turn left again as the block counter changes to 6, you skipped a block on the left side. You updated blockset 4 and 6 but skipped 5.

The algorithm has a correction mechanism though. Notice that we normally iterate over the blocks twice for one column update window. That block 5 will get corrected as you continue to walk left… unless you do the same turnback again. Keep repeating this turnback until you have exited the column update window and you have successfully skipped updating the block, performing a “scroll glitch”.

This glitch does not let you put any tile value you want there. You are only skipping writing a value. This means the value will be whatever was there last.

=== Removing Tile Updating RNG ===
If the block counter is only updated every other frame, it seems impossible to actually make the trick predictable. Luckily, there is a neat math trick that solves this. This is best explained with an example:

If you move 1 frame, did you move the block counter? You don’t know. There is a 50% probability you did. If you move 2 frames, did you move the block counter? You moved the counter one and only one time with 100% certainty. This is because you either updated on the first frame or the second frame. It can’t be both or neither!

The above generalizes as you walk forward more pixels. If you move an even number of pixels without stopping, you are 100% certain to have moved the block counter the number of pixels moved divided by 2. If you moved an odd number of pixels, you don’t know what the block counter is incremented to.

As a concrete example, if you walk 6 pixels forward without stopping, you definitely moved the counter up by 3. If you moved 7 pixels, you have a 50% probability of moving it by 3 and a 50% probability of moving it 4.

=== Turnback Requirements ===
As you walk through a Column Update Window, you update each block in a column twice. Given this, it would seem like you will need to execute two turnbacks. Unfortunately, this is not always the case.

When you execute a turnback, you go back two pixels, then forward two pixels. You have now incremented the block counter twice. However, you are also on the same pixel in the Column Update Window as you were before you started the turnback. This means you have essentially added two extra counter updates than a normal walkthrough. Since you have to execute the turnback a second time, you are incrementing the block counter a total of four extra times. Those four extra increments will cause you to start updating some of the higher blocks a third time!

In practice, if you execute 2 frame turnbacks, you need to do three turnbacks unless you are targeting blocks at the 5th or 6th height index in the above diagram, in which case you can continue doing 2 turnbacks.

If you execute 4 frame turnbacks, you need to do 4 turnbacks for block indexes from 1 to 3, and 3 turnbacks for indices 4-6.

Note that these are simplifications. There are scenarios where you can do fewer turnbacks if you get lucky ( a combination of turnbacks being too short but getting lucky with the frame counter). In addition, you often want to execute extra turnbacks to raise consistency (discussed later).

''TECHNICAL NOTE - This is oversimplified. There are some details around having an odd number of pixels on the last walk forward that leads to one extra counter iteration. I don’t think this is a missing aspect of the algorithm, just some tricky off-by-one math. I got frustrated and stopped trying to nail it down exactly. ''

=== Scroll Glitch Execution Approaches ===

For all strategies, there is an important starting pixel where you want to start your turnbacks. This is the pixel that will have the block counter 1 below your target block regardless of whether. You can find this pixel with visuals for each of the level 5 tricks further down this page.

=== 2 - 14 Turnback Method ===

The 2-14 method is the first RTA viable method used by runners and is still used by most. We will do a series of 2 pixel turnbacks followed by 14 pixel walk forwards.

==== Beginner Approach ====
The easiest, although slowest, method is to find a launch point to predictably get to your starting pixel. This is usually done by back jumping and changing direction midair by ducking the opposite direction. If the backjump succeeds, you will have always landed on the right starting pixel. This gives you plenty of time to make sure you pick the right jump point without breaking the glitch.

Once you have gotten to the first pixel, you need a consistent way to go back two pixels. This is usually done by turning in the backwards direction and whipping on the next possible frame. If you are late on the whip, Simon will visibly walk further. If you are early, you will move only 1 pixel back but simon will still be facing forward.

After this, walk forward 14 pixels, rinse, and repeat. Most runners learn the proper 14 pixel visual at each turnback point and practice going to each one. Pictures are on the wiki for this.

This is a slow method, but it is easier for beginners to learn, execute, and diagnose. This slowness will limit the RTA viability of the trick to stage 13, stage 14 standard, and stage 14 advanced. The others are either too risky or the time savings are largely negated by the setup time.

==== Advanced Approach ====

There are two approaches to speed this up. The first is to pick a proper jump point to land on the right starting pixel. If you recognize that you jumped a pixel early, you can duck to move one extra pixel on landing to compensate.

The second approach is to just push back for two frames and push forward for fourteen frames repeatedly without whipping. You can use the jump setup described above or just hit back on the appropriate first frame. This is currently only being executed by Jay_Cee and I don’t have good advice for how to do this outside of lots of practice.

=== Corrections and Reliability Improvements ===

==== Adjust Pixels ====

Most runners learn to target each turnback pixel. If your turnback or turn forward is off by one pixel, the trick now has a 50% chance of success. This is because you now how much you have incremented the Block Counter (see the even-odd rule in the “Removing Tile Updating RNG” section).

HOWEVER, if you proceed as normal and target the same pixels afterwards, you now cut your probability of success down to 25%. For example, if you walk backwards 3 pixels instead of 2, your walk forward will now be 15 pixels if you keep your same target. That is now effectively one more area where you may have moved the counter an extra time.

You instead want to keep your existing movements the same and only move forward 14 pixels. You should either adjust your visual cue or use a rhythm method to feel what 14 frames of movement is like and ignore all pixel targets outside of the first one.

If you moved backwards more than 3 pixels, you definitely moved the counter more than you wanted. It can be saved but only by switching mid-run to the 4-12 turnback method (discussed later).

If you walked forward 2 pixels beyond your target pixel, unless you messed something earlier, the tile you wanted has been locked into a new value and the trick is dead.

==== Extra Turnback ====

As you get closer to the end of the Column Update Window, there are a few additional tweaks that can help save a dead scrollglitch attempt. For example, you may want to consider adding a 3rd turnback for the stage 14 scrollglitch.

For that glitch, unlike stage 13, the block counter doesn’t loop around for a 3rd time to that lower tile, so only two turnbacks are necessary. However, the counter ALMOST makes it there. If you have 3 pixel turnbacks instead of 2 or start the turnbacks slightly early, you are walking more in the Column Update Window after the final turnback. This can increment the block counter more and update your tile, even if you succeeded on the first two turnbacks.

Given this, you can consider adding one extra turnback as an insurance policy. For the 2-14 turnbacks, this is usually most relevant for the stage 14 wall glitch. For higher blocks like the stage 13 glitch, it is very unlikely that it will be able to make an extra loop, so I would not recommend it there.

=== Lenient Final Turnback ===

The above extra turnback is valuable when the normal final turnback is far away from the end of the Column Update Window. However, for some tricks, the final turnback is very close to the end of the Column Update Window. Stage 13 is a great example of this. That closeness creates extra leniency that we can take advantage of.

When normally doing the scroll glitch, let's assume you make a mistake. Instead of going back two pixels, you go back four. You have moved the counter two times. Your target block was not updated, so the trick is still alive; however, the trick is now out of alignment. If you move forward the normal 14 pixels, the trick will be ripped. HOWEVER, if this turnback was close to the end of the Column Update Window, you will escape before you walk 14 pixels. This means a 4 pixel turnback will not rip the final turnback on stage 13!

In fact, I would RECOMMEND doing a 4 pixel turnback on your final turnback here. The reason is you are skipping over two blocks on that last turnback. So if, for example, the block counter is 1 behind due to an earlier mistake, your run would normally be ripped on the final turnback. However, by moving the counter twice at the end, you protected yourself. In fact, this can move the 50% probability of success back to 100%. The block counter could have one of two possible values, and you handle both cases with one turnback.

You should do the 4 pixel turnback after walking 14 pixels if you think the counter is one behind. If you think the counter is one ahead, you should walk forward 12 pixels and then do the 4 pixel turnback. I highly recommend adding one of these approaches to your final turnback on stage 13. If you are adding an EXTRA turnback, as discussed above, the same leniency rule will apply there.

=== 4-12 Turnback Method ===

The leniency property on the last turnback can actually be applied to all turnbacks. Instead of doing 2-14 pixel turnbacks, you can execute 4-12 pixel turnbacks everywhere. This is my preferred technique.

By going back 4 pixels, you are actually skipping two blocks, not one. You don’t need to move two blocks; however, this can provide an extra buffer in case you make a mistake. For the 2-14 pixel approach, if you are off by 1 pixel, the success rate drops to 50%. If you are ever off by more than 1 pixel, the success rate is 0% unless you get lucky and make a countering mistake elsewhere.

For the 4-12 approach, if you are off by 1 pixel, you have a 50% probability for one of the blocks to be overridden. However, assuming the direction you are off is random, you have a 50% chance of that block being the one you care about. So now you have around a 75% probability of success even if you make a 1 pixel mistake. Furthermore, if you make a 2 pixel mistake, you still have a 50% probability of success. A 3 pixel mistake lowers you to around a 25% chance.

While the above math is just a rough approximation, this method has generally seemed more lenient than the 2-14 approach. In addition, if you are doing the whipless turnback technique, at least for me, it is much easier to consistently do a 4 pixel turnback instead of a 2 pixel one. You learn the back and forth d-pad rhythm and the trick can become quite consistent.

Unfortunately, this approach does have a few downsides. First, each turnback will cost an extra 4 frames. In addition, you will often have to do one extra turnback relative to the two pixel turnback. If targeting block 2 or 3, I would recommend 4 turnbacks. Anything below that, I would recommend 3 turnbacks.

=== Training Resources, Starting Pixels and Timings ===
ROMHack - A romhack is available on the CV1 discord. When used, it will print out Simon’s pixel coordinates. In addition, it will print the Block Counter.

The starting pixel coordinates for the scroll glitches are:

{| class="wikitable" style="margin:left"
|+
|-
! Stage Number !! Pixel !! Savings**
|-
| Stage 6 Crusher || 1D9 & 1B9 || ~ 9 sec
|-
| Stage 7 Coffee || 255 & 1F9 || ~ 1.4 sec
|-
| Stage 13 Griddle || A4 || ~ 12.5 sec
|-
| Stage 14 Bacon || 45C or 43D || ~ 3.5 sec
|-
| Stage 14 Egg || 2C4* || ~ 6 sec
|-
| Stage 14 Cheese || 328 || ~ 8 sec
|-
| Stage 17 Clocktower || 219 & 1FB || ~ 6 sec
|}

<nowiki>*</nowiki>Touching pixel 2B9 is needed before turning around

<nowiki>**</nowiki>Timings are approximate, also you may not see the same time savings if you don't play the rest of the level as optimal as your prior splits, example the 12 second saving of Stage 13 might turn into 6 seconds if you missed other things in level 5.

Stage 13:

Start on 7A turn around, backwards jump and turnaround to land on A4 -> A1. The a 14 frame Walk to B0 then B0 2 frame turnaround AE. Then a 14 frame walk end on BC quick left turn around (between 2-5 frames?) and then walk right.

[[File:CV1_13-SG-1.png|250px]]
[[File:CV1_13-SG-2.png|250px]]
[[File:CV1_13-SG-3.png|250px]]
[[File:CV1_13-SG-4.png|250px]]

Stage 14
Start on 2FE then backwards jump and turn and land on 328. Whip turnaround 328 -> 326, then move to and do a whip turn around 334 -> 332.

[[File:CV1_14-SG-1.png|250px]]
[[File:CV1_14-SG-2.png|250px]]
[[File:CV1_14-SG-3.png|250px]]

=== Emulator Training Tools ===
I have created a set of scroll glitch training tools (along with other cv1 helper tools). These currently require using bizhawk, although I will likely port to other emulators in the future.

https://www.speedrun.com/cv1/resources

Helpful tools included are:

1. Create lines onscreen to show turnback locations
2. Auto-death tool - kills you if you miss a scroll glitch
3. Turnback-Turnforward diagnostic printout (to highlight if you really are hitting 2-14 or 4-12)

Note, if you are using original hardware, the above tools may be a little annoying as the input latency is different. I would still recommend trying them though as many scroll glitch execution strategies are not latency sensitive.

=== Rhythm Sounds ===
If you are trying to learn a whipless rhythm approach, sounds can also be a helpful aid. You hit the buttons on the appropriate beat. Every frame is 1/60th of a second (technically 1/60.09), so you can use that to create a beat. One style is to do 4/60th of a second followed by 12/60th of a second. Another is to just have a metronome set to 16/60th of a second and time either your forward or backward presses to that beat.

Below are two videos with rhythm of whipless scroll glitch turnbacks for 4-12 pattern. To execute 4-12 wiggles, do a turnback on the short note, and move forward on the long note.

{{#ev:youtube|Zn2FFhDc5WE|550}}

{{#ev:youtube|-WG7e4nAnp4|550}}

=== Acknowledgements ===

InfoManiac
Originally discovered the scroll glitch. The initial method only worked on TAS

Challenger
Implemented almost all the current scroll glitches in TAS that have since been ported to RTA by others.

NatGoesFast
Accidently did a scroll glitch on stream. An investigation of this led to the whip based RTA strategy discussed above.

SBDWolf
Found the whip based RTA viable approach for stage 13 and stage 14. Also figured out probably 75% of the basic block updating algorithm and RTA strategies such as odd/even frames approach. Also was the first person to use these scroll glitches to get WR. (May have also found the crusher room scrollglitch).

Shockratease
Along with SBDWolf, did extensive investigation and teaching on the scroll glitch. Suggested using 16/60th beats instead of two-part beats.

Kajong0007
Created the Romhack mentioned above, which has been used extensively by runners to better learn the trick.

JayCee
First person to remove whips for turnbacks and use it in runs. The removal of whips also enabled a lot of additional scroll glitch areas (crusher, clocktower) which did not seem viable otherwise. This inspired additional scrollglitch innovations.

Trisk (tr1sklion)
Wrote this document. Found the Block Counter and Column Update Window in the game bytecode. Validated and enhanced the earlier algorithm approximation SBDWolf modeled. Wrote the Bizhawk training tools. Pioneered the 4-frame turnbacks strategy and most correction strategies.

== Videos ==

SBDWolf talking about the scroll glitches

{{#ev:youtube|rmlBCzdVlOc|550}}

{{#ev:youtube|yaRmDa_T-oo|550}}

Here's Shockra Tease talking about both Scroll Glitches

{{#ev:youtube|Dw7NkOzp8tE|550}}

Advanced Stage 14

{{#ev:youtube|zxLs7h2cL6Y|550}}

Displaced Gamers Video on the code

{{#ev:youtube|wd18YNZB0D4|550}}

Cv1/ScrollGlitch

2024-04-17T21:35:49Z

K c r: /* Training Resources, Starting Pixels and Timings */

== Breaking Dracula’s Castle 101 ==

Before delving into why the scroll glitch works and how to execute it, I recommend understanding how castlevania updates its background tiles. Once we understand this, we can find various ways to break it, as well as diagnose when the scroll glitch fails.

=== How are background tiles updated? ===

Castlevania graphics are made up of foreground sprites (simon, candles, hearts, enemies) and background tiles. The game is building up these background tiles ahead of what is actually on the screen behind the scenes so that it can scroll smoothly as Simon moves. Around half a screen offscreen, the game is drawing a column two blocks wide. When that is complete, the game moves onto the next column. It looks something like this:

[[File:CV1_ScrollGlitch1. updated.png|550px]]

=== Tile Update Algorithm ===

Step 1: Should the update algorithm run?

There is a framecounter that starts at the beginning of every screen. This is the same framecounter that powers the item drops throughout the game. The update algorithm ONLY runs every other frame. I am not certain as to why, but I would guess this is because the Nintendo is not a very powerful system and this gives it time to do other work. Even if Simon is moving forward on a non updating frame, no tile will be updated.

Step 2: Is Simon moving (left or right… doesn’t matter)?

If Simon is moving (and we are on an even frame as discussed above), the tile upgrading algorithm will run and update a tile. Otherwise, the tile updating process is skipped.

Step 3: Determine which vertical column is going to be updated

If Simon is walking left, we will select a column on the left to update. If he is walking right, the column will be to the right. Every column is 32 pixels wide. For every column, there is another set of 32 pixels around 1.5 screens away that map to that column. When Simon is walking over this set of pixels in the direction towards that column, that column will be updated. See the section “How Background Tiles are Updated” for a picture that corresponds to this mapping.

I will refer to this 32 pixel walking space as the Column Update Window.

Step 4: Determine which tiles will be updated

We are now going to choose which actual blocks on the column will be updated. The game manages a special variable called the Block Counter that determines that location. This variable maps to the tiles vertically like so:

[[File:Block_Counter_mapping.png|550px]]

The block counter has a value between 0 and 7, inclusive; however, only the values 1-6 actually map to blocks.

Here is how the algorithm works:

# Did I just enter a new “Column update window”? (One of those 32 pixel spaces you walk over)
#*If yes, no matter WHAT ( even overriding the every other frame rule described above), reset the Block counter to 0
# Update the blocks in the selected column (the direction Simon is facing) at the vertical level marked by the block counter.
#*If the counter is 0 or 7, this does nothing.
# Increment the block counter by 1
# If the block counter > 7, set the block counter to 0

=== How non-glitched walking normally works ===
A player usually just walks in one direction for a while. As they walk through a new Column Update Window, the column 1.5 screens away starts getting updated. The Column Update Window is 32 pixels wide and we update tiles every other pixel, so we will run the tile upgrading algorithm 16 times (32/2). This will cause the block counter to go from 0 -> 7 and then 0 -> 7 again. This updates every tile value twice. Updating it twice doesn’t cause any harm - it just puts the same value there.

''NOTE - Technically there is a 50% probability of it being 15 times, not 16. This is because the first value is always overridden to 0. If that happens on the tile updating frame, the counter will still be held at 0. ''

=== What causes the scroll glitch to happen? ===

This algorithm manages tile drawing in BOTH the left and right direction. However, there is only ONE block counter. If you are walking left and the tile counter is at 4 but then turn right while the block counter turns to 5, then turn left again as the block counter changes to 6, you skipped a block on the left side. You updated blockset 4 and 6 but skipped 5.

The algorithm has a correction mechanism though. Notice that we normally iterate over the blocks twice for one column update window. That block 5 will get corrected as you continue to walk left… unless you do the same turnback again. Keep repeating this turnback until you have exited the column update window and you have successfully skipped updating the block, performing a “scroll glitch”.

This glitch does not let you put any tile value you want there. You are only skipping writing a value. This means the value will be whatever was there last.

=== Removing Tile Updating RNG ===
If the block counter is only updated every other frame, it seems impossible to actually make the trick predictable. Luckily, there is a neat math trick that solves this. This is best explained with an example:

If you move 1 frame, did you move the block counter? You don’t know. There is a 50% probability you did. If you move 2 frames, did you move the block counter? You moved the counter one and only one time with 100% certainty. This is because you either updated on the first frame or the second frame. It can’t be both or neither!

The above generalizes as you walk forward more pixels. If you move an even number of pixels without stopping, you are 100% certain to have moved the block counter the number of pixels moved divided by 2. If you moved an odd number of pixels, you don’t know what the block counter is incremented to.

As a concrete example, if you walk 6 pixels forward without stopping, you definitely moved the counter up by 3. If you moved 7 pixels, you have a 50% probability of moving it by 3 and a 50% probability of moving it 4.

=== Turnback Requirements ===
As you walk through a Column Update Window, you update each block in a column twice. Given this, it would seem like you will need to execute two turnbacks. Unfortunately, this is not always the case.

When you execute a turnback, you go back two pixels, then forward two pixels. You have now incremented the block counter twice. However, you are also on the same pixel in the Column Update Window as you were before you started the turnback. This means you have essentially added two extra counter updates than a normal walkthrough. Since you have to execute the turnback a second time, you are incrementing the block counter a total of four extra times. Those four extra increments will cause you to start updating some of the higher blocks a third time!

In practice, if you execute 2 frame turnbacks, you need to do three turnbacks unless you are targeting blocks at the 5th or 6th height index in the above diagram, in which case you can continue doing 2 turnbacks.

If you execute 4 frame turnbacks, you need to do 4 turnbacks for block indexes from 1 to 3, and 3 turnbacks for indices 4-6.

Note that these are simplifications. There are scenarios where you can do fewer turnbacks if you get lucky ( a combination of turnbacks being too short but getting lucky with the frame counter). In addition, you often want to execute extra turnbacks to raise consistency (discussed later).

''TECHNICAL NOTE - This is oversimplified. There are some details around having an odd number of pixels on the last walk forward that leads to one extra counter iteration. I don’t think this is a missing aspect of the algorithm, just some tricky off-by-one math. I got frustrated and stopped trying to nail it down exactly. ''

=== Scroll Glitch Execution Approaches ===

For all strategies, there is an important starting pixel where you want to start your turnbacks. This is the pixel that will have the block counter 1 below your target block regardless of whether. You can find this pixel with visuals for each of the level 5 tricks further down this page.

=== 2 - 14 Turnback Method ===

The 2-14 method is the first RTA viable method used by runners and is still used by most. We will do a series of 2 pixel turnbacks followed by 14 pixel walk forwards.

==== Beginner Approach ====
The easiest, although slowest, method is to find a launch point to predictably get to your starting pixel. This is usually done by back jumping and changing direction midair by ducking the opposite direction. If the backjump succeeds, you will have always landed on the right starting pixel. This gives you plenty of time to make sure you pick the right jump point without breaking the glitch.

Once you have gotten to the first pixel, you need a consistent way to go back two pixels. This is usually done by turning in the backwards direction and whipping on the next possible frame. If you are late on the whip, Simon will visibly walk further. If you are early, you will move only 1 pixel back but simon will still be facing forward.

After this, walk forward 14 pixels, rinse, and repeat. Most runners learn the proper 14 pixel visual at each turnback point and practice going to each one. Pictures are on the wiki for this.

This is a slow method, but it is easier for beginners to learn, execute, and diagnose. This slowness will limit the RTA viability of the trick to stage 13, stage 14 standard, and stage 14 advanced. The others are either too risky or the time savings are largely negated by the setup time.

==== Advanced Approach ====

There are two approaches to speed this up. The first is to pick a proper jump point to land on the right starting pixel. If you recognize that you jumped a pixel early, you can duck to move one extra pixel on landing to compensate.

The second approach is to just push back for two frames and push forward for fourteen frames repeatedly without whipping. You can use the jump setup described above or just hit back on the appropriate first frame. This is currently only being executed by Jay_Cee and I don’t have good advice for how to do this outside of lots of practice.

=== Corrections and Reliability Improvements ===

==== Adjust Pixels ====

Most runners learn to target each turnback pixel. If your turnback or turn forward is off by one pixel, the trick now has a 50% chance of success. This is because you now how much you have incremented the Block Counter (see the even-odd rule in the “Removing Tile Updating RNG” section).

HOWEVER, if you proceed as normal and target the same pixels afterwards, you now cut your probability of success down to 25%. For example, if you walk backwards 3 pixels instead of 2, your walk forward will now be 15 pixels if you keep your same target. That is now effectively one more area where you may have moved the counter an extra time.

You instead want to keep your existing movements the same and only move forward 14 pixels. You should either adjust your visual cue or use a rhythm method to feel what 14 frames of movement is like and ignore all pixel targets outside of the first one.

If you moved backwards more than 3 pixels, you definitely moved the counter more than you wanted. It can be saved but only by switching mid-run to the 4-12 turnback method (discussed later).

If you walked forward 2 pixels beyond your target pixel, unless you messed something earlier, the tile you wanted has been locked into a new value and the trick is dead.

==== Extra Turnback ====

As you get closer to the end of the Column Update Window, there are a few additional tweaks that can help save a dead scrollglitch attempt. For example, you may want to consider adding a 3rd turnback for the stage 14 scrollglitch.

For that glitch, unlike stage 13, the block counter doesn’t loop around for a 3rd time to that lower tile, so only two turnbacks are necessary. However, the counter ALMOST makes it there. If you have 3 pixel turnbacks instead of 2 or start the turnbacks slightly early, you are walking more in the Column Update Window after the final turnback. This can increment the block counter more and update your tile, even if you succeeded on the first two turnbacks.

Given this, you can consider adding one extra turnback as an insurance policy. For the 2-14 turnbacks, this is usually most relevant for the stage 14 wall glitch. For higher blocks like the stage 13 glitch, it is very unlikely that it will be able to make an extra loop, so I would not recommend it there.

=== Lenient Final Turnback ===

The above extra turnback is valuable when the normal final turnback is far away from the end of the Column Update Window. However, for some tricks, the final turnback is very close to the end of the Column Update Window. Stage 13 is a great example of this. That closeness creates extra leniency that we can take advantage of.

When normally doing the scroll glitch, let's assume you make a mistake. Instead of going back two pixels, you go back four. You have moved the counter two times. Your target block was not updated, so the trick is still alive; however, the trick is now out of alignment. If you move forward the normal 14 pixels, the trick will be ripped. HOWEVER, if this turnback was close to the end of the Column Update Window, you will escape before you walk 14 pixels. This means a 4 pixel turnback will not rip the final turnback on stage 13!

In fact, I would RECOMMEND doing a 4 pixel turnback on your final turnback here. The reason is you are skipping over two blocks on that last turnback. So if, for example, the block counter is 1 behind due to an earlier mistake, your run would normally be ripped on the final turnback. However, by moving the counter twice at the end, you protected yourself. In fact, this can move the 50% probability of success back to 100%. The block counter could have one of two possible values, and you handle both cases with one turnback.

You should do the 4 pixel turnback after walking 14 pixels if you think the counter is one behind. If you think the counter is one ahead, you should walk forward 12 pixels and then do the 4 pixel turnback. I highly recommend adding one of these approaches to your final turnback on stage 13. If you are adding an EXTRA turnback, as discussed above, the same leniency rule will apply there.

=== 4-12 Turnback Method ===

The leniency property on the last turnback can actually be applied to all turnbacks. Instead of doing 2-14 pixel turnbacks, you can execute 4-12 pixel turnbacks everywhere. This is my preferred technique.

By going back 4 pixels, you are actually skipping two blocks, not one. You don’t need to move two blocks; however, this can provide an extra buffer in case you make a mistake. For the 2-14 pixel approach, if you are off by 1 pixel, the success rate drops to 50%. If you are ever off by more than 1 pixel, the success rate is 0% unless you get lucky and make a countering mistake elsewhere.

For the 4-12 approach, if you are off by 1 pixel, you have a 50% probability for one of the blocks to be overridden. However, assuming the direction you are off is random, you have a 50% chance of that block being the one you care about. So now you have around a 75% probability of success even if you make a 1 pixel mistake. Furthermore, if you make a 2 pixel mistake, you still have a 50% probability of success. A 3 pixel mistake lowers you to around a 25% chance.

While the above math is just a rough approximation, this method has generally seemed more lenient than the 2-14 approach. In addition, if you are doing the whipless turnback technique, at least for me, it is much easier to consistently do a 4 pixel turnback instead of a 2 pixel one. You learn the back and forth d-pad rhythm and the trick can become quite consistent.

Unfortunately, this approach does have a few downsides. First, each turnback will cost an extra 4 frames. In addition, you will often have to do one extra turnback relative to the two pixel turnback. If targeting block 2 or 3, I would recommend 4 turnbacks. Anything below that, I would recommend 3 turnbacks.

=== Training Resources, Starting Pixels and Timings ===
ROMHack - A romhack is available on the CV1 discord. When used, it will print out Simon’s pixel coordinates. In addition, it will print the Block Counter.

The starting pixel coordinates for the scroll glitches are:

{| class="wikitable" style="margin:left"
|+
|-
! Stage Number !! Pixel !! Savings**
|-
| Stage 6 Crusher || 1D9 & 1B9 || ~9 sec
|-
| Stage 7 Coffee || 255 & 1F9 || ~1.4 sec
|-
| Stage 13 Griddle || A4 || ~12.5 sec
|-
| Stage 14 Bacon || 45C or 43D || ~3.5 sec
|-
| Stage 14 Egg || 2C4* || ~6 sec
|-
| Stage 14 Cheese || 328 || ~8 sec
|-
| Stage 17 Clocktower || 219 & 1FB || ~6 sec
|}

<nowiki>*</nowiki>Touching pixel 2B9 is needed before turning around

<nowiki>**</nowiki>Timings are approximate, also you may not see the same time savings if you don't play the rest of the level as optimal as your prior splits, example the 12 second saving of Stage 13 might turn into 6 seconds if you missed other things in level 5.

Stage 13:

Start on 7A turn around, backwards jump and turnaround to land on A4 -> A1. The a 14 frame Walk to B0 then B0 2 frame turnaround AE. Then a 14 frame walk end on BC quick left turn around (between 2-5 frames?) and then walk right.

[[File:CV1_13-SG-1.png|250px]]
[[File:CV1_13-SG-2.png|250px]]
[[File:CV1_13-SG-3.png|250px]]
[[File:CV1_13-SG-4.png|250px]]

Stage 14
Start on 2FE then backwards jump and turn and land on 328. Whip turnaround 328 -> 326, then move to and do a whip turn around 334 -> 332.

[[File:CV1_14-SG-1.png|250px]]
[[File:CV1_14-SG-2.png|250px]]
[[File:CV1_14-SG-3.png|250px]]

=== Emulator Training Tools ===
I have created a set of scroll glitch training tools (along with other cv1 helper tools). These currently require using bizhawk, although I will likely port to other emulators in the future.

https://www.speedrun.com/cv1/resources

Helpful tools included are:

1. Create lines onscreen to show turnback locations
2. Auto-death tool - kills you if you miss a scroll glitch
3. Turnback-Turnforward diagnostic printout (to highlight if you really are hitting 2-14 or 4-12)

Note, if you are using original hardware, the above tools may be a little annoying as the input latency is different. I would still recommend trying them though as many scroll glitch execution strategies are not latency sensitive.

=== Rhythm Sounds ===
If you are trying to learn a whipless rhythm approach, sounds can also be a helpful aid. You hit the buttons on the appropriate beat. Every frame is 1/60th of a second (technically 1/60.09), so you can use that to create a beat. One style is to do 4/60th of a second followed by 12/60th of a second. Another is to just have a metronome set to 16/60th of a second and time either your forward or backward presses to that beat.

Below are two videos with rhythm of whipless scroll glitch turnbacks for 4-12 pattern. To execute 4-12 wiggles, do a turnback on the short note, and move forward on the long note.

{{#ev:youtube|Zn2FFhDc5WE|550}}

{{#ev:youtube|-WG7e4nAnp4|550}}

=== Acknowledgements ===

InfoManiac
Originally discovered the scroll glitch. The initial method only worked on TAS

Challenger
Implemented almost all the current scroll glitches in TAS that have since been ported to RTA by others.

NatGoesFast
Accidently did a scroll glitch on stream. An investigation of this led to the whip based RTA strategy discussed above.

SBDWolf
Found the whip based RTA viable approach for stage 13 and stage 14. Also figured out probably 75% of the basic block updating algorithm and RTA strategies such as odd/even frames approach. Also was the first person to use these scroll glitches to get WR. (May have also found the crusher room scrollglitch).

Shockratease
Along with SBDWolf, did extensive investigation and teaching on the scroll glitch. Suggested using 16/60th beats instead of two-part beats.

Kajong0007
Created the Romhack mentioned above, which has been used extensively by runners to better learn the trick.

JayCee
First person to remove whips for turnbacks and use it in runs. The removal of whips also enabled a lot of additional scroll glitch areas (crusher, clocktower) which did not seem viable otherwise. This inspired additional scrollglitch innovations.

Trisk (tr1sklion)
Wrote this document. Found the Block Counter and Column Update Window in the game bytecode. Validated and enhanced the earlier algorithm approximation SBDWolf modeled. Wrote the Bizhawk training tools. Pioneered the 4-frame turnbacks strategy and most correction strategies.

== Videos ==

SBDWolf talking about the scroll glitches

{{#ev:youtube|rmlBCzdVlOc|550}}

{{#ev:youtube|yaRmDa_T-oo|550}}

Here's Shockra Tease talking about both Scroll Glitches

{{#ev:youtube|Dw7NkOzp8tE|550}}

Advanced Stage 14

{{#ev:youtube|zxLs7h2cL6Y|550}}

Displaced Gamers Video on the code

{{#ev:youtube|wd18YNZB0D4|550}}

Cv1/ScrollGlitch

2024-04-17T21:34:47Z

K c r: /* Training Resources */

== Breaking Dracula’s Castle 101 ==

Before delving into why the scroll glitch works and how to execute it, I recommend understanding how castlevania updates its background tiles. Once we understand this, we can find various ways to break it, as well as diagnose when the scroll glitch fails.

=== How are background tiles updated? ===

Castlevania graphics are made up of foreground sprites (simon, candles, hearts, enemies) and background tiles. The game is building up these background tiles ahead of what is actually on the screen behind the scenes so that it can scroll smoothly as Simon moves. Around half a screen offscreen, the game is drawing a column two blocks wide. When that is complete, the game moves onto the next column. It looks something like this:

[[File:CV1_ScrollGlitch1. updated.png|550px]]

=== Tile Update Algorithm ===

Step 1: Should the update algorithm run?

There is a framecounter that starts at the beginning of every screen. This is the same framecounter that powers the item drops throughout the game. The update algorithm ONLY runs every other frame. I am not certain as to why, but I would guess this is because the Nintendo is not a very powerful system and this gives it time to do other work. Even if Simon is moving forward on a non updating frame, no tile will be updated.

Step 2: Is Simon moving (left or right… doesn’t matter)?

If Simon is moving (and we are on an even frame as discussed above), the tile upgrading algorithm will run and update a tile. Otherwise, the tile updating process is skipped.

Step 3: Determine which vertical column is going to be updated

If Simon is walking left, we will select a column on the left to update. If he is walking right, the column will be to the right. Every column is 32 pixels wide. For every column, there is another set of 32 pixels around 1.5 screens away that map to that column. When Simon is walking over this set of pixels in the direction towards that column, that column will be updated. See the section “How Background Tiles are Updated” for a picture that corresponds to this mapping.

I will refer to this 32 pixel walking space as the Column Update Window.

Step 4: Determine which tiles will be updated

We are now going to choose which actual blocks on the column will be updated. The game manages a special variable called the Block Counter that determines that location. This variable maps to the tiles vertically like so:

[[File:Block_Counter_mapping.png|550px]]

The block counter has a value between 0 and 7, inclusive; however, only the values 1-6 actually map to blocks.

Here is how the algorithm works:

# Did I just enter a new “Column update window”? (One of those 32 pixel spaces you walk over)
#*If yes, no matter WHAT ( even overriding the every other frame rule described above), reset the Block counter to 0
# Update the blocks in the selected column (the direction Simon is facing) at the vertical level marked by the block counter.
#*If the counter is 0 or 7, this does nothing.
# Increment the block counter by 1
# If the block counter > 7, set the block counter to 0

=== How non-glitched walking normally works ===
A player usually just walks in one direction for a while. As they walk through a new Column Update Window, the column 1.5 screens away starts getting updated. The Column Update Window is 32 pixels wide and we update tiles every other pixel, so we will run the tile upgrading algorithm 16 times (32/2). This will cause the block counter to go from 0 -> 7 and then 0 -> 7 again. This updates every tile value twice. Updating it twice doesn’t cause any harm - it just puts the same value there.

''NOTE - Technically there is a 50% probability of it being 15 times, not 16. This is because the first value is always overridden to 0. If that happens on the tile updating frame, the counter will still be held at 0. ''

=== What causes the scroll glitch to happen? ===

This algorithm manages tile drawing in BOTH the left and right direction. However, there is only ONE block counter. If you are walking left and the tile counter is at 4 but then turn right while the block counter turns to 5, then turn left again as the block counter changes to 6, you skipped a block on the left side. You updated blockset 4 and 6 but skipped 5.

The algorithm has a correction mechanism though. Notice that we normally iterate over the blocks twice for one column update window. That block 5 will get corrected as you continue to walk left… unless you do the same turnback again. Keep repeating this turnback until you have exited the column update window and you have successfully skipped updating the block, performing a “scroll glitch”.

This glitch does not let you put any tile value you want there. You are only skipping writing a value. This means the value will be whatever was there last.

=== Removing Tile Updating RNG ===
If the block counter is only updated every other frame, it seems impossible to actually make the trick predictable. Luckily, there is a neat math trick that solves this. This is best explained with an example:

If you move 1 frame, did you move the block counter? You don’t know. There is a 50% probability you did. If you move 2 frames, did you move the block counter? You moved the counter one and only one time with 100% certainty. This is because you either updated on the first frame or the second frame. It can’t be both or neither!

The above generalizes as you walk forward more pixels. If you move an even number of pixels without stopping, you are 100% certain to have moved the block counter the number of pixels moved divided by 2. If you moved an odd number of pixels, you don’t know what the block counter is incremented to.

As a concrete example, if you walk 6 pixels forward without stopping, you definitely moved the counter up by 3. If you moved 7 pixels, you have a 50% probability of moving it by 3 and a 50% probability of moving it 4.

=== Turnback Requirements ===
As you walk through a Column Update Window, you update each block in a column twice. Given this, it would seem like you will need to execute two turnbacks. Unfortunately, this is not always the case.

When you execute a turnback, you go back two pixels, then forward two pixels. You have now incremented the block counter twice. However, you are also on the same pixel in the Column Update Window as you were before you started the turnback. This means you have essentially added two extra counter updates than a normal walkthrough. Since you have to execute the turnback a second time, you are incrementing the block counter a total of four extra times. Those four extra increments will cause you to start updating some of the higher blocks a third time!

In practice, if you execute 2 frame turnbacks, you need to do three turnbacks unless you are targeting blocks at the 5th or 6th height index in the above diagram, in which case you can continue doing 2 turnbacks.

If you execute 4 frame turnbacks, you need to do 4 turnbacks for block indexes from 1 to 3, and 3 turnbacks for indices 4-6.

Note that these are simplifications. There are scenarios where you can do fewer turnbacks if you get lucky ( a combination of turnbacks being too short but getting lucky with the frame counter). In addition, you often want to execute extra turnbacks to raise consistency (discussed later).

''TECHNICAL NOTE - This is oversimplified. There are some details around having an odd number of pixels on the last walk forward that leads to one extra counter iteration. I don’t think this is a missing aspect of the algorithm, just some tricky off-by-one math. I got frustrated and stopped trying to nail it down exactly. ''

=== Scroll Glitch Execution Approaches ===

For all strategies, there is an important starting pixel where you want to start your turnbacks. This is the pixel that will have the block counter 1 below your target block regardless of whether. You can find this pixel with visuals for each of the level 5 tricks further down this page.

=== 2 - 14 Turnback Method ===

The 2-14 method is the first RTA viable method used by runners and is still used by most. We will do a series of 2 pixel turnbacks followed by 14 pixel walk forwards.

==== Beginner Approach ====
The easiest, although slowest, method is to find a launch point to predictably get to your starting pixel. This is usually done by back jumping and changing direction midair by ducking the opposite direction. If the backjump succeeds, you will have always landed on the right starting pixel. This gives you plenty of time to make sure you pick the right jump point without breaking the glitch.

Once you have gotten to the first pixel, you need a consistent way to go back two pixels. This is usually done by turning in the backwards direction and whipping on the next possible frame. If you are late on the whip, Simon will visibly walk further. If you are early, you will move only 1 pixel back but simon will still be facing forward.

After this, walk forward 14 pixels, rinse, and repeat. Most runners learn the proper 14 pixel visual at each turnback point and practice going to each one. Pictures are on the wiki for this.

This is a slow method, but it is easier for beginners to learn, execute, and diagnose. This slowness will limit the RTA viability of the trick to stage 13, stage 14 standard, and stage 14 advanced. The others are either too risky or the time savings are largely negated by the setup time.

==== Advanced Approach ====

There are two approaches to speed this up. The first is to pick a proper jump point to land on the right starting pixel. If you recognize that you jumped a pixel early, you can duck to move one extra pixel on landing to compensate.

The second approach is to just push back for two frames and push forward for fourteen frames repeatedly without whipping. You can use the jump setup described above or just hit back on the appropriate first frame. This is currently only being executed by Jay_Cee and I don’t have good advice for how to do this outside of lots of practice.

=== Corrections and Reliability Improvements ===

==== Adjust Pixels ====

Most runners learn to target each turnback pixel. If your turnback or turn forward is off by one pixel, the trick now has a 50% chance of success. This is because you now how much you have incremented the Block Counter (see the even-odd rule in the “Removing Tile Updating RNG” section).

HOWEVER, if you proceed as normal and target the same pixels afterwards, you now cut your probability of success down to 25%. For example, if you walk backwards 3 pixels instead of 2, your walk forward will now be 15 pixels if you keep your same target. That is now effectively one more area where you may have moved the counter an extra time.

You instead want to keep your existing movements the same and only move forward 14 pixels. You should either adjust your visual cue or use a rhythm method to feel what 14 frames of movement is like and ignore all pixel targets outside of the first one.

If you moved backwards more than 3 pixels, you definitely moved the counter more than you wanted. It can be saved but only by switching mid-run to the 4-12 turnback method (discussed later).

If you walked forward 2 pixels beyond your target pixel, unless you messed something earlier, the tile you wanted has been locked into a new value and the trick is dead.

==== Extra Turnback ====

As you get closer to the end of the Column Update Window, there are a few additional tweaks that can help save a dead scrollglitch attempt. For example, you may want to consider adding a 3rd turnback for the stage 14 scrollglitch.

For that glitch, unlike stage 13, the block counter doesn’t loop around for a 3rd time to that lower tile, so only two turnbacks are necessary. However, the counter ALMOST makes it there. If you have 3 pixel turnbacks instead of 2 or start the turnbacks slightly early, you are walking more in the Column Update Window after the final turnback. This can increment the block counter more and update your tile, even if you succeeded on the first two turnbacks.

Given this, you can consider adding one extra turnback as an insurance policy. For the 2-14 turnbacks, this is usually most relevant for the stage 14 wall glitch. For higher blocks like the stage 13 glitch, it is very unlikely that it will be able to make an extra loop, so I would not recommend it there.

=== Lenient Final Turnback ===

The above extra turnback is valuable when the normal final turnback is far away from the end of the Column Update Window. However, for some tricks, the final turnback is very close to the end of the Column Update Window. Stage 13 is a great example of this. That closeness creates extra leniency that we can take advantage of.

When normally doing the scroll glitch, let's assume you make a mistake. Instead of going back two pixels, you go back four. You have moved the counter two times. Your target block was not updated, so the trick is still alive; however, the trick is now out of alignment. If you move forward the normal 14 pixels, the trick will be ripped. HOWEVER, if this turnback was close to the end of the Column Update Window, you will escape before you walk 14 pixels. This means a 4 pixel turnback will not rip the final turnback on stage 13!

In fact, I would RECOMMEND doing a 4 pixel turnback on your final turnback here. The reason is you are skipping over two blocks on that last turnback. So if, for example, the block counter is 1 behind due to an earlier mistake, your run would normally be ripped on the final turnback. However, by moving the counter twice at the end, you protected yourself. In fact, this can move the 50% probability of success back to 100%. The block counter could have one of two possible values, and you handle both cases with one turnback.

You should do the 4 pixel turnback after walking 14 pixels if you think the counter is one behind. If you think the counter is one ahead, you should walk forward 12 pixels and then do the 4 pixel turnback. I highly recommend adding one of these approaches to your final turnback on stage 13. If you are adding an EXTRA turnback, as discussed above, the same leniency rule will apply there.

=== 4-12 Turnback Method ===

The leniency property on the last turnback can actually be applied to all turnbacks. Instead of doing 2-14 pixel turnbacks, you can execute 4-12 pixel turnbacks everywhere. This is my preferred technique.

By going back 4 pixels, you are actually skipping two blocks, not one. You don’t need to move two blocks; however, this can provide an extra buffer in case you make a mistake. For the 2-14 pixel approach, if you are off by 1 pixel, the success rate drops to 50%. If you are ever off by more than 1 pixel, the success rate is 0% unless you get lucky and make a countering mistake elsewhere.

For the 4-12 approach, if you are off by 1 pixel, you have a 50% probability for one of the blocks to be overridden. However, assuming the direction you are off is random, you have a 50% chance of that block being the one you care about. So now you have around a 75% probability of success even if you make a 1 pixel mistake. Furthermore, if you make a 2 pixel mistake, you still have a 50% probability of success. A 3 pixel mistake lowers you to around a 25% chance.

While the above math is just a rough approximation, this method has generally seemed more lenient than the 2-14 approach. In addition, if you are doing the whipless turnback technique, at least for me, it is much easier to consistently do a 4 pixel turnback instead of a 2 pixel one. You learn the back and forth d-pad rhythm and the trick can become quite consistent.

Unfortunately, this approach does have a few downsides. First, each turnback will cost an extra 4 frames. In addition, you will often have to do one extra turnback relative to the two pixel turnback. If targeting block 2 or 3, I would recommend 4 turnbacks. Anything below that, I would recommend 3 turnbacks.

=== Training Resources, Starting Pixels and Timings ===
ROMHack - A romhack is available on the CV1 discord. When used, it will print out Simon’s pixel coordinates. In addition, it will print the Block Counter.

The starting pixel coordinates for the scroll glitches are:

{| class="wikitable" style="margin:left"
|+
|-
! Stage Number !! Pixel !! Savings**
|-
| Stage 6 Crusher || 1D9 & 1B9 || ~9 sec
|-
| Stage 7 Coffee || 255 & 1F9 || ~1.4 sec
|-
| Stage 13 Griddle || A4 || ~12.5 sec
|-
| Stage 14 Bacon || 45C or 43D || ~3.5 sec
|-
| Stage 14 Egg || 2C4* || ~6 sec
|-
| Stage 14 Cheese || 328 || ~8 sec
|-
| Stage 17 Clocktower || 219 & 1FB || ~6 sec
|}

<nowiki>*</nowiki>Touching pixel 2B9 is needed before turning around

<nowiki>**</nowiki>Timings are approximate, also you may not see the same time savings if you don't play the rest of the level as optimal as your prior splits, so 12s might turn into 6s.

Stage 13:

Start on 7A turn around, backwards jump and turnaround to land on A4 -> A1. The a 14 frame Walk to B0 then B0 2 frame turnaround AE. Then a 14 frame walk end on BC quick left turn around (between 2-5 frames?) and then walk right.

[[File:CV1_13-SG-1.png|250px]]
[[File:CV1_13-SG-2.png|250px]]
[[File:CV1_13-SG-3.png|250px]]
[[File:CV1_13-SG-4.png|250px]]

Stage 14
Start on 2FE then backwards jump and turn and land on 328. Whip turnaround 328 -> 326, then move to and do a whip turn around 334 -> 332.

[[File:CV1_14-SG-1.png|250px]]
[[File:CV1_14-SG-2.png|250px]]
[[File:CV1_14-SG-3.png|250px]]

=== Emulator Training Tools ===
I have created a set of scroll glitch training tools (along with other cv1 helper tools). These currently require using bizhawk, although I will likely port to other emulators in the future.

https://www.speedrun.com/cv1/resources

Helpful tools included are:

1. Create lines onscreen to show turnback locations
2. Auto-death tool - kills you if you miss a scroll glitch
3. Turnback-Turnforward diagnostic printout (to highlight if you really are hitting 2-14 or 4-12)

Note, if you are using original hardware, the above tools may be a little annoying as the input latency is different. I would still recommend trying them though as many scroll glitch execution strategies are not latency sensitive.

=== Rhythm Sounds ===
If you are trying to learn a whipless rhythm approach, sounds can also be a helpful aid. You hit the buttons on the appropriate beat. Every frame is 1/60th of a second (technically 1/60.09), so you can use that to create a beat. One style is to do 4/60th of a second followed by 12/60th of a second. Another is to just have a metronome set to 16/60th of a second and time either your forward or backward presses to that beat.

Below are two videos with rhythm of whipless scroll glitch turnbacks for 4-12 pattern. To execute 4-12 wiggles, do a turnback on the short note, and move forward on the long note.

{{#ev:youtube|Zn2FFhDc5WE|550}}

{{#ev:youtube|-WG7e4nAnp4|550}}

=== Acknowledgements ===

InfoManiac
Originally discovered the scroll glitch. The initial method only worked on TAS

Challenger
Implemented almost all the current scroll glitches in TAS that have since been ported to RTA by others.

NatGoesFast
Accidently did a scroll glitch on stream. An investigation of this led to the whip based RTA strategy discussed above.

SBDWolf
Found the whip based RTA viable approach for stage 13 and stage 14. Also figured out probably 75% of the basic block updating algorithm and RTA strategies such as odd/even frames approach. Also was the first person to use these scroll glitches to get WR. (May have also found the crusher room scrollglitch).

Shockratease
Along with SBDWolf, did extensive investigation and teaching on the scroll glitch. Suggested using 16/60th beats instead of two-part beats.

Kajong0007
Created the Romhack mentioned above, which has been used extensively by runners to better learn the trick.

JayCee
First person to remove whips for turnbacks and use it in runs. The removal of whips also enabled a lot of additional scroll glitch areas (crusher, clocktower) which did not seem viable otherwise. This inspired additional scrollglitch innovations.

Trisk (tr1sklion)
Wrote this document. Found the Block Counter and Column Update Window in the game bytecode. Validated and enhanced the earlier algorithm approximation SBDWolf modeled. Wrote the Bizhawk training tools. Pioneered the 4-frame turnbacks strategy and most correction strategies.

== Videos ==

SBDWolf talking about the scroll glitches

{{#ev:youtube|rmlBCzdVlOc|550}}

{{#ev:youtube|yaRmDa_T-oo|550}}

Here's Shockra Tease talking about both Scroll Glitches

{{#ev:youtube|Dw7NkOzp8tE|550}}

Advanced Stage 14

{{#ev:youtube|zxLs7h2cL6Y|550}}

Displaced Gamers Video on the code

{{#ev:youtube|wd18YNZB0D4|550}}

Cv1/ScrollGlitch

2024-04-17T21:30:01Z

K c r: /* Training Resources */

== Breaking Dracula’s Castle 101 ==

Before delving into why the scroll glitch works and how to execute it, I recommend understanding how castlevania updates its background tiles. Once we understand this, we can find various ways to break it, as well as diagnose when the scroll glitch fails.

=== How are background tiles updated? ===

Castlevania graphics are made up of foreground sprites (simon, candles, hearts, enemies) and background tiles. The game is building up these background tiles ahead of what is actually on the screen behind the scenes so that it can scroll smoothly as Simon moves. Around half a screen offscreen, the game is drawing a column two blocks wide. When that is complete, the game moves onto the next column. It looks something like this:

[[File:CV1_ScrollGlitch1. updated.png|550px]]

=== Tile Update Algorithm ===

Step 1: Should the update algorithm run?

There is a framecounter that starts at the beginning of every screen. This is the same framecounter that powers the item drops throughout the game. The update algorithm ONLY runs every other frame. I am not certain as to why, but I would guess this is because the Nintendo is not a very powerful system and this gives it time to do other work. Even if Simon is moving forward on a non updating frame, no tile will be updated.

Step 2: Is Simon moving (left or right… doesn’t matter)?

If Simon is moving (and we are on an even frame as discussed above), the tile upgrading algorithm will run and update a tile. Otherwise, the tile updating process is skipped.

Step 3: Determine which vertical column is going to be updated

If Simon is walking left, we will select a column on the left to update. If he is walking right, the column will be to the right. Every column is 32 pixels wide. For every column, there is another set of 32 pixels around 1.5 screens away that map to that column. When Simon is walking over this set of pixels in the direction towards that column, that column will be updated. See the section “How Background Tiles are Updated” for a picture that corresponds to this mapping.

I will refer to this 32 pixel walking space as the Column Update Window.

Step 4: Determine which tiles will be updated

We are now going to choose which actual blocks on the column will be updated. The game manages a special variable called the Block Counter that determines that location. This variable maps to the tiles vertically like so:

[[File:Block_Counter_mapping.png|550px]]

The block counter has a value between 0 and 7, inclusive; however, only the values 1-6 actually map to blocks.

Here is how the algorithm works:

# Did I just enter a new “Column update window”? (One of those 32 pixel spaces you walk over)
#*If yes, no matter WHAT ( even overriding the every other frame rule described above), reset the Block counter to 0
# Update the blocks in the selected column (the direction Simon is facing) at the vertical level marked by the block counter.
#*If the counter is 0 or 7, this does nothing.
# Increment the block counter by 1
# If the block counter > 7, set the block counter to 0

=== How non-glitched walking normally works ===
A player usually just walks in one direction for a while. As they walk through a new Column Update Window, the column 1.5 screens away starts getting updated. The Column Update Window is 32 pixels wide and we update tiles every other pixel, so we will run the tile upgrading algorithm 16 times (32/2). This will cause the block counter to go from 0 -> 7 and then 0 -> 7 again. This updates every tile value twice. Updating it twice doesn’t cause any harm - it just puts the same value there.

''NOTE - Technically there is a 50% probability of it being 15 times, not 16. This is because the first value is always overridden to 0. If that happens on the tile updating frame, the counter will still be held at 0. ''

=== What causes the scroll glitch to happen? ===

This algorithm manages tile drawing in BOTH the left and right direction. However, there is only ONE block counter. If you are walking left and the tile counter is at 4 but then turn right while the block counter turns to 5, then turn left again as the block counter changes to 6, you skipped a block on the left side. You updated blockset 4 and 6 but skipped 5.

The algorithm has a correction mechanism though. Notice that we normally iterate over the blocks twice for one column update window. That block 5 will get corrected as you continue to walk left… unless you do the same turnback again. Keep repeating this turnback until you have exited the column update window and you have successfully skipped updating the block, performing a “scroll glitch”.

This glitch does not let you put any tile value you want there. You are only skipping writing a value. This means the value will be whatever was there last.

=== Removing Tile Updating RNG ===
If the block counter is only updated every other frame, it seems impossible to actually make the trick predictable. Luckily, there is a neat math trick that solves this. This is best explained with an example:

If you move 1 frame, did you move the block counter? You don’t know. There is a 50% probability you did. If you move 2 frames, did you move the block counter? You moved the counter one and only one time with 100% certainty. This is because you either updated on the first frame or the second frame. It can’t be both or neither!

The above generalizes as you walk forward more pixels. If you move an even number of pixels without stopping, you are 100% certain to have moved the block counter the number of pixels moved divided by 2. If you moved an odd number of pixels, you don’t know what the block counter is incremented to.

As a concrete example, if you walk 6 pixels forward without stopping, you definitely moved the counter up by 3. If you moved 7 pixels, you have a 50% probability of moving it by 3 and a 50% probability of moving it 4.

=== Turnback Requirements ===
As you walk through a Column Update Window, you update each block in a column twice. Given this, it would seem like you will need to execute two turnbacks. Unfortunately, this is not always the case.

When you execute a turnback, you go back two pixels, then forward two pixels. You have now incremented the block counter twice. However, you are also on the same pixel in the Column Update Window as you were before you started the turnback. This means you have essentially added two extra counter updates than a normal walkthrough. Since you have to execute the turnback a second time, you are incrementing the block counter a total of four extra times. Those four extra increments will cause you to start updating some of the higher blocks a third time!

In practice, if you execute 2 frame turnbacks, you need to do three turnbacks unless you are targeting blocks at the 5th or 6th height index in the above diagram, in which case you can continue doing 2 turnbacks.

If you execute 4 frame turnbacks, you need to do 4 turnbacks for block indexes from 1 to 3, and 3 turnbacks for indices 4-6.

Note that these are simplifications. There are scenarios where you can do fewer turnbacks if you get lucky ( a combination of turnbacks being too short but getting lucky with the frame counter). In addition, you often want to execute extra turnbacks to raise consistency (discussed later).

''TECHNICAL NOTE - This is oversimplified. There are some details around having an odd number of pixels on the last walk forward that leads to one extra counter iteration. I don’t think this is a missing aspect of the algorithm, just some tricky off-by-one math. I got frustrated and stopped trying to nail it down exactly. ''

=== Scroll Glitch Execution Approaches ===

For all strategies, there is an important starting pixel where you want to start your turnbacks. This is the pixel that will have the block counter 1 below your target block regardless of whether. You can find this pixel with visuals for each of the level 5 tricks further down this page.

=== 2 - 14 Turnback Method ===

The 2-14 method is the first RTA viable method used by runners and is still used by most. We will do a series of 2 pixel turnbacks followed by 14 pixel walk forwards.

==== Beginner Approach ====
The easiest, although slowest, method is to find a launch point to predictably get to your starting pixel. This is usually done by back jumping and changing direction midair by ducking the opposite direction. If the backjump succeeds, you will have always landed on the right starting pixel. This gives you plenty of time to make sure you pick the right jump point without breaking the glitch.

Once you have gotten to the first pixel, you need a consistent way to go back two pixels. This is usually done by turning in the backwards direction and whipping on the next possible frame. If you are late on the whip, Simon will visibly walk further. If you are early, you will move only 1 pixel back but simon will still be facing forward.

After this, walk forward 14 pixels, rinse, and repeat. Most runners learn the proper 14 pixel visual at each turnback point and practice going to each one. Pictures are on the wiki for this.

This is a slow method, but it is easier for beginners to learn, execute, and diagnose. This slowness will limit the RTA viability of the trick to stage 13, stage 14 standard, and stage 14 advanced. The others are either too risky or the time savings are largely negated by the setup time.

==== Advanced Approach ====

There are two approaches to speed this up. The first is to pick a proper jump point to land on the right starting pixel. If you recognize that you jumped a pixel early, you can duck to move one extra pixel on landing to compensate.

The second approach is to just push back for two frames and push forward for fourteen frames repeatedly without whipping. You can use the jump setup described above or just hit back on the appropriate first frame. This is currently only being executed by Jay_Cee and I don’t have good advice for how to do this outside of lots of practice.

=== Corrections and Reliability Improvements ===

==== Adjust Pixels ====

Most runners learn to target each turnback pixel. If your turnback or turn forward is off by one pixel, the trick now has a 50% chance of success. This is because you now how much you have incremented the Block Counter (see the even-odd rule in the “Removing Tile Updating RNG” section).

HOWEVER, if you proceed as normal and target the same pixels afterwards, you now cut your probability of success down to 25%. For example, if you walk backwards 3 pixels instead of 2, your walk forward will now be 15 pixels if you keep your same target. That is now effectively one more area where you may have moved the counter an extra time.

You instead want to keep your existing movements the same and only move forward 14 pixels. You should either adjust your visual cue or use a rhythm method to feel what 14 frames of movement is like and ignore all pixel targets outside of the first one.

If you moved backwards more than 3 pixels, you definitely moved the counter more than you wanted. It can be saved but only by switching mid-run to the 4-12 turnback method (discussed later).

If you walked forward 2 pixels beyond your target pixel, unless you messed something earlier, the tile you wanted has been locked into a new value and the trick is dead.

==== Extra Turnback ====

As you get closer to the end of the Column Update Window, there are a few additional tweaks that can help save a dead scrollglitch attempt. For example, you may want to consider adding a 3rd turnback for the stage 14 scrollglitch.

For that glitch, unlike stage 13, the block counter doesn’t loop around for a 3rd time to that lower tile, so only two turnbacks are necessary. However, the counter ALMOST makes it there. If you have 3 pixel turnbacks instead of 2 or start the turnbacks slightly early, you are walking more in the Column Update Window after the final turnback. This can increment the block counter more and update your tile, even if you succeeded on the first two turnbacks.

Given this, you can consider adding one extra turnback as an insurance policy. For the 2-14 turnbacks, this is usually most relevant for the stage 14 wall glitch. For higher blocks like the stage 13 glitch, it is very unlikely that it will be able to make an extra loop, so I would not recommend it there.

=== Lenient Final Turnback ===

The above extra turnback is valuable when the normal final turnback is far away from the end of the Column Update Window. However, for some tricks, the final turnback is very close to the end of the Column Update Window. Stage 13 is a great example of this. That closeness creates extra leniency that we can take advantage of.

When normally doing the scroll glitch, let's assume you make a mistake. Instead of going back two pixels, you go back four. You have moved the counter two times. Your target block was not updated, so the trick is still alive; however, the trick is now out of alignment. If you move forward the normal 14 pixels, the trick will be ripped. HOWEVER, if this turnback was close to the end of the Column Update Window, you will escape before you walk 14 pixels. This means a 4 pixel turnback will not rip the final turnback on stage 13!

In fact, I would RECOMMEND doing a 4 pixel turnback on your final turnback here. The reason is you are skipping over two blocks on that last turnback. So if, for example, the block counter is 1 behind due to an earlier mistake, your run would normally be ripped on the final turnback. However, by moving the counter twice at the end, you protected yourself. In fact, this can move the 50% probability of success back to 100%. The block counter could have one of two possible values, and you handle both cases with one turnback.

You should do the 4 pixel turnback after walking 14 pixels if you think the counter is one behind. If you think the counter is one ahead, you should walk forward 12 pixels and then do the 4 pixel turnback. I highly recommend adding one of these approaches to your final turnback on stage 13. If you are adding an EXTRA turnback, as discussed above, the same leniency rule will apply there.

=== 4-12 Turnback Method ===

The leniency property on the last turnback can actually be applied to all turnbacks. Instead of doing 2-14 pixel turnbacks, you can execute 4-12 pixel turnbacks everywhere. This is my preferred technique.

By going back 4 pixels, you are actually skipping two blocks, not one. You don’t need to move two blocks; however, this can provide an extra buffer in case you make a mistake. For the 2-14 pixel approach, if you are off by 1 pixel, the success rate drops to 50%. If you are ever off by more than 1 pixel, the success rate is 0% unless you get lucky and make a countering mistake elsewhere.

For the 4-12 approach, if you are off by 1 pixel, you have a 50% probability for one of the blocks to be overridden. However, assuming the direction you are off is random, you have a 50% chance of that block being the one you care about. So now you have around a 75% probability of success even if you make a 1 pixel mistake. Furthermore, if you make a 2 pixel mistake, you still have a 50% probability of success. A 3 pixel mistake lowers you to around a 25% chance.

While the above math is just a rough approximation, this method has generally seemed more lenient than the 2-14 approach. In addition, if you are doing the whipless turnback technique, at least for me, it is much easier to consistently do a 4 pixel turnback instead of a 2 pixel one. You learn the back and forth d-pad rhythm and the trick can become quite consistent.

Unfortunately, this approach does have a few downsides. First, each turnback will cost an extra 4 frames. In addition, you will often have to do one extra turnback relative to the two pixel turnback. If targeting block 2 or 3, I would recommend 4 turnbacks. Anything below that, I would recommend 3 turnbacks.

=== Training Resources ===
ROMHack - A romhack is available on the CV1 discord. When used, it will print out Simon’s pixel coordinates. In addition, it will print the Block Counter.

The starting pixel coordinates for the scroll glitches are:

{| class="wikitable" style="margin:left"
|+
|-
! Stage Number !! Pixel !! Savings**
|-
| Stage 6 Crusher || 1D9 & 1B9 || ~9 sec
|-
| Stage 7 Coffee || 255 & 1F9 || ~1.4 sec
|-
| Stage 13 Griddle || A4 || ~12.5 sec
|-
| Stage 14 Bacon || 45C or 43D || ~3.5 sec
|-
| Stage 14 Egg || 2C4* || ~6 sec
|-
| Stage 14 Cheese || 328 || ~8 sec
|-
| Stage 17 Clocktower || 219 & 1FB || ~6 sec
|}

<nowiki>*</nowiki>Touching pixel 2B9 is needed before turning around

<nowiki>**</nowiki>Timings are approximate, also you may not see the same time savings if you don't play the rest of the level as optimal as your prior splits, so 12s might turn into 6s.

Stage 13:

Start on 7A turn around, backwards jump and turnaround to land on A4 -> A1. The a 14 frame Walk to B0 then B0 2 frame turnaround AE. Then a 14 frame walk end on BC quick left turn around (between 2-5 frames?) and then walk right.

[[File:CV1_13-SG-1.png|250px]]
[[File:CV1_13-SG-2.png|250px]]
[[File:CV1_13-SG-3.png|250px]]
[[File:CV1_13-SG-4.png|250px]]

Stage 14
Start on 2FE then backwards jump and turn and land on 328. Whip turnaround 328 -> 326, then move to and do a whip turn around 334 -> 332.

[[File:CV1_14-SG-1.png|250px]]
[[File:CV1_14-SG-2.png|250px]]
[[File:CV1_14-SG-3.png|250px]]

=== Emulator Training Tools ===
I have created a set of scroll glitch training tools (along with other cv1 helper tools). These currently require using bizhawk, although I will likely port to other emulators in the future.

https://www.speedrun.com/cv1/resources

Helpful tools included are:

1. Create lines onscreen to show turnback locations
2. Auto-death tool - kills you if you miss a scroll glitch
3. Turnback-Turnforward diagnostic printout (to highlight if you really are hitting 2-14 or 4-12)

Note, if you are using original hardware, the above tools may be a little annoying as the input latency is different. I would still recommend trying them though as many scroll glitch execution strategies are not latency sensitive.

=== Rhythm Sounds ===
If you are trying to learn a whipless rhythm approach, sounds can also be a helpful aid. You hit the buttons on the appropriate beat. Every frame is 1/60th of a second (technically 1/60.09), so you can use that to create a beat. One style is to do 4/60th of a second followed by 12/60th of a second. Another is to just have a metronome set to 16/60th of a second and time either your forward or backward presses to that beat.

Below are two videos with rhythm of whipless scroll glitch turnbacks for 4-12 pattern. To execute 4-12 wiggles, do a turnback on the short note, and move forward on the long note.

{{#ev:youtube|Zn2FFhDc5WE|550}}

{{#ev:youtube|-WG7e4nAnp4|550}}

=== Acknowledgements ===

InfoManiac
Originally discovered the scroll glitch. The initial method only worked on TAS

Challenger
Implemented almost all the current scroll glitches in TAS that have since been ported to RTA by others.

NatGoesFast
Accidently did a scroll glitch on stream. An investigation of this led to the whip based RTA strategy discussed above.

SBDWolf
Found the whip based RTA viable approach for stage 13 and stage 14. Also figured out probably 75% of the basic block updating algorithm and RTA strategies such as odd/even frames approach. Also was the first person to use these scroll glitches to get WR. (May have also found the crusher room scrollglitch).

Shockratease
Along with SBDWolf, did extensive investigation and teaching on the scroll glitch. Suggested using 16/60th beats instead of two-part beats.

Kajong0007
Created the Romhack mentioned above, which has been used extensively by runners to better learn the trick.

JayCee
First person to remove whips for turnbacks and use it in runs. The removal of whips also enabled a lot of additional scroll glitch areas (crusher, clocktower) which did not seem viable otherwise. This inspired additional scrollglitch innovations.

Trisk (tr1sklion)
Wrote this document. Found the Block Counter and Column Update Window in the game bytecode. Validated and enhanced the earlier algorithm approximation SBDWolf modeled. Wrote the Bizhawk training tools. Pioneered the 4-frame turnbacks strategy and most correction strategies.

== Videos ==

SBDWolf talking about the scroll glitches

{{#ev:youtube|rmlBCzdVlOc|550}}

{{#ev:youtube|yaRmDa_T-oo|550}}

Here's Shockra Tease talking about both Scroll Glitches

{{#ev:youtube|Dw7NkOzp8tE|550}}

Advanced Stage 14

{{#ev:youtube|zxLs7h2cL6Y|550}}

Displaced Gamers Video on the code

{{#ev:youtube|wd18YNZB0D4|550}}

Cv1/ScrollGlitch

2024-04-17T21:28:33Z

K c r: /* Training Resources */

== Breaking Dracula’s Castle 101 ==

Before delving into why the scroll glitch works and how to execute it, I recommend understanding how castlevania updates its background tiles. Once we understand this, we can find various ways to break it, as well as diagnose when the scroll glitch fails.

=== How are background tiles updated? ===

Castlevania graphics are made up of foreground sprites (simon, candles, hearts, enemies) and background tiles. The game is building up these background tiles ahead of what is actually on the screen behind the scenes so that it can scroll smoothly as Simon moves. Around half a screen offscreen, the game is drawing a column two blocks wide. When that is complete, the game moves onto the next column. It looks something like this:

[[File:CV1_ScrollGlitch1. updated.png|550px]]

=== Tile Update Algorithm ===

Step 1: Should the update algorithm run?

There is a framecounter that starts at the beginning of every screen. This is the same framecounter that powers the item drops throughout the game. The update algorithm ONLY runs every other frame. I am not certain as to why, but I would guess this is because the Nintendo is not a very powerful system and this gives it time to do other work. Even if Simon is moving forward on a non updating frame, no tile will be updated.

Step 2: Is Simon moving (left or right… doesn’t matter)?

If Simon is moving (and we are on an even frame as discussed above), the tile upgrading algorithm will run and update a tile. Otherwise, the tile updating process is skipped.

Step 3: Determine which vertical column is going to be updated

If Simon is walking left, we will select a column on the left to update. If he is walking right, the column will be to the right. Every column is 32 pixels wide. For every column, there is another set of 32 pixels around 1.5 screens away that map to that column. When Simon is walking over this set of pixels in the direction towards that column, that column will be updated. See the section “How Background Tiles are Updated” for a picture that corresponds to this mapping.

I will refer to this 32 pixel walking space as the Column Update Window.

Step 4: Determine which tiles will be updated

We are now going to choose which actual blocks on the column will be updated. The game manages a special variable called the Block Counter that determines that location. This variable maps to the tiles vertically like so:

[[File:Block_Counter_mapping.png|550px]]

The block counter has a value between 0 and 7, inclusive; however, only the values 1-6 actually map to blocks.

Here is how the algorithm works:

# Did I just enter a new “Column update window”? (One of those 32 pixel spaces you walk over)
#*If yes, no matter WHAT ( even overriding the every other frame rule described above), reset the Block counter to 0
# Update the blocks in the selected column (the direction Simon is facing) at the vertical level marked by the block counter.
#*If the counter is 0 or 7, this does nothing.
# Increment the block counter by 1
# If the block counter > 7, set the block counter to 0

=== How non-glitched walking normally works ===
A player usually just walks in one direction for a while. As they walk through a new Column Update Window, the column 1.5 screens away starts getting updated. The Column Update Window is 32 pixels wide and we update tiles every other pixel, so we will run the tile upgrading algorithm 16 times (32/2). This will cause the block counter to go from 0 -> 7 and then 0 -> 7 again. This updates every tile value twice. Updating it twice doesn’t cause any harm - it just puts the same value there.

''NOTE - Technically there is a 50% probability of it being 15 times, not 16. This is because the first value is always overridden to 0. If that happens on the tile updating frame, the counter will still be held at 0. ''

=== What causes the scroll glitch to happen? ===

This algorithm manages tile drawing in BOTH the left and right direction. However, there is only ONE block counter. If you are walking left and the tile counter is at 4 but then turn right while the block counter turns to 5, then turn left again as the block counter changes to 6, you skipped a block on the left side. You updated blockset 4 and 6 but skipped 5.

The algorithm has a correction mechanism though. Notice that we normally iterate over the blocks twice for one column update window. That block 5 will get corrected as you continue to walk left… unless you do the same turnback again. Keep repeating this turnback until you have exited the column update window and you have successfully skipped updating the block, performing a “scroll glitch”.

This glitch does not let you put any tile value you want there. You are only skipping writing a value. This means the value will be whatever was there last.

=== Removing Tile Updating RNG ===
If the block counter is only updated every other frame, it seems impossible to actually make the trick predictable. Luckily, there is a neat math trick that solves this. This is best explained with an example:

If you move 1 frame, did you move the block counter? You don’t know. There is a 50% probability you did. If you move 2 frames, did you move the block counter? You moved the counter one and only one time with 100% certainty. This is because you either updated on the first frame or the second frame. It can’t be both or neither!

The above generalizes as you walk forward more pixels. If you move an even number of pixels without stopping, you are 100% certain to have moved the block counter the number of pixels moved divided by 2. If you moved an odd number of pixels, you don’t know what the block counter is incremented to.

As a concrete example, if you walk 6 pixels forward without stopping, you definitely moved the counter up by 3. If you moved 7 pixels, you have a 50% probability of moving it by 3 and a 50% probability of moving it 4.

=== Turnback Requirements ===
As you walk through a Column Update Window, you update each block in a column twice. Given this, it would seem like you will need to execute two turnbacks. Unfortunately, this is not always the case.

When you execute a turnback, you go back two pixels, then forward two pixels. You have now incremented the block counter twice. However, you are also on the same pixel in the Column Update Window as you were before you started the turnback. This means you have essentially added two extra counter updates than a normal walkthrough. Since you have to execute the turnback a second time, you are incrementing the block counter a total of four extra times. Those four extra increments will cause you to start updating some of the higher blocks a third time!

In practice, if you execute 2 frame turnbacks, you need to do three turnbacks unless you are targeting blocks at the 5th or 6th height index in the above diagram, in which case you can continue doing 2 turnbacks.

If you execute 4 frame turnbacks, you need to do 4 turnbacks for block indexes from 1 to 3, and 3 turnbacks for indices 4-6.

Note that these are simplifications. There are scenarios where you can do fewer turnbacks if you get lucky ( a combination of turnbacks being too short but getting lucky with the frame counter). In addition, you often want to execute extra turnbacks to raise consistency (discussed later).

''TECHNICAL NOTE - This is oversimplified. There are some details around having an odd number of pixels on the last walk forward that leads to one extra counter iteration. I don’t think this is a missing aspect of the algorithm, just some tricky off-by-one math. I got frustrated and stopped trying to nail it down exactly. ''

=== Scroll Glitch Execution Approaches ===

For all strategies, there is an important starting pixel where you want to start your turnbacks. This is the pixel that will have the block counter 1 below your target block regardless of whether. You can find this pixel with visuals for each of the level 5 tricks further down this page.

=== 2 - 14 Turnback Method ===

The 2-14 method is the first RTA viable method used by runners and is still used by most. We will do a series of 2 pixel turnbacks followed by 14 pixel walk forwards.

==== Beginner Approach ====
The easiest, although slowest, method is to find a launch point to predictably get to your starting pixel. This is usually done by back jumping and changing direction midair by ducking the opposite direction. If the backjump succeeds, you will have always landed on the right starting pixel. This gives you plenty of time to make sure you pick the right jump point without breaking the glitch.

Once you have gotten to the first pixel, you need a consistent way to go back two pixels. This is usually done by turning in the backwards direction and whipping on the next possible frame. If you are late on the whip, Simon will visibly walk further. If you are early, you will move only 1 pixel back but simon will still be facing forward.

After this, walk forward 14 pixels, rinse, and repeat. Most runners learn the proper 14 pixel visual at each turnback point and practice going to each one. Pictures are on the wiki for this.

This is a slow method, but it is easier for beginners to learn, execute, and diagnose. This slowness will limit the RTA viability of the trick to stage 13, stage 14 standard, and stage 14 advanced. The others are either too risky or the time savings are largely negated by the setup time.

==== Advanced Approach ====

There are two approaches to speed this up. The first is to pick a proper jump point to land on the right starting pixel. If you recognize that you jumped a pixel early, you can duck to move one extra pixel on landing to compensate.

The second approach is to just push back for two frames and push forward for fourteen frames repeatedly without whipping. You can use the jump setup described above or just hit back on the appropriate first frame. This is currently only being executed by Jay_Cee and I don’t have good advice for how to do this outside of lots of practice.

=== Corrections and Reliability Improvements ===

==== Adjust Pixels ====

Most runners learn to target each turnback pixel. If your turnback or turn forward is off by one pixel, the trick now has a 50% chance of success. This is because you now how much you have incremented the Block Counter (see the even-odd rule in the “Removing Tile Updating RNG” section).

HOWEVER, if you proceed as normal and target the same pixels afterwards, you now cut your probability of success down to 25%. For example, if you walk backwards 3 pixels instead of 2, your walk forward will now be 15 pixels if you keep your same target. That is now effectively one more area where you may have moved the counter an extra time.

You instead want to keep your existing movements the same and only move forward 14 pixels. You should either adjust your visual cue or use a rhythm method to feel what 14 frames of movement is like and ignore all pixel targets outside of the first one.

If you moved backwards more than 3 pixels, you definitely moved the counter more than you wanted. It can be saved but only by switching mid-run to the 4-12 turnback method (discussed later).

If you walked forward 2 pixels beyond your target pixel, unless you messed something earlier, the tile you wanted has been locked into a new value and the trick is dead.

==== Extra Turnback ====

As you get closer to the end of the Column Update Window, there are a few additional tweaks that can help save a dead scrollglitch attempt. For example, you may want to consider adding a 3rd turnback for the stage 14 scrollglitch.

For that glitch, unlike stage 13, the block counter doesn’t loop around for a 3rd time to that lower tile, so only two turnbacks are necessary. However, the counter ALMOST makes it there. If you have 3 pixel turnbacks instead of 2 or start the turnbacks slightly early, you are walking more in the Column Update Window after the final turnback. This can increment the block counter more and update your tile, even if you succeeded on the first two turnbacks.

Given this, you can consider adding one extra turnback as an insurance policy. For the 2-14 turnbacks, this is usually most relevant for the stage 14 wall glitch. For higher blocks like the stage 13 glitch, it is very unlikely that it will be able to make an extra loop, so I would not recommend it there.

=== Lenient Final Turnback ===

The above extra turnback is valuable when the normal final turnback is far away from the end of the Column Update Window. However, for some tricks, the final turnback is very close to the end of the Column Update Window. Stage 13 is a great example of this. That closeness creates extra leniency that we can take advantage of.

When normally doing the scroll glitch, let's assume you make a mistake. Instead of going back two pixels, you go back four. You have moved the counter two times. Your target block was not updated, so the trick is still alive; however, the trick is now out of alignment. If you move forward the normal 14 pixels, the trick will be ripped. HOWEVER, if this turnback was close to the end of the Column Update Window, you will escape before you walk 14 pixels. This means a 4 pixel turnback will not rip the final turnback on stage 13!

In fact, I would RECOMMEND doing a 4 pixel turnback on your final turnback here. The reason is you are skipping over two blocks on that last turnback. So if, for example, the block counter is 1 behind due to an earlier mistake, your run would normally be ripped on the final turnback. However, by moving the counter twice at the end, you protected yourself. In fact, this can move the 50% probability of success back to 100%. The block counter could have one of two possible values, and you handle both cases with one turnback.

You should do the 4 pixel turnback after walking 14 pixels if you think the counter is one behind. If you think the counter is one ahead, you should walk forward 12 pixels and then do the 4 pixel turnback. I highly recommend adding one of these approaches to your final turnback on stage 13. If you are adding an EXTRA turnback, as discussed above, the same leniency rule will apply there.

=== 4-12 Turnback Method ===

The leniency property on the last turnback can actually be applied to all turnbacks. Instead of doing 2-14 pixel turnbacks, you can execute 4-12 pixel turnbacks everywhere. This is my preferred technique.

By going back 4 pixels, you are actually skipping two blocks, not one. You don’t need to move two blocks; however, this can provide an extra buffer in case you make a mistake. For the 2-14 pixel approach, if you are off by 1 pixel, the success rate drops to 50%. If you are ever off by more than 1 pixel, the success rate is 0% unless you get lucky and make a countering mistake elsewhere.

For the 4-12 approach, if you are off by 1 pixel, you have a 50% probability for one of the blocks to be overridden. However, assuming the direction you are off is random, you have a 50% chance of that block being the one you care about. So now you have around a 75% probability of success even if you make a 1 pixel mistake. Furthermore, if you make a 2 pixel mistake, you still have a 50% probability of success. A 3 pixel mistake lowers you to around a 25% chance.

While the above math is just a rough approximation, this method has generally seemed more lenient than the 2-14 approach. In addition, if you are doing the whipless turnback technique, at least for me, it is much easier to consistently do a 4 pixel turnback instead of a 2 pixel one. You learn the back and forth d-pad rhythm and the trick can become quite consistent.

Unfortunately, this approach does have a few downsides. First, each turnback will cost an extra 4 frames. In addition, you will often have to do one extra turnback relative to the two pixel turnback. If targeting block 2 or 3, I would recommend 4 turnbacks. Anything below that, I would recommend 3 turnbacks.

=== Training Resources ===
ROMHack - A romhack is available on the CV1 discord. When used, it will print out Simon’s pixel coordinates. In addition, it will print the Block Counter.

The starting pixel coordinates for the scroll glitches are:

{| class="wikitable" style="margin:left"
|+
|-
! Stage Number !! Pixel !! Savings**
|-
| Stage 6 Crusher || 1D9 & 1B9 || ~9 sec
|-
| Stage 7 Coffee || 255 & 1F9 || ~1.4 sec
|-
| Stage 13 Griddle || A4 || ~12.5 sec
|-
| Stage 14 Bacon || 45C or 43D || ~3.5 sec
|-
| Stage 14 Egg || 2C4* || ~6 sec
|-
| Stage 14 Cheese || 328 || ~8 sec
|-
| Stage 17 Clocktower || 219 & 1FB || 6 sec
|}

<nowiki>*</nowiki>Touching pixel 2B9 is needed before turning around

<nowiki>**</nowiki>Timings are approximate, also you may not see the same time savings if you don't play the rest of the level as optimal as your prior splits, so 12s might turn into 6s.

Stage 13:

Start on 7A turn around, backwards jump and turnaround to land on A4 -> A1. The a 14 frame Walk to B0 then B0 2 frame turnaround AE. Then a 14 frame walk end on BC quick left turn around (between 2-5 frames?) and then walk right.

[[File:CV1_13-SG-1.png|250px]]
[[File:CV1_13-SG-2.png|250px]]
[[File:CV1_13-SG-3.png|250px]]
[[File:CV1_13-SG-4.png|250px]]

Stage 14
Start on 2FE then backwards jump and turn and land on 328. Whip turnaround 328 -> 326, then move to and do a whip turn around 334 -> 332.

[[File:CV1_14-SG-1.png|250px]]
[[File:CV1_14-SG-2.png|250px]]
[[File:CV1_14-SG-3.png|250px]]

=== Emulator Training Tools ===
I have created a set of scroll glitch training tools (along with other cv1 helper tools). These currently require using bizhawk, although I will likely port to other emulators in the future.

https://www.speedrun.com/cv1/resources

Helpful tools included are:

1. Create lines onscreen to show turnback locations
2. Auto-death tool - kills you if you miss a scroll glitch
3. Turnback-Turnforward diagnostic printout (to highlight if you really are hitting 2-14 or 4-12)

Note, if you are using original hardware, the above tools may be a little annoying as the input latency is different. I would still recommend trying them though as many scroll glitch execution strategies are not latency sensitive.

=== Rhythm Sounds ===
If you are trying to learn a whipless rhythm approach, sounds can also be a helpful aid. You hit the buttons on the appropriate beat. Every frame is 1/60th of a second (technically 1/60.09), so you can use that to create a beat. One style is to do 4/60th of a second followed by 12/60th of a second. Another is to just have a metronome set to 16/60th of a second and time either your forward or backward presses to that beat.

Below are two videos with rhythm of whipless scroll glitch turnbacks for 4-12 pattern. To execute 4-12 wiggles, do a turnback on the short note, and move forward on the long note.

{{#ev:youtube|Zn2FFhDc5WE|550}}

{{#ev:youtube|-WG7e4nAnp4|550}}

=== Acknowledgements ===

InfoManiac
Originally discovered the scroll glitch. The initial method only worked on TAS

Challenger
Implemented almost all the current scroll glitches in TAS that have since been ported to RTA by others.

NatGoesFast
Accidently did a scroll glitch on stream. An investigation of this led to the whip based RTA strategy discussed above.

SBDWolf
Found the whip based RTA viable approach for stage 13 and stage 14. Also figured out probably 75% of the basic block updating algorithm and RTA strategies such as odd/even frames approach. Also was the first person to use these scroll glitches to get WR. (May have also found the crusher room scrollglitch).

Shockratease
Along with SBDWolf, did extensive investigation and teaching on the scroll glitch. Suggested using 16/60th beats instead of two-part beats.

Kajong0007
Created the Romhack mentioned above, which has been used extensively by runners to better learn the trick.

JayCee
First person to remove whips for turnbacks and use it in runs. The removal of whips also enabled a lot of additional scroll glitch areas (crusher, clocktower) which did not seem viable otherwise. This inspired additional scrollglitch innovations.

Trisk (tr1sklion)
Wrote this document. Found the Block Counter and Column Update Window in the game bytecode. Validated and enhanced the earlier algorithm approximation SBDWolf modeled. Wrote the Bizhawk training tools. Pioneered the 4-frame turnbacks strategy and most correction strategies.

== Videos ==

SBDWolf talking about the scroll glitches

{{#ev:youtube|rmlBCzdVlOc|550}}

{{#ev:youtube|yaRmDa_T-oo|550}}

Here's Shockra Tease talking about both Scroll Glitches

{{#ev:youtube|Dw7NkOzp8tE|550}}

Advanced Stage 14

{{#ev:youtube|zxLs7h2cL6Y|550}}

Displaced Gamers Video on the code

{{#ev:youtube|wd18YNZB0D4|550}}

Cv1/ScrollGlitch

2024-04-17T21:28:22Z

K c r: /* Training Resources */

== Breaking Dracula’s Castle 101 ==

Before delving into why the scroll glitch works and how to execute it, I recommend understanding how castlevania updates its background tiles. Once we understand this, we can find various ways to break it, as well as diagnose when the scroll glitch fails.

=== How are background tiles updated? ===

Castlevania graphics are made up of foreground sprites (simon, candles, hearts, enemies) and background tiles. The game is building up these background tiles ahead of what is actually on the screen behind the scenes so that it can scroll smoothly as Simon moves. Around half a screen offscreen, the game is drawing a column two blocks wide. When that is complete, the game moves onto the next column. It looks something like this:

[[File:CV1_ScrollGlitch1. updated.png|550px]]

=== Tile Update Algorithm ===

Step 1: Should the update algorithm run?

There is a framecounter that starts at the beginning of every screen. This is the same framecounter that powers the item drops throughout the game. The update algorithm ONLY runs every other frame. I am not certain as to why, but I would guess this is because the Nintendo is not a very powerful system and this gives it time to do other work. Even if Simon is moving forward on a non updating frame, no tile will be updated.

Step 2: Is Simon moving (left or right… doesn’t matter)?

If Simon is moving (and we are on an even frame as discussed above), the tile upgrading algorithm will run and update a tile. Otherwise, the tile updating process is skipped.

Step 3: Determine which vertical column is going to be updated

If Simon is walking left, we will select a column on the left to update. If he is walking right, the column will be to the right. Every column is 32 pixels wide. For every column, there is another set of 32 pixels around 1.5 screens away that map to that column. When Simon is walking over this set of pixels in the direction towards that column, that column will be updated. See the section “How Background Tiles are Updated” for a picture that corresponds to this mapping.

I will refer to this 32 pixel walking space as the Column Update Window.

Step 4: Determine which tiles will be updated

We are now going to choose which actual blocks on the column will be updated. The game manages a special variable called the Block Counter that determines that location. This variable maps to the tiles vertically like so:

[[File:Block_Counter_mapping.png|550px]]

The block counter has a value between 0 and 7, inclusive; however, only the values 1-6 actually map to blocks.

Here is how the algorithm works:

# Did I just enter a new “Column update window”? (One of those 32 pixel spaces you walk over)
#*If yes, no matter WHAT ( even overriding the every other frame rule described above), reset the Block counter to 0
# Update the blocks in the selected column (the direction Simon is facing) at the vertical level marked by the block counter.
#*If the counter is 0 or 7, this does nothing.
# Increment the block counter by 1
# If the block counter > 7, set the block counter to 0

=== How non-glitched walking normally works ===
A player usually just walks in one direction for a while. As they walk through a new Column Update Window, the column 1.5 screens away starts getting updated. The Column Update Window is 32 pixels wide and we update tiles every other pixel, so we will run the tile upgrading algorithm 16 times (32/2). This will cause the block counter to go from 0 -> 7 and then 0 -> 7 again. This updates every tile value twice. Updating it twice doesn’t cause any harm - it just puts the same value there.

''NOTE - Technically there is a 50% probability of it being 15 times, not 16. This is because the first value is always overridden to 0. If that happens on the tile updating frame, the counter will still be held at 0. ''

=== What causes the scroll glitch to happen? ===

This algorithm manages tile drawing in BOTH the left and right direction. However, there is only ONE block counter. If you are walking left and the tile counter is at 4 but then turn right while the block counter turns to 5, then turn left again as the block counter changes to 6, you skipped a block on the left side. You updated blockset 4 and 6 but skipped 5.

The algorithm has a correction mechanism though. Notice that we normally iterate over the blocks twice for one column update window. That block 5 will get corrected as you continue to walk left… unless you do the same turnback again. Keep repeating this turnback until you have exited the column update window and you have successfully skipped updating the block, performing a “scroll glitch”.

This glitch does not let you put any tile value you want there. You are only skipping writing a value. This means the value will be whatever was there last.

=== Removing Tile Updating RNG ===
If the block counter is only updated every other frame, it seems impossible to actually make the trick predictable. Luckily, there is a neat math trick that solves this. This is best explained with an example:

If you move 1 frame, did you move the block counter? You don’t know. There is a 50% probability you did. If you move 2 frames, did you move the block counter? You moved the counter one and only one time with 100% certainty. This is because you either updated on the first frame or the second frame. It can’t be both or neither!

The above generalizes as you walk forward more pixels. If you move an even number of pixels without stopping, you are 100% certain to have moved the block counter the number of pixels moved divided by 2. If you moved an odd number of pixels, you don’t know what the block counter is incremented to.

As a concrete example, if you walk 6 pixels forward without stopping, you definitely moved the counter up by 3. If you moved 7 pixels, you have a 50% probability of moving it by 3 and a 50% probability of moving it 4.

=== Turnback Requirements ===
As you walk through a Column Update Window, you update each block in a column twice. Given this, it would seem like you will need to execute two turnbacks. Unfortunately, this is not always the case.

When you execute a turnback, you go back two pixels, then forward two pixels. You have now incremented the block counter twice. However, you are also on the same pixel in the Column Update Window as you were before you started the turnback. This means you have essentially added two extra counter updates than a normal walkthrough. Since you have to execute the turnback a second time, you are incrementing the block counter a total of four extra times. Those four extra increments will cause you to start updating some of the higher blocks a third time!

In practice, if you execute 2 frame turnbacks, you need to do three turnbacks unless you are targeting blocks at the 5th or 6th height index in the above diagram, in which case you can continue doing 2 turnbacks.

If you execute 4 frame turnbacks, you need to do 4 turnbacks for block indexes from 1 to 3, and 3 turnbacks for indices 4-6.

Note that these are simplifications. There are scenarios where you can do fewer turnbacks if you get lucky ( a combination of turnbacks being too short but getting lucky with the frame counter). In addition, you often want to execute extra turnbacks to raise consistency (discussed later).

''TECHNICAL NOTE - This is oversimplified. There are some details around having an odd number of pixels on the last walk forward that leads to one extra counter iteration. I don’t think this is a missing aspect of the algorithm, just some tricky off-by-one math. I got frustrated and stopped trying to nail it down exactly. ''

=== Scroll Glitch Execution Approaches ===

For all strategies, there is an important starting pixel where you want to start your turnbacks. This is the pixel that will have the block counter 1 below your target block regardless of whether. You can find this pixel with visuals for each of the level 5 tricks further down this page.

=== 2 - 14 Turnback Method ===

The 2-14 method is the first RTA viable method used by runners and is still used by most. We will do a series of 2 pixel turnbacks followed by 14 pixel walk forwards.

==== Beginner Approach ====
The easiest, although slowest, method is to find a launch point to predictably get to your starting pixel. This is usually done by back jumping and changing direction midair by ducking the opposite direction. If the backjump succeeds, you will have always landed on the right starting pixel. This gives you plenty of time to make sure you pick the right jump point without breaking the glitch.

Once you have gotten to the first pixel, you need a consistent way to go back two pixels. This is usually done by turning in the backwards direction and whipping on the next possible frame. If you are late on the whip, Simon will visibly walk further. If you are early, you will move only 1 pixel back but simon will still be facing forward.

After this, walk forward 14 pixels, rinse, and repeat. Most runners learn the proper 14 pixel visual at each turnback point and practice going to each one. Pictures are on the wiki for this.

This is a slow method, but it is easier for beginners to learn, execute, and diagnose. This slowness will limit the RTA viability of the trick to stage 13, stage 14 standard, and stage 14 advanced. The others are either too risky or the time savings are largely negated by the setup time.

==== Advanced Approach ====

There are two approaches to speed this up. The first is to pick a proper jump point to land on the right starting pixel. If you recognize that you jumped a pixel early, you can duck to move one extra pixel on landing to compensate.

The second approach is to just push back for two frames and push forward for fourteen frames repeatedly without whipping. You can use the jump setup described above or just hit back on the appropriate first frame. This is currently only being executed by Jay_Cee and I don’t have good advice for how to do this outside of lots of practice.

=== Corrections and Reliability Improvements ===

==== Adjust Pixels ====

Most runners learn to target each turnback pixel. If your turnback or turn forward is off by one pixel, the trick now has a 50% chance of success. This is because you now how much you have incremented the Block Counter (see the even-odd rule in the “Removing Tile Updating RNG” section).

HOWEVER, if you proceed as normal and target the same pixels afterwards, you now cut your probability of success down to 25%. For example, if you walk backwards 3 pixels instead of 2, your walk forward will now be 15 pixels if you keep your same target. That is now effectively one more area where you may have moved the counter an extra time.

You instead want to keep your existing movements the same and only move forward 14 pixels. You should either adjust your visual cue or use a rhythm method to feel what 14 frames of movement is like and ignore all pixel targets outside of the first one.

If you moved backwards more than 3 pixels, you definitely moved the counter more than you wanted. It can be saved but only by switching mid-run to the 4-12 turnback method (discussed later).

If you walked forward 2 pixels beyond your target pixel, unless you messed something earlier, the tile you wanted has been locked into a new value and the trick is dead.

==== Extra Turnback ====

As you get closer to the end of the Column Update Window, there are a few additional tweaks that can help save a dead scrollglitch attempt. For example, you may want to consider adding a 3rd turnback for the stage 14 scrollglitch.

For that glitch, unlike stage 13, the block counter doesn’t loop around for a 3rd time to that lower tile, so only two turnbacks are necessary. However, the counter ALMOST makes it there. If you have 3 pixel turnbacks instead of 2 or start the turnbacks slightly early, you are walking more in the Column Update Window after the final turnback. This can increment the block counter more and update your tile, even if you succeeded on the first two turnbacks.

Given this, you can consider adding one extra turnback as an insurance policy. For the 2-14 turnbacks, this is usually most relevant for the stage 14 wall glitch. For higher blocks like the stage 13 glitch, it is very unlikely that it will be able to make an extra loop, so I would not recommend it there.

=== Lenient Final Turnback ===

The above extra turnback is valuable when the normal final turnback is far away from the end of the Column Update Window. However, for some tricks, the final turnback is very close to the end of the Column Update Window. Stage 13 is a great example of this. That closeness creates extra leniency that we can take advantage of.

When normally doing the scroll glitch, let's assume you make a mistake. Instead of going back two pixels, you go back four. You have moved the counter two times. Your target block was not updated, so the trick is still alive; however, the trick is now out of alignment. If you move forward the normal 14 pixels, the trick will be ripped. HOWEVER, if this turnback was close to the end of the Column Update Window, you will escape before you walk 14 pixels. This means a 4 pixel turnback will not rip the final turnback on stage 13!

In fact, I would RECOMMEND doing a 4 pixel turnback on your final turnback here. The reason is you are skipping over two blocks on that last turnback. So if, for example, the block counter is 1 behind due to an earlier mistake, your run would normally be ripped on the final turnback. However, by moving the counter twice at the end, you protected yourself. In fact, this can move the 50% probability of success back to 100%. The block counter could have one of two possible values, and you handle both cases with one turnback.

You should do the 4 pixel turnback after walking 14 pixels if you think the counter is one behind. If you think the counter is one ahead, you should walk forward 12 pixels and then do the 4 pixel turnback. I highly recommend adding one of these approaches to your final turnback on stage 13. If you are adding an EXTRA turnback, as discussed above, the same leniency rule will apply there.

=== 4-12 Turnback Method ===

The leniency property on the last turnback can actually be applied to all turnbacks. Instead of doing 2-14 pixel turnbacks, you can execute 4-12 pixel turnbacks everywhere. This is my preferred technique.

By going back 4 pixels, you are actually skipping two blocks, not one. You don’t need to move two blocks; however, this can provide an extra buffer in case you make a mistake. For the 2-14 pixel approach, if you are off by 1 pixel, the success rate drops to 50%. If you are ever off by more than 1 pixel, the success rate is 0% unless you get lucky and make a countering mistake elsewhere.

For the 4-12 approach, if you are off by 1 pixel, you have a 50% probability for one of the blocks to be overridden. However, assuming the direction you are off is random, you have a 50% chance of that block being the one you care about. So now you have around a 75% probability of success even if you make a 1 pixel mistake. Furthermore, if you make a 2 pixel mistake, you still have a 50% probability of success. A 3 pixel mistake lowers you to around a 25% chance.

While the above math is just a rough approximation, this method has generally seemed more lenient than the 2-14 approach. In addition, if you are doing the whipless turnback technique, at least for me, it is much easier to consistently do a 4 pixel turnback instead of a 2 pixel one. You learn the back and forth d-pad rhythm and the trick can become quite consistent.

Unfortunately, this approach does have a few downsides. First, each turnback will cost an extra 4 frames. In addition, you will often have to do one extra turnback relative to the two pixel turnback. If targeting block 2 or 3, I would recommend 4 turnbacks. Anything below that, I would recommend 3 turnbacks.

=== Training Resources ===
ROMHack - A romhack is available on the CV1 discord. When used, it will print out Simon’s pixel coordinates. In addition, it will print the Block Counter.

The starting pixel coordinates for the scroll glitches are:

{| class="wikitable" style="margin:left"
|+
|-
! Stage Number !! Pixel !! Savings**
|-
| Stage 6 Crusher || 1D9 & 1B9 || ~9 sec
|-
| Stage 7 Coffee || 255 & 1F9 || ~1.4 sec
|-
| Stage 13 || A4 || ~12.5 sec
|-
| Stage 14 Bacon || 45C or 43D || ~3.5 sec
|-
| Stage 14 Egg || 2C4* || ~6 sec
|-
| Stage 14 Cheese || 328 || ~8 sec
|-
| Stage 17 Clocktower || 219 & 1FB || 6 sec
|}

<nowiki>*</nowiki>Touching pixel 2B9 is needed before turning around

<nowiki>**</nowiki>Timings are approximate, also you may not see the same time savings if you don't play the rest of the level as optimal as your prior splits, so 12s might turn into 6s.

Stage 13:

Start on 7A turn around, backwards jump and turnaround to land on A4 -> A1. The a 14 frame Walk to B0 then B0 2 frame turnaround AE. Then a 14 frame walk end on BC quick left turn around (between 2-5 frames?) and then walk right.

[[File:CV1_13-SG-1.png|250px]]
[[File:CV1_13-SG-2.png|250px]]
[[File:CV1_13-SG-3.png|250px]]
[[File:CV1_13-SG-4.png|250px]]

Stage 14
Start on 2FE then backwards jump and turn and land on 328. Whip turnaround 328 -> 326, then move to and do a whip turn around 334 -> 332.

[[File:CV1_14-SG-1.png|250px]]
[[File:CV1_14-SG-2.png|250px]]
[[File:CV1_14-SG-3.png|250px]]

=== Emulator Training Tools ===
I have created a set of scroll glitch training tools (along with other cv1 helper tools). These currently require using bizhawk, although I will likely port to other emulators in the future.

https://www.speedrun.com/cv1/resources

Helpful tools included are:

1. Create lines onscreen to show turnback locations
2. Auto-death tool - kills you if you miss a scroll glitch
3. Turnback-Turnforward diagnostic printout (to highlight if you really are hitting 2-14 or 4-12)

Note, if you are using original hardware, the above tools may be a little annoying as the input latency is different. I would still recommend trying them though as many scroll glitch execution strategies are not latency sensitive.

=== Rhythm Sounds ===
If you are trying to learn a whipless rhythm approach, sounds can also be a helpful aid. You hit the buttons on the appropriate beat. Every frame is 1/60th of a second (technically 1/60.09), so you can use that to create a beat. One style is to do 4/60th of a second followed by 12/60th of a second. Another is to just have a metronome set to 16/60th of a second and time either your forward or backward presses to that beat.

Below are two videos with rhythm of whipless scroll glitch turnbacks for 4-12 pattern. To execute 4-12 wiggles, do a turnback on the short note, and move forward on the long note.

{{#ev:youtube|Zn2FFhDc5WE|550}}

{{#ev:youtube|-WG7e4nAnp4|550}}

=== Acknowledgements ===

InfoManiac
Originally discovered the scroll glitch. The initial method only worked on TAS

Challenger
Implemented almost all the current scroll glitches in TAS that have since been ported to RTA by others.

NatGoesFast
Accidently did a scroll glitch on stream. An investigation of this led to the whip based RTA strategy discussed above.

SBDWolf
Found the whip based RTA viable approach for stage 13 and stage 14. Also figured out probably 75% of the basic block updating algorithm and RTA strategies such as odd/even frames approach. Also was the first person to use these scroll glitches to get WR. (May have also found the crusher room scrollglitch).

Shockratease
Along with SBDWolf, did extensive investigation and teaching on the scroll glitch. Suggested using 16/60th beats instead of two-part beats.

Kajong0007
Created the Romhack mentioned above, which has been used extensively by runners to better learn the trick.

JayCee
First person to remove whips for turnbacks and use it in runs. The removal of whips also enabled a lot of additional scroll glitch areas (crusher, clocktower) which did not seem viable otherwise. This inspired additional scrollglitch innovations.

Trisk (tr1sklion)
Wrote this document. Found the Block Counter and Column Update Window in the game bytecode. Validated and enhanced the earlier algorithm approximation SBDWolf modeled. Wrote the Bizhawk training tools. Pioneered the 4-frame turnbacks strategy and most correction strategies.

== Videos ==

SBDWolf talking about the scroll glitches

{{#ev:youtube|rmlBCzdVlOc|550}}

{{#ev:youtube|yaRmDa_T-oo|550}}

Here's Shockra Tease talking about both Scroll Glitches

{{#ev:youtube|Dw7NkOzp8tE|550}}

Advanced Stage 14

{{#ev:youtube|zxLs7h2cL6Y|550}}

Displaced Gamers Video on the code

{{#ev:youtube|wd18YNZB0D4|550}}

Cv1/ScrollGlitch

2024-04-17T21:24:00Z

K c r: /* Training Resources */

== Breaking Dracula’s Castle 101 ==

Before delving into why the scroll glitch works and how to execute it, I recommend understanding how castlevania updates its background tiles. Once we understand this, we can find various ways to break it, as well as diagnose when the scroll glitch fails.

=== How are background tiles updated? ===

Castlevania graphics are made up of foreground sprites (simon, candles, hearts, enemies) and background tiles. The game is building up these background tiles ahead of what is actually on the screen behind the scenes so that it can scroll smoothly as Simon moves. Around half a screen offscreen, the game is drawing a column two blocks wide. When that is complete, the game moves onto the next column. It looks something like this:

[[File:CV1_ScrollGlitch1. updated.png|550px]]

=== Tile Update Algorithm ===

Step 1: Should the update algorithm run?

There is a framecounter that starts at the beginning of every screen. This is the same framecounter that powers the item drops throughout the game. The update algorithm ONLY runs every other frame. I am not certain as to why, but I would guess this is because the Nintendo is not a very powerful system and this gives it time to do other work. Even if Simon is moving forward on a non updating frame, no tile will be updated.

Step 2: Is Simon moving (left or right… doesn’t matter)?

If Simon is moving (and we are on an even frame as discussed above), the tile upgrading algorithm will run and update a tile. Otherwise, the tile updating process is skipped.

Step 3: Determine which vertical column is going to be updated

If Simon is walking left, we will select a column on the left to update. If he is walking right, the column will be to the right. Every column is 32 pixels wide. For every column, there is another set of 32 pixels around 1.5 screens away that map to that column. When Simon is walking over this set of pixels in the direction towards that column, that column will be updated. See the section “How Background Tiles are Updated” for a picture that corresponds to this mapping.

I will refer to this 32 pixel walking space as the Column Update Window.

Step 4: Determine which tiles will be updated

We are now going to choose which actual blocks on the column will be updated. The game manages a special variable called the Block Counter that determines that location. This variable maps to the tiles vertically like so:

[[File:Block_Counter_mapping.png|550px]]

The block counter has a value between 0 and 7, inclusive; however, only the values 1-6 actually map to blocks.

Here is how the algorithm works:

# Did I just enter a new “Column update window”? (One of those 32 pixel spaces you walk over)
#*If yes, no matter WHAT ( even overriding the every other frame rule described above), reset the Block counter to 0
# Update the blocks in the selected column (the direction Simon is facing) at the vertical level marked by the block counter.
#*If the counter is 0 or 7, this does nothing.
# Increment the block counter by 1
# If the block counter > 7, set the block counter to 0

=== How non-glitched walking normally works ===
A player usually just walks in one direction for a while. As they walk through a new Column Update Window, the column 1.5 screens away starts getting updated. The Column Update Window is 32 pixels wide and we update tiles every other pixel, so we will run the tile upgrading algorithm 16 times (32/2). This will cause the block counter to go from 0 -> 7 and then 0 -> 7 again. This updates every tile value twice. Updating it twice doesn’t cause any harm - it just puts the same value there.

''NOTE - Technically there is a 50% probability of it being 15 times, not 16. This is because the first value is always overridden to 0. If that happens on the tile updating frame, the counter will still be held at 0. ''

=== What causes the scroll glitch to happen? ===

This algorithm manages tile drawing in BOTH the left and right direction. However, there is only ONE block counter. If you are walking left and the tile counter is at 4 but then turn right while the block counter turns to 5, then turn left again as the block counter changes to 6, you skipped a block on the left side. You updated blockset 4 and 6 but skipped 5.

The algorithm has a correction mechanism though. Notice that we normally iterate over the blocks twice for one column update window. That block 5 will get corrected as you continue to walk left… unless you do the same turnback again. Keep repeating this turnback until you have exited the column update window and you have successfully skipped updating the block, performing a “scroll glitch”.

This glitch does not let you put any tile value you want there. You are only skipping writing a value. This means the value will be whatever was there last.

=== Removing Tile Updating RNG ===
If the block counter is only updated every other frame, it seems impossible to actually make the trick predictable. Luckily, there is a neat math trick that solves this. This is best explained with an example:

If you move 1 frame, did you move the block counter? You don’t know. There is a 50% probability you did. If you move 2 frames, did you move the block counter? You moved the counter one and only one time with 100% certainty. This is because you either updated on the first frame or the second frame. It can’t be both or neither!

The above generalizes as you walk forward more pixels. If you move an even number of pixels without stopping, you are 100% certain to have moved the block counter the number of pixels moved divided by 2. If you moved an odd number of pixels, you don’t know what the block counter is incremented to.

As a concrete example, if you walk 6 pixels forward without stopping, you definitely moved the counter up by 3. If you moved 7 pixels, you have a 50% probability of moving it by 3 and a 50% probability of moving it 4.

=== Turnback Requirements ===
As you walk through a Column Update Window, you update each block in a column twice. Given this, it would seem like you will need to execute two turnbacks. Unfortunately, this is not always the case.

When you execute a turnback, you go back two pixels, then forward two pixels. You have now incremented the block counter twice. However, you are also on the same pixel in the Column Update Window as you were before you started the turnback. This means you have essentially added two extra counter updates than a normal walkthrough. Since you have to execute the turnback a second time, you are incrementing the block counter a total of four extra times. Those four extra increments will cause you to start updating some of the higher blocks a third time!

In practice, if you execute 2 frame turnbacks, you need to do three turnbacks unless you are targeting blocks at the 5th or 6th height index in the above diagram, in which case you can continue doing 2 turnbacks.

If you execute 4 frame turnbacks, you need to do 4 turnbacks for block indexes from 1 to 3, and 3 turnbacks for indices 4-6.

Note that these are simplifications. There are scenarios where you can do fewer turnbacks if you get lucky ( a combination of turnbacks being too short but getting lucky with the frame counter). In addition, you often want to execute extra turnbacks to raise consistency (discussed later).

''TECHNICAL NOTE - This is oversimplified. There are some details around having an odd number of pixels on the last walk forward that leads to one extra counter iteration. I don’t think this is a missing aspect of the algorithm, just some tricky off-by-one math. I got frustrated and stopped trying to nail it down exactly. ''

=== Scroll Glitch Execution Approaches ===

For all strategies, there is an important starting pixel where you want to start your turnbacks. This is the pixel that will have the block counter 1 below your target block regardless of whether. You can find this pixel with visuals for each of the level 5 tricks further down this page.

=== 2 - 14 Turnback Method ===

The 2-14 method is the first RTA viable method used by runners and is still used by most. We will do a series of 2 pixel turnbacks followed by 14 pixel walk forwards.

==== Beginner Approach ====
The easiest, although slowest, method is to find a launch point to predictably get to your starting pixel. This is usually done by back jumping and changing direction midair by ducking the opposite direction. If the backjump succeeds, you will have always landed on the right starting pixel. This gives you plenty of time to make sure you pick the right jump point without breaking the glitch.

Once you have gotten to the first pixel, you need a consistent way to go back two pixels. This is usually done by turning in the backwards direction and whipping on the next possible frame. If you are late on the whip, Simon will visibly walk further. If you are early, you will move only 1 pixel back but simon will still be facing forward.

After this, walk forward 14 pixels, rinse, and repeat. Most runners learn the proper 14 pixel visual at each turnback point and practice going to each one. Pictures are on the wiki for this.

This is a slow method, but it is easier for beginners to learn, execute, and diagnose. This slowness will limit the RTA viability of the trick to stage 13, stage 14 standard, and stage 14 advanced. The others are either too risky or the time savings are largely negated by the setup time.

==== Advanced Approach ====

There are two approaches to speed this up. The first is to pick a proper jump point to land on the right starting pixel. If you recognize that you jumped a pixel early, you can duck to move one extra pixel on landing to compensate.

The second approach is to just push back for two frames and push forward for fourteen frames repeatedly without whipping. You can use the jump setup described above or just hit back on the appropriate first frame. This is currently only being executed by Jay_Cee and I don’t have good advice for how to do this outside of lots of practice.

=== Corrections and Reliability Improvements ===

==== Adjust Pixels ====

Most runners learn to target each turnback pixel. If your turnback or turn forward is off by one pixel, the trick now has a 50% chance of success. This is because you now how much you have incremented the Block Counter (see the even-odd rule in the “Removing Tile Updating RNG” section).

HOWEVER, if you proceed as normal and target the same pixels afterwards, you now cut your probability of success down to 25%. For example, if you walk backwards 3 pixels instead of 2, your walk forward will now be 15 pixels if you keep your same target. That is now effectively one more area where you may have moved the counter an extra time.

You instead want to keep your existing movements the same and only move forward 14 pixels. You should either adjust your visual cue or use a rhythm method to feel what 14 frames of movement is like and ignore all pixel targets outside of the first one.

If you moved backwards more than 3 pixels, you definitely moved the counter more than you wanted. It can be saved but only by switching mid-run to the 4-12 turnback method (discussed later).

If you walked forward 2 pixels beyond your target pixel, unless you messed something earlier, the tile you wanted has been locked into a new value and the trick is dead.

==== Extra Turnback ====

As you get closer to the end of the Column Update Window, there are a few additional tweaks that can help save a dead scrollglitch attempt. For example, you may want to consider adding a 3rd turnback for the stage 14 scrollglitch.

For that glitch, unlike stage 13, the block counter doesn’t loop around for a 3rd time to that lower tile, so only two turnbacks are necessary. However, the counter ALMOST makes it there. If you have 3 pixel turnbacks instead of 2 or start the turnbacks slightly early, you are walking more in the Column Update Window after the final turnback. This can increment the block counter more and update your tile, even if you succeeded on the first two turnbacks.

Given this, you can consider adding one extra turnback as an insurance policy. For the 2-14 turnbacks, this is usually most relevant for the stage 14 wall glitch. For higher blocks like the stage 13 glitch, it is very unlikely that it will be able to make an extra loop, so I would not recommend it there.

=== Lenient Final Turnback ===

The above extra turnback is valuable when the normal final turnback is far away from the end of the Column Update Window. However, for some tricks, the final turnback is very close to the end of the Column Update Window. Stage 13 is a great example of this. That closeness creates extra leniency that we can take advantage of.

When normally doing the scroll glitch, let's assume you make a mistake. Instead of going back two pixels, you go back four. You have moved the counter two times. Your target block was not updated, so the trick is still alive; however, the trick is now out of alignment. If you move forward the normal 14 pixels, the trick will be ripped. HOWEVER, if this turnback was close to the end of the Column Update Window, you will escape before you walk 14 pixels. This means a 4 pixel turnback will not rip the final turnback on stage 13!

In fact, I would RECOMMEND doing a 4 pixel turnback on your final turnback here. The reason is you are skipping over two blocks on that last turnback. So if, for example, the block counter is 1 behind due to an earlier mistake, your run would normally be ripped on the final turnback. However, by moving the counter twice at the end, you protected yourself. In fact, this can move the 50% probability of success back to 100%. The block counter could have one of two possible values, and you handle both cases with one turnback.

You should do the 4 pixel turnback after walking 14 pixels if you think the counter is one behind. If you think the counter is one ahead, you should walk forward 12 pixels and then do the 4 pixel turnback. I highly recommend adding one of these approaches to your final turnback on stage 13. If you are adding an EXTRA turnback, as discussed above, the same leniency rule will apply there.

=== 4-12 Turnback Method ===

The leniency property on the last turnback can actually be applied to all turnbacks. Instead of doing 2-14 pixel turnbacks, you can execute 4-12 pixel turnbacks everywhere. This is my preferred technique.

By going back 4 pixels, you are actually skipping two blocks, not one. You don’t need to move two blocks; however, this can provide an extra buffer in case you make a mistake. For the 2-14 pixel approach, if you are off by 1 pixel, the success rate drops to 50%. If you are ever off by more than 1 pixel, the success rate is 0% unless you get lucky and make a countering mistake elsewhere.

For the 4-12 approach, if you are off by 1 pixel, you have a 50% probability for one of the blocks to be overridden. However, assuming the direction you are off is random, you have a 50% chance of that block being the one you care about. So now you have around a 75% probability of success even if you make a 1 pixel mistake. Furthermore, if you make a 2 pixel mistake, you still have a 50% probability of success. A 3 pixel mistake lowers you to around a 25% chance.

While the above math is just a rough approximation, this method has generally seemed more lenient than the 2-14 approach. In addition, if you are doing the whipless turnback technique, at least for me, it is much easier to consistently do a 4 pixel turnback instead of a 2 pixel one. You learn the back and forth d-pad rhythm and the trick can become quite consistent.

Unfortunately, this approach does have a few downsides. First, each turnback will cost an extra 4 frames. In addition, you will often have to do one extra turnback relative to the two pixel turnback. If targeting block 2 or 3, I would recommend 4 turnbacks. Anything below that, I would recommend 3 turnbacks.

=== Training Resources ===
ROMHack - A romhack is available on the CV1 discord. When used, it will print out Simon’s pixel coordinates. In addition, it will print the Block Counter.

The starting pixel coordinates for the scroll glitches are:

{| class="wikitable" style="margin:left"
|+
|-
! Stage Number !! Pixel !! Savings**
|-
| Stage 6 Crusher || 1D9 & 1B9 || ~9 sec
|-
| Stage 7 Coffee || 255 & 1F9 ||
|-
| Stage 13 || A4 || ~12.5 sec
|-
| Stage 14 Bacon || 45C or 43D ||
|-
| Stage 14 Egg || 2C4* ||
|-
| Stage 14 Cheese || 328 || ~8 sec
|-
| Stage 17 Clocktower || 219 & 1FB ||
|}

<nowiki>*</nowiki>Touching pixel 2B9 is needed before turning around

<nowiki>**</nowiki>Timings are approximate, also you may not see the same time savings if you don't play the rest of the level as optimal as your prior splits, so 12s might turn into 6s.

Stage 13:

Start on 7A turn around, backwards jump and turnaround to land on A4 -> A1. The a 14 frame Walk to B0 then B0 2 frame turnaround AE. Then a 14 frame walk end on BC quick left turn around (between 2-5 frames?) and then walk right.

[[File:CV1_13-SG-1.png|250px]]
[[File:CV1_13-SG-2.png|250px]]
[[File:CV1_13-SG-3.png|250px]]
[[File:CV1_13-SG-4.png|250px]]

Stage 14
Start on 2FE then backwards jump and turn and land on 328. Whip turnaround 328 -> 326, then move to and do a whip turn around 334 -> 332.

[[File:CV1_14-SG-1.png|250px]]
[[File:CV1_14-SG-2.png|250px]]
[[File:CV1_14-SG-3.png|250px]]

=== Emulator Training Tools ===
I have created a set of scroll glitch training tools (along with other cv1 helper tools). These currently require using bizhawk, although I will likely port to other emulators in the future.

https://www.speedrun.com/cv1/resources

Helpful tools included are:

1. Create lines onscreen to show turnback locations
2. Auto-death tool - kills you if you miss a scroll glitch
3. Turnback-Turnforward diagnostic printout (to highlight if you really are hitting 2-14 or 4-12)

Note, if you are using original hardware, the above tools may be a little annoying as the input latency is different. I would still recommend trying them though as many scroll glitch execution strategies are not latency sensitive.

=== Rhythm Sounds ===
If you are trying to learn a whipless rhythm approach, sounds can also be a helpful aid. You hit the buttons on the appropriate beat. Every frame is 1/60th of a second (technically 1/60.09), so you can use that to create a beat. One style is to do 4/60th of a second followed by 12/60th of a second. Another is to just have a metronome set to 16/60th of a second and time either your forward or backward presses to that beat.

Below are two videos with rhythm of whipless scroll glitch turnbacks for 4-12 pattern. To execute 4-12 wiggles, do a turnback on the short note, and move forward on the long note.

{{#ev:youtube|Zn2FFhDc5WE|550}}

{{#ev:youtube|-WG7e4nAnp4|550}}

=== Acknowledgements ===

InfoManiac
Originally discovered the scroll glitch. The initial method only worked on TAS

Challenger
Implemented almost all the current scroll glitches in TAS that have since been ported to RTA by others.

NatGoesFast
Accidently did a scroll glitch on stream. An investigation of this led to the whip based RTA strategy discussed above.

SBDWolf
Found the whip based RTA viable approach for stage 13 and stage 14. Also figured out probably 75% of the basic block updating algorithm and RTA strategies such as odd/even frames approach. Also was the first person to use these scroll glitches to get WR. (May have also found the crusher room scrollglitch).

Shockratease
Along with SBDWolf, did extensive investigation and teaching on the scroll glitch. Suggested using 16/60th beats instead of two-part beats.

Kajong0007
Created the Romhack mentioned above, which has been used extensively by runners to better learn the trick.

JayCee
First person to remove whips for turnbacks and use it in runs. The removal of whips also enabled a lot of additional scroll glitch areas (crusher, clocktower) which did not seem viable otherwise. This inspired additional scrollglitch innovations.

Trisk (tr1sklion)
Wrote this document. Found the Block Counter and Column Update Window in the game bytecode. Validated and enhanced the earlier algorithm approximation SBDWolf modeled. Wrote the Bizhawk training tools. Pioneered the 4-frame turnbacks strategy and most correction strategies.

== Videos ==

SBDWolf talking about the scroll glitches

{{#ev:youtube|rmlBCzdVlOc|550}}

{{#ev:youtube|yaRmDa_T-oo|550}}

Here's Shockra Tease talking about both Scroll Glitches

{{#ev:youtube|Dw7NkOzp8tE|550}}

Advanced Stage 14

{{#ev:youtube|zxLs7h2cL6Y|550}}

Displaced Gamers Video on the code

{{#ev:youtube|wd18YNZB0D4|550}}

Cv1/ScrollGlitch

2024-04-17T21:20:57Z

K c r: /* Training Resources */

== Breaking Dracula’s Castle 101 ==

Before delving into why the scroll glitch works and how to execute it, I recommend understanding how castlevania updates its background tiles. Once we understand this, we can find various ways to break it, as well as diagnose when the scroll glitch fails.

=== How are background tiles updated? ===

Castlevania graphics are made up of foreground sprites (simon, candles, hearts, enemies) and background tiles. The game is building up these background tiles ahead of what is actually on the screen behind the scenes so that it can scroll smoothly as Simon moves. Around half a screen offscreen, the game is drawing a column two blocks wide. When that is complete, the game moves onto the next column. It looks something like this:

[[File:CV1_ScrollGlitch1. updated.png|550px]]

=== Tile Update Algorithm ===

Step 1: Should the update algorithm run?

There is a framecounter that starts at the beginning of every screen. This is the same framecounter that powers the item drops throughout the game. The update algorithm ONLY runs every other frame. I am not certain as to why, but I would guess this is because the Nintendo is not a very powerful system and this gives it time to do other work. Even if Simon is moving forward on a non updating frame, no tile will be updated.

Step 2: Is Simon moving (left or right… doesn’t matter)?

If Simon is moving (and we are on an even frame as discussed above), the tile upgrading algorithm will run and update a tile. Otherwise, the tile updating process is skipped.

Step 3: Determine which vertical column is going to be updated

If Simon is walking left, we will select a column on the left to update. If he is walking right, the column will be to the right. Every column is 32 pixels wide. For every column, there is another set of 32 pixels around 1.5 screens away that map to that column. When Simon is walking over this set of pixels in the direction towards that column, that column will be updated. See the section “How Background Tiles are Updated” for a picture that corresponds to this mapping.

I will refer to this 32 pixel walking space as the Column Update Window.

Step 4: Determine which tiles will be updated

We are now going to choose which actual blocks on the column will be updated. The game manages a special variable called the Block Counter that determines that location. This variable maps to the tiles vertically like so:

[[File:Block_Counter_mapping.png|550px]]

The block counter has a value between 0 and 7, inclusive; however, only the values 1-6 actually map to blocks.

Here is how the algorithm works:

# Did I just enter a new “Column update window”? (One of those 32 pixel spaces you walk over)
#*If yes, no matter WHAT ( even overriding the every other frame rule described above), reset the Block counter to 0
# Update the blocks in the selected column (the direction Simon is facing) at the vertical level marked by the block counter.
#*If the counter is 0 or 7, this does nothing.
# Increment the block counter by 1
# If the block counter > 7, set the block counter to 0

=== How non-glitched walking normally works ===
A player usually just walks in one direction for a while. As they walk through a new Column Update Window, the column 1.5 screens away starts getting updated. The Column Update Window is 32 pixels wide and we update tiles every other pixel, so we will run the tile upgrading algorithm 16 times (32/2). This will cause the block counter to go from 0 -> 7 and then 0 -> 7 again. This updates every tile value twice. Updating it twice doesn’t cause any harm - it just puts the same value there.

''NOTE - Technically there is a 50% probability of it being 15 times, not 16. This is because the first value is always overridden to 0. If that happens on the tile updating frame, the counter will still be held at 0. ''

=== What causes the scroll glitch to happen? ===

This algorithm manages tile drawing in BOTH the left and right direction. However, there is only ONE block counter. If you are walking left and the tile counter is at 4 but then turn right while the block counter turns to 5, then turn left again as the block counter changes to 6, you skipped a block on the left side. You updated blockset 4 and 6 but skipped 5.

The algorithm has a correction mechanism though. Notice that we normally iterate over the blocks twice for one column update window. That block 5 will get corrected as you continue to walk left… unless you do the same turnback again. Keep repeating this turnback until you have exited the column update window and you have successfully skipped updating the block, performing a “scroll glitch”.

This glitch does not let you put any tile value you want there. You are only skipping writing a value. This means the value will be whatever was there last.

=== Removing Tile Updating RNG ===
If the block counter is only updated every other frame, it seems impossible to actually make the trick predictable. Luckily, there is a neat math trick that solves this. This is best explained with an example:

If you move 1 frame, did you move the block counter? You don’t know. There is a 50% probability you did. If you move 2 frames, did you move the block counter? You moved the counter one and only one time with 100% certainty. This is because you either updated on the first frame or the second frame. It can’t be both or neither!

The above generalizes as you walk forward more pixels. If you move an even number of pixels without stopping, you are 100% certain to have moved the block counter the number of pixels moved divided by 2. If you moved an odd number of pixels, you don’t know what the block counter is incremented to.

As a concrete example, if you walk 6 pixels forward without stopping, you definitely moved the counter up by 3. If you moved 7 pixels, you have a 50% probability of moving it by 3 and a 50% probability of moving it 4.

=== Turnback Requirements ===
As you walk through a Column Update Window, you update each block in a column twice. Given this, it would seem like you will need to execute two turnbacks. Unfortunately, this is not always the case.

When you execute a turnback, you go back two pixels, then forward two pixels. You have now incremented the block counter twice. However, you are also on the same pixel in the Column Update Window as you were before you started the turnback. This means you have essentially added two extra counter updates than a normal walkthrough. Since you have to execute the turnback a second time, you are incrementing the block counter a total of four extra times. Those four extra increments will cause you to start updating some of the higher blocks a third time!

In practice, if you execute 2 frame turnbacks, you need to do three turnbacks unless you are targeting blocks at the 5th or 6th height index in the above diagram, in which case you can continue doing 2 turnbacks.

If you execute 4 frame turnbacks, you need to do 4 turnbacks for block indexes from 1 to 3, and 3 turnbacks for indices 4-6.

Note that these are simplifications. There are scenarios where you can do fewer turnbacks if you get lucky ( a combination of turnbacks being too short but getting lucky with the frame counter). In addition, you often want to execute extra turnbacks to raise consistency (discussed later).

''TECHNICAL NOTE - This is oversimplified. There are some details around having an odd number of pixels on the last walk forward that leads to one extra counter iteration. I don’t think this is a missing aspect of the algorithm, just some tricky off-by-one math. I got frustrated and stopped trying to nail it down exactly. ''

=== Scroll Glitch Execution Approaches ===

For all strategies, there is an important starting pixel where you want to start your turnbacks. This is the pixel that will have the block counter 1 below your target block regardless of whether. You can find this pixel with visuals for each of the level 5 tricks further down this page.

=== 2 - 14 Turnback Method ===

The 2-14 method is the first RTA viable method used by runners and is still used by most. We will do a series of 2 pixel turnbacks followed by 14 pixel walk forwards.

==== Beginner Approach ====
The easiest, although slowest, method is to find a launch point to predictably get to your starting pixel. This is usually done by back jumping and changing direction midair by ducking the opposite direction. If the backjump succeeds, you will have always landed on the right starting pixel. This gives you plenty of time to make sure you pick the right jump point without breaking the glitch.

Once you have gotten to the first pixel, you need a consistent way to go back two pixels. This is usually done by turning in the backwards direction and whipping on the next possible frame. If you are late on the whip, Simon will visibly walk further. If you are early, you will move only 1 pixel back but simon will still be facing forward.

After this, walk forward 14 pixels, rinse, and repeat. Most runners learn the proper 14 pixel visual at each turnback point and practice going to each one. Pictures are on the wiki for this.

This is a slow method, but it is easier for beginners to learn, execute, and diagnose. This slowness will limit the RTA viability of the trick to stage 13, stage 14 standard, and stage 14 advanced. The others are either too risky or the time savings are largely negated by the setup time.

==== Advanced Approach ====

There are two approaches to speed this up. The first is to pick a proper jump point to land on the right starting pixel. If you recognize that you jumped a pixel early, you can duck to move one extra pixel on landing to compensate.

The second approach is to just push back for two frames and push forward for fourteen frames repeatedly without whipping. You can use the jump setup described above or just hit back on the appropriate first frame. This is currently only being executed by Jay_Cee and I don’t have good advice for how to do this outside of lots of practice.

=== Corrections and Reliability Improvements ===

==== Adjust Pixels ====

Most runners learn to target each turnback pixel. If your turnback or turn forward is off by one pixel, the trick now has a 50% chance of success. This is because you now how much you have incremented the Block Counter (see the even-odd rule in the “Removing Tile Updating RNG” section).

HOWEVER, if you proceed as normal and target the same pixels afterwards, you now cut your probability of success down to 25%. For example, if you walk backwards 3 pixels instead of 2, your walk forward will now be 15 pixels if you keep your same target. That is now effectively one more area where you may have moved the counter an extra time.

You instead want to keep your existing movements the same and only move forward 14 pixels. You should either adjust your visual cue or use a rhythm method to feel what 14 frames of movement is like and ignore all pixel targets outside of the first one.

If you moved backwards more than 3 pixels, you definitely moved the counter more than you wanted. It can be saved but only by switching mid-run to the 4-12 turnback method (discussed later).

If you walked forward 2 pixels beyond your target pixel, unless you messed something earlier, the tile you wanted has been locked into a new value and the trick is dead.

==== Extra Turnback ====

As you get closer to the end of the Column Update Window, there are a few additional tweaks that can help save a dead scrollglitch attempt. For example, you may want to consider adding a 3rd turnback for the stage 14 scrollglitch.

For that glitch, unlike stage 13, the block counter doesn’t loop around for a 3rd time to that lower tile, so only two turnbacks are necessary. However, the counter ALMOST makes it there. If you have 3 pixel turnbacks instead of 2 or start the turnbacks slightly early, you are walking more in the Column Update Window after the final turnback. This can increment the block counter more and update your tile, even if you succeeded on the first two turnbacks.

Given this, you can consider adding one extra turnback as an insurance policy. For the 2-14 turnbacks, this is usually most relevant for the stage 14 wall glitch. For higher blocks like the stage 13 glitch, it is very unlikely that it will be able to make an extra loop, so I would not recommend it there.

=== Lenient Final Turnback ===

The above extra turnback is valuable when the normal final turnback is far away from the end of the Column Update Window. However, for some tricks, the final turnback is very close to the end of the Column Update Window. Stage 13 is a great example of this. That closeness creates extra leniency that we can take advantage of.

When normally doing the scroll glitch, let's assume you make a mistake. Instead of going back two pixels, you go back four. You have moved the counter two times. Your target block was not updated, so the trick is still alive; however, the trick is now out of alignment. If you move forward the normal 14 pixels, the trick will be ripped. HOWEVER, if this turnback was close to the end of the Column Update Window, you will escape before you walk 14 pixels. This means a 4 pixel turnback will not rip the final turnback on stage 13!

In fact, I would RECOMMEND doing a 4 pixel turnback on your final turnback here. The reason is you are skipping over two blocks on that last turnback. So if, for example, the block counter is 1 behind due to an earlier mistake, your run would normally be ripped on the final turnback. However, by moving the counter twice at the end, you protected yourself. In fact, this can move the 50% probability of success back to 100%. The block counter could have one of two possible values, and you handle both cases with one turnback.

You should do the 4 pixel turnback after walking 14 pixels if you think the counter is one behind. If you think the counter is one ahead, you should walk forward 12 pixels and then do the 4 pixel turnback. I highly recommend adding one of these approaches to your final turnback on stage 13. If you are adding an EXTRA turnback, as discussed above, the same leniency rule will apply there.

=== 4-12 Turnback Method ===

The leniency property on the last turnback can actually be applied to all turnbacks. Instead of doing 2-14 pixel turnbacks, you can execute 4-12 pixel turnbacks everywhere. This is my preferred technique.

By going back 4 pixels, you are actually skipping two blocks, not one. You don’t need to move two blocks; however, this can provide an extra buffer in case you make a mistake. For the 2-14 pixel approach, if you are off by 1 pixel, the success rate drops to 50%. If you are ever off by more than 1 pixel, the success rate is 0% unless you get lucky and make a countering mistake elsewhere.

For the 4-12 approach, if you are off by 1 pixel, you have a 50% probability for one of the blocks to be overridden. However, assuming the direction you are off is random, you have a 50% chance of that block being the one you care about. So now you have around a 75% probability of success even if you make a 1 pixel mistake. Furthermore, if you make a 2 pixel mistake, you still have a 50% probability of success. A 3 pixel mistake lowers you to around a 25% chance.

While the above math is just a rough approximation, this method has generally seemed more lenient than the 2-14 approach. In addition, if you are doing the whipless turnback technique, at least for me, it is much easier to consistently do a 4 pixel turnback instead of a 2 pixel one. You learn the back and forth d-pad rhythm and the trick can become quite consistent.

Unfortunately, this approach does have a few downsides. First, each turnback will cost an extra 4 frames. In addition, you will often have to do one extra turnback relative to the two pixel turnback. If targeting block 2 or 3, I would recommend 4 turnbacks. Anything below that, I would recommend 3 turnbacks.

=== Training Resources ===
ROMHack - A romhack is available on the CV1 discord. When used, it will print out Simon’s pixel coordinates. In addition, it will print the Block Counter.

The starting pixel coordinates for the scroll glitches are:

{| class="wikitable" style="margin:auto"
|+
|-
! Stage Number !! Pixel !! Savings**
|-
| Stage 6 Crusher || 1D9 & 1B9 || ~9 sec
|-
| Stage 7 Coffee || 255 & 1F9 ||
|-
| Stage 13 || A4 || ~12.5 sec
|-
| Stage 14 Bacon || 45C or 43D ||
|-
| Stage 14 Egg || 2C4* ||
|-
| Stage 14 Cheese || 328 || ~8 sec
|-
| Stage 17 Clocktower || 219 & 1FB ||
|}

<nowiki>*</nowiki>Touching pixel 2B9 is needed before turning around

<nowiki>**</nowiki>Timings are approximate, also you may not see the same time savings if you don't play the rest of the level as optimal as your prior splits, so 12s might turn into 6s.

Stage 13:

Start on 7A turn around, backwards jump and turnaround to land on A4 -> A1. The a 14 frame Walk to B0 then B0 2 frame turnaround AE. Then a 14 frame walk end on BC quick left turn around (between 2-5 frames?) and then walk right.

[[File:CV1_13-SG-1.png|250px]]
[[File:CV1_13-SG-2.png|250px]]
[[File:CV1_13-SG-3.png|250px]]
[[File:CV1_13-SG-4.png|250px]]

Stage 14
Start on 2FE then backwards jump and turn and land on 328. Whip turnaround 328 -> 326, then move to and do a whip turn around 334 -> 332.

[[File:CV1_14-SG-1.png|250px]]
[[File:CV1_14-SG-2.png|250px]]
[[File:CV1_14-SG-3.png|250px]]

=== Emulator Training Tools ===
I have created a set of scroll glitch training tools (along with other cv1 helper tools). These currently require using bizhawk, although I will likely port to other emulators in the future.

https://www.speedrun.com/cv1/resources

Helpful tools included are:

1. Create lines onscreen to show turnback locations
2. Auto-death tool - kills you if you miss a scroll glitch
3. Turnback-Turnforward diagnostic printout (to highlight if you really are hitting 2-14 or 4-12)

Note, if you are using original hardware, the above tools may be a little annoying as the input latency is different. I would still recommend trying them though as many scroll glitch execution strategies are not latency sensitive.

=== Rhythm Sounds ===
If you are trying to learn a whipless rhythm approach, sounds can also be a helpful aid. You hit the buttons on the appropriate beat. Every frame is 1/60th of a second (technically 1/60.09), so you can use that to create a beat. One style is to do 4/60th of a second followed by 12/60th of a second. Another is to just have a metronome set to 16/60th of a second and time either your forward or backward presses to that beat.

Below are two videos with rhythm of whipless scroll glitch turnbacks for 4-12 pattern. To execute 4-12 wiggles, do a turnback on the short note, and move forward on the long note.

{{#ev:youtube|Zn2FFhDc5WE|550}}

{{#ev:youtube|-WG7e4nAnp4|550}}

=== Acknowledgements ===

InfoManiac
Originally discovered the scroll glitch. The initial method only worked on TAS

Challenger
Implemented almost all the current scroll glitches in TAS that have since been ported to RTA by others.

NatGoesFast
Accidently did a scroll glitch on stream. An investigation of this led to the whip based RTA strategy discussed above.

SBDWolf
Found the whip based RTA viable approach for stage 13 and stage 14. Also figured out probably 75% of the basic block updating algorithm and RTA strategies such as odd/even frames approach. Also was the first person to use these scroll glitches to get WR. (May have also found the crusher room scrollglitch).

Shockratease
Along with SBDWolf, did extensive investigation and teaching on the scroll glitch. Suggested using 16/60th beats instead of two-part beats.

Kajong0007
Created the Romhack mentioned above, which has been used extensively by runners to better learn the trick.

JayCee
First person to remove whips for turnbacks and use it in runs. The removal of whips also enabled a lot of additional scroll glitch areas (crusher, clocktower) which did not seem viable otherwise. This inspired additional scrollglitch innovations.

Trisk (tr1sklion)
Wrote this document. Found the Block Counter and Column Update Window in the game bytecode. Validated and enhanced the earlier algorithm approximation SBDWolf modeled. Wrote the Bizhawk training tools. Pioneered the 4-frame turnbacks strategy and most correction strategies.

== Videos ==

SBDWolf talking about the scroll glitches

{{#ev:youtube|rmlBCzdVlOc|550}}

{{#ev:youtube|yaRmDa_T-oo|550}}

Here's Shockra Tease talking about both Scroll Glitches

{{#ev:youtube|Dw7NkOzp8tE|550}}

Advanced Stage 14

{{#ev:youtube|zxLs7h2cL6Y|550}}

Displaced Gamers Video on the code

{{#ev:youtube|wd18YNZB0D4|550}}

Cv1/ScrollGlitch

2024-04-17T21:20:31Z

K c r: /* Training Resources */

== Breaking Dracula’s Castle 101 ==

Before delving into why the scroll glitch works and how to execute it, I recommend understanding how castlevania updates its background tiles. Once we understand this, we can find various ways to break it, as well as diagnose when the scroll glitch fails.

=== How are background tiles updated? ===

Castlevania graphics are made up of foreground sprites (simon, candles, hearts, enemies) and background tiles. The game is building up these background tiles ahead of what is actually on the screen behind the scenes so that it can scroll smoothly as Simon moves. Around half a screen offscreen, the game is drawing a column two blocks wide. When that is complete, the game moves onto the next column. It looks something like this:

[[File:CV1_ScrollGlitch1. updated.png|550px]]

=== Tile Update Algorithm ===

Step 1: Should the update algorithm run?

There is a framecounter that starts at the beginning of every screen. This is the same framecounter that powers the item drops throughout the game. The update algorithm ONLY runs every other frame. I am not certain as to why, but I would guess this is because the Nintendo is not a very powerful system and this gives it time to do other work. Even if Simon is moving forward on a non updating frame, no tile will be updated.

Step 2: Is Simon moving (left or right… doesn’t matter)?

If Simon is moving (and we are on an even frame as discussed above), the tile upgrading algorithm will run and update a tile. Otherwise, the tile updating process is skipped.

Step 3: Determine which vertical column is going to be updated

If Simon is walking left, we will select a column on the left to update. If he is walking right, the column will be to the right. Every column is 32 pixels wide. For every column, there is another set of 32 pixels around 1.5 screens away that map to that column. When Simon is walking over this set of pixels in the direction towards that column, that column will be updated. See the section “How Background Tiles are Updated” for a picture that corresponds to this mapping.

I will refer to this 32 pixel walking space as the Column Update Window.

Step 4: Determine which tiles will be updated

We are now going to choose which actual blocks on the column will be updated. The game manages a special variable called the Block Counter that determines that location. This variable maps to the tiles vertically like so:

[[File:Block_Counter_mapping.png|550px]]

The block counter has a value between 0 and 7, inclusive; however, only the values 1-6 actually map to blocks.

Here is how the algorithm works:

# Did I just enter a new “Column update window”? (One of those 32 pixel spaces you walk over)
#*If yes, no matter WHAT ( even overriding the every other frame rule described above), reset the Block counter to 0
# Update the blocks in the selected column (the direction Simon is facing) at the vertical level marked by the block counter.
#*If the counter is 0 or 7, this does nothing.
# Increment the block counter by 1
# If the block counter > 7, set the block counter to 0

=== How non-glitched walking normally works ===
A player usually just walks in one direction for a while. As they walk through a new Column Update Window, the column 1.5 screens away starts getting updated. The Column Update Window is 32 pixels wide and we update tiles every other pixel, so we will run the tile upgrading algorithm 16 times (32/2). This will cause the block counter to go from 0 -> 7 and then 0 -> 7 again. This updates every tile value twice. Updating it twice doesn’t cause any harm - it just puts the same value there.

''NOTE - Technically there is a 50% probability of it being 15 times, not 16. This is because the first value is always overridden to 0. If that happens on the tile updating frame, the counter will still be held at 0. ''

=== What causes the scroll glitch to happen? ===

This algorithm manages tile drawing in BOTH the left and right direction. However, there is only ONE block counter. If you are walking left and the tile counter is at 4 but then turn right while the block counter turns to 5, then turn left again as the block counter changes to 6, you skipped a block on the left side. You updated blockset 4 and 6 but skipped 5.

The algorithm has a correction mechanism though. Notice that we normally iterate over the blocks twice for one column update window. That block 5 will get corrected as you continue to walk left… unless you do the same turnback again. Keep repeating this turnback until you have exited the column update window and you have successfully skipped updating the block, performing a “scroll glitch”.

This glitch does not let you put any tile value you want there. You are only skipping writing a value. This means the value will be whatever was there last.

=== Removing Tile Updating RNG ===
If the block counter is only updated every other frame, it seems impossible to actually make the trick predictable. Luckily, there is a neat math trick that solves this. This is best explained with an example:

If you move 1 frame, did you move the block counter? You don’t know. There is a 50% probability you did. If you move 2 frames, did you move the block counter? You moved the counter one and only one time with 100% certainty. This is because you either updated on the first frame or the second frame. It can’t be both or neither!

The above generalizes as you walk forward more pixels. If you move an even number of pixels without stopping, you are 100% certain to have moved the block counter the number of pixels moved divided by 2. If you moved an odd number of pixels, you don’t know what the block counter is incremented to.

As a concrete example, if you walk 6 pixels forward without stopping, you definitely moved the counter up by 3. If you moved 7 pixels, you have a 50% probability of moving it by 3 and a 50% probability of moving it 4.

=== Turnback Requirements ===
As you walk through a Column Update Window, you update each block in a column twice. Given this, it would seem like you will need to execute two turnbacks. Unfortunately, this is not always the case.

When you execute a turnback, you go back two pixels, then forward two pixels. You have now incremented the block counter twice. However, you are also on the same pixel in the Column Update Window as you were before you started the turnback. This means you have essentially added two extra counter updates than a normal walkthrough. Since you have to execute the turnback a second time, you are incrementing the block counter a total of four extra times. Those four extra increments will cause you to start updating some of the higher blocks a third time!

In practice, if you execute 2 frame turnbacks, you need to do three turnbacks unless you are targeting blocks at the 5th or 6th height index in the above diagram, in which case you can continue doing 2 turnbacks.

If you execute 4 frame turnbacks, you need to do 4 turnbacks for block indexes from 1 to 3, and 3 turnbacks for indices 4-6.

Note that these are simplifications. There are scenarios where you can do fewer turnbacks if you get lucky ( a combination of turnbacks being too short but getting lucky with the frame counter). In addition, you often want to execute extra turnbacks to raise consistency (discussed later).

''TECHNICAL NOTE - This is oversimplified. There are some details around having an odd number of pixels on the last walk forward that leads to one extra counter iteration. I don’t think this is a missing aspect of the algorithm, just some tricky off-by-one math. I got frustrated and stopped trying to nail it down exactly. ''

=== Scroll Glitch Execution Approaches ===

For all strategies, there is an important starting pixel where you want to start your turnbacks. This is the pixel that will have the block counter 1 below your target block regardless of whether. You can find this pixel with visuals for each of the level 5 tricks further down this page.

=== 2 - 14 Turnback Method ===

The 2-14 method is the first RTA viable method used by runners and is still used by most. We will do a series of 2 pixel turnbacks followed by 14 pixel walk forwards.

==== Beginner Approach ====
The easiest, although slowest, method is to find a launch point to predictably get to your starting pixel. This is usually done by back jumping and changing direction midair by ducking the opposite direction. If the backjump succeeds, you will have always landed on the right starting pixel. This gives you plenty of time to make sure you pick the right jump point without breaking the glitch.

Once you have gotten to the first pixel, you need a consistent way to go back two pixels. This is usually done by turning in the backwards direction and whipping on the next possible frame. If you are late on the whip, Simon will visibly walk further. If you are early, you will move only 1 pixel back but simon will still be facing forward.

After this, walk forward 14 pixels, rinse, and repeat. Most runners learn the proper 14 pixel visual at each turnback point and practice going to each one. Pictures are on the wiki for this.

This is a slow method, but it is easier for beginners to learn, execute, and diagnose. This slowness will limit the RTA viability of the trick to stage 13, stage 14 standard, and stage 14 advanced. The others are either too risky or the time savings are largely negated by the setup time.

==== Advanced Approach ====

There are two approaches to speed this up. The first is to pick a proper jump point to land on the right starting pixel. If you recognize that you jumped a pixel early, you can duck to move one extra pixel on landing to compensate.

The second approach is to just push back for two frames and push forward for fourteen frames repeatedly without whipping. You can use the jump setup described above or just hit back on the appropriate first frame. This is currently only being executed by Jay_Cee and I don’t have good advice for how to do this outside of lots of practice.

=== Corrections and Reliability Improvements ===

==== Adjust Pixels ====

Most runners learn to target each turnback pixel. If your turnback or turn forward is off by one pixel, the trick now has a 50% chance of success. This is because you now how much you have incremented the Block Counter (see the even-odd rule in the “Removing Tile Updating RNG” section).

HOWEVER, if you proceed as normal and target the same pixels afterwards, you now cut your probability of success down to 25%. For example, if you walk backwards 3 pixels instead of 2, your walk forward will now be 15 pixels if you keep your same target. That is now effectively one more area where you may have moved the counter an extra time.

You instead want to keep your existing movements the same and only move forward 14 pixels. You should either adjust your visual cue or use a rhythm method to feel what 14 frames of movement is like and ignore all pixel targets outside of the first one.

If you moved backwards more than 3 pixels, you definitely moved the counter more than you wanted. It can be saved but only by switching mid-run to the 4-12 turnback method (discussed later).

If you walked forward 2 pixels beyond your target pixel, unless you messed something earlier, the tile you wanted has been locked into a new value and the trick is dead.

==== Extra Turnback ====

As you get closer to the end of the Column Update Window, there are a few additional tweaks that can help save a dead scrollglitch attempt. For example, you may want to consider adding a 3rd turnback for the stage 14 scrollglitch.

For that glitch, unlike stage 13, the block counter doesn’t loop around for a 3rd time to that lower tile, so only two turnbacks are necessary. However, the counter ALMOST makes it there. If you have 3 pixel turnbacks instead of 2 or start the turnbacks slightly early, you are walking more in the Column Update Window after the final turnback. This can increment the block counter more and update your tile, even if you succeeded on the first two turnbacks.

Given this, you can consider adding one extra turnback as an insurance policy. For the 2-14 turnbacks, this is usually most relevant for the stage 14 wall glitch. For higher blocks like the stage 13 glitch, it is very unlikely that it will be able to make an extra loop, so I would not recommend it there.

=== Lenient Final Turnback ===

The above extra turnback is valuable when the normal final turnback is far away from the end of the Column Update Window. However, for some tricks, the final turnback is very close to the end of the Column Update Window. Stage 13 is a great example of this. That closeness creates extra leniency that we can take advantage of.

When normally doing the scroll glitch, let's assume you make a mistake. Instead of going back two pixels, you go back four. You have moved the counter two times. Your target block was not updated, so the trick is still alive; however, the trick is now out of alignment. If you move forward the normal 14 pixels, the trick will be ripped. HOWEVER, if this turnback was close to the end of the Column Update Window, you will escape before you walk 14 pixels. This means a 4 pixel turnback will not rip the final turnback on stage 13!

In fact, I would RECOMMEND doing a 4 pixel turnback on your final turnback here. The reason is you are skipping over two blocks on that last turnback. So if, for example, the block counter is 1 behind due to an earlier mistake, your run would normally be ripped on the final turnback. However, by moving the counter twice at the end, you protected yourself. In fact, this can move the 50% probability of success back to 100%. The block counter could have one of two possible values, and you handle both cases with one turnback.

You should do the 4 pixel turnback after walking 14 pixels if you think the counter is one behind. If you think the counter is one ahead, you should walk forward 12 pixels and then do the 4 pixel turnback. I highly recommend adding one of these approaches to your final turnback on stage 13. If you are adding an EXTRA turnback, as discussed above, the same leniency rule will apply there.

=== 4-12 Turnback Method ===

The leniency property on the last turnback can actually be applied to all turnbacks. Instead of doing 2-14 pixel turnbacks, you can execute 4-12 pixel turnbacks everywhere. This is my preferred technique.

By going back 4 pixels, you are actually skipping two blocks, not one. You don’t need to move two blocks; however, this can provide an extra buffer in case you make a mistake. For the 2-14 pixel approach, if you are off by 1 pixel, the success rate drops to 50%. If you are ever off by more than 1 pixel, the success rate is 0% unless you get lucky and make a countering mistake elsewhere.

For the 4-12 approach, if you are off by 1 pixel, you have a 50% probability for one of the blocks to be overridden. However, assuming the direction you are off is random, you have a 50% chance of that block being the one you care about. So now you have around a 75% probability of success even if you make a 1 pixel mistake. Furthermore, if you make a 2 pixel mistake, you still have a 50% probability of success. A 3 pixel mistake lowers you to around a 25% chance.

While the above math is just a rough approximation, this method has generally seemed more lenient than the 2-14 approach. In addition, if you are doing the whipless turnback technique, at least for me, it is much easier to consistently do a 4 pixel turnback instead of a 2 pixel one. You learn the back and forth d-pad rhythm and the trick can become quite consistent.

Unfortunately, this approach does have a few downsides. First, each turnback will cost an extra 4 frames. In addition, you will often have to do one extra turnback relative to the two pixel turnback. If targeting block 2 or 3, I would recommend 4 turnbacks. Anything below that, I would recommend 3 turnbacks.

=== Training Resources ===
ROMHack - A romhack is available on the CV1 discord. When used, it will print out Simon’s pixel coordinates. In addition, it will print the Block Counter.

The starting pixel coordinates for the scroll glitches are:

{| class="wikitable" style="margin:auto"
|+
|-
! Stage Number !! Pixel !! Savings**
|-
| Stage 6 Crusher || 1D9 & 1B9 || ~9 sec
|-
| Stage 7 Coffee || 255 & 1F9 ||
|-
| Stage 13 || A4 || ~12.5 sec
|-
| Stage 14 Bacon || 45C or 43D ||
|-
| Stage 14 Egg || 2C4* ||
|-
| Stage 14 Cheese || 328 || ~8 sec
|-
| Stage 17 Clocktower || 219 & 1FB ||
|}

<nowiki>*</nowiki>Touching pixel 2B9 is needed before turning around
<nowiki>**</nowiki>Timings are approximate, also you may not see the same time savings if you don't play the rest of the level as optimal as your prior splits, so 12s might turn into 6s.

Stage 13:

Start on 7A turn around, backwards jump and turnaround to land on A4 -> A1. The a 14 frame Walk to B0 then B0 2 frame turnaround AE. Then a 14 frame walk end on BC quick left turn around (between 2-5 frames?) and then walk right.

[[File:CV1_13-SG-1.png|250px]]
[[File:CV1_13-SG-2.png|250px]]
[[File:CV1_13-SG-3.png|250px]]
[[File:CV1_13-SG-4.png|250px]]

Stage 14
Start on 2FE then backwards jump and turn and land on 328. Whip turnaround 328 -> 326, then move to and do a whip turn around 334 -> 332.

[[File:CV1_14-SG-1.png|250px]]
[[File:CV1_14-SG-2.png|250px]]
[[File:CV1_14-SG-3.png|250px]]

=== Emulator Training Tools ===
I have created a set of scroll glitch training tools (along with other cv1 helper tools). These currently require using bizhawk, although I will likely port to other emulators in the future.

https://www.speedrun.com/cv1/resources

Helpful tools included are:

1. Create lines onscreen to show turnback locations
2. Auto-death tool - kills you if you miss a scroll glitch
3. Turnback-Turnforward diagnostic printout (to highlight if you really are hitting 2-14 or 4-12)

Note, if you are using original hardware, the above tools may be a little annoying as the input latency is different. I would still recommend trying them though as many scroll glitch execution strategies are not latency sensitive.

=== Rhythm Sounds ===
If you are trying to learn a whipless rhythm approach, sounds can also be a helpful aid. You hit the buttons on the appropriate beat. Every frame is 1/60th of a second (technically 1/60.09), so you can use that to create a beat. One style is to do 4/60th of a second followed by 12/60th of a second. Another is to just have a metronome set to 16/60th of a second and time either your forward or backward presses to that beat.

Below are two videos with rhythm of whipless scroll glitch turnbacks for 4-12 pattern. To execute 4-12 wiggles, do a turnback on the short note, and move forward on the long note.

{{#ev:youtube|Zn2FFhDc5WE|550}}

{{#ev:youtube|-WG7e4nAnp4|550}}

=== Acknowledgements ===

InfoManiac
Originally discovered the scroll glitch. The initial method only worked on TAS

Challenger
Implemented almost all the current scroll glitches in TAS that have since been ported to RTA by others.

NatGoesFast
Accidently did a scroll glitch on stream. An investigation of this led to the whip based RTA strategy discussed above.

SBDWolf
Found the whip based RTA viable approach for stage 13 and stage 14. Also figured out probably 75% of the basic block updating algorithm and RTA strategies such as odd/even frames approach. Also was the first person to use these scroll glitches to get WR. (May have also found the crusher room scrollglitch).

Shockratease
Along with SBDWolf, did extensive investigation and teaching on the scroll glitch. Suggested using 16/60th beats instead of two-part beats.

Kajong0007
Created the Romhack mentioned above, which has been used extensively by runners to better learn the trick.

JayCee
First person to remove whips for turnbacks and use it in runs. The removal of whips also enabled a lot of additional scroll glitch areas (crusher, clocktower) which did not seem viable otherwise. This inspired additional scrollglitch innovations.

Trisk (tr1sklion)
Wrote this document. Found the Block Counter and Column Update Window in the game bytecode. Validated and enhanced the earlier algorithm approximation SBDWolf modeled. Wrote the Bizhawk training tools. Pioneered the 4-frame turnbacks strategy and most correction strategies.

== Videos ==

SBDWolf talking about the scroll glitches

{{#ev:youtube|rmlBCzdVlOc|550}}

{{#ev:youtube|yaRmDa_T-oo|550}}

Here's Shockra Tease talking about both Scroll Glitches

{{#ev:youtube|Dw7NkOzp8tE|550}}

Advanced Stage 14

{{#ev:youtube|zxLs7h2cL6Y|550}}

Displaced Gamers Video on the code

{{#ev:youtube|wd18YNZB0D4|550}}

Cv1/ScrollGlitch

2024-04-17T21:20:12Z

K c r: /* Training Resources */

== Breaking Dracula’s Castle 101 ==

Before delving into why the scroll glitch works and how to execute it, I recommend understanding how castlevania updates its background tiles. Once we understand this, we can find various ways to break it, as well as diagnose when the scroll glitch fails.

=== How are background tiles updated? ===

Castlevania graphics are made up of foreground sprites (simon, candles, hearts, enemies) and background tiles. The game is building up these background tiles ahead of what is actually on the screen behind the scenes so that it can scroll smoothly as Simon moves. Around half a screen offscreen, the game is drawing a column two blocks wide. When that is complete, the game moves onto the next column. It looks something like this:

[[File:CV1_ScrollGlitch1. updated.png|550px]]

=== Tile Update Algorithm ===

Step 1: Should the update algorithm run?

There is a framecounter that starts at the beginning of every screen. This is the same framecounter that powers the item drops throughout the game. The update algorithm ONLY runs every other frame. I am not certain as to why, but I would guess this is because the Nintendo is not a very powerful system and this gives it time to do other work. Even if Simon is moving forward on a non updating frame, no tile will be updated.

Step 2: Is Simon moving (left or right… doesn’t matter)?

If Simon is moving (and we are on an even frame as discussed above), the tile upgrading algorithm will run and update a tile. Otherwise, the tile updating process is skipped.

Step 3: Determine which vertical column is going to be updated

If Simon is walking left, we will select a column on the left to update. If he is walking right, the column will be to the right. Every column is 32 pixels wide. For every column, there is another set of 32 pixels around 1.5 screens away that map to that column. When Simon is walking over this set of pixels in the direction towards that column, that column will be updated. See the section “How Background Tiles are Updated” for a picture that corresponds to this mapping.

I will refer to this 32 pixel walking space as the Column Update Window.

Step 4: Determine which tiles will be updated

We are now going to choose which actual blocks on the column will be updated. The game manages a special variable called the Block Counter that determines that location. This variable maps to the tiles vertically like so:

[[File:Block_Counter_mapping.png|550px]]

The block counter has a value between 0 and 7, inclusive; however, only the values 1-6 actually map to blocks.

Here is how the algorithm works:

# Did I just enter a new “Column update window”? (One of those 32 pixel spaces you walk over)
#*If yes, no matter WHAT ( even overriding the every other frame rule described above), reset the Block counter to 0
# Update the blocks in the selected column (the direction Simon is facing) at the vertical level marked by the block counter.
#*If the counter is 0 or 7, this does nothing.
# Increment the block counter by 1
# If the block counter > 7, set the block counter to 0

=== How non-glitched walking normally works ===
A player usually just walks in one direction for a while. As they walk through a new Column Update Window, the column 1.5 screens away starts getting updated. The Column Update Window is 32 pixels wide and we update tiles every other pixel, so we will run the tile upgrading algorithm 16 times (32/2). This will cause the block counter to go from 0 -> 7 and then 0 -> 7 again. This updates every tile value twice. Updating it twice doesn’t cause any harm - it just puts the same value there.

''NOTE - Technically there is a 50% probability of it being 15 times, not 16. This is because the first value is always overridden to 0. If that happens on the tile updating frame, the counter will still be held at 0. ''

=== What causes the scroll glitch to happen? ===

This algorithm manages tile drawing in BOTH the left and right direction. However, there is only ONE block counter. If you are walking left and the tile counter is at 4 but then turn right while the block counter turns to 5, then turn left again as the block counter changes to 6, you skipped a block on the left side. You updated blockset 4 and 6 but skipped 5.

The algorithm has a correction mechanism though. Notice that we normally iterate over the blocks twice for one column update window. That block 5 will get corrected as you continue to walk left… unless you do the same turnback again. Keep repeating this turnback until you have exited the column update window and you have successfully skipped updating the block, performing a “scroll glitch”.

This glitch does not let you put any tile value you want there. You are only skipping writing a value. This means the value will be whatever was there last.

=== Removing Tile Updating RNG ===
If the block counter is only updated every other frame, it seems impossible to actually make the trick predictable. Luckily, there is a neat math trick that solves this. This is best explained with an example:

If you move 1 frame, did you move the block counter? You don’t know. There is a 50% probability you did. If you move 2 frames, did you move the block counter? You moved the counter one and only one time with 100% certainty. This is because you either updated on the first frame or the second frame. It can’t be both or neither!

The above generalizes as you walk forward more pixels. If you move an even number of pixels without stopping, you are 100% certain to have moved the block counter the number of pixels moved divided by 2. If you moved an odd number of pixels, you don’t know what the block counter is incremented to.

As a concrete example, if you walk 6 pixels forward without stopping, you definitely moved the counter up by 3. If you moved 7 pixels, you have a 50% probability of moving it by 3 and a 50% probability of moving it 4.

=== Turnback Requirements ===
As you walk through a Column Update Window, you update each block in a column twice. Given this, it would seem like you will need to execute two turnbacks. Unfortunately, this is not always the case.

When you execute a turnback, you go back two pixels, then forward two pixels. You have now incremented the block counter twice. However, you are also on the same pixel in the Column Update Window as you were before you started the turnback. This means you have essentially added two extra counter updates than a normal walkthrough. Since you have to execute the turnback a second time, you are incrementing the block counter a total of four extra times. Those four extra increments will cause you to start updating some of the higher blocks a third time!

In practice, if you execute 2 frame turnbacks, you need to do three turnbacks unless you are targeting blocks at the 5th or 6th height index in the above diagram, in which case you can continue doing 2 turnbacks.

If you execute 4 frame turnbacks, you need to do 4 turnbacks for block indexes from 1 to 3, and 3 turnbacks for indices 4-6.

Note that these are simplifications. There are scenarios where you can do fewer turnbacks if you get lucky ( a combination of turnbacks being too short but getting lucky with the frame counter). In addition, you often want to execute extra turnbacks to raise consistency (discussed later).

''TECHNICAL NOTE - This is oversimplified. There are some details around having an odd number of pixels on the last walk forward that leads to one extra counter iteration. I don’t think this is a missing aspect of the algorithm, just some tricky off-by-one math. I got frustrated and stopped trying to nail it down exactly. ''

=== Scroll Glitch Execution Approaches ===

For all strategies, there is an important starting pixel where you want to start your turnbacks. This is the pixel that will have the block counter 1 below your target block regardless of whether. You can find this pixel with visuals for each of the level 5 tricks further down this page.

=== 2 - 14 Turnback Method ===

The 2-14 method is the first RTA viable method used by runners and is still used by most. We will do a series of 2 pixel turnbacks followed by 14 pixel walk forwards.

==== Beginner Approach ====
The easiest, although slowest, method is to find a launch point to predictably get to your starting pixel. This is usually done by back jumping and changing direction midair by ducking the opposite direction. If the backjump succeeds, you will have always landed on the right starting pixel. This gives you plenty of time to make sure you pick the right jump point without breaking the glitch.

Once you have gotten to the first pixel, you need a consistent way to go back two pixels. This is usually done by turning in the backwards direction and whipping on the next possible frame. If you are late on the whip, Simon will visibly walk further. If you are early, you will move only 1 pixel back but simon will still be facing forward.

After this, walk forward 14 pixels, rinse, and repeat. Most runners learn the proper 14 pixel visual at each turnback point and practice going to each one. Pictures are on the wiki for this.

This is a slow method, but it is easier for beginners to learn, execute, and diagnose. This slowness will limit the RTA viability of the trick to stage 13, stage 14 standard, and stage 14 advanced. The others are either too risky or the time savings are largely negated by the setup time.

==== Advanced Approach ====

There are two approaches to speed this up. The first is to pick a proper jump point to land on the right starting pixel. If you recognize that you jumped a pixel early, you can duck to move one extra pixel on landing to compensate.

The second approach is to just push back for two frames and push forward for fourteen frames repeatedly without whipping. You can use the jump setup described above or just hit back on the appropriate first frame. This is currently only being executed by Jay_Cee and I don’t have good advice for how to do this outside of lots of practice.

=== Corrections and Reliability Improvements ===

==== Adjust Pixels ====

Most runners learn to target each turnback pixel. If your turnback or turn forward is off by one pixel, the trick now has a 50% chance of success. This is because you now how much you have incremented the Block Counter (see the even-odd rule in the “Removing Tile Updating RNG” section).

HOWEVER, if you proceed as normal and target the same pixels afterwards, you now cut your probability of success down to 25%. For example, if you walk backwards 3 pixels instead of 2, your walk forward will now be 15 pixels if you keep your same target. That is now effectively one more area where you may have moved the counter an extra time.

You instead want to keep your existing movements the same and only move forward 14 pixels. You should either adjust your visual cue or use a rhythm method to feel what 14 frames of movement is like and ignore all pixel targets outside of the first one.

If you moved backwards more than 3 pixels, you definitely moved the counter more than you wanted. It can be saved but only by switching mid-run to the 4-12 turnback method (discussed later).

If you walked forward 2 pixels beyond your target pixel, unless you messed something earlier, the tile you wanted has been locked into a new value and the trick is dead.

==== Extra Turnback ====

As you get closer to the end of the Column Update Window, there are a few additional tweaks that can help save a dead scrollglitch attempt. For example, you may want to consider adding a 3rd turnback for the stage 14 scrollglitch.

For that glitch, unlike stage 13, the block counter doesn’t loop around for a 3rd time to that lower tile, so only two turnbacks are necessary. However, the counter ALMOST makes it there. If you have 3 pixel turnbacks instead of 2 or start the turnbacks slightly early, you are walking more in the Column Update Window after the final turnback. This can increment the block counter more and update your tile, even if you succeeded on the first two turnbacks.

Given this, you can consider adding one extra turnback as an insurance policy. For the 2-14 turnbacks, this is usually most relevant for the stage 14 wall glitch. For higher blocks like the stage 13 glitch, it is very unlikely that it will be able to make an extra loop, so I would not recommend it there.

=== Lenient Final Turnback ===

The above extra turnback is valuable when the normal final turnback is far away from the end of the Column Update Window. However, for some tricks, the final turnback is very close to the end of the Column Update Window. Stage 13 is a great example of this. That closeness creates extra leniency that we can take advantage of.

When normally doing the scroll glitch, let's assume you make a mistake. Instead of going back two pixels, you go back four. You have moved the counter two times. Your target block was not updated, so the trick is still alive; however, the trick is now out of alignment. If you move forward the normal 14 pixels, the trick will be ripped. HOWEVER, if this turnback was close to the end of the Column Update Window, you will escape before you walk 14 pixels. This means a 4 pixel turnback will not rip the final turnback on stage 13!

In fact, I would RECOMMEND doing a 4 pixel turnback on your final turnback here. The reason is you are skipping over two blocks on that last turnback. So if, for example, the block counter is 1 behind due to an earlier mistake, your run would normally be ripped on the final turnback. However, by moving the counter twice at the end, you protected yourself. In fact, this can move the 50% probability of success back to 100%. The block counter could have one of two possible values, and you handle both cases with one turnback.

You should do the 4 pixel turnback after walking 14 pixels if you think the counter is one behind. If you think the counter is one ahead, you should walk forward 12 pixels and then do the 4 pixel turnback. I highly recommend adding one of these approaches to your final turnback on stage 13. If you are adding an EXTRA turnback, as discussed above, the same leniency rule will apply there.

=== 4-12 Turnback Method ===

The leniency property on the last turnback can actually be applied to all turnbacks. Instead of doing 2-14 pixel turnbacks, you can execute 4-12 pixel turnbacks everywhere. This is my preferred technique.

By going back 4 pixels, you are actually skipping two blocks, not one. You don’t need to move two blocks; however, this can provide an extra buffer in case you make a mistake. For the 2-14 pixel approach, if you are off by 1 pixel, the success rate drops to 50%. If you are ever off by more than 1 pixel, the success rate is 0% unless you get lucky and make a countering mistake elsewhere.

For the 4-12 approach, if you are off by 1 pixel, you have a 50% probability for one of the blocks to be overridden. However, assuming the direction you are off is random, you have a 50% chance of that block being the one you care about. So now you have around a 75% probability of success even if you make a 1 pixel mistake. Furthermore, if you make a 2 pixel mistake, you still have a 50% probability of success. A 3 pixel mistake lowers you to around a 25% chance.

While the above math is just a rough approximation, this method has generally seemed more lenient than the 2-14 approach. In addition, if you are doing the whipless turnback technique, at least for me, it is much easier to consistently do a 4 pixel turnback instead of a 2 pixel one. You learn the back and forth d-pad rhythm and the trick can become quite consistent.

Unfortunately, this approach does have a few downsides. First, each turnback will cost an extra 4 frames. In addition, you will often have to do one extra turnback relative to the two pixel turnback. If targeting block 2 or 3, I would recommend 4 turnbacks. Anything below that, I would recommend 3 turnbacks.

=== Training Resources ===
ROMHack - A romhack is available on the CV1 discord. When used, it will print out Simon’s pixel coordinates. In addition, it will print the Block Counter.

The starting pixel coordinates for the scroll glitches are:

{| class="wikitable" style="margin:auto"
|+
|-
! Stage Number !! Pixel !! Savings**
|-
| Stage 6 Crusher || 1D9 & 1B9 || ~9 sec
|-
| Stage 7 Coffee || 255 & 1F9 ||
|-
| Stage 13 || A4 || ~12.5 sec
|-
| Stage 14 Bacon || 45C or 43D ||
|-
| Stage 14 Egg || 2C4* ||
|-
| Stage 14 Cheese || 328 || ~8 sec
|-
| Stage 17 Clocktower || 219 & 1FB ||
|}

<nowiki>*</nowiki>Touching pixel 2B9 is needed before turning around
<nowiki>**</nowiki>Timings are approximate, also you may not see the same time savings if you don't play the rest of the level as optimal as your prior splits, so 12s might turn into 6s.
Stage 13:

Start on 7A turn around, backwards jump and turnaround to land on A4 -> A1. The a 14 frame Walk to B0 then B0 2 frame turnaround AE. Then a 14 frame walk end on BC quick left turn around (between 2-5 frames?) and then walk right.

[[File:CV1_13-SG-1.png|250px]]
[[File:CV1_13-SG-2.png|250px]]
[[File:CV1_13-SG-3.png|250px]]
[[File:CV1_13-SG-4.png|250px]]

Stage 14
Start on 2FE then backwards jump and turn and land on 328. Whip turnaround 328 -> 326, then move to and do a whip turn around 334 -> 332.

[[File:CV1_14-SG-1.png|250px]]
[[File:CV1_14-SG-2.png|250px]]
[[File:CV1_14-SG-3.png|250px]]

=== Emulator Training Tools ===
I have created a set of scroll glitch training tools (along with other cv1 helper tools). These currently require using bizhawk, although I will likely port to other emulators in the future.

https://www.speedrun.com/cv1/resources

Helpful tools included are:

1. Create lines onscreen to show turnback locations
2. Auto-death tool - kills you if you miss a scroll glitch
3. Turnback-Turnforward diagnostic printout (to highlight if you really are hitting 2-14 or 4-12)

Note, if you are using original hardware, the above tools may be a little annoying as the input latency is different. I would still recommend trying them though as many scroll glitch execution strategies are not latency sensitive.

=== Rhythm Sounds ===
If you are trying to learn a whipless rhythm approach, sounds can also be a helpful aid. You hit the buttons on the appropriate beat. Every frame is 1/60th of a second (technically 1/60.09), so you can use that to create a beat. One style is to do 4/60th of a second followed by 12/60th of a second. Another is to just have a metronome set to 16/60th of a second and time either your forward or backward presses to that beat.

Below are two videos with rhythm of whipless scroll glitch turnbacks for 4-12 pattern. To execute 4-12 wiggles, do a turnback on the short note, and move forward on the long note.

{{#ev:youtube|Zn2FFhDc5WE|550}}

{{#ev:youtube|-WG7e4nAnp4|550}}

=== Acknowledgements ===

InfoManiac
Originally discovered the scroll glitch. The initial method only worked on TAS

Challenger
Implemented almost all the current scroll glitches in TAS that have since been ported to RTA by others.

NatGoesFast
Accidently did a scroll glitch on stream. An investigation of this led to the whip based RTA strategy discussed above.

SBDWolf
Found the whip based RTA viable approach for stage 13 and stage 14. Also figured out probably 75% of the basic block updating algorithm and RTA strategies such as odd/even frames approach. Also was the first person to use these scroll glitches to get WR. (May have also found the crusher room scrollglitch).

Shockratease
Along with SBDWolf, did extensive investigation and teaching on the scroll glitch. Suggested using 16/60th beats instead of two-part beats.

Kajong0007
Created the Romhack mentioned above, which has been used extensively by runners to better learn the trick.

JayCee
First person to remove whips for turnbacks and use it in runs. The removal of whips also enabled a lot of additional scroll glitch areas (crusher, clocktower) which did not seem viable otherwise. This inspired additional scrollglitch innovations.

Trisk (tr1sklion)
Wrote this document. Found the Block Counter and Column Update Window in the game bytecode. Validated and enhanced the earlier algorithm approximation SBDWolf modeled. Wrote the Bizhawk training tools. Pioneered the 4-frame turnbacks strategy and most correction strategies.

== Videos ==

SBDWolf talking about the scroll glitches

{{#ev:youtube|rmlBCzdVlOc|550}}

{{#ev:youtube|yaRmDa_T-oo|550}}

Here's Shockra Tease talking about both Scroll Glitches

{{#ev:youtube|Dw7NkOzp8tE|550}}

Advanced Stage 14

{{#ev:youtube|zxLs7h2cL6Y|550}}

Displaced Gamers Video on the code

{{#ev:youtube|wd18YNZB0D4|550}}

Cv1/ScrollGlitch

2024-04-17T21:11:51Z

K c r: /* Training Resources */

== Breaking Dracula’s Castle 101 ==

Before delving into why the scroll glitch works and how to execute it, I recommend understanding how castlevania updates its background tiles. Once we understand this, we can find various ways to break it, as well as diagnose when the scroll glitch fails.

=== How are background tiles updated? ===

Castlevania graphics are made up of foreground sprites (simon, candles, hearts, enemies) and background tiles. The game is building up these background tiles ahead of what is actually on the screen behind the scenes so that it can scroll smoothly as Simon moves. Around half a screen offscreen, the game is drawing a column two blocks wide. When that is complete, the game moves onto the next column. It looks something like this:

[[File:CV1_ScrollGlitch1. updated.png|550px]]

=== Tile Update Algorithm ===

Step 1: Should the update algorithm run?

There is a framecounter that starts at the beginning of every screen. This is the same framecounter that powers the item drops throughout the game. The update algorithm ONLY runs every other frame. I am not certain as to why, but I would guess this is because the Nintendo is not a very powerful system and this gives it time to do other work. Even if Simon is moving forward on a non updating frame, no tile will be updated.

Step 2: Is Simon moving (left or right… doesn’t matter)?

If Simon is moving (and we are on an even frame as discussed above), the tile upgrading algorithm will run and update a tile. Otherwise, the tile updating process is skipped.

Step 3: Determine which vertical column is going to be updated

If Simon is walking left, we will select a column on the left to update. If he is walking right, the column will be to the right. Every column is 32 pixels wide. For every column, there is another set of 32 pixels around 1.5 screens away that map to that column. When Simon is walking over this set of pixels in the direction towards that column, that column will be updated. See the section “How Background Tiles are Updated” for a picture that corresponds to this mapping.

I will refer to this 32 pixel walking space as the Column Update Window.

Step 4: Determine which tiles will be updated

We are now going to choose which actual blocks on the column will be updated. The game manages a special variable called the Block Counter that determines that location. This variable maps to the tiles vertically like so:

[[File:Block_Counter_mapping.png|550px]]

The block counter has a value between 0 and 7, inclusive; however, only the values 1-6 actually map to blocks.

Here is how the algorithm works:

# Did I just enter a new “Column update window”? (One of those 32 pixel spaces you walk over)
#*If yes, no matter WHAT ( even overriding the every other frame rule described above), reset the Block counter to 0
# Update the blocks in the selected column (the direction Simon is facing) at the vertical level marked by the block counter.
#*If the counter is 0 or 7, this does nothing.
# Increment the block counter by 1
# If the block counter > 7, set the block counter to 0

=== How non-glitched walking normally works ===
A player usually just walks in one direction for a while. As they walk through a new Column Update Window, the column 1.5 screens away starts getting updated. The Column Update Window is 32 pixels wide and we update tiles every other pixel, so we will run the tile upgrading algorithm 16 times (32/2). This will cause the block counter to go from 0 -> 7 and then 0 -> 7 again. This updates every tile value twice. Updating it twice doesn’t cause any harm - it just puts the same value there.

''NOTE - Technically there is a 50% probability of it being 15 times, not 16. This is because the first value is always overridden to 0. If that happens on the tile updating frame, the counter will still be held at 0. ''

=== What causes the scroll glitch to happen? ===

This algorithm manages tile drawing in BOTH the left and right direction. However, there is only ONE block counter. If you are walking left and the tile counter is at 4 but then turn right while the block counter turns to 5, then turn left again as the block counter changes to 6, you skipped a block on the left side. You updated blockset 4 and 6 but skipped 5.

The algorithm has a correction mechanism though. Notice that we normally iterate over the blocks twice for one column update window. That block 5 will get corrected as you continue to walk left… unless you do the same turnback again. Keep repeating this turnback until you have exited the column update window and you have successfully skipped updating the block, performing a “scroll glitch”.

This glitch does not let you put any tile value you want there. You are only skipping writing a value. This means the value will be whatever was there last.

=== Removing Tile Updating RNG ===
If the block counter is only updated every other frame, it seems impossible to actually make the trick predictable. Luckily, there is a neat math trick that solves this. This is best explained with an example:

If you move 1 frame, did you move the block counter? You don’t know. There is a 50% probability you did. If you move 2 frames, did you move the block counter? You moved the counter one and only one time with 100% certainty. This is because you either updated on the first frame or the second frame. It can’t be both or neither!

The above generalizes as you walk forward more pixels. If you move an even number of pixels without stopping, you are 100% certain to have moved the block counter the number of pixels moved divided by 2. If you moved an odd number of pixels, you don’t know what the block counter is incremented to.

As a concrete example, if you walk 6 pixels forward without stopping, you definitely moved the counter up by 3. If you moved 7 pixels, you have a 50% probability of moving it by 3 and a 50% probability of moving it 4.

=== Turnback Requirements ===
As you walk through a Column Update Window, you update each block in a column twice. Given this, it would seem like you will need to execute two turnbacks. Unfortunately, this is not always the case.

When you execute a turnback, you go back two pixels, then forward two pixels. You have now incremented the block counter twice. However, you are also on the same pixel in the Column Update Window as you were before you started the turnback. This means you have essentially added two extra counter updates than a normal walkthrough. Since you have to execute the turnback a second time, you are incrementing the block counter a total of four extra times. Those four extra increments will cause you to start updating some of the higher blocks a third time!

In practice, if you execute 2 frame turnbacks, you need to do three turnbacks unless you are targeting blocks at the 5th or 6th height index in the above diagram, in which case you can continue doing 2 turnbacks.

If you execute 4 frame turnbacks, you need to do 4 turnbacks for block indexes from 1 to 3, and 3 turnbacks for indices 4-6.

Note that these are simplifications. There are scenarios where you can do fewer turnbacks if you get lucky ( a combination of turnbacks being too short but getting lucky with the frame counter). In addition, you often want to execute extra turnbacks to raise consistency (discussed later).

''TECHNICAL NOTE - This is oversimplified. There are some details around having an odd number of pixels on the last walk forward that leads to one extra counter iteration. I don’t think this is a missing aspect of the algorithm, just some tricky off-by-one math. I got frustrated and stopped trying to nail it down exactly. ''

=== Scroll Glitch Execution Approaches ===

For all strategies, there is an important starting pixel where you want to start your turnbacks. This is the pixel that will have the block counter 1 below your target block regardless of whether. You can find this pixel with visuals for each of the level 5 tricks further down this page.

=== 2 - 14 Turnback Method ===

The 2-14 method is the first RTA viable method used by runners and is still used by most. We will do a series of 2 pixel turnbacks followed by 14 pixel walk forwards.

==== Beginner Approach ====
The easiest, although slowest, method is to find a launch point to predictably get to your starting pixel. This is usually done by back jumping and changing direction midair by ducking the opposite direction. If the backjump succeeds, you will have always landed on the right starting pixel. This gives you plenty of time to make sure you pick the right jump point without breaking the glitch.

Once you have gotten to the first pixel, you need a consistent way to go back two pixels. This is usually done by turning in the backwards direction and whipping on the next possible frame. If you are late on the whip, Simon will visibly walk further. If you are early, you will move only 1 pixel back but simon will still be facing forward.

After this, walk forward 14 pixels, rinse, and repeat. Most runners learn the proper 14 pixel visual at each turnback point and practice going to each one. Pictures are on the wiki for this.

This is a slow method, but it is easier for beginners to learn, execute, and diagnose. This slowness will limit the RTA viability of the trick to stage 13, stage 14 standard, and stage 14 advanced. The others are either too risky or the time savings are largely negated by the setup time.

==== Advanced Approach ====

There are two approaches to speed this up. The first is to pick a proper jump point to land on the right starting pixel. If you recognize that you jumped a pixel early, you can duck to move one extra pixel on landing to compensate.

The second approach is to just push back for two frames and push forward for fourteen frames repeatedly without whipping. You can use the jump setup described above or just hit back on the appropriate first frame. This is currently only being executed by Jay_Cee and I don’t have good advice for how to do this outside of lots of practice.

=== Corrections and Reliability Improvements ===

==== Adjust Pixels ====

Most runners learn to target each turnback pixel. If your turnback or turn forward is off by one pixel, the trick now has a 50% chance of success. This is because you now how much you have incremented the Block Counter (see the even-odd rule in the “Removing Tile Updating RNG” section).

HOWEVER, if you proceed as normal and target the same pixels afterwards, you now cut your probability of success down to 25%. For example, if you walk backwards 3 pixels instead of 2, your walk forward will now be 15 pixels if you keep your same target. That is now effectively one more area where you may have moved the counter an extra time.

You instead want to keep your existing movements the same and only move forward 14 pixels. You should either adjust your visual cue or use a rhythm method to feel what 14 frames of movement is like and ignore all pixel targets outside of the first one.

If you moved backwards more than 3 pixels, you definitely moved the counter more than you wanted. It can be saved but only by switching mid-run to the 4-12 turnback method (discussed later).

If you walked forward 2 pixels beyond your target pixel, unless you messed something earlier, the tile you wanted has been locked into a new value and the trick is dead.

==== Extra Turnback ====

As you get closer to the end of the Column Update Window, there are a few additional tweaks that can help save a dead scrollglitch attempt. For example, you may want to consider adding a 3rd turnback for the stage 14 scrollglitch.

For that glitch, unlike stage 13, the block counter doesn’t loop around for a 3rd time to that lower tile, so only two turnbacks are necessary. However, the counter ALMOST makes it there. If you have 3 pixel turnbacks instead of 2 or start the turnbacks slightly early, you are walking more in the Column Update Window after the final turnback. This can increment the block counter more and update your tile, even if you succeeded on the first two turnbacks.

Given this, you can consider adding one extra turnback as an insurance policy. For the 2-14 turnbacks, this is usually most relevant for the stage 14 wall glitch. For higher blocks like the stage 13 glitch, it is very unlikely that it will be able to make an extra loop, so I would not recommend it there.

=== Lenient Final Turnback ===

The above extra turnback is valuable when the normal final turnback is far away from the end of the Column Update Window. However, for some tricks, the final turnback is very close to the end of the Column Update Window. Stage 13 is a great example of this. That closeness creates extra leniency that we can take advantage of.

When normally doing the scroll glitch, let's assume you make a mistake. Instead of going back two pixels, you go back four. You have moved the counter two times. Your target block was not updated, so the trick is still alive; however, the trick is now out of alignment. If you move forward the normal 14 pixels, the trick will be ripped. HOWEVER, if this turnback was close to the end of the Column Update Window, you will escape before you walk 14 pixels. This means a 4 pixel turnback will not rip the final turnback on stage 13!

In fact, I would RECOMMEND doing a 4 pixel turnback on your final turnback here. The reason is you are skipping over two blocks on that last turnback. So if, for example, the block counter is 1 behind due to an earlier mistake, your run would normally be ripped on the final turnback. However, by moving the counter twice at the end, you protected yourself. In fact, this can move the 50% probability of success back to 100%. The block counter could have one of two possible values, and you handle both cases with one turnback.

You should do the 4 pixel turnback after walking 14 pixels if you think the counter is one behind. If you think the counter is one ahead, you should walk forward 12 pixels and then do the 4 pixel turnback. I highly recommend adding one of these approaches to your final turnback on stage 13. If you are adding an EXTRA turnback, as discussed above, the same leniency rule will apply there.

=== 4-12 Turnback Method ===

The leniency property on the last turnback can actually be applied to all turnbacks. Instead of doing 2-14 pixel turnbacks, you can execute 4-12 pixel turnbacks everywhere. This is my preferred technique.

By going back 4 pixels, you are actually skipping two blocks, not one. You don’t need to move two blocks; however, this can provide an extra buffer in case you make a mistake. For the 2-14 pixel approach, if you are off by 1 pixel, the success rate drops to 50%. If you are ever off by more than 1 pixel, the success rate is 0% unless you get lucky and make a countering mistake elsewhere.

For the 4-12 approach, if you are off by 1 pixel, you have a 50% probability for one of the blocks to be overridden. However, assuming the direction you are off is random, you have a 50% chance of that block being the one you care about. So now you have around a 75% probability of success even if you make a 1 pixel mistake. Furthermore, if you make a 2 pixel mistake, you still have a 50% probability of success. A 3 pixel mistake lowers you to around a 25% chance.

While the above math is just a rough approximation, this method has generally seemed more lenient than the 2-14 approach. In addition, if you are doing the whipless turnback technique, at least for me, it is much easier to consistently do a 4 pixel turnback instead of a 2 pixel one. You learn the back and forth d-pad rhythm and the trick can become quite consistent.

Unfortunately, this approach does have a few downsides. First, each turnback will cost an extra 4 frames. In addition, you will often have to do one extra turnback relative to the two pixel turnback. If targeting block 2 or 3, I would recommend 4 turnbacks. Anything below that, I would recommend 3 turnbacks.

=== Training Resources ===
ROMHack - A romhack is available on the CV1 discord. When used, it will print out Simon’s pixel coordinates. In addition, it will print the Block Counter.

The starting pixel coordinates for the scroll glitches are:

{| class="wikitable" style="margin:auto"
|+
|-
! Stage Number !! Pixel !! Savings
|-
| Stage 6 Crusher || 1D9 & 1B9 || ~9 sec
|-
| Stage 7 Coffee || 255 & 1F9 ||
|-
| Stage 13 || A4 || ~12.5 sec
|-
| Stage 14 Bacon || 45C or 43D ||
|-
| Stage 14 Egg || 2C4* ||
|-
| Stage 14 Cheese || 328 || ~8 sec
|-
| Stage 17 Clocktower || 219 & 1FB ||
|}

<nowiki>*</nowiki>Touching pixel 2B9 is needed before turning around

Stage 13:

Start on 7A turn around, backwards jump and turnaround to land on A4 -> A1. The a 14 frame Walk to B0 then B0 2 frame turnaround AE. Then a 14 frame walk end on BC quick left turn around (between 2-5 frames?) and then walk right.

[[File:CV1_13-SG-1.png|250px]]
[[File:CV1_13-SG-2.png|250px]]
[[File:CV1_13-SG-3.png|250px]]
[[File:CV1_13-SG-4.png|250px]]

Stage 14
Start on 2FE then backwards jump and turn and land on 328. Whip turnaround 328 -> 326, then move to and do a whip turn around 334 -> 332.

[[File:CV1_14-SG-1.png|250px]]
[[File:CV1_14-SG-2.png|250px]]
[[File:CV1_14-SG-3.png|250px]]

=== Emulator Training Tools ===
I have created a set of scroll glitch training tools (along with other cv1 helper tools). These currently require using bizhawk, although I will likely port to other emulators in the future.

https://www.speedrun.com/cv1/resources

Helpful tools included are:

1. Create lines onscreen to show turnback locations
2. Auto-death tool - kills you if you miss a scroll glitch
3. Turnback-Turnforward diagnostic printout (to highlight if you really are hitting 2-14 or 4-12)

Note, if you are using original hardware, the above tools may be a little annoying as the input latency is different. I would still recommend trying them though as many scroll glitch execution strategies are not latency sensitive.

=== Rhythm Sounds ===
If you are trying to learn a whipless rhythm approach, sounds can also be a helpful aid. You hit the buttons on the appropriate beat. Every frame is 1/60th of a second (technically 1/60.09), so you can use that to create a beat. One style is to do 4/60th of a second followed by 12/60th of a second. Another is to just have a metronome set to 16/60th of a second and time either your forward or backward presses to that beat.

Below are two videos with rhythm of whipless scroll glitch turnbacks for 4-12 pattern. To execute 4-12 wiggles, do a turnback on the short note, and move forward on the long note.

{{#ev:youtube|Zn2FFhDc5WE|550}}

{{#ev:youtube|-WG7e4nAnp4|550}}

=== Acknowledgements ===

InfoManiac
Originally discovered the scroll glitch. The initial method only worked on TAS

Challenger
Implemented almost all the current scroll glitches in TAS that have since been ported to RTA by others.

NatGoesFast
Accidently did a scroll glitch on stream. An investigation of this led to the whip based RTA strategy discussed above.

SBDWolf
Found the whip based RTA viable approach for stage 13 and stage 14. Also figured out probably 75% of the basic block updating algorithm and RTA strategies such as odd/even frames approach. Also was the first person to use these scroll glitches to get WR. (May have also found the crusher room scrollglitch).

Shockratease
Along with SBDWolf, did extensive investigation and teaching on the scroll glitch. Suggested using 16/60th beats instead of two-part beats.

Kajong0007
Created the Romhack mentioned above, which has been used extensively by runners to better learn the trick.

JayCee
First person to remove whips for turnbacks and use it in runs. The removal of whips also enabled a lot of additional scroll glitch areas (crusher, clocktower) which did not seem viable otherwise. This inspired additional scrollglitch innovations.

Trisk (tr1sklion)
Wrote this document. Found the Block Counter and Column Update Window in the game bytecode. Validated and enhanced the earlier algorithm approximation SBDWolf modeled. Wrote the Bizhawk training tools. Pioneered the 4-frame turnbacks strategy and most correction strategies.

== Videos ==

SBDWolf talking about the scroll glitches

{{#ev:youtube|rmlBCzdVlOc|550}}

{{#ev:youtube|yaRmDa_T-oo|550}}

Here's Shockra Tease talking about both Scroll Glitches

{{#ev:youtube|Dw7NkOzp8tE|550}}

Advanced Stage 14

{{#ev:youtube|zxLs7h2cL6Y|550}}

Displaced Gamers Video on the code

{{#ev:youtube|wd18YNZB0D4|550}}

Cv1/ScrollGlitch

2024-04-17T21:05:35Z

K c r:

== Breaking Dracula’s Castle 101 ==

Before delving into why the scroll glitch works and how to execute it, I recommend understanding how castlevania updates its background tiles. Once we understand this, we can find various ways to break it, as well as diagnose when the scroll glitch fails.

=== How are background tiles updated? ===

Castlevania graphics are made up of foreground sprites (simon, candles, hearts, enemies) and background tiles. The game is building up these background tiles ahead of what is actually on the screen behind the scenes so that it can scroll smoothly as Simon moves. Around half a screen offscreen, the game is drawing a column two blocks wide. When that is complete, the game moves onto the next column. It looks something like this:

[[File:CV1_ScrollGlitch1. updated.png|550px]]

=== Tile Update Algorithm ===

Step 1: Should the update algorithm run?

There is a framecounter that starts at the beginning of every screen. This is the same framecounter that powers the item drops throughout the game. The update algorithm ONLY runs every other frame. I am not certain as to why, but I would guess this is because the Nintendo is not a very powerful system and this gives it time to do other work. Even if Simon is moving forward on a non updating frame, no tile will be updated.

Step 2: Is Simon moving (left or right… doesn’t matter)?

If Simon is moving (and we are on an even frame as discussed above), the tile upgrading algorithm will run and update a tile. Otherwise, the tile updating process is skipped.

Step 3: Determine which vertical column is going to be updated

If Simon is walking left, we will select a column on the left to update. If he is walking right, the column will be to the right. Every column is 32 pixels wide. For every column, there is another set of 32 pixels around 1.5 screens away that map to that column. When Simon is walking over this set of pixels in the direction towards that column, that column will be updated. See the section “How Background Tiles are Updated” for a picture that corresponds to this mapping.

I will refer to this 32 pixel walking space as the Column Update Window.

Step 4: Determine which tiles will be updated

We are now going to choose which actual blocks on the column will be updated. The game manages a special variable called the Block Counter that determines that location. This variable maps to the tiles vertically like so:

[[File:Block_Counter_mapping.png|550px]]

The block counter has a value between 0 and 7, inclusive; however, only the values 1-6 actually map to blocks.

Here is how the algorithm works:

# Did I just enter a new “Column update window”? (One of those 32 pixel spaces you walk over)
#*If yes, no matter WHAT ( even overriding the every other frame rule described above), reset the Block counter to 0
# Update the blocks in the selected column (the direction Simon is facing) at the vertical level marked by the block counter.
#*If the counter is 0 or 7, this does nothing.
# Increment the block counter by 1
# If the block counter > 7, set the block counter to 0

=== How non-glitched walking normally works ===
A player usually just walks in one direction for a while. As they walk through a new Column Update Window, the column 1.5 screens away starts getting updated. The Column Update Window is 32 pixels wide and we update tiles every other pixel, so we will run the tile upgrading algorithm 16 times (32/2). This will cause the block counter to go from 0 -> 7 and then 0 -> 7 again. This updates every tile value twice. Updating it twice doesn’t cause any harm - it just puts the same value there.

''NOTE - Technically there is a 50% probability of it being 15 times, not 16. This is because the first value is always overridden to 0. If that happens on the tile updating frame, the counter will still be held at 0. ''

=== What causes the scroll glitch to happen? ===

This algorithm manages tile drawing in BOTH the left and right direction. However, there is only ONE block counter. If you are walking left and the tile counter is at 4 but then turn right while the block counter turns to 5, then turn left again as the block counter changes to 6, you skipped a block on the left side. You updated blockset 4 and 6 but skipped 5.

The algorithm has a correction mechanism though. Notice that we normally iterate over the blocks twice for one column update window. That block 5 will get corrected as you continue to walk left… unless you do the same turnback again. Keep repeating this turnback until you have exited the column update window and you have successfully skipped updating the block, performing a “scroll glitch”.

This glitch does not let you put any tile value you want there. You are only skipping writing a value. This means the value will be whatever was there last.

=== Removing Tile Updating RNG ===
If the block counter is only updated every other frame, it seems impossible to actually make the trick predictable. Luckily, there is a neat math trick that solves this. This is best explained with an example:

If you move 1 frame, did you move the block counter? You don’t know. There is a 50% probability you did. If you move 2 frames, did you move the block counter? You moved the counter one and only one time with 100% certainty. This is because you either updated on the first frame or the second frame. It can’t be both or neither!

The above generalizes as you walk forward more pixels. If you move an even number of pixels without stopping, you are 100% certain to have moved the block counter the number of pixels moved divided by 2. If you moved an odd number of pixels, you don’t know what the block counter is incremented to.

As a concrete example, if you walk 6 pixels forward without stopping, you definitely moved the counter up by 3. If you moved 7 pixels, you have a 50% probability of moving it by 3 and a 50% probability of moving it 4.

=== Turnback Requirements ===
As you walk through a Column Update Window, you update each block in a column twice. Given this, it would seem like you will need to execute two turnbacks. Unfortunately, this is not always the case.

When you execute a turnback, you go back two pixels, then forward two pixels. You have now incremented the block counter twice. However, you are also on the same pixel in the Column Update Window as you were before you started the turnback. This means you have essentially added two extra counter updates than a normal walkthrough. Since you have to execute the turnback a second time, you are incrementing the block counter a total of four extra times. Those four extra increments will cause you to start updating some of the higher blocks a third time!

In practice, if you execute 2 frame turnbacks, you need to do three turnbacks unless you are targeting blocks at the 5th or 6th height index in the above diagram, in which case you can continue doing 2 turnbacks.

If you execute 4 frame turnbacks, you need to do 4 turnbacks for block indexes from 1 to 3, and 3 turnbacks for indices 4-6.

Note that these are simplifications. There are scenarios where you can do fewer turnbacks if you get lucky ( a combination of turnbacks being too short but getting lucky with the frame counter). In addition, you often want to execute extra turnbacks to raise consistency (discussed later).

''TECHNICAL NOTE - This is oversimplified. There are some details around having an odd number of pixels on the last walk forward that leads to one extra counter iteration. I don’t think this is a missing aspect of the algorithm, just some tricky off-by-one math. I got frustrated and stopped trying to nail it down exactly. ''

=== Scroll Glitch Execution Approaches ===

For all strategies, there is an important starting pixel where you want to start your turnbacks. This is the pixel that will have the block counter 1 below your target block regardless of whether. You can find this pixel with visuals for each of the level 5 tricks further down this page.

=== 2 - 14 Turnback Method ===

The 2-14 method is the first RTA viable method used by runners and is still used by most. We will do a series of 2 pixel turnbacks followed by 14 pixel walk forwards.

==== Beginner Approach ====
The easiest, although slowest, method is to find a launch point to predictably get to your starting pixel. This is usually done by back jumping and changing direction midair by ducking the opposite direction. If the backjump succeeds, you will have always landed on the right starting pixel. This gives you plenty of time to make sure you pick the right jump point without breaking the glitch.

Once you have gotten to the first pixel, you need a consistent way to go back two pixels. This is usually done by turning in the backwards direction and whipping on the next possible frame. If you are late on the whip, Simon will visibly walk further. If you are early, you will move only 1 pixel back but simon will still be facing forward.

After this, walk forward 14 pixels, rinse, and repeat. Most runners learn the proper 14 pixel visual at each turnback point and practice going to each one. Pictures are on the wiki for this.

This is a slow method, but it is easier for beginners to learn, execute, and diagnose. This slowness will limit the RTA viability of the trick to stage 13, stage 14 standard, and stage 14 advanced. The others are either too risky or the time savings are largely negated by the setup time.

==== Advanced Approach ====

There are two approaches to speed this up. The first is to pick a proper jump point to land on the right starting pixel. If you recognize that you jumped a pixel early, you can duck to move one extra pixel on landing to compensate.

The second approach is to just push back for two frames and push forward for fourteen frames repeatedly without whipping. You can use the jump setup described above or just hit back on the appropriate first frame. This is currently only being executed by Jay_Cee and I don’t have good advice for how to do this outside of lots of practice.

=== Corrections and Reliability Improvements ===

==== Adjust Pixels ====

Most runners learn to target each turnback pixel. If your turnback or turn forward is off by one pixel, the trick now has a 50% chance of success. This is because you now how much you have incremented the Block Counter (see the even-odd rule in the “Removing Tile Updating RNG” section).

HOWEVER, if you proceed as normal and target the same pixels afterwards, you now cut your probability of success down to 25%. For example, if you walk backwards 3 pixels instead of 2, your walk forward will now be 15 pixels if you keep your same target. That is now effectively one more area where you may have moved the counter an extra time.

You instead want to keep your existing movements the same and only move forward 14 pixels. You should either adjust your visual cue or use a rhythm method to feel what 14 frames of movement is like and ignore all pixel targets outside of the first one.

If you moved backwards more than 3 pixels, you definitely moved the counter more than you wanted. It can be saved but only by switching mid-run to the 4-12 turnback method (discussed later).

If you walked forward 2 pixels beyond your target pixel, unless you messed something earlier, the tile you wanted has been locked into a new value and the trick is dead.

==== Extra Turnback ====

As you get closer to the end of the Column Update Window, there are a few additional tweaks that can help save a dead scrollglitch attempt. For example, you may want to consider adding a 3rd turnback for the stage 14 scrollglitch.

For that glitch, unlike stage 13, the block counter doesn’t loop around for a 3rd time to that lower tile, so only two turnbacks are necessary. However, the counter ALMOST makes it there. If you have 3 pixel turnbacks instead of 2 or start the turnbacks slightly early, you are walking more in the Column Update Window after the final turnback. This can increment the block counter more and update your tile, even if you succeeded on the first two turnbacks.

Given this, you can consider adding one extra turnback as an insurance policy. For the 2-14 turnbacks, this is usually most relevant for the stage 14 wall glitch. For higher blocks like the stage 13 glitch, it is very unlikely that it will be able to make an extra loop, so I would not recommend it there.

=== Lenient Final Turnback ===

The above extra turnback is valuable when the normal final turnback is far away from the end of the Column Update Window. However, for some tricks, the final turnback is very close to the end of the Column Update Window. Stage 13 is a great example of this. That closeness creates extra leniency that we can take advantage of.

When normally doing the scroll glitch, let's assume you make a mistake. Instead of going back two pixels, you go back four. You have moved the counter two times. Your target block was not updated, so the trick is still alive; however, the trick is now out of alignment. If you move forward the normal 14 pixels, the trick will be ripped. HOWEVER, if this turnback was close to the end of the Column Update Window, you will escape before you walk 14 pixels. This means a 4 pixel turnback will not rip the final turnback on stage 13!

In fact, I would RECOMMEND doing a 4 pixel turnback on your final turnback here. The reason is you are skipping over two blocks on that last turnback. So if, for example, the block counter is 1 behind due to an earlier mistake, your run would normally be ripped on the final turnback. However, by moving the counter twice at the end, you protected yourself. In fact, this can move the 50% probability of success back to 100%. The block counter could have one of two possible values, and you handle both cases with one turnback.

You should do the 4 pixel turnback after walking 14 pixels if you think the counter is one behind. If you think the counter is one ahead, you should walk forward 12 pixels and then do the 4 pixel turnback. I highly recommend adding one of these approaches to your final turnback on stage 13. If you are adding an EXTRA turnback, as discussed above, the same leniency rule will apply there.

=== 4-12 Turnback Method ===

The leniency property on the last turnback can actually be applied to all turnbacks. Instead of doing 2-14 pixel turnbacks, you can execute 4-12 pixel turnbacks everywhere. This is my preferred technique.

By going back 4 pixels, you are actually skipping two blocks, not one. You don’t need to move two blocks; however, this can provide an extra buffer in case you make a mistake. For the 2-14 pixel approach, if you are off by 1 pixel, the success rate drops to 50%. If you are ever off by more than 1 pixel, the success rate is 0% unless you get lucky and make a countering mistake elsewhere.

For the 4-12 approach, if you are off by 1 pixel, you have a 50% probability for one of the blocks to be overridden. However, assuming the direction you are off is random, you have a 50% chance of that block being the one you care about. So now you have around a 75% probability of success even if you make a 1 pixel mistake. Furthermore, if you make a 2 pixel mistake, you still have a 50% probability of success. A 3 pixel mistake lowers you to around a 25% chance.

While the above math is just a rough approximation, this method has generally seemed more lenient than the 2-14 approach. In addition, if you are doing the whipless turnback technique, at least for me, it is much easier to consistently do a 4 pixel turnback instead of a 2 pixel one. You learn the back and forth d-pad rhythm and the trick can become quite consistent.

Unfortunately, this approach does have a few downsides. First, each turnback will cost an extra 4 frames. In addition, you will often have to do one extra turnback relative to the two pixel turnback. If targeting block 2 or 3, I would recommend 4 turnbacks. Anything below that, I would recommend 3 turnbacks.

=== Training Resources ===
ROMHack - A romhack is available on the CV1 discord. When used, it will print out Simon’s pixel coordinates. In addition, it will print the Block Counter.

The starting pixel coordinates for the scroll glitches are:

{| class="wikitable" style="margin:auto"
|+
|-
! Stage Number !! Pixel !! Savings
|-
| Stage 6 Crusher || 1D9 & 1B9
|-
| Stage 7 || 255 & 1F9
|-
| Stage 13 || A4
|-
| Stage 14 Wall || 328
|-
| Stage 14 Ceiling Drop || 45C or 43D
|-
| Stage 14 Advanced || 2C4*
|-
| Stage 17 Clocktower || 219 & 1FB
|}

<nowiki>*</nowiki>Touching pixel 2B9 is needed before turning around

Stage 13:

Start on 7A turn around, backwards jump and turnaround to land on A4 -> A1. The a 14 frame Walk to B0 then B0 2 frame turnaround AE. Then a 14 frame walk end on BC quick left turn around (between 2-5 frames?) and then walk right.

[[File:CV1_13-SG-1.png|250px]]
[[File:CV1_13-SG-2.png|250px]]
[[File:CV1_13-SG-3.png|250px]]
[[File:CV1_13-SG-4.png|250px]]

Stage 14
Start on 2FE then backwards jump and turn and land on 328. Whip turnaround 328 -> 326, then move to and do a whip turn around 334 -> 332.

[[File:CV1_14-SG-1.png|250px]]
[[File:CV1_14-SG-2.png|250px]]
[[File:CV1_14-SG-3.png|250px]]

=== Emulator Training Tools ===
I have created a set of scroll glitch training tools (along with other cv1 helper tools). These currently require using bizhawk, although I will likely port to other emulators in the future.

https://www.speedrun.com/cv1/resources

Helpful tools included are:

1. Create lines onscreen to show turnback locations
2. Auto-death tool - kills you if you miss a scroll glitch
3. Turnback-Turnforward diagnostic printout (to highlight if you really are hitting 2-14 or 4-12)

Note, if you are using original hardware, the above tools may be a little annoying as the input latency is different. I would still recommend trying them though as many scroll glitch execution strategies are not latency sensitive.

=== Rhythm Sounds ===
If you are trying to learn a whipless rhythm approach, sounds can also be a helpful aid. You hit the buttons on the appropriate beat. Every frame is 1/60th of a second (technically 1/60.09), so you can use that to create a beat. One style is to do 4/60th of a second followed by 12/60th of a second. Another is to just have a metronome set to 16/60th of a second and time either your forward or backward presses to that beat.

Below are two videos with rhythm of whipless scroll glitch turnbacks for 4-12 pattern. To execute 4-12 wiggles, do a turnback on the short note, and move forward on the long note.

{{#ev:youtube|Zn2FFhDc5WE|550}}

{{#ev:youtube|-WG7e4nAnp4|550}}

=== Acknowledgements ===

InfoManiac
Originally discovered the scroll glitch. The initial method only worked on TAS

Challenger
Implemented almost all the current scroll glitches in TAS that have since been ported to RTA by others.

NatGoesFast
Accidently did a scroll glitch on stream. An investigation of this led to the whip based RTA strategy discussed above.

SBDWolf
Found the whip based RTA viable approach for stage 13 and stage 14. Also figured out probably 75% of the basic block updating algorithm and RTA strategies such as odd/even frames approach. Also was the first person to use these scroll glitches to get WR. (May have also found the crusher room scrollglitch).

Shockratease
Along with SBDWolf, did extensive investigation and teaching on the scroll glitch. Suggested using 16/60th beats instead of two-part beats.

Kajong0007
Created the Romhack mentioned above, which has been used extensively by runners to better learn the trick.

JayCee
First person to remove whips for turnbacks and use it in runs. The removal of whips also enabled a lot of additional scroll glitch areas (crusher, clocktower) which did not seem viable otherwise. This inspired additional scrollglitch innovations.

Trisk (tr1sklion)
Wrote this document. Found the Block Counter and Column Update Window in the game bytecode. Validated and enhanced the earlier algorithm approximation SBDWolf modeled. Wrote the Bizhawk training tools. Pioneered the 4-frame turnbacks strategy and most correction strategies.

== Videos ==

SBDWolf talking about the scroll glitches

{{#ev:youtube|rmlBCzdVlOc|550}}

{{#ev:youtube|yaRmDa_T-oo|550}}

Here's Shockra Tease talking about both Scroll Glitches

{{#ev:youtube|Dw7NkOzp8tE|550}}

Advanced Stage 14

{{#ev:youtube|zxLs7h2cL6Y|550}}

Displaced Gamers Video on the code

{{#ev:youtube|wd18YNZB0D4|550}}

Cv1/dracula

2024-03-01T03:55:04Z

K c r: /* Drac Crit Chart */

{{Infobox level
| image = CV1 Drac.png
| game = Castlevania
| level_name = 6
| level_sections = Dracula
| previous = [[cv1/level6 | Level 6]]
| next = None
}}

This article is a heavy WIP - for anything beyond basic to intermediate strategies please refer to SBD Wolf's World Record strat video https://www.twitch.tv/videos/1048136981

== <span class="mw-customtoggle-0" style="font-size:large; display:inline-block; float:right;"><span class="mw-customtoggletext">[Show/Hide]</span></span> Phase 1 ==
<div id="mw-customcollapsible-0" class="mw-collapsible mw-collapsed">
=== Simple ===
<span style="color:#00FF00">Recommended to newcomers</span><br />
(Video Link)
*3-cycle attempt with 5-cycle backup
*Explain left-right switching, how spawns and fireball patterns work

=== 2-Cycle: Descending Crit ===
{{#ev:youtube|o31bSltaYh0|550}}
*Easier to learn
*Thoroughly explain movements and visual cues
*Optional whip buffer (not recommended)
*Frame perfect descending crit variant to keep it simple and let people focus on movement
*3-Cycle backup (maybe put this section under backups?)
*Refer to backups if missed backward jump
*If fast pattern, either fall back on old school 3-cycle attempt, or refer to the Pause Buffer Section

=== 2-Cycle: Ascending Crit ===
{{#ev:youtube|QHU4UGNDVII|550}}
*More difficult to learn, but more lenient
*Thoroughly explain movements and visual cues
*Optional whip buffer (not recommended)
*Explain Ascending Whip setup (aim for 2-frame stagger pixels)
*3-Cycle backup (maybe put this section under backups?)
*Refer to backups if missed backward jump
*If fast pattern, either fall back on old school 3-cycle attempt, or refer to the Pause Buffer Section

=== Fast Pattern 2-Cycle: Pause Buffer ===
{{#ev:youtube|XwwtLf4ptXg|550}}
*Give frame number
*Append this chart:
<div class="toccolours mw-collapsible mw-collapsed" style="width:560px">
'''Pause Buffer Patterns'''
<div class="mw-collapsible-content">
"x frames pause" means pressing start once, and repressing it to unpause x frames later.
These spawns happen if Simon does the 2-cycle movement after a pause buffer on the fast pattern.
-2 frames pause: normal 2-cycle spawn that we're used to, but attack speed seems RNG.
-3 frames pause: Dracula spawns just left of the mid-left candle.
-4 frames pause: Dracula spawns just right of the leftmost candle.
-5 frames pause: Dracula spawns on top of Simon, hitting him.
-6 frames pause: Dracula spawns on top of Simon, hitting him (same as 5 frames pause).
-7 frames pause: Dracula spawns just right of the leftmost candle.
-8 frames pause: Dracula spawns just right of the mid-left candle.
-9 frames pause: Dracula spawns on the far right. Attack speed seems RNG.
-10 frames pause: Normal 2-cycle spawn. Fixed attack speed. Aim for this one.
-11 frames pause: Dracula spawns just left of the mid-left candle.
-12 frames pause: Dracula spawns just right of the leftmost candle.
-13 frames pause: Dracula spawns on top of Simon, hitting him.
-14 frames pause: Dracula spawns on top of Simon, hitting him. (same as 13 frames pause).
-15 frames pause: Dracula spawns just right of the leftmost candle.
-16 frames pause: Dracula spawns just right of the mid-left candle.
-17 frames pause: Dracula spawns on the far right. Attack speed might be fixed here.
-18 frames pause: Normal 2-cycle spawn.
Seems to continue on this pattern.
</div>
</div>
*Explain how to go about the fight if missed pause buffer

=== Hitless 3-Cycle ===
{{#ev:youtube|v_QSCyZhVYs|550}}
*Explanation

=== Backups ===
==== Missed Crit on 2-Cycle Strat ====
{{#ev:youtube|c9K-M_DSRqI|550}}
*Refresh rate in the video makes it a little unclear where Simon should be positioned for the backup. Here is the general location.
[[File:Drac_2-cycle_backup1_position.png|280px]]

==== Missed Backward Jump on 2-cycle Strat ====
{{#ev:youtube|-iMQ7BA1KpE|550}}
*Ideally you react in time to missing the backward jump and you stop throwing crosses, which would break the candles on the left. If you do break those candles, you will have to fight the cookie monster with a single shot holy water or even with the cross.
==== Death Recovery ====
(Video Link)

</div>

== <span class="mw-customtoggle-1" style="font-size:large; display:inline-block; float:right;"><span class="mw-customtoggletext">[Show/Hide]</span></span> Phase 2 ==
<div id="mw-customcollapsible-1" class="mw-collapsible mw-collapsed">
=== Standard After 3-Cycle ===
{{#ev:youtube|-BPHCKCNeLE|550}}
*You ideally want to have 12-14 hearts at the beginning of Phase 2 for this strat
*Pickup holy water and triple multiplier and position yourself approximately 1 whip length from Dracula
**The whip before the transformation is used to both gauge this distance and for a timing mechanism
*You can get 2 jump whips in before the first available jump
**Be sure to hold B after the 2nd whip. This will manipulate Drac into a quick short hop.
*Once landed, stun Drac with a holy water while it is in the crounched position
*Begin with a jump whip followed by a holy water while falling to chain the stun lock
*The holy water will deal damage to Drac as long as it passes through its head
**If you miss a jump whip, ensure that you still throw a holy water to maintain the stun lock

=== Standard After 4-Cycle or higher ===
*Same strat as Standard After 3-cycle, you will just be setting up wherever you end up killing Drac in Phase 1

=== Standard After 2-Cycle ===
==== Simple Opening ====
{{#ev:youtube|sMh89DRJDIs|550}}
*Easy 2-hit cross opening. Hold B after throwing the second cross to force the early jump.
==== Intermediate Opening ====
{{#ev:youtube|Cy8WFw0gDjc|550}}
*3-hit cross opening. For the second cross throw, press right, release, then jump to avoid getting a forward jump towards Cookie. Hold B after the second cross.
==== Optimal Opening ====
{{#ev:youtube|TbAekcTp7ww|550}}
*4-hit cross opening. Requires a just-frame backjump input for the first cross. Hold B after whipping the Holy Water candle.

=== Drac Crit Chart ===
[[File:Dracula_rising_crit_map.png|thumb|500px]]

=== Tyson Cookie ===
{{#ev:youtube|JyGAiRkEcmY|550}}
*This can be done after any Phase 1 and after any opening.
*Requires fewer hearts. You can skip a big heart at the end of Stage 17 if good pattern on 17-2 fleamen.
*Think of each jump whip and falling whip as a set. Each whip input of each set of whips (jump whips and down whips) are frame perfect.
**The first whip needs to be staggered 1 frame after your jump input, and the falling whip needs to be input exactly 22 frames after the first whip input in order to connect.
**If you jump and get no whip, your jump and whip inputs were on the same frame
**If you input a second whip, but it did not come out, your input was early.
*Note the pink hit markers for each whip. If you do not see a hit marker for your falling whip, it did not deal damage and was too slow.
*Only worth going for if you can consistently get 4 or more sets of tyson whips, otherwise this loses time over the standard (Machine gun) strat.

=== Backups ===
==== Double Shot Fight ====
<span style="color:#00FF00">Recommended to newcomers</span><br />
{{#ev:youtube|x-RYQRIkWMk|550}}
*This can also be used if you lack the hearts for the Standard Kill (Machine Gun)
*You can get in 2 jump whips per holy water

==== Single Shot Fight ====
{{#ev:youtube|szRuYKjnzwU|550}}
*Recommend stunning immediately
*You can get in 3 jump whips per holy water
*When attacking, tap B for as little as possible to reduce the chances of the Cookie Monster jumping.
*If Cookie Monster poises to jump (raises arms/one leg), do NOT finish your current set of jump whips. Move to a safe distance and re-apply holy water stun lock.
</div>

== <span class="mw-customtoggle-2" style="font-size:large; display:inline-block; float:right;"><span class="mw-customtoggletext">[Show/Hide]</span></span> 2snek Beginner/Race Video Guide ==
<div id="mw-customcollapsible-2" class="mw-collapsible mw-collapsed">

{{#ev:youtube|ZZ4LA2dM5Ro|550}}

</div>

Cv1/dracula

2024-03-01T03:54:05Z

K c r: /* Drac Crit Chart */

{{Infobox level
| image = CV1 Drac.png
| game = Castlevania
| level_name = 6
| level_sections = Dracula
| previous = [[cv1/level6 | Level 6]]
| next = None
}}

This article is a heavy WIP - for anything beyond basic to intermediate strategies please refer to SBD Wolf's World Record strat video https://www.twitch.tv/videos/1048136981

== <span class="mw-customtoggle-0" style="font-size:large; display:inline-block; float:right;"><span class="mw-customtoggletext">[Show/Hide]</span></span> Phase 1 ==
<div id="mw-customcollapsible-0" class="mw-collapsible mw-collapsed">
=== Simple ===
<span style="color:#00FF00">Recommended to newcomers</span><br />
(Video Link)
*3-cycle attempt with 5-cycle backup
*Explain left-right switching, how spawns and fireball patterns work

=== 2-Cycle: Descending Crit ===
{{#ev:youtube|o31bSltaYh0|550}}
*Easier to learn
*Thoroughly explain movements and visual cues
*Optional whip buffer (not recommended)
*Frame perfect descending crit variant to keep it simple and let people focus on movement
*3-Cycle backup (maybe put this section under backups?)
*Refer to backups if missed backward jump
*If fast pattern, either fall back on old school 3-cycle attempt, or refer to the Pause Buffer Section

=== 2-Cycle: Ascending Crit ===
{{#ev:youtube|QHU4UGNDVII|550}}
*More difficult to learn, but more lenient
*Thoroughly explain movements and visual cues
*Optional whip buffer (not recommended)
*Explain Ascending Whip setup (aim for 2-frame stagger pixels)
*3-Cycle backup (maybe put this section under backups?)
*Refer to backups if missed backward jump
*If fast pattern, either fall back on old school 3-cycle attempt, or refer to the Pause Buffer Section

=== Fast Pattern 2-Cycle: Pause Buffer ===
{{#ev:youtube|XwwtLf4ptXg|550}}
*Give frame number
*Append this chart:
<div class="toccolours mw-collapsible mw-collapsed" style="width:560px">
'''Pause Buffer Patterns'''
<div class="mw-collapsible-content">
"x frames pause" means pressing start once, and repressing it to unpause x frames later.
These spawns happen if Simon does the 2-cycle movement after a pause buffer on the fast pattern.
-2 frames pause: normal 2-cycle spawn that we're used to, but attack speed seems RNG.
-3 frames pause: Dracula spawns just left of the mid-left candle.
-4 frames pause: Dracula spawns just right of the leftmost candle.
-5 frames pause: Dracula spawns on top of Simon, hitting him.
-6 frames pause: Dracula spawns on top of Simon, hitting him (same as 5 frames pause).
-7 frames pause: Dracula spawns just right of the leftmost candle.
-8 frames pause: Dracula spawns just right of the mid-left candle.
-9 frames pause: Dracula spawns on the far right. Attack speed seems RNG.
-10 frames pause: Normal 2-cycle spawn. Fixed attack speed. Aim for this one.
-11 frames pause: Dracula spawns just left of the mid-left candle.
-12 frames pause: Dracula spawns just right of the leftmost candle.
-13 frames pause: Dracula spawns on top of Simon, hitting him.
-14 frames pause: Dracula spawns on top of Simon, hitting him. (same as 13 frames pause).
-15 frames pause: Dracula spawns just right of the leftmost candle.
-16 frames pause: Dracula spawns just right of the mid-left candle.
-17 frames pause: Dracula spawns on the far right. Attack speed might be fixed here.
-18 frames pause: Normal 2-cycle spawn.
Seems to continue on this pattern.
</div>
</div>
*Explain how to go about the fight if missed pause buffer

=== Hitless 3-Cycle ===
{{#ev:youtube|v_QSCyZhVYs|550}}
*Explanation

=== Backups ===
==== Missed Crit on 2-Cycle Strat ====
{{#ev:youtube|c9K-M_DSRqI|550}}
*Refresh rate in the video makes it a little unclear where Simon should be positioned for the backup. Here is the general location.
[[File:Drac_2-cycle_backup1_position.png|280px]]

==== Missed Backward Jump on 2-cycle Strat ====
{{#ev:youtube|-iMQ7BA1KpE|550}}
*Ideally you react in time to missing the backward jump and you stop throwing crosses, which would break the candles on the left. If you do break those candles, you will have to fight the cookie monster with a single shot holy water or even with the cross.
==== Death Recovery ====
(Video Link)

</div>

== <span class="mw-customtoggle-1" style="font-size:large; display:inline-block; float:right;"><span class="mw-customtoggletext">[Show/Hide]</span></span> Phase 2 ==
<div id="mw-customcollapsible-1" class="mw-collapsible mw-collapsed">
=== Standard After 3-Cycle ===
{{#ev:youtube|-BPHCKCNeLE|550}}
*You ideally want to have 12-14 hearts at the beginning of Phase 2 for this strat
*Pickup holy water and triple multiplier and position yourself approximately 1 whip length from Dracula
**The whip before the transformation is used to both gauge this distance and for a timing mechanism
*You can get 2 jump whips in before the first available jump
**Be sure to hold B after the 2nd whip. This will manipulate Drac into a quick short hop.
*Once landed, stun Drac with a holy water while it is in the crounched position
*Begin with a jump whip followed by a holy water while falling to chain the stun lock
*The holy water will deal damage to Drac as long as it passes through its head
**If you miss a jump whip, ensure that you still throw a holy water to maintain the stun lock

=== Standard After 4-Cycle or higher ===
*Same strat as Standard After 3-cycle, you will just be setting up wherever you end up killing Drac in Phase 1

=== Standard After 2-Cycle ===
==== Simple Opening ====
{{#ev:youtube|sMh89DRJDIs|550}}
*Easy 2-hit cross opening. Hold B after throwing the second cross to force the early jump.
==== Intermediate Opening ====
{{#ev:youtube|Cy8WFw0gDjc|550}}
*3-hit cross opening. For the second cross throw, press right, release, then jump to avoid getting a forward jump towards Cookie. Hold B after the second cross.
==== Optimal Opening ====
{{#ev:youtube|TbAekcTp7ww|550}}
*4-hit cross opening. Requires a just-frame backjump input for the first cross. Hold B after whipping the Holy Water candle.

=== Drac Crit Chart ===
[[File:Dracula_rising_crit_map.png|50px|right|frame||]]

=== Tyson Cookie ===
{{#ev:youtube|JyGAiRkEcmY|550}}
*This can be done after any Phase 1 and after any opening.
*Requires fewer hearts. You can skip a big heart at the end of Stage 17 if good pattern on 17-2 fleamen.
*Think of each jump whip and falling whip as a set. Each whip input of each set of whips (jump whips and down whips) are frame perfect.
**The first whip needs to be staggered 1 frame after your jump input, and the falling whip needs to be input exactly 22 frames after the first whip input in order to connect.
**If you jump and get no whip, your jump and whip inputs were on the same frame
**If you input a second whip, but it did not come out, your input was early.
*Note the pink hit markers for each whip. If you do not see a hit marker for your falling whip, it did not deal damage and was too slow.
*Only worth going for if you can consistently get 4 or more sets of tyson whips, otherwise this loses time over the standard (Machine gun) strat.

=== Backups ===
==== Double Shot Fight ====
<span style="color:#00FF00">Recommended to newcomers</span><br />
{{#ev:youtube|x-RYQRIkWMk|550}}
*This can also be used if you lack the hearts for the Standard Kill (Machine Gun)
*You can get in 2 jump whips per holy water

==== Single Shot Fight ====
{{#ev:youtube|szRuYKjnzwU|550}}
*Recommend stunning immediately
*You can get in 3 jump whips per holy water
*When attacking, tap B for as little as possible to reduce the chances of the Cookie Monster jumping.
*If Cookie Monster poises to jump (raises arms/one leg), do NOT finish your current set of jump whips. Move to a safe distance and re-apply holy water stun lock.
</div>

== <span class="mw-customtoggle-2" style="font-size:large; display:inline-block; float:right;"><span class="mw-customtoggletext">[Show/Hide]</span></span> 2snek Beginner/Race Video Guide ==
<div id="mw-customcollapsible-2" class="mw-collapsible mw-collapsed">

{{#ev:youtube|ZZ4LA2dM5Ro|550}}

</div>

Cv1/dracula

2024-03-01T03:53:45Z

K c r: /* Drac Crit Chart */

{{Infobox level
| image = CV1 Drac.png
| game = Castlevania
| level_name = 6
| level_sections = Dracula
| previous = [[cv1/level6 | Level 6]]
| next = None
}}

This article is a heavy WIP - for anything beyond basic to intermediate strategies please refer to SBD Wolf's World Record strat video https://www.twitch.tv/videos/1048136981

== <span class="mw-customtoggle-0" style="font-size:large; display:inline-block; float:right;"><span class="mw-customtoggletext">[Show/Hide]</span></span> Phase 1 ==
<div id="mw-customcollapsible-0" class="mw-collapsible mw-collapsed">
=== Simple ===
<span style="color:#00FF00">Recommended to newcomers</span><br />
(Video Link)
*3-cycle attempt with 5-cycle backup
*Explain left-right switching, how spawns and fireball patterns work

=== 2-Cycle: Descending Crit ===
{{#ev:youtube|o31bSltaYh0|550}}
*Easier to learn
*Thoroughly explain movements and visual cues
*Optional whip buffer (not recommended)
*Frame perfect descending crit variant to keep it simple and let people focus on movement
*3-Cycle backup (maybe put this section under backups?)
*Refer to backups if missed backward jump
*If fast pattern, either fall back on old school 3-cycle attempt, or refer to the Pause Buffer Section

=== 2-Cycle: Ascending Crit ===
{{#ev:youtube|QHU4UGNDVII|550}}
*More difficult to learn, but more lenient
*Thoroughly explain movements and visual cues
*Optional whip buffer (not recommended)
*Explain Ascending Whip setup (aim for 2-frame stagger pixels)
*3-Cycle backup (maybe put this section under backups?)
*Refer to backups if missed backward jump
*If fast pattern, either fall back on old school 3-cycle attempt, or refer to the Pause Buffer Section

=== Fast Pattern 2-Cycle: Pause Buffer ===
{{#ev:youtube|XwwtLf4ptXg|550}}
*Give frame number
*Append this chart:
<div class="toccolours mw-collapsible mw-collapsed" style="width:560px">
'''Pause Buffer Patterns'''
<div class="mw-collapsible-content">
"x frames pause" means pressing start once, and repressing it to unpause x frames later.
These spawns happen if Simon does the 2-cycle movement after a pause buffer on the fast pattern.
-2 frames pause: normal 2-cycle spawn that we're used to, but attack speed seems RNG.
-3 frames pause: Dracula spawns just left of the mid-left candle.
-4 frames pause: Dracula spawns just right of the leftmost candle.
-5 frames pause: Dracula spawns on top of Simon, hitting him.
-6 frames pause: Dracula spawns on top of Simon, hitting him (same as 5 frames pause).
-7 frames pause: Dracula spawns just right of the leftmost candle.
-8 frames pause: Dracula spawns just right of the mid-left candle.
-9 frames pause: Dracula spawns on the far right. Attack speed seems RNG.
-10 frames pause: Normal 2-cycle spawn. Fixed attack speed. Aim for this one.
-11 frames pause: Dracula spawns just left of the mid-left candle.
-12 frames pause: Dracula spawns just right of the leftmost candle.
-13 frames pause: Dracula spawns on top of Simon, hitting him.
-14 frames pause: Dracula spawns on top of Simon, hitting him. (same as 13 frames pause).
-15 frames pause: Dracula spawns just right of the leftmost candle.
-16 frames pause: Dracula spawns just right of the mid-left candle.
-17 frames pause: Dracula spawns on the far right. Attack speed might be fixed here.
-18 frames pause: Normal 2-cycle spawn.
Seems to continue on this pattern.
</div>
</div>
*Explain how to go about the fight if missed pause buffer

=== Hitless 3-Cycle ===
{{#ev:youtube|v_QSCyZhVYs|550}}
*Explanation

=== Backups ===
==== Missed Crit on 2-Cycle Strat ====
{{#ev:youtube|c9K-M_DSRqI|550}}
*Refresh rate in the video makes it a little unclear where Simon should be positioned for the backup. Here is the general location.
[[File:Drac_2-cycle_backup1_position.png|280px]]

==== Missed Backward Jump on 2-cycle Strat ====
{{#ev:youtube|-iMQ7BA1KpE|550}}
*Ideally you react in time to missing the backward jump and you stop throwing crosses, which would break the candles on the left. If you do break those candles, you will have to fight the cookie monster with a single shot holy water or even with the cross.
==== Death Recovery ====
(Video Link)

</div>

== <span class="mw-customtoggle-1" style="font-size:large; display:inline-block; float:right;"><span class="mw-customtoggletext">[Show/Hide]</span></span> Phase 2 ==
<div id="mw-customcollapsible-1" class="mw-collapsible mw-collapsed">
=== Standard After 3-Cycle ===
{{#ev:youtube|-BPHCKCNeLE|550}}
*You ideally want to have 12-14 hearts at the beginning of Phase 2 for this strat
*Pickup holy water and triple multiplier and position yourself approximately 1 whip length from Dracula
**The whip before the transformation is used to both gauge this distance and for a timing mechanism
*You can get 2 jump whips in before the first available jump
**Be sure to hold B after the 2nd whip. This will manipulate Drac into a quick short hop.
*Once landed, stun Drac with a holy water while it is in the crounched position
*Begin with a jump whip followed by a holy water while falling to chain the stun lock
*The holy water will deal damage to Drac as long as it passes through its head
**If you miss a jump whip, ensure that you still throw a holy water to maintain the stun lock

=== Standard After 4-Cycle or higher ===
*Same strat as Standard After 3-cycle, you will just be setting up wherever you end up killing Drac in Phase 1

=== Standard After 2-Cycle ===
==== Simple Opening ====
{{#ev:youtube|sMh89DRJDIs|550}}
*Easy 2-hit cross opening. Hold B after throwing the second cross to force the early jump.
==== Intermediate Opening ====
{{#ev:youtube|Cy8WFw0gDjc|550}}
*3-hit cross opening. For the second cross throw, press right, release, then jump to avoid getting a forward jump towards Cookie. Hold B after the second cross.
==== Optimal Opening ====
{{#ev:youtube|TbAekcTp7ww|550}}
*4-hit cross opening. Requires a just-frame backjump input for the first cross. Hold B after whipping the Holy Water candle.

=== Drac Crit Chart ===
[[File:Dracula_rising_crit_map.png|500px|right|frame||]]

=== Tyson Cookie ===
{{#ev:youtube|JyGAiRkEcmY|550}}
*This can be done after any Phase 1 and after any opening.
*Requires fewer hearts. You can skip a big heart at the end of Stage 17 if good pattern on 17-2 fleamen.
*Think of each jump whip and falling whip as a set. Each whip input of each set of whips (jump whips and down whips) are frame perfect.
**The first whip needs to be staggered 1 frame after your jump input, and the falling whip needs to be input exactly 22 frames after the first whip input in order to connect.
**If you jump and get no whip, your jump and whip inputs were on the same frame
**If you input a second whip, but it did not come out, your input was early.
*Note the pink hit markers for each whip. If you do not see a hit marker for your falling whip, it did not deal damage and was too slow.
*Only worth going for if you can consistently get 4 or more sets of tyson whips, otherwise this loses time over the standard (Machine gun) strat.

=== Backups ===
==== Double Shot Fight ====
<span style="color:#00FF00">Recommended to newcomers</span><br />
{{#ev:youtube|x-RYQRIkWMk|550}}
*This can also be used if you lack the hearts for the Standard Kill (Machine Gun)
*You can get in 2 jump whips per holy water

==== Single Shot Fight ====
{{#ev:youtube|szRuYKjnzwU|550}}
*Recommend stunning immediately
*You can get in 3 jump whips per holy water
*When attacking, tap B for as little as possible to reduce the chances of the Cookie Monster jumping.
*If Cookie Monster poises to jump (raises arms/one leg), do NOT finish your current set of jump whips. Move to a safe distance and re-apply holy water stun lock.
</div>

== <span class="mw-customtoggle-2" style="font-size:large; display:inline-block; float:right;"><span class="mw-customtoggletext">[Show/Hide]</span></span> 2snek Beginner/Race Video Guide ==
<div id="mw-customcollapsible-2" class="mw-collapsible mw-collapsed">

{{#ev:youtube|ZZ4LA2dM5Ro|550}}

</div>

Cv1/dracula

2024-03-01T03:51:11Z

K c r: /* [Show/Hide] Phase 2 */

{{Infobox level
| image = CV1 Drac.png
| game = Castlevania
| level_name = 6
| level_sections = Dracula
| previous = [[cv1/level6 | Level 6]]
| next = None
}}

This article is a heavy WIP - for anything beyond basic to intermediate strategies please refer to SBD Wolf's World Record strat video https://www.twitch.tv/videos/1048136981

== <span class="mw-customtoggle-0" style="font-size:large; display:inline-block; float:right;"><span class="mw-customtoggletext">[Show/Hide]</span></span> Phase 1 ==
<div id="mw-customcollapsible-0" class="mw-collapsible mw-collapsed">
=== Simple ===
<span style="color:#00FF00">Recommended to newcomers</span><br />
(Video Link)
*3-cycle attempt with 5-cycle backup
*Explain left-right switching, how spawns and fireball patterns work

=== 2-Cycle: Descending Crit ===
{{#ev:youtube|o31bSltaYh0|550}}
*Easier to learn
*Thoroughly explain movements and visual cues
*Optional whip buffer (not recommended)
*Frame perfect descending crit variant to keep it simple and let people focus on movement
*3-Cycle backup (maybe put this section under backups?)
*Refer to backups if missed backward jump
*If fast pattern, either fall back on old school 3-cycle attempt, or refer to the Pause Buffer Section

=== 2-Cycle: Ascending Crit ===
{{#ev:youtube|QHU4UGNDVII|550}}
*More difficult to learn, but more lenient
*Thoroughly explain movements and visual cues
*Optional whip buffer (not recommended)
*Explain Ascending Whip setup (aim for 2-frame stagger pixels)
*3-Cycle backup (maybe put this section under backups?)
*Refer to backups if missed backward jump
*If fast pattern, either fall back on old school 3-cycle attempt, or refer to the Pause Buffer Section

=== Fast Pattern 2-Cycle: Pause Buffer ===
{{#ev:youtube|XwwtLf4ptXg|550}}
*Give frame number
*Append this chart:
<div class="toccolours mw-collapsible mw-collapsed" style="width:560px">
'''Pause Buffer Patterns'''
<div class="mw-collapsible-content">
"x frames pause" means pressing start once, and repressing it to unpause x frames later.
These spawns happen if Simon does the 2-cycle movement after a pause buffer on the fast pattern.
-2 frames pause: normal 2-cycle spawn that we're used to, but attack speed seems RNG.
-3 frames pause: Dracula spawns just left of the mid-left candle.
-4 frames pause: Dracula spawns just right of the leftmost candle.
-5 frames pause: Dracula spawns on top of Simon, hitting him.
-6 frames pause: Dracula spawns on top of Simon, hitting him (same as 5 frames pause).
-7 frames pause: Dracula spawns just right of the leftmost candle.
-8 frames pause: Dracula spawns just right of the mid-left candle.
-9 frames pause: Dracula spawns on the far right. Attack speed seems RNG.
-10 frames pause: Normal 2-cycle spawn. Fixed attack speed. Aim for this one.
-11 frames pause: Dracula spawns just left of the mid-left candle.
-12 frames pause: Dracula spawns just right of the leftmost candle.
-13 frames pause: Dracula spawns on top of Simon, hitting him.
-14 frames pause: Dracula spawns on top of Simon, hitting him. (same as 13 frames pause).
-15 frames pause: Dracula spawns just right of the leftmost candle.
-16 frames pause: Dracula spawns just right of the mid-left candle.
-17 frames pause: Dracula spawns on the far right. Attack speed might be fixed here.
-18 frames pause: Normal 2-cycle spawn.
Seems to continue on this pattern.
</div>
</div>
*Explain how to go about the fight if missed pause buffer

=== Hitless 3-Cycle ===
{{#ev:youtube|v_QSCyZhVYs|550}}
*Explanation

=== Backups ===
==== Missed Crit on 2-Cycle Strat ====
{{#ev:youtube|c9K-M_DSRqI|550}}
*Refresh rate in the video makes it a little unclear where Simon should be positioned for the backup. Here is the general location.
[[File:Drac_2-cycle_backup1_position.png|280px]]

==== Missed Backward Jump on 2-cycle Strat ====
{{#ev:youtube|-iMQ7BA1KpE|550}}
*Ideally you react in time to missing the backward jump and you stop throwing crosses, which would break the candles on the left. If you do break those candles, you will have to fight the cookie monster with a single shot holy water or even with the cross.
==== Death Recovery ====
(Video Link)

</div>

== <span class="mw-customtoggle-1" style="font-size:large; display:inline-block; float:right;"><span class="mw-customtoggletext">[Show/Hide]</span></span> Phase 2 ==
<div id="mw-customcollapsible-1" class="mw-collapsible mw-collapsed">
=== Standard After 3-Cycle ===
{{#ev:youtube|-BPHCKCNeLE|550}}
*You ideally want to have 12-14 hearts at the beginning of Phase 2 for this strat
*Pickup holy water and triple multiplier and position yourself approximately 1 whip length from Dracula
**The whip before the transformation is used to both gauge this distance and for a timing mechanism
*You can get 2 jump whips in before the first available jump
**Be sure to hold B after the 2nd whip. This will manipulate Drac into a quick short hop.
*Once landed, stun Drac with a holy water while it is in the crounched position
*Begin with a jump whip followed by a holy water while falling to chain the stun lock
*The holy water will deal damage to Drac as long as it passes through its head
**If you miss a jump whip, ensure that you still throw a holy water to maintain the stun lock

=== Standard After 4-Cycle or higher ===
*Same strat as Standard After 3-cycle, you will just be setting up wherever you end up killing Drac in Phase 1

=== Standard After 2-Cycle ===
==== Simple Opening ====
{{#ev:youtube|sMh89DRJDIs|550}}
*Easy 2-hit cross opening. Hold B after throwing the second cross to force the early jump.
==== Intermediate Opening ====
{{#ev:youtube|Cy8WFw0gDjc|550}}
*3-hit cross opening. For the second cross throw, press right, release, then jump to avoid getting a forward jump towards Cookie. Hold B after the second cross.
==== Optimal Opening ====
{{#ev:youtube|TbAekcTp7ww|550}}
*4-hit cross opening. Requires a just-frame backjump input for the first cross. Hold B after whipping the Holy Water candle.

=== Drac Crit Chart ===
[[File:Dracula_rising_crit_map.png|right|frame||]]

=== Tyson Cookie ===
{{#ev:youtube|JyGAiRkEcmY|550}}
*This can be done after any Phase 1 and after any opening.
*Requires fewer hearts. You can skip a big heart at the end of Stage 17 if good pattern on 17-2 fleamen.
*Think of each jump whip and falling whip as a set. Each whip input of each set of whips (jump whips and down whips) are frame perfect.
**The first whip needs to be staggered 1 frame after your jump input, and the falling whip needs to be input exactly 22 frames after the first whip input in order to connect.
**If you jump and get no whip, your jump and whip inputs were on the same frame
**If you input a second whip, but it did not come out, your input was early.
*Note the pink hit markers for each whip. If you do not see a hit marker for your falling whip, it did not deal damage and was too slow.
*Only worth going for if you can consistently get 4 or more sets of tyson whips, otherwise this loses time over the standard (Machine gun) strat.

=== Backups ===
==== Double Shot Fight ====
<span style="color:#00FF00">Recommended to newcomers</span><br />
{{#ev:youtube|x-RYQRIkWMk|550}}
*This can also be used if you lack the hearts for the Standard Kill (Machine Gun)
*You can get in 2 jump whips per holy water

==== Single Shot Fight ====
{{#ev:youtube|szRuYKjnzwU|550}}
*Recommend stunning immediately
*You can get in 3 jump whips per holy water
*When attacking, tap B for as little as possible to reduce the chances of the Cookie Monster jumping.
*If Cookie Monster poises to jump (raises arms/one leg), do NOT finish your current set of jump whips. Move to a safe distance and re-apply holy water stun lock.
</div>

== <span class="mw-customtoggle-2" style="font-size:large; display:inline-block; float:right;"><span class="mw-customtoggletext">[Show/Hide]</span></span> 2snek Beginner/Race Video Guide ==
<div id="mw-customcollapsible-2" class="mw-collapsible mw-collapsed">

{{#ev:youtube|ZZ4LA2dM5Ro|550}}

</div>

File:Dracula rising crit map.png

2024-03-01T03:49:04Z

K c r: