Let's take a look at what we know.
-During gameplay, keen's non sprite interactions are stored in small 16x16 pixel blocks we call tiles.
-These tiles contain a variety of information, including blocking data and point or kill values.
-The blocking data is only applicable to the first row or column of pixels that are blocked. That is, if you spawn keen inside a completely solid tile, he will have the ability to move to one tile in any direction, as long as the tile he is moving to isn't blocked on that side.
-We also know that keen and other sprites will clip through solid tiles, if their collision box gains an extra tile on the side interacting with the solid tile, while that sprite is directly next to the box. This is further proof that the solid tile/sprite interaction only looks at the first row of tiles on a side.
-If you've been especially observant, then you've noticed that its not just the vorticon that can get stuck in the wall, but also the garg and yorp in rare circumstances.
-Finally, and most important of all, the sprites will only get stuck in the wall if their collison box is touching the "collison box" of the blocking tile. There can be no pixels in between.
This last observable fact indicates that there are programmed limits as to how close and how far a sprite can detect a wall. A sprite clearly cannot detect a wall unless there is a pixel of space in between, otherwise it wouldn't get stuck, creating the glitch. The sprite certainly wasn't programmed to detect an infinite distance for a wall, as this would have probably overloaded the computer. Most likely, the sprites were designed to detect walls that were up to 16 pixels away. Not only is 16 the length of a tile, but it is (if i recall correctly) the number that the width of a sprite must be divisible by in order to prevent the game from crashing. If this is the case, then the detection for the sprite would be programmed to look for a wall within 15-16 pixels of the sprite's collison box. If it finds that wall, it would travel the 15-16 pixels, turn around, and start moving the other way.
A random number is generated every time the sprite moves, which determines how far it moves before pausing to look around. This will occur regardless of whether or not the sprite has reached the wall, so as to prevent unnatural movement near walls. Therefore, it is my belief that another call to the detection function is made here that updates the distance to the next wall.
The glitch occurs when a sprite needs to travel 0 pixels after pausing to look around. If the above is correct, the distance to travel variable will only read 0 on stopping, which explains why sprites don't get stuck in the wall all the time. It should just move 0 pixels, turn around, and keep moving. This obviously does not happen. The sprite might move 1 pixel forward (I'm not sure about this) and then turns around and doesn't move.
Why would this happen? One possibility is that the there's some code such as:
Code: Select all
newPosition=oldPosition + distanceToWall
if (newPosition > oldPosition)&&(sprite is going left)
turn right
else if (newPosition<oldPosition)&&(sprite is going right)
turn left
If this is the case (or something similar), then the glitch should have a chance of about 1/(Detection Distance) *1/(highest random number possible for a sprite to move before pausing) of occuring.
This begs the question- when sprites spawn near walls, how come they never get stuck immediately, regardless of their sprite widths.
also:
Is there some speed sprites could be programmed to move that would be so fast that it could cause the sprites travel a distance greater than that of the detection distance? If so, a sprite moving at that speed would be able to clip through walls at will. If not, then possibly detectionDistance=SpeedOfSprite/frame*1 frame. (the amount of pixels covered in one movement unit or frame)
Anyway this is all just a theory but I wanted to post it in case it helped Lemm or someone fix this obnoxious glitch.