# What causes polygonal twitching in older games?

I'd like this answer large part to curiosity and I'd like to recreate it with our modern computers somehow.

By old games I'm referring to ps1 games. My specific example would be Megaman Legends I've not really noticed it in any other games maybe Final Fantasy 8. There probably are others.

When your looking around, vertices "lock" into different locations very twitchily. The Textures follow too. Sometimes vertices supposedly connecting to each other are in two different locations looking like one is jutting out of place.

Heres a video of the game. You have to look at about mid range to see changes is location.

Its probably not something uncommon to old polygonal graphics.

My only theory is its rounding floating points to the closest integer but that doesn't seem plausible to me.

 PSX doesn't have floating points there goes my theory XD.

I'd like to hear anyone's theory even if they don't know. Take a stab. I'll investigate any of them myself.

• The PS1 had no hardware support for floating point at all. Commented Feb 16, 2013 at 13:13
• Thats good to know. Commented Feb 16, 2013 at 13:24
• If you're going to ask a question like this, you should at least post a sequence of pictures or a link to a video. As is this question is incomplete Commented Feb 17, 2013 at 17:44
• Theres your link >.> . Boy this place can be fun Commented Feb 17, 2013 at 18:37

Floating or fixed point precision would have caused this problem. Older games commonly used fixed point as it was traditionally faster than floating point, prior to widespread FPU support in consumer machines which began in the early 1990's. (The Intel 386SX / DX gap showed the floating point performance difference clearly in a game like Doom which relied heavily on fractional numbers.)

Consider a range of numbers which uses only 1 decimal place. If every full unit were to represent a metre, then every decimal place would represent a tenth of a meter (AKA a decimeter). Since this is your maximum precision, objects will obviously jump in increments of 0.1m, rounding up or down to the nearest decimeter as necessary.

Fixed point is how we tend to traditionally think of decimal point numbers: numbers that can be represented down to some smallest fraction of a single unit (as in the above decimeters example). However, given that every number must be stored in a certain number of bits (for modern IEE-754 floating point, a commonly-used standard, this is 32 bits or 4 bytes), we have a limit on precision for what sits to the left of the point, i.e. the significand, and what to the right of it, i.e. the fraction.

Now, given n total bits in which to store such a number, we have two choices.

• We can choose to use x of n bits to store the upper part, and the remaining y of n bits to store the lower part, in a fixed point format (eg. 16.16 fixed point, a total of 32 bits used). This is conceptually simple, but not space-efficient.
• Floating point offers another option, and this is why it is named "floating": The bits can be used in a variable configuration to provide a much larger range, at the expense of whatever is on the other side of our "floating" decimal point. Range for the fraction comes at the expense of the significand; and vice versa. Given this, one can see how smooth movement over galactic (or greater) distances is possible in simulations (googling single-precision floating point range" will indicate just how large a range 32-bit IEEE-754 can support, never mind higher-precision standards which use 64- or 128-bit words.)

This should give you some indication as to why in this age, where even low-spec mobile devices now support floating point arithmetic, we no longer have the aliasing effects you describe.

As for the vertex issue, I find it likely that this is due to the fact that before GPU tech became widespread in the days of 3DFX, it may have been common to duplicate vertices, possibly because getting a good winding order along with linear (and thus efficient) data access is not a particularly trivial problem and it may be easier for performance reasons to simply duplicate most vertices so that each triangle consists of 3 unique vertices... this would positively impact cache performance at the very least. In that case, vertices might be matched in any of a number of ways, from manual entry to precalculated positions for different orientations to runtime calculation. But I am going to hazard a guess that this sort of thing is unique for every game. I remember games which simply didn't do this at all. So it is likely this was a specific quirk of individual engines that occurred for different reasons.

• That was an amazing amount of information O.o. I think I'll end up giving you the correct answer. So to recreate this effect I would enlarge a scene and use only integers. Does this explain when two seemingly touching vertexes split into two different locations? If you get real close they touch but sometimes they'll split anywhere from medium to far distance. You'd think they would go to the same fixed point being so close to each other. Commented Feb 17, 2013 at 17:56
• I can post a link to any megaman video you should see the twitching parts but the splitting isn't something I can just find. It obviously didn't happen that often or it would of been bad for the game. Kinda comes with having played it a few times. As to your previous comment you answered it just fine without any kind of reference >.> . Thanks for all you've done. Commented Feb 17, 2013 at 18:25

It could have to do with how they used to (and still do) reduce the detail of polygons the further away they are from the player. When the player gets closer to the scenery then the extra vertices are added which causes the mesh to seemingly 'pop' at certain places. Also, from looking at the video they employ mip maps and fog which further reduces the rendering power required and which also contributes to the antiquated look of the game. Beyond that your guess is as good as mine.

• Thanks. I was aware of the LoD. Its usually only two stages and its the whole object not pieces at a time. I was suspect of Mipmaps however I'm not sure whether that plays a role or not yet. Other than changing the texture quality I don't think it affects vertex location. I was not aware fog reduces the amount of calculations. I thought it made more. Thanks a lot for the input. Commented Feb 17, 2013 at 8:49
• What I meant by that is that the use of fog calculations is a cheap way of obscuring the reduction of detail that happens when you use a lower res texture via mip maps. They do add a very small bit of calculation. Commented Feb 17, 2013 at 9:39
• I wanna recreate this effect so bad but it seams much hard to crack than I thought. Commented Feb 17, 2013 at 11:43