124
edits
Changes
m
no edit summary
Simon moves at a consistent 1 pixel per frame. Walking is the same speed as jumping. While traveling on stairs, he moves more slowly.
A damage boost has Simon travel at 1 pixel per frame, but loses 23 (22? needs confirmation) frames to hit and recovery frames.
Whipping or using a subweapon takes 23 frames on the gorund ground or 22 frames while in the air. If landing with an attack, Simon will not be able to move until the attack animation is over.<br />
If falling or jumping off of a 4-block height or higher, Simon goes into a clunk animation which loses 16 frames. This can be prevent by whipping on landing (can only be done off of a jump), as the whip animation takes precedence over the clunk. The earlier the whip, the less frames Simon has to spend locked on the ground on landing. With a perfect whip, zero frames can be lost from the landing.<br />
Falling off a small height loses 2 frames. This can be avoided by simply jumping over it.
=== Scroll Glitch ===
This glitch is related to Castlevania's way of loading tilesets offscreen. Blocks may only be loaded every 2 frames, and only while Simon is moving. This means that by moving only on frames when blocks are not being updated, they will fail to load properly and instead leave on screen a predetermined, consistent "garbage" tileset.
Attempts to load the blocks will continue until Simon is close enough to them. Usually this requires the user to perform 20+ 1-frame movements on the correct frames, which is unfeasible in a Real Time setting.
There is another exploit to this mechanic though: if, on the frame a tileset would normally load, Simon moves BACK instead of forward, the block will fail to load, and no further attempts will be made to load it until 8 more frames of movement on "loading frames", at which point another turnaround will be needed. Usually two or three turnarounds are needed to permanently prevent a tileset from being loaded. This method is feasible in Real Time and leads to a number of skips.
Please see [[Cv1/ScrollGlitch | Scroll Glitch]] for more info.
----
*Stage 14-2
=== Enemy Patterns RNG ======= In Summary ====A lot of Some enemy patterns are only a function of how many frames have elapsed since the start of the screen and Simon's current position on screen. This allows for pattern manipulation on enemies such as the Bat Boss, Birds, and the Mummies.White Skeletons are also affected by RNG Other enemies patterns instead, on top of Simon's current position on screen, depend on RNG.<br />The RNG algorithm is a factor of the previous RNG value, as well as how many frames have elapsed since the factors mentioned abovestart of the screen. NotablyOn certain frames, they have the RNG value can be very predictable. This allows for a smaller extent of manipulation, for example on white skeletons, by simply losing a certain amount of frames before ancountering said enemies. This can force them into a limited set amount of patterns (chosen at random, or sometimes even a single possible pattern. ==== The Technical Version ====In Castlevania, whenever the code is finished doing everything it needed to do for the current frame, it enters an idle loop while waiting for the NMI interrupt to occur, signaling the start of the next frame. During this idle loop, the RNG value gets advanced over and over. Here's the code of the idle loop (taken from [https://github.com/josephstevenspgh/Castlevania-Labelled-Disassembly this public disassembly]): <nowiki>Legend: CurrentRandomBonusId = $6F FrameCounter = $1A BonusTable = $C03F MainLoop $C030 A5 6F: lda CurrentRandomBonusId $C032 05 1A: ora FrameCounter $C034 29 0F: and #$0F $C036 A8: tay $C037 B9 3F C0: lda BonusTable,y $C03A 85 6F: sta CurrentRandomBonusId $C03C 4C 30 C0: jmp MainLoop BonusTable $C03F .byte $33,$BB,$3F,$80,$2E,$A9,$61,$87,$AD,$C3,$B2,$C8,$7C,$25,$48,$7A</nowiki> On one hand, the fact that the RNG algorithm is placed in the idle loop can make it very hard to manipulate its value, because the length of this loop will be affected by how many things the game has already processed on that frames, where in the loop the NMI interrupt happened on the previous frame (since it will resume exactly where it left off on the next frame), as well as CPU/PPU sync (which is deterministic on most emulators but random on a real console).<br />On the other hand, this RNG algorithm is extremely prone to getting stuck on either a single value, or a very limited set of values. In other words, the idle loop will pretty much always loop over a limited set of values. There are even values from the BonusTable array that are never going to get picked.<br />On top of that, the RNG value will always reset every 16 frames (to value 0x7A). This gives the value that the RNG will assume a degree of predictability. Assuming the loop runs for at least a few interations (which it pretty much always does, outside of laggy areas), here is a list of all the possible value that the RNG can contain on any of the 16 values of the room's frame counter: <nowiki>Legend: The value on the left represents the value of the current room's frame counter, modulo 16 (since that's what the RNG algorithm uses) depending , as well as the conditions that have to be met for the values stated on those two factorsthe right to potentially occur (which is essentially a specific value from the previous frame). The exact value(s) on the right represent the set of possible values that the RNG could contain at the end of the idle loop, on the specific frame and conditions specified. * = Regardless of previous value if 0xXX = If the value from the previous frame was 0xXX 0x0: 0x7A, 0x3F, 0xB2 0x1, *: 0xC8, 0xC3, 0x80, 0xBB 0x2, *: 0xB2, 0x3F, 0x7A 0x3, if 0xB2: 0x80 0x3, if 0x3F: 0xC8 0x3, if 0x7A: 0xC8 0x4, *: 0x7C 0x5, *: 0x25, 0xA9 0x6, if 0x25: 0x87 0x6, if 0xA9: 0x48 0x7, if 0x87: 0x87 0x7, if 0x48: 0x7A 0x8, *: 0xB2 0x9, *: 0xC8, 0xC3 0xA, *: 0xB2 0xB, *: 0xC8 0xC, *: 0x7C 0xD, *: 0x25 0xE, *: 0x48 0xF, *: 0x7A</nowiki> These values will then be read on demand by an enemy, which will determine their pattern (interpreted in a unique way for every enemy). Note that this RNG read will not additionally advance the RNG.<br />For a practical example, with the standard strat of entering Dracula's room without losing any frames, Dracula's pattern will be determined with the frame counter reading 0xC7.<br />On this frame, the possible values are either 0x87 or 0x7A. If it reads 0x87, this will make Dracula do the fast fireball pattern, while if it reads 0x7A, this will make Dracula do the slow fireball pattern gets chosen at random. This allows essentially makes either pattern a 50% chance that is impossible to control in an RTA setting. === Score Management ===In some games, having certain scores can cause more lag due to the game having to spend more computations to display it on screen.<br />In Castlevania, this is not the case. The current score is stored in memory in a "decimal" format, which makes it fairly quick for the game to then display it on screen and also makes it the same speed for any combination of digits.<br />On the other hand, the moment points are acquired, there could be a smaller extent little bit of variance in the amount of computations performed depending on the current score and the score added, but this is usually just a handful of manipulationCPU cycles in total, which is pretty negligible.<br />The bottom line is, score doesn't really matter for lag in Castlevania.
=== Additional Links ===
*[http://tasvideos.org/GameResources/NES/Castlevania.html TASVideos tricks page]
