== 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
|-
| Stage 6 Crusher || TO FILL IN
|-
| Stage 13 || A4
|-
| Stage 14 Wall || 328
|-
| Stage 14 Ceiling Drop || TO FILL IN
|-
| Stage 14 Advanced || 2C4
|-
| Stage 17 Clocktower || TO FILL IN
|}

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.

Attached is an MP3 created for the 4-12 pattern: TO FILL IN

=== 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}}

File:CV1 ScrollGlitch1. updated.png

2022-08-11T23:57:14Z

KidCharlemagneReturns:

Cv1/ScrollGlitch

2022-08-11T23:56:11Z

KidCharlemagneReturns: /* How are background tiles updated? */

== 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_ScrollGlitch1new.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
|-
| Stage 6 Crusher || TO FILL IN
|-
| Stage 13 || A4
|-
| Stage 14 Wall || 328
|-
| Stage 14 Ceiling Drop || TO FILL IN
|-
| Stage 14 Advanced || 2C4
|-
| Stage 17 Clocktower || TO FILL IN
|}

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.

Attached is an MP3 created for the 4-12 pattern: TO FILL IN

=== 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}}

Cv1/ScrollGlitch

2022-08-11T23:54:14Z

KidCharlemagneReturns: /* How are background tiles updated? */

== 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_new.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
|-
| Stage 6 Crusher || TO FILL IN
|-
| Stage 13 || A4
|-
| Stage 14 Wall || 328
|-
| Stage 14 Ceiling Drop || TO FILL IN
|-
| Stage 14 Advanced || 2C4
|-
| Stage 17 Clocktower || TO FILL IN
|}

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.

Attached is an MP3 created for the 4-12 pattern: TO FILL IN

=== 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}}

Cv1/ScrollGlitch

2022-08-11T23:54:04Z

KidCharlemagneReturns: /* How are background tiles updated? */

== 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_ScrollGlitch1new.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
|-
| Stage 6 Crusher || TO FILL IN
|-
| Stage 13 || A4
|-
| Stage 14 Wall || 328
|-
| Stage 14 Ceiling Drop || TO FILL IN
|-
| Stage 14 Advanced || 2C4
|-
| Stage 17 Clocktower || TO FILL IN
|}

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.

Attached is an MP3 created for the 4-12 pattern: TO FILL IN

=== 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}}

File:CV1 ScrollGlitch1.png

2022-08-11T23:51:56Z

KidCharlemagneReturns: KidCharlemagneReturns uploaded a new version of File:CV1 ScrollGlitch1.png

2022-08-11T16:44:25Z

KidCharlemagneReturns:

{{Infobox level
| image = CV1 Level1.png
| game = Castlevania
| level_name = 1
| level_sections = Stage 1, Stage 2, Stage 3
| previous = None
| next = [[cv1/level2 | Level 2]]
}}

== <span class="mw-customtoggle-0" style="font-size:large; display:inline-block; float:right;"><span class="mw-customtoggletext">[Show/Hide]</span></span> Stage 01 ==
<div id="mw-customcollapsible-0" class="mw-collapsible mw-collapsed">
=== Simple ===
<span style="color:#00FF00">Recommended to newcomers</span><br />
{{#ev:youtube|WytD-jPacY0|550}}
[[File:Cv1-Zombie DBoost.gif|right|frame||If two or three zombies spawn clumped up together, take a damage boost.]]
*Jumping into the gate as shown is faster. This is because as soon as Simon touches the castle entrance, the game automatically moves him at a slower speed, so you want to jump to preserve normal speed.
*Right at the start of the castle, there could be one, two or three zombie spawning next to each other. If it's only one, you can simply jump over it and whip the one trailing a bit behind it, if there is one. If there's two or three zombies grouped up together, you might want to take a damage boost on one of them.
*Get the first whip upgrade from one of the high candles. Try to not get it from one of the low candles, especially if close to a zombie since it'll make timing your subsequent jump difficult.
**Try to hold off on collecting the final whip upgrade, as having the short whip will make Cave Skip in level 4 easier.
*On the second wave on zombies, there will never be two zombies next to each other. Feel free to jump and whip on landing for these guys.
*Don't be afraid to start climbing the staircase to avoid taking knockback from a zombie behind it.

=== Stopwatch Manipulation (Optimal) ===
{{#ev:youtube|a1-C85VCv5A|550}}
[[File:Cv1-stage01 double drop.gif|right|frame||Money Bag dropping from the first Zombie, advancing the item chart.]]
*The optimal frame to jump into the gate is the one shown in the video, where Simon turns around for a very brief moment before going into the castle.
*Aim to get the Stopwatch off the first zombie. Break the first candle to get the whip upgrade, then jump and whip the zombie on landing. Whipping to get the Stopwatch is a 1-frame window.
**Pay attention if there's two or more zombies at the start, as the additional zombie will also generate a Money Bag if the Stopwatch drops and it'll advance the item chart to Slot 2 (this would be the Holy Water but it gets turned into a money bag due to the Important Item Rule). This needs to be taken into consideration later for a more optimal Level 3.
*If you successfully got the stopwatch already, go through the second wave of zombies as shown in the video to make it less likely to collect additional item drops.
<div class="toccolours mw-collapsible mw-collapsed" style="width:560px">
'''Jump visual cue for second wave'''
<div class="mw-collapsible-content">
[[File:Cv1-Stage01 jump cue.jpg]]
*Jump when Simon's front foot overlaps this spot in the background pillar.
</div>
</div>

If you don't have a Stopwatch by the second wave, use this strat:<br />
{{#ev:youtube|Y6TNwlSusLY|400}}
*You should aim to get the stopwatch on these two zombies showcased. The exact timing of the whips to get the stopwatch depends on how much time has already been lost whipping previous zombies: the more time has been lost, the earlier your whip will have to be to get the stopwatch.
**If the first zombie in this wave doesn't spawn, you should delay the whip on the second zombie by a lot.

=== Alternate Watch Manip Strats ===
{{#ev:youtube|e1Nh3a_JmWA|550}}
*This watch manipulation is a lot more complex as the actions are different from pattern to pattern, but it can always avoid a second item drop from happening in this stage, and some people may find the timing a little less awkward on some of these patterns.
*In order, the patterns shown are the Space Zombies (one zombie, a space, one zombie), the Couple (two zombies), the Triplet (three zombies), the Triplet with heart drops, and the Solo pattern (one unusable zombie and no more trailing zombies).
**On the Solo pattern, you will have to get the Stopwatch on the second wave. It is recommended to lose a few frames before the second wave with a stutter to help with the timing.
**Remember that if you don't get the Stopwatch on the first wave, you will have to adjust the whip timing for second wave depending on exactly how many frames have been lost whipping these first zombies. Usually, the Space zombies will lose fewer frames and demand a later timing, while the Couple and Triplet will lose more and demand an earlier timing.

=== TAS Framerule ===
https://clips.twitch.tv/SwissPlumpAnteaterDendiFace-PgXOHhKl-4LZtjPW
*As of the date of this writing (April 27th 2021), this framerule has only been hit once in real time. To hit it, it is required to only whip a single zombie on the earliest possible frame, get the stopwatch off of it, pray that there's no zombies coming from the back of the stairs at the end, and get an optimal [[Cv1/tricks#Staircases | Stairs Grab]]. The chances of this happening are obviously extremely unlikely, and actively attempting this kind of strategy makes consistency greatly suffer. As such, it is not recommended to try to hit this framerule.
</div>

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

=== Easier Bat Boost ===
<span style="color:#00FF00">Recommended to newcomers</span><br />
{{#ev:youtube|4aAr2RgyT64|550}}
[[File:Cv1-Stage02 pixel.png|thumb|right|frame|400px||This is the pixel you need to stay at to manipulate an item drop. You can use Simon's front foot in relation to the bricks in the background as a visual cue.]]
*Stand on a pixel perfect location. This will force the bat to force an item as soon as it hits Simon. If no other item drops have occurred yet, this item will be a Stopwatch.
**If you fail the Stopwatch manipulation or you get another item drop, it's recommended to not retry it and continue with the setup instead. Fall back on the backup Axe strats for stage 03 if you leave this stage without a Stopwatch.
***If you happen to have collected a Stopwatch from stage 01 already, you should stand on a pixel left or right of this one to avoid getting another item drop. Taking the knockback is not necessary to perform the bat boost, but it will allow you to execute this pseudo-buffer strat.
*As soon as Simon lands back on his feet from the knockback, whip while still in the crouched position and start holding right. Perform the jump and the other whip stall where shown in the video to manipulate the bat's Y position and be able to boost over.

=== Early Boost (Stopwatch) ===
{{#ev:youtube|kwwpOo6ZuCE|550}}
*The first bat will spawn on the second frame of the room. Thus, by activating the Stopwatch on the first frame of control, it's possible to delay its spawn and make the boost with the first bat. This saves ~4 seconds.
**While the bat will spawn on the second frame of the room, its visual model will spawn on the third frame. This means that if the Stopwatch is used on the second frame, it will look like the bat is not present, while in reality it has already spawned in the top right. It's not possible to boost over using this bat spawn.
***By holding left+up and pushing B at the start of the room, it's possible to tell early if the Stopwatch has been activated on the first or second frame. If Simon keeps facing right after the activation, it means that it was done on the first frame, while if Simon faces left, that means it was done on the second frame, making the boost impossible. Switch to right ASAP after activating the Stopwatch (in the middle of the whip animation).
*Perform the whip stalls and the jump where shown in the video to manipulate the bat's Y position in order to boost over.
**You can jump over the big heart if you intend on resetting for a missed crit in in stage 03, otherwise feel free to take it. The jump does not help manipulate the bat's Y position so you can skip it if you want to pick up the big heart.

=== Optimal Early Boost (Stopwatch) ===
{{#ev:youtube|37B6l3-KqMI|550}}
*Same principle as the other Early Boost method shown above, but the movements are slightly different so that an additional framerule may be saved. This is significantly more difficult.
*Two grounded whip stalls are made and then one on jump landing to lose a few more frames. The timing for this whip is a bit specific. Whip too early and you will break the candle, potentially getting a heart drop, and the bat will likely spawn too low. Whip too late, ad the bat will likely spawn too high.
**This landing whip can also be replaced with a simple stutter.
*Jump immediately as soon as you drop off the block. The earlier, the lower the bat will spawn and usually the easier the boost will be.
*You can do small stutter before jumping in for the boost to make it a little easier to hit the back of the bat and boost forward. As long as the stutter is kept tiny, you will still make the framerule.
**One side effect of doing this stutter is that it increases the chances of getting the bat to drop an item after boosting, which will advance the item chart.

=== Backups ===
==== Manual Bat Boost ====
{{#ev:youtube|5WNKWypGBMc|550}}
*To be used if the standard bat boost fails.
*Walking off the ledge and going back up seems to increase the chances of getting a higher bat spawn, which makes the boost easier.
*Wait at the ledge, then as soon as you see the bat appear on screen go back a little, then jump forward.
</div>

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

=== Simple Crit attempt + backup Stopwatch kill ===
<span style="color:#00FF00">Recommended to newcomers</span><br />
[[File:Cv1-Successful Crit.gif|right|frame||Successful Crit, killing the bat in a single whip strike.]]
{{#ev:youtube|xmF1ImWb92U|550}}
[[File:Cv1-MidBat.PNG|thumb|right|frame|320px||Whip when the bat's middle crosses this line.]]
*The boss pattern is dependent on how many frames have elapsed since the start of this room (so to clarify, this excludes stage 01 and stage 02). This means that by always holding right, and performing consistent actions, it's possible to always get the same pattern on the boss.
*To achieve this, got through the room taking special care to never let go of right, take the invincibility potion, and simply walk off the big ledge, taking a clunk. This will consistently lose exactly 18 frames, providing a good pattern on the boss.
*Once you're at the boss, position Simon on the middle step. Once the bat starts to move, move to the top step and wait. When the bat approaches you, there is a 1-frame window where you can whip and kill the boss in one hit. This is known as the [[Cv1/tricks#Critical_Hit_Glitch | Critical Hit Glitch]]
**A general visual cue designed for people running on original console with a low display monitor (CRT or low delay LCD) in mind is depicted in this picture. This changes from person to person depending on reaction time and input delay, so experiment with your visual cue and try to create your own line a little earlier or later if you feel like it works better.
**Some people count the number of wing flaps from the bat as a visual cue ('''Needs amounts''').
***If you fail the crit, there's an easy way to tell if you were late or early. If you were late, Simon will hit the boss for 2 bars of HP, and a red sparkle will appear around the bat, indicating a hit. If you were early, SImon will not hit the boss instead and it will stay at full health.
*As a backup, activate the stopwatch and kill the bat there. You need to press either up+B on the same frame, or B 1 frame after pressing up, to avoid climbing the step.
*The simplest way to grab the end-stage orb is to let it fall on Simon. You might be tempted to jump towards the orb to collect it sooner, but you risk losing time that way. Read [[Cv1/tricks#Orb_Grabs | here]] if you're interested in the full details.

=== Simple Stopwatch kill ===
{{#ev:youtube|QU1c3xGGcuQ|550}}
*This is an easier alternative to the Stopwatch kill with the Crit attempt listed above. This will require 10 hearts, grab the big heart from the candle as shown in the video if you still need hearts.
*Perform the same movements to manipulate the boss to swoop down, but as soon as it gets close to Simon, instead of attempting the Crit, activate the stopwatch and fully climb the stairs. Then turn around and start whipping down the bat. Activate the Stopwatch a second time as soon as it runs out.

=== Advanced Crit (Optimal) ===
*The boss pattern is dependent on how many frames have elapsed since the start of this room (so to clarify, this excludes stage 01 and stage 02). If you never release right through this room, the only spot that has time variance is the whip cancel off the big ledge. Depending on exactly how good the whip cancel is, a different amount of frames will be lost and the boss will have a different pattern. You will have to be able to tell exactly how many frames have been lost and perform different movements to make the bat swoop down quickly. The following videos illustrate what to do on every relevant scenario. If you lose more than 3 frames (or do some other kind of mistake), just do the same movement that the 2-frame and the 3-frame videos do and patiently wait for the bat to swoop down (it will likely take a lot longer).
*Breaking the candle that contains the invincibility potion can cause some lag, so you can skip it and get away with it most of the time. But there are certain zombie patterns that will hit you if you don't get the potion, so do this at your own risk.
*By jumping from a specific spot on the platform, you can have a chance at destroying the candle that cointains the Axe. If you jump from this spot, you can use this candle as an aid in telling what kind of whip cancel you just got: if you don't destroy the candle or clunk, it means the whip landing lost you no less than 2 frames. If you do destroy the candle, you will only have to recognize between a 1-frame landing and a 0-frame landing.
**If you do use this axe candle as a visual cue, it is recommended that you pick up the invincibility potion, as breaking the candle without being invincible has a chance of causing some lag as well, and it will make it harder to tell what kind of whip landing you just got.
***If you want to be fully optimal, you should skip both the invincibility potion and the axe candle by jumping from as far out as possible on the platform. This also means you can jump, whip too early and get a clunk, without having the Axe drop on Simon during the clunk.
*Read [[Cv1/tricks#Orb_Grabs | here]] for information on how to grab the end-stage orb optimally.

==== 3-frame pattern ====
[[File:Cv1-MidBat.PNG|thumb|right|frame|260px||Whip when the bat's middle crosses this line.]]
{{#ev:youtube|7ySRArdJeTA|450}}
*Wait on the middle step, wait for the bat to move, then move to the top step and go for the crit.

==== 2-frame pattern ====
[[File:Cv1-MidBat.PNG|thumb|right|frame|260px||Whip when the bat's middle crosses this line.]]
{{#ev:youtube|4p2VNLmUxxA|450}}
*Same movement as the 3-frame pattern. Wait on the middle step, wait for the bat to move, then move to the top step and go for the crit. This saves about 0.5s over the 3-frame pattern, as the boss will swoop down more quickly.

==== 1-frame pattern ====
[[File:Cv1-TopBat.PNG|thumb|right|frame|260px||Whip when the bat's middle crosses this line.]]
{{#ev:youtube|ZUnYMJceZ8I|450}}
*Wait on the top step right from the start and go for the crit. This crit is exactly same speed as the 2-frame pattern, down to the frame.

==== 0-frame pattern (TASCrit) (Fastest!) ====
[[File:TASBat.PNG|thumb|right|frame|260px||Whip when the bat's middle crosses this line.]]
{{#ev:youtube|xDmQgvKuzIo|450}}
[[File:Cv1-TASCrit failed backward.PNG|thumb|right|frame|210px||If you fail the backward jump, strike a bit later.]]
*This is the fastest possible kill, it saves a little over 0.4s over the 2-frame and the 1-frame patterns (26 frames at most).
*To do this setup, climb two steps of the stairs and then go immediately down. Make sure that every movement so far is buffered. At this point, wait a split second and aim to do a backward jump up the top platform. There is a 4-frame window to perform a backward jump and get a usable swoop from the boss. Immediately start going down a step (buffer this action as well) and go for the crit.
**If you jump up to the top platform too early, the bat will swoop down too high and it won't hit Simon. If you jump too late, it will move from its original position, making the rest of the setup not work (there is a backup for this, check the Backups section below).
**The last 2 frames of the 4-frame window on the backward jump will require you to whip 1 frame later, shifting your visual cue slightly. In other words, if you jump to the top platform later rather than sooner, you will have to whip 1 frame later.
**If you fail to get a backward jump (you start facing right during the jump instead), you will have to whip a bit later.
**There is no good backup if you miss the Crit, so it's recommended to only go for this if you intend on resetting after missing it.

==== Clunk pattern ====
[[File:TASBat.PNG|thumb|right|frame|260px||Whip when the bat's middle crosses this line.]]
{{#ev:youtube|e-9QD0wywk8|450}}
*Getting a clunk just provides the 0-frame pattern. Refer to the above section for instructions.

=== Backups ===
==== Rare Double Zombie pattern ====
{{#ev:youtube|W8PrhtSIgAU|550}}
*Rarely, two zombies will spawn at the start of the room. If this happens, take knockback from the zombie on the back, then perform a jump-clunk off the platform to get the same pattern that the Simple Stopwatch Kills and the 2-frame landing from the Advanced section get from the boss.

==== Late jump on TASCrit ====
[[File:Cv1-MidBat.PNG|thumb|right|frame|260px||Whip when the bat's middle crosses this line.]]
{{#ev:youtube|8EtSD9AaRF0|550}}
*If you jump too late on the top platform during a TASCrit attempt, the bat will move slightly from its original position and won't swoop down for a while. To get him to move quickly, go down two steps and then move back up one step. This will allow you to go for a Crit, and it loses about 1 second over the standard TASCrit. The crit has a similar visual cue to the 2-frame pattern.
==== Axe strats ====
{{#ev:youtube|E1U3fPZutuY|550}}
*This is recommended to be used as a backup if the stopwatch manipulation failed in stage 02, though it can be used in alternative to the stopwatch kills and some people may find this more simple.
**Keep in mind that not having the stopwatch for level 2 will make it slower and more difficult.
*The number of frames that have elapsed since the start of the room doesn't really matter with this strat.
*Make sure you have enough hearts for this kill, you can break the candle shown in the video for an extra Big Heart if you need it.
*Position Simon against the bottom platform to the right and wait. There's a breakable block that contains a Double Shot there, you can break this in advance but wait until the boss has moved down before walking in to collect it.
*As soon as you've collected the Double Shot, simply fire off Axes from safety until the boss is dead.

</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|25oLuFsUdCg|550}}

</div>

2022-08-11T16:03:16Z

KidCharlemagneReturns:

Cv1/ScrollGlitch

2022-08-11T16:02:48Z

KidCharlemagneReturns: /* Breaking Dracula’s Castle 101 */

Cv1/ScrollGlitch

2022-08-11T16:00:35Z

KidCharlemagneReturns:

Cv1/ScrollGlitch

2022-08-11T15:57:34Z

KidCharlemagneReturns:

File:CV1 ScrollGlitch2.jpg

2022-08-11T15:55:21Z

KidCharlemagneReturns:

Cv1/ScrollGlitch

2022-08-11T15:53:09Z

KidCharlemagneReturns: /* How are background tiles updated? */