Tweaking the Graphics

Dave Whiteside of Rowan released this information abput tweaking the graphics settings.

This information is for advanced users only. You probably can't hurt your computer by fiddling with this file, but may stop the game running and neccesitate a fresh installation.

Notes on Rowan's Battle of Britain's cardbase.rc file.

Why does Rowan's Battle of Britain need a cardbase.rc file?

The cardbase.rc file allows for the graphics engine to be tuned by hand and for specific machines and tastes. For example some of the W/Z buffer issues may be a matter of taste, if someone is happy to lose a small amount of resolution close up in order to gain a greater view distance then they can make tweaks for their own specific hardware. Also cardbase.rc allows Rowan's Battle of Britain to be more future proof. For example when Rowan's Battle of Britain was mastered the Geforce2MX card was not available so anyone with that card would have had to have waited for a patch to make the card work. As it is they can just add the correct line to the cardbase file and then get flying. Also a graphics chipset may be used by a number of card manufacturers to build their own cards some of which need different fixes. What we have attempted to provide is a generic set of solutions, but allow fine tuning and tweaking where desirable.

Tweaking the Graphics "Below is a slightly expanded explanation of what the different options within cardbase do and why they are present.

General fixes:


Try this if there are fog problems (usually things are blue in the wrong places) or everything is blue. Some cards offer this ability as an option - for example the geforce cards can switch off fog table emulation at which point this will need to be added to the fix list.


If the sea looks wrong or the cloud layer looks wrong then this may be the option for you (also effect the dither antialiasing). The sea animation will look poorer as will the cloud layer as only one texture will be applied to a polygon at a time.


This can fix the problems from the above in a more satisfactory manner. Also if the game can't even get into the 3D it is a good idea to try this one. What it really means is ignore the capabilities that DirectX reports and assume it can handle best guess approximations on its own.



If textures seem to be cut off or you can't get into the 3D then using these two fixes with values of 256 or 128


Don't do guardband clipping if it is available. Some graphics cards allow for polygons to be drawn to a larger area than the screen buffer without clipping - they define a guardband region. This option should not really be needed unless a card enumerates wrongly.


This can fix problems that may occur with the luminous transparency blending, use if the view reticle in the cockpit and the lens flares look wrong.


Use if textures don't mesh or tear along polygon edges in the landscape and clouds. This means that during Rowan's Battle of Britain's polygon transform stage the whole size of the scene will be scaled down to prevent the sizes of polygons from being bigger than can be fitted into a 16bit value. It seems that some cards only do 16bit internally for texture calculations and require this."

Try these if tiles (squares) of the landscape are black or the wrong colours.


This renders textures into the back buffer not directly into the texture. Can cause some stuttering.


This doesn't use a hardware blit for copying the textures but a software copy. Can cause stuttering but only when lots of tiles need building (i.e. spinning the view around the horizon)


As above, however only one of this fix and the previous one can be active at once, if both are a line then the last to appear will be used. This is even slower than the above.


As above, sometimes a better option as can be quicker, however can use up gfx card memory in 32 bit colour depth. However when the pixel formats are the same a hardware blit will often work. The comparative speed of using this and SLOW_TEXTURE_DOWNLOAD to fix non working blits is system dependant and effected by such things as AGP/PCI bus speeds and aperture sizes as well as hardware blit speeds.

If there is only a 16 bit or smaller z buffer available we will use a z buffer, otherwise we will use a w buffer if the card claims it can. The reason for this is that z is non-linear - it has a greater resolution when objects are up close to the viewpoint. This is needed when there is only 16 bits available otherwise depth clipping of objects - such as hangars etc - against the landscape scenery may be unreliable. W buffering is however needed for detail in the distance, as it is linear all of the way to the horizon. This is why the far horizon option only works when a 32bit w buffer is in use - which requires a 32bit colour depth as the two are locked together on most hardware.


Always use a W buffer


Always use a Z buffer. Symptoms for needing these fixes include the 3d not being displayed over the splash screen, only the 2d overlay.


Fakes a w buffer using z, can prevent the above being used. This fixed fog and specular for the voodoo 5. I this case direct X thinks that a z buffer is in use but is fed w values in the z parameter for sorting."