The Additive Blending Test Demo

The Additive Blending Test Demo comes in both a dcr and open source dir movie. It contains two sections, which both aid developers and users in determining if the effect is supported, and what settings are required for their 3D card/system. First is the User Diagnosis Mode (UDM) where users can tweak several properties, the second is the Self Diagnosis Tool (SDT), which attempts to automatically determine which settings work.

Before you reach the sections though the movie does some very vital profiling and checking of the available 3D API's. It first ensures that hardware acceleration is available (software is ignored although it probably works in the same manor as DX5 does). Then it proceeds to switch through all the supported API's to check that firstly the users SW 3D Renderer setting isn't overriding the dcr, and secondly that they are truly supported. It also makes a note of the start up renderer, but this was mainly due to issues with starting up in DX5 and then having DX7 fail to achieve additive blending, when it should have. The reason this is no longer the case can be found in these questions and answers 'Why does API factor into getting additive support?' and 'Start up Renderer, who cares?'.

 

User Diagnosis Mode

In this section the user has complete control over a number of possible properties that might affect the display of additive blended textures. Several of these are no longer thought to be necessary but are maintained in case they become vital in the future, through changes to SW3D, new 3D cards etc.

Initially it starts up and uses the getHardwareinfo textureunits as the num of fill layers to use, taking into account which API is being used. On the whole this will be correct except for Macs (see Is the Mac getHardwareInfo reliable?) and ATI's Radeon 9000 series on PC.

On screen it displays a collection of textures rotating, that should appear with additive blending, so as textures overlay each other they get brighter. There is an info box, with some data about the specific test case being used and all the important data can be stored either in the clipboard, or emailed directly from the dcr.

If the additive blend effect is not viewable, then the user can elect to tweak the various properties. These including switching 3D API (where each is checked it is supported, and updates the num of fill layers based on its getHardwareInfo results), fill layer mode, which toggles between fill layers using an empty alpha channel or a plain bitmap. Then there are the Num of fill layers, which can be increased up to 24 for testing nextshader comparability (doesn't appear to have any affect). Finally num of additive layers, which should mainly be left alone, as if this value+ num of fill layers > 8 then it falls to using the nextshader and is unlikely to work.

These are the only properties that need be considered for additive blending, and hopefully there will be at least one combination that works on a users system.

 

Self Diagnosis Tool

With an understanding over how additive blending should affect a texture on screen, it has proved possible to automatically detect cases that pass. This is achieved through taking a screengrab of the SW3D sprite, displaying what should be an additive blended texture. Key areas in the texture will be black, whilst the SW3d background colour is set to pure blue. It then becomes a simple case of checking a few pixels from the screengrab in the area of the texture that is black. The resultant getpixel should return pure blue, as black applied via #add has no effect. Some care should be taken to give a tolerance to the colour check, e.g. colour.blue > 240 instead of colour.blue = 255, and further checks are required in areas of the texture that should be white, to ensure the whole texture hasn't just vanished and all we have left is the background colour of the SW3D member.

This process has proved successful in both DX7 and DX5, but alas a bug with openGL means it fails with that API on either Macs or PC's. The problem with openGL is that any method used to extract the rendered image, results in an image produced by the openGL software engine. This gives skewed results more can be found here (Why doesn't self diagnosis work in openGL?)

The process begins by creating a list of the most appropriate test cases based on API, and textureunits of the card. It then loops through these in turn, testing if the additive blending has worked. It will check all supported API's including openGL, but the openGL results are likely to be incorrect and always report 1 fill layer as passing. As it tests each case the screengrab is added to a gallery of images in the bottom half of the screen, for that extra bit of visual information.

There are two properties that can be tweaked, but neither should have to be used. The first is SW3D DTS, this is off by default and means the screenshot is produced via my preferred method, of setting the sw3d sprite DTS = false, and using copypixels of the stage. If turned on it uses the standard member.image fucntion. However my method gets around the memory leak with crash on Win98 machines when using member.image and it also appears much faster. Overall its highly unlikely that this option would ever have an impact on the results.

The second is max fill layers, which is similar to the one in the UDM. Here the default is 7, as thats the most fill layers likely to work. This value is used by the SDT when compiling test cases, as it will loop through from 1 to Max Fill Layers. Again as nextshader appears to have no impact, its unlikely this should ever be used.

As with the UDM, there is the copy to clipboard and send test results to access the information created by the test, which is useful for debugging.

 

Additive Blending - A Cunning Plan
 
Additive Blending - Test Results

 

All material including text, images, source, results and demos are copyright Noisecrime Productions
You may not modify, copy, reproduce or publish in any manner the material in this tutorial which includes text, graphics, html, or anything else with out written approval.

@ 1996-2003 Noisecrime Productions