Difference between revisions of "Cv1/ScrollGlitch"

Revision as of 20:37, 21 March 2023 (view source) SBDWolf (talk | contribs) m ← Older edit		Revision as of 22:00, 21 March 2023 (view source) SBDWolf (talk | contribs) m (Added more info on Stage 14 advanced pixel) Newer edit →
Line 168:		Line 168:
	| Stage 14 Ceiling Drop  || 45C or 43D		| Stage 14 Ceiling Drop  || 45C or 43D
	|-		|-
−	| Stage 14 Advanced  || 2C4	+	| Stage 14 Advanced  || 2C4*
	|-		|-
	| Stage 17 Clocktower  || 219 & 1FB		| Stage 17 Clocktower  || 219 & 1FB
	|}		|}
		+
		+	<nowiki>*</nowiki>Touching pixel 2B9 is needed before turning around
	Stage 13:		Stage 13:

---

Revision as of 22:00, 21 March 2023

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:

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:

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:

1. 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
2. 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.
3. Increment the block counter by 1
4. 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:

Stage Number	Pixel
Stage 6 Crusher	1D9 & 1B9
Stage 13	A4
Stage 14 Wall	328
Stage 14 Ceiling Drop	45C or 43D
Stage 14 Advanced	2C4*
Stage 17 Clocktower	219 & 1FB

*Touching pixel 2B9 is needed before turning around

Stage 13:

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

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.

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

Here's Shockra Tease talking about both Scroll Glitches

Advanced Stage 14

Displaced Gamers Video on the code