Table Upgrade Guide

c-f-h edited this page Jun 23, 2014 · 19 revisions

Upgrading legacy VP9 tables for DirectX 9

Legacy tables are all tables created for a DirectX 7 version of VP9, i.e., VP 9.2.1 and earlier. VP 9.9, the initial DirectX 9 release of VP, generally has very good compatibility with legacy tables, but some aspects may need tweaking.

Lights with transparent textures

It's a common technique in VP9 to have lights covering parts of the playfield, for instance for simulating GI. The used textures typically have black areas which are intended to be transparent. In legacy VP, these areas were transparent automatically, however in DX9, the transparency color has to be set accordingly.

This issue most commonly manifests itself through blacked-out playfield lights.

To fix this, go to Table > Image Manager, find the textures in question, click on the Transparency color, and set it to pure black (RGB 0/0/0).

Draw order problems

VP 9.9 uses an automatic depth ordering system for transparent objects like flashers, alpha ramps, primitives with transparent textures, and so on. The order of these elements in the editor does not matter, VP tries to determine a proper ordering itself which is based on the height (z-coordinate) of the object. This works well in most cases, but sometimes VP needs a little help to figure out the proper order. In general, transparent objects need to be drawn from back to front in order to get correct results.

This issue can manifest itself as lights not showing or being partly cut off, alpha ramps having visual glitches, light halos overwriting table elements which are supposed to be visible, and so on.

To fix this, a new Depth Bias parameter has been introduced to these objects. A negative Depth Bias value pulls the object closer to the camera (for the purpose of depth sorting only, the objects are not actually moved) and therefore makes it render later. A positive Depth Bias value makes the object render earlier. Depth Bias is specified in VP length units.

The most common problem of transparent lights (realized through alpha ramps or similar methods) not rendering properly is usually easily fixed by assigning them a negative Depth Bias.

Future-proofing VP9 tables for VP10

The tweaks described above are generally sufficient to make legacy VP9 tables render correctly in VP 9.9. However, since VP10 is already on the horizon, it's a good idea to start now on getting rid of old methods which won't be supported in VP10 anymore.

Multiple overlapping light objects (fading lights)

Note: VP10 now has a changed light system, so the following isn't completely correct for VP10 tables. Overlapping lights still have to be reduced to one, though.

Most VP9 tables realize fading playfield lights by layering multiple light objects with the same shape, but different textures on top of each other. The light with the last changed state would then be drawn on top of all others, making it the only visible one.

VP 9.9 emulates this behavior by sorting all playfield lights according to when they were last updated. This however comes at a certain cost in complexity and performance and will not be supported in VP10.

There is a much simpler way to realize these fading lights in VP 9.9 and onwards: the texture of the light object can be changed through the script directly (see the OffImage and OnImage properties of the Light object). This means that only a single light object needs to be used per playfield light, which also improves performance since it reduces the number of lights the engine has to render each frame.

This technique is already fully supported in VP 9.9 and is therefore the recommended approach for new and updated tables. The community will presumably develop new vbs scripts to replace the legacy fading light routines soon.

Region update lights

A common technique in legacy VP9 were pure black light objects (rarely also other object types were used) which were completely invisible and had the sole purpose of making the engine update the visuals of whatever was behind them. This was due to the design of the DirectX 7 engine, which had a region-based update system and tried to render only changed parts of the screen.

In VP 9.9 and onwards, the entire screen is rendered every frame, and therefore these update lights are not needed anymore. They should be removed completely.

Region updates triggered from script

Later DX7 versions (VP 9.2.0 and later) introduced script functions, UpdateRegions and TriggerSingleUpdate, which were designed to make the use of region update lights as described above unnecessary.

Again, calls to these functions are obsolete in all DirectX 9 versions of VP and should be removed completely.

Sprite-based rendering properties

Many objects in legacy VP9 were first pre-rendered to a number of animation sprites and then blitted onto the playfield. In DX9, these elements are typically rendered completely dynamically. Therefore, some properties are now obsolete and will be removed in VP10:

Gate: Animations

Spinner: Animations

Sprite flippers

Some VP9 tables make the flippers invisible by setting their color to pure black and then rendering bitmapped flippers in their place. This is done to enable decorations on top of the flippers. On modern tables, it's better to use a primitive which is rotated along with the flipper.

In VP10, it will be possible to replace the flipper model completely with a custom flipper mesh.

Acrylic ramps

Ramps with the "Acrylic" type are used in some old tables to emulate transparent ramps. Alpha ramps are a much better way to do this, and Acrylic ramps will be removed in VP10.

Porting tables to VP10

First, make sure that you have done everything under Future-proofing above. The following are breaking changes between VP9 and VP10.

Camera positioning

The bugs in the VP9 camera positioning routine have been fixed for VP10. This means that the parameters under Backdrop > Colors & Formatting have to be changed. Most tables shouldn't need an offset now, and the scale should be close to 1.

To fix old tables, set the X Scale and Y Scale to 1, set the X Offset and Y Offset to 0, and adjust from there if needed.

Light source positioning

In VP9, all light sources had their Z component flipped. To fix this, go to the "Lightsources" pane on the table and change the sign (+/-) on the Z components of all light source positions and directions. If the light parameters are all 0, you don't need to do anything.

Scripting changes

The IsVisible property on ramps and flashers has been renamed to Visible to be consistent with all other objects. Transparent ramps can now have their visibility toggled using this property.

The TopVisible property on primitives has been renamed to Visible for consistency.

The Alpha property on ramps is now called Transparent to be consistent with walls and to avoid confusion with the Opacity parameter. In most cases, however, Alpha was used to toggle the visibility of ramps, and this should be done using the Visible property now.

Functions UpdateRegions and TriggerSingleUpdate are not needed anymore and have been removed.

The property CollisionMass of the ball object was renamed to Mass and affects all physical interactions now, not only ball/ball collisions.

Upgrading to VP10 physics

VP10 has a completely overhauled physics engine; see the page on VP10 physics for more information. Here are some very basic instructions for modifying a VP9 table to work with VP10 physics:

  1. Backdrop > Physics & Graphics: Gravity 1, Playfield Friction 0.08-0.1
  2. Table properties > Slope & Dimensions: set the table slope (around 6 on modern DMD tables, lower for older SS and EM tables)
  3. Select all flippers and adjust the physics parameters: Mass 1, Strength around 1000-3000, Elasticity 0.8-0.9, Friction 0.8, Return Strength Ratio 0.10
  4. Due to the extra energy needed to get the ball rolling, plungers, slingshots, bumpers, etc., typically all need to have their force increased by 20-40%.
  5. Physics scripts like BMPR or light tap scripts should not be used with the new physics engine. Also, many VP9 tables have small helper routines which adjust the velocity of the ball on ramps etc, these often do not work well and should be removed.

See the page on VP10 physics parameters and flipper parameters for more help on how to tune these values!

BigBoss gives some additional guidelines in this forum post:

Clone this wiki locally
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.