Levels of Fixing

From Bo3b's School for Shaderhackers
Jump to: navigation, search

Beginner 0 - change profiles

As a very first step in fixing games, it is often worth trying different profiles, because sometimes you can fix a game by simply putting it on a better profile. A good example is Defense Grid, where simply switching profiles makes it flawless.

Beginner 1 - remove effects

The very first fixes are simply to remove broken shader effects.

Maybe we can't describe these as actual 'fixes', but if we can take a game from being unplayable to playable, that would seem to qualify as a 'Fix'.

Anyone can learn how to disable shader effects. If you can edit a .ini file, you can remove effects.

You will need to get familiar with the basic assembly shader structure, but that is all. Structure are the pieces that define variables, including the key input and output variables.

Beginner 2 - move to depth

The next level of fix is to move an effect to the right depth.

A skybox might appear annoyingly close in 3D, and we can move it to infinity where it belongs.


Intermediate 1 - separate textures

Separating textures is necessary when a specific shaders is being used for multiple parts of the image.

For example, the HUD and the Crosshair might both be drawn by the same shader. To move the Crosshair to depth, without impacting the HUD is where we would separate textures.

You will need to understand what textures are, and how textures are applied to the wire-frame models. Also how to use HelixMod to find textures and specify their use on specific shaders.

Intermediate 2 - stereo-correction

At this level, we want to actually correct a position in 3D space.

An example would be moving player nameplates from screen depth to a better object depth. Or fixing halos around characters.

You will need to understand how vertex shaders and pixel shaders make up the graphics pipeline, and why vertex shaders usually are the spot for deciding depth. You will also need to understand the stereo prime directive, which is the simple math behind what changes perceived depth.

Advanced - deferred-rendering

This level generally fixes effects in PixelShaders, where the developer is using the deferred-rendering technique.

Examples are some lighting effects, and often shadows.

You will need to understand how objects are stereoized in the first place, and how the graphics pipeline works for deferred-rendering. You will need to be able to roughly understand shader language to determine if deferred-rendering is being used. And then apply several common techniques to fix the depth.

Beginner fixes do not require shader knowledge, or DX9 knowledge. You just need to learn "what to do". Studying other peoples fixes will help you absorb it pretty quickly, and bo3bs references above have loads of stuff. These beginner fixes are NOT using "full stereo correction", but more are 'moving things to fixed locations/depths' etc. 1. Read the stuff on what the helixmod dll is, the difference between the debug and the releae 2. Learn how to disable problematic shaders. This will crystalize your understanding of the basics of using the helixmod wrapper, stepping through shaders, editing them etc. 3. Find a game (even if it's already been fixed!) that has a skybox at the wrong depth. Fix it using the instructions in the original Helix guides. 4. Similarly, find a game with a 2D hud. Practice moving the hud elements to different depths. ** When you can do the above 3 things, you will actually be in a great position to start creating fixes that make games playable. This is not insignificant! 5. Next step would be spending a bit more time looking at how you "separate textures" - this is really useful for HUD fixes, so you can move some parts of the hud and not others. It's also essential for some games where fixing one part of the game (e.g. moving a HUD element to depth) also affects some entirely unrelated part of the game (objects in the world). ** With the above, you can now do some fancy stuff :-) == Intermediate 2 == Intermediate fixes start to require some knowledge of what is going on in the vertex shaders, and they start to use "full stereo correction" i.e. the actual formula that Nvidia uses to inject stereo in the drivers. Only Vertex shaders are involved. 6. Haloing: A lot of the really nasty looking issues in games are caused when things "halo" or "double/triple image". There is an absolute (almost universal) reason for, pattern to fixing, all of these issues. I will state it here for when you are ready to tray this out. In a VS the "output position" variable is calculated from a View Projection transformation (you need to read about what that is), and this is what defines the coordinates of objects in the scene - the nvidia drivers specifically stereoizes these output variables. However, what often happens in games is that a temporary variable is used for the result of the VPM transform, and then used to set the output position variable. The problem comes when this same temporary position variable is additionally output to other "texcoords" that get used in later Pixel Shaders. These texcoords do not get stereoized by the Nvidia driver, and so in the pixel shaders they are the wrong coordinates. The fix is to manually stereoize the temp position variable before outputting to the texcoord. There are loads of example fixes for this 7. Water: Many (but not all) water effects are vertex shader issues, and this is where you would start looking for a solution. Main issues are haloing and reflections. Both of these are often fixed the same way as above in point 6. == Advanced == These fixes require Pixel Shader correction. They require you to understand much better the graphics rendering stages, the coordinate systems, and the transformations between them, including what the stereo correction is doing - this background is actually the most important part. You still do *not* need to know much about shader programming, though it will start to help a teeny bit to understand how to apply matrix transforms. I am not going to go into detail right now, but there are a few levels at which PS correction is relevant: - Accepting a newly defined replacement variable from a parent VS and using that (e.g. a stereoized version of some texcoord that is needed in only one part of the PS, but not everwhere) - What is called "texture coordinate" corrections to offset where sample maps are sampled (often a texture coordinate needs to be "built' form something call vPos) - Direct correction of projection space coordinates (easiest) - Indirect correction of world space coordinates for deferred rendered shaders (hardest)

Big thanks to Mike_ar69 for providing the initial text layout.

Consult the User's Guide for information on using the wiki software.

Wiki Getting started