289
edits
Changes
no edit summary
# 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.
=== 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:
''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. ''
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).
''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 at: https://castlevaniaspeedruns.com/Cv1/level5
=== 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"
|+
|-
! Header text !! Header text
|-
| 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
|}
