• Play
  • About
  • News
  • Forums
  • Yppedia
  • Help
Personal tools

User:Birchle

From YPPedia

Contents

Flicker

Flicker, also known as winking, is when two or more overlapping objects fight for placement priority, causing the objects to "wink" or "flicker" by trading visibility rights back and forth.

Causes of Flicker

Underlying grid showing preset rendering priority.
Underlying grid showing preset rendering priority.

The Basics

The grid in the Editor is written with preset priorities that work as shown in the picture on the right. These priorities are passed on to any placed objects, such that they share the priority assigned to the base square(s). This means that anything in the first row will cover the next row, even if the object in the next row is farther forward (1 covers 3, 4 covers 7, and so on). Trying to go against that essentially guarantees flicker. Going with it doesn't guarantee there will be no flicker, but it increases the chances.

The grid and rock with the two key parts highlighted.
The grid and rock with the two key parts highlighted.

Objects have two distinct parts to consider -- the base (blue squares), which determines what priority the object is assigned, and the surrounding image (red squares). Because a rock's base is four squares, it has four simultaneous priorities, one for each of the squares it fills. Usually, this becomes a single average. Sometimes, depending on where and how other objects share a given square, and on how their averages compare, this average acts as though it has split into individual square-specific priorities again. The surrounding image, meanwhile, has no specifically associated square to give it a unique priority, so it takes the average priority of the base as its own.

When rendering occurs, it changes the priority of an object's base. However, this change does not carry over well to the image because of its lack of an associated square to enforce the priority change. This discrepancy between base and image priorities is the root of all flickering problems.

At-Risk Areas

When rendered correctly, two objects can usually overlap without any problem. Sometimes three objects can overlap without flickering, but it's rare. More than that, and something will flicker. There are also times when objects flicker because there is too much overlap in the vicinity, even if it's only several pairs of objects. In those cases, playing with rendering may fix it, but sometimes the only solution is to remove or redo the flickering section.

Overlapping objects with different flicker-risk areas color-coded.
Overlapping objects with different flicker-risk areas color-coded.

Usually, overlapping bases, rather than just overlapping images, are required for flickering to occur. If there are no overlapping bases and there's still flicker, cliff tiles are usually at fault, or sometimes a few leaves of a rain tree.

Color code for the picture to the right:

  • Red is the first rock, base and image.
  • Yellow is a new, overlapping, rendered rock.
  • Orange is where the two images overlap, increasing the risk of flicker.
  • Purple is where the two rocks share base tiles.

The two purple squares have the greatest risk of flickering, even though individually they would be two of four flicker-free squares. The middle yellow and red zones are the next most likely areas for flicker, followed by the orange areas, because of the unrendered average priority used by the images.

In the following pictures, the different shades of blue grid lines show the bases of the affected objects. The circles show where the object, currently flickering on top, is supposed to be below the other object.

Notice how the flicker is between the base of one object and the images of both (equivalent of the above labelled middle yellow and orange zones). Image:IDG-renderingflicker2.png Notice how the flicker is where the two objects' bases overlap (equivalent of the purple zone) as well as between the base of one object and the image of the other.

Guidelines

Flicker-safe tree and rock setup.
Flicker-safe tree and rock setup.

On the left:

Note: The tree should be rendered below the rock; above is only to make the base location obvious.

Assuming correct rendering, this is a fairly safe placement of a large singe-square object. The unrendered average priority of the rock is higher than that of the tree, so the images won't fight unless you try telling the tree to grow out of the front of the rock (as in the picture).


Tree and rock setup that will always cause flicker.
Tree and rock setup that will always cause flicker.

On the right:

This positioning is going to flicker regardless of rendering (Perhaps it would be safe if it were the only overlap in the entire scene, but overlaps tend to come in multiples...). Trying to hide the tree behind the rock will make the images fight, because the tree wants to be in front. Placing the tree in front, with roots growing out of solid stone, looks funny. It also flickers, for reasons unknown. The same frequently happens with scrubgrass placed in the front square of any 4-square object. Overlaping two low pumices on any corner/side also tends to cause flickering, often for no obvious logical reason, and almost as frequently it can be fixed by changing the rendering to what would seem to cause more flicker. And as a rule, the more overlap there is in any given area, the more flickers will result and need fixing.

Finding Flickers

In extreme cases, flickering will occur just by moving the mouse across the screen. Other times, placing an additional object will help locate flickers. Sometimes, scrolling to an entirely different part of the screen and back brings out more flickers. Any number of methods can be used to expose flickers; it just takes learning to watch for them to see them when they happen.

Powered by MediaWiki
Attribution

Puzzle Pirates™ © 2001-2008 Three Rings Design, Inc. All Rights Reserved.TermsPrivacy