Theory: How the Vorticon Glitch Works.

Request patches for Keens 1-3.
Post Reply
Stealthy71088
Posts: 583
Joined: Thu Mar 17, 2005 11:54 pm
Location: NY

Theory: How the Vorticon Glitch Works.

Post by Stealthy71088 »

I've done some experimentation with the vorticon to try to determine why it gets stuck in the wall, and how this could be possibly fixed. After much study, I'm come up with a theory as to how it works. I don't have the ability to look into the assembly and actually play with it though to see, but here's my theory.

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
Since the newPosition = oldPosition when distanceToWall=0, and the distanceToWall would normally never equal zero unless the sprites stops moving, the if statements won't fire, and the sprite won't turn.

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.
levellass
Posts: 3001
Joined: Wed Oct 11, 2006 12:03 pm
Location: Ngaruawahia New Zealand

Post by levellass »

* Interactions are not quite sprite\not sprite; there are a number of checks made every 'level loop', for sprites, every sprite in order runs a check for hitting tiles, hitting sprites, gravity, etc.

* For blocking the check controls whether Keen can pass into a tile, that is why Keen spawned in a tile can walk through it. The exception is doors, which change his momentum. In Keen Galaxy solid properties push Keen, to avoid clipping bugs.

* Many sprites have a 'reverse speed' code when they hit a wall allowing them to bounce off, others have a 'set speed to 0' code.

* Wall detection works via a simple check on relevant tiles, a sprite moving left checks the tile left of it, one falling tiles below it and so on. A sprite can only check two tiles at a time, one vertical, one horizontal.

* The check returns a value from 0-15, top blocking is +1, right blocking +2, down blocking +4 and left blocking +8. The sprite then acts depending on the value returned by the check.

* The two most common reactions are 'Tile top blocking AND sprite falling -> set vertical speed to 0' and 'If sprite moving right AND tile left blocking speed = left ELSE IF sprite moving left AND tile right blocking speed = right' That is, stop falling when hitting the ground and turn when hitting walls. A sprite may turn by using a new speed (Then it will have separate left\right speeds) or by a more complex process where a positive speed is turned negative and vice versa.

* It is possible to patch some speeds so that wall glitches always occur.

* Since there is no 'detection distance' no matter how fast a sprite moves it will not do anything untoward. Checks are taken from where the sprite will BE after one game tick, not where it is. At high speeds this can cause some interesting effects with hitting walls it hasn't traveled too, but by then it's moving so fast it's hard to tell.


What happens (As near as I can tell, I'm sure I posted this somewhere...) is that a sprite executes a behavior that sets its h speed to 0, usually this is searching, you will find if you set the Vorts, Yorps etc to not search, they will not glitch.

When this is done up against a wall AND that wall is in the same direction as Keen (That is, to get to Keen the sprite would have to move into a wall) the 'you're hitting a wall' code is triggered. But the sprite speed is zero and it has no 'reverse' speed in this behavior. As such it can't move away from the wall and its speed remains 0.

Since walking sprites don't care what their speed is, they will 'walk' with a speed of 0 and not make any more collision checks, thus they won't be able to change their speed unless checking for Keen again. This is why stuck Vorts can be cured by moving to the other side of them, when they will look for you and walk away from the wall.
Stealthy71088
Posts: 583
Joined: Thu Mar 17, 2005 11:54 pm
Location: NY

Post by Stealthy71088 »

levellass wrote:
What happens (As near as I can tell, I'm sure I posted this somewhere...) is that a sprite executes a behavior that sets its h speed to 0, usually this is searching, you will find if you set the Vorts, Yorps etc to not search, they will not glitch.

When this is done up against a wall AND that wall is in the same direction as Keen (That is, to get to Keen the sprite would have to move into a wall) the 'you're hitting a wall' code is triggered. But the sprite speed is zero and it has no 'reverse' speed in this behavior. As such it can't move away from the wall and its speed remains 0.

Since walking sprites don't care what their speed is, they will 'walk' with a speed of 0 and not make any more collision checks, thus they won't be able to change their speed unless checking for Keen again. This is why stuck Vorts can be cured by moving to the other side of them, when they will look for you and walk away from the wall.
Does this mean that all we'd have to do is find the search speeds and set them to 1?
levellass
Posts: 3001
Joined: Wed Oct 11, 2006 12:03 pm
Location: Ngaruawahia New Zealand

Post by levellass »

I believe that might well do the trick, or if not 1 then a similarly low speed like 2 or 4.
Post Reply