Difference between revisions of "HelixMod Feature List"

Latest revision as of 20:36, 8 September 2019

Gotchas

HelixMod

• Gotcha - it's a good to add comments to your DX9Settings.ini, but beware that comments must go on their own separate lines. If you add them to the end of a line the entire line will be ignored.

• Gotcha - Pressing F7 in the game (to save custom separation and convergence settings to a preset) will remove all comments (in fact - all lines the DLL does not understand) from the DX9Settings.ini. It seems that comments starting with a semicolon instead of a double slash are retained.

• Gotcha - Games can sometimes crash when moving the view with the mouse, when a particular shader is disabled while hunting. Press the Numpad- key to clear the disable list before moving to a new spot.

• Gotcha - Any [VSxxxxxxxx] section must come after any key and preset definitions. Otherwise key functions will be silently disabled.

ASM

• Gotcha - You cannot use two different constant registers in a given instruction. add r30.x, c250.y, c220.x will silently fail. But add r30.x, c250.y, c250.x will work. Use temp registers as a workaround.

• Gotcha - Output registers cannot be read. mov r3, o0 will silently fail, but still assemble. Overwriting an output register works.

• Gotcha - Reading from a masked component of an input register can cause strange results (in some cases fixing the issue is insufficient to make the weirdness go away and the game has to be restarted). e.g. if an input register was declared dcl_texcoord5 v6.xy, then doing a mov r30, v6 is illegal as it tries to read from all four components of v6, the z and w of which are invalid.

• Gotcha - Right side swizzles can silently fail if you only use 2 or 3 parameters. e.g. mov r1.yzw, r30.xyz will silently add w to the end giving the result mov r1.yzw, r30.xyzw which maps yzw to yzw, which is not what you expect. mov r1.yzw, r30.xxyz is correct.

Helix Mod Advanced Techniques, Tips and Tricks

This section is mostly for advanced techniques that may be useful in certain situations. For the basics of using Helix mod, refer to the lessons.

Shader Hunting a Vertex Shader for a Given Pixel Shader (or vice versa)

If you are having difficulty finding a pixel or vertex shader for a given effect, but you are able to find the other type of shader for the effect, you can look at the numbers next to VertexPair and PixelPair to work out possible shaders.

e.g. If you are looking for a pixel shader for an effect, but can only identify the vertex shader, cycle until the vertex shader is disabled and look at the number next to VertexPair. Then cycle pixel shaders to that same number and you will be on the corresponding pixel shader.

Note that these numbers may change while cycling shaders, so I'd suggest cycling both pixel and vertex shaders to different effects and back to make sure the numbers still match up.

e.g. If you have successfully disabled both vertex and pixel shaders for the same effect, you will have VS = PixelPair and PS = VertexPair, like this:

   VS 36 CRC32 0xblah PS 28 CRC32 0xblah ... VertexPair 28 PixelPair 36

Also, keep in mind that that some effects may have multiple layers, so you may need to check several shader pairs (and sometimes these even have the same CRCs for one of the shaders) to find the right one.

Texture Hunting and Filtering

If you have altered a shader and find it is affecting things that you would rather leave alone, you need to find a way to distinguish between the different effects it is used for. This is quite common for UI shaders, where you may only want to adjust the depth for part of the UI (e.g. crosshair), or where you find the UI shader also affects other non-UI things in the scene. One common technique do achieve this is by filtering on the CRC of the texture used for the effects.

To get started you will need to identify the CRCs of the relevant textures. Helix mod supports hunting for textures in much the same way as it does for shaders. To get started you first need to add bCalcTexCRCatStart = true in the ini. The up/down arrow keys will cycle textures by default, but you can change them with PrevTexKey and NextTexKey if they interfere with the game.

For the most part textures will go black while they are disabled, and once you have found the right one you should write down the CRC displayed in the red text (if they are shorter than 8 characters, pad them with zeros in the same way we do for shaders).

You will need to add a section similar to the following to the ini file (replace nnnnnnnn with the CRC of the vertex shader you are filtering in):

   [VSnnnnnnnn]
   CheckTexCRC = true
   ValForDefined = 1
   ValNotDefined = 0
   TexCounterReg = 251
   UseDefinedOnly = false
   DefinedTexturesVS = 01234567;89ABCDEF;

The DefinedTexturesVS list needs to be filled out with the texture CRCs you found. You have two choices - you either need to list all the textures where you *DO* want the depth adjustment to be enabled (whitelisting), or list those where you *DON'T* want the adjustment to be enabled (blacklisting), but *not both*. If you can only find textures for some of the effects that might force your decision, or if you find that one way would require you to keep finding more and more textures it might be easier to go the other way (e.g. for a while in Dreamfall Chapters I was whitelisting every texture used on an inventory object, but that didn't seem smart as I'd have to keep finding more and more textures, so I blacklisted the inventory background instead).

It's probably worthwhile leaving a comment in the ini with what CRC corresponds with what. It's also a good idea to leave a comment for the textures you didn't inlcude in the DefiendTexturesVS list as well, so if find you need to invert the test later on you don't have to hunt them all again.

In the shader you will be able to determine if the texture was in the list or not by testing the x component of the constant register defined by TexCounterReg (c251.x in this example). If it is in the list, it will have the value in ValForDefined (1.0 in this example), otherwise it will have the value defined by ValNotDefined (0.0 in this example).

Then, in the shader you add an if_eq around the stereo adjustment, something like:

   def c220, 0, 1, 0.0625, 0.5 // Added a 0 and 1 in .x and .y of this constant
   
   // ...
   
   // We can't use two constant registers in the same instruction, so copy
   // TexCounterReg to a temporary register first:
   mov r29.x, c251.x
   
   // Test if the texture is whitelisted if TexCounterReg.x == ValForDefined
   // For blacklisting, check if TexCounterReg.x == ValNotDefined instead
   if_eq r29.x, c220.y
   
       // Whatever needs to be conditional, e.g. a UI depth adjustment:
       texldl r31, c220.z, s0
       mad r30.x, r31.x, c200.z, r30.x
   
   endif
   
   // Anything that needs to always happen, e.g. copying the temporary position
   // register to the output position register:
   mov o1, r30

Reliability: Sometimes a texture will have a different CRC every time the game is launched which will make it impossible to filter on. In this case the test should be inverted to avoid the need for that CRC, or an alternate filtering method will need to be employed.

Pixel Shaders: Helix Mod appears to support texture filtering in pixel shaders as well (with DefinedTexturesPS and a TexCounterReg no higher than 223), however it appears that this may not work. One possible workaround might be to use the vertex shader to pass the TexCounterReg through to the pixel shader as an extra texcoord output.

Overriding an Individual Instance of a Shader

If you find multiple shaders with the same CRC and need to apply different fixes to each instance, you can add an index number to the filename, as in XXXXXXXX.txt.1, XXXXXXXX.txt.2 and so on.

This technique was originally documented here:

http://helixmod.blogspot.com/2012/03/dlls-update.html

Examples of fixes using this technique:

• http://helixmod.blogspot.com/2014/01/divinity-original-sin-alpha-3d-vision.html

• http://helixmod.blogspot.com/2012/03/x3-terran-conflict-and-albion-prelude.html

Overriding a Vertex Shader Based on the Matching Pixel Shader

If you find a vertex shader that is used for multiple effects and you need to apply different fixes to different instances of the vertex shader you need to find a way to distinguish between them. If they use different pixel shaders you may be able to use this technique to do so.

You will need to hunt down the pixel shaders for each of the effects you need to fix. These will all need to be added to the ShaderOverride\PixelShaders folder, though you do not need to alter them (except maybe to upgrade them to ps_3_0 if they are an earlier version).

Then, rename your vertex shader to the CRC of the pixel shader and add a .txt.ps extension (e.g. if the pixel shader for the UI was 12345678.txt, you would rename the vertex shader to Shaderoverride\VetexShaders\12345678.txt.ps). Make a copy of this shader for each pixel shader and name it appropriately.

Then, apply the appropriate fix for each of the vertex shaders for whichever pixel shader they correspond with.

Default vertex shader:

If you find a vertex shader used for a lot of effects and most of them need to be fixed in the same way, you may prefer to leave a default vertex shader with it's original filename for most of the effects, and use the pixel shader specific ones only where you need a different fix. Note that reliability issues have been noted in this case, where a pixel shader specific vertex shader may sometimes be used in other instances.

Example:

In Montague's Mount, one of the vertex shaders is used for three different effects - part of the UI, the lens flare and halos around lights. Originally I was using the texture filtering technique to distinguish between UI and flare/halos and depth to distinguish between flares and halos:

https://github.com/DarkStarSword/3d-fixes/blob/c8956ee23d6ad7518dd31b1bbe6c2467b10c158c/Montague%27s%20Mount/ShaderOverride/VertexShaders/CD61F9B3.txt

As an experiment, I replaced the texture filtering technique with these two separate vertex shaders (the flare and halos use the same pixel shader, so I still needed the depth test to distinguish between them):

• UI: https://github.com/DarkStarSword/3d-fixes/blob/acf86f567ef91cfc6e6d5557294f0bf47bc7d337/Montague%27s%20Mount/ShaderOverride/VertexShaders/75DCC6F8.txt.ps

• Lens flare/halo: https://github.com/DarkStarSword/3d-fixes/blob/acf86f567ef91cfc6e6d5557294f0bf47bc7d337/Montague%27s%20Mount/ShaderOverride/VertexShaders/4028F8B5.txt.ps

• diff: https://github.com/DarkStarSword/3d-fixes/commit/acf86f567ef91cfc6e6d5557294f0bf47bc7d337

Inserting a Missing Vertex Shader Before a Pixel Shader

This is a variation on the above, but for the situation where you need to move the position of an effect, but no vertex shader exists for the effect, but a pixel shader does. In this case you will have to manufacture a new vertex shader that has the passes it's inputs straight through to it's outputs (except for the position which you are adjusting).

Presumably you would need to pass through any inputs that the pixel shader uses, such as texcoords, colors, etc.

This technique is known to be used in the X3 fix:

http://helixmod.blogspot.com/2012/03/x3-terran-conflict-and-albion-prelude.html

Overview of DX9Settings.ini

[General]

UseAlternateCRC

This is either true or false. It is unclear if this was a general feature or specific to a given game. It is believed that it was provided to get round the issue whereby a game will write the installation directory to the shaders, so the CRCs are different depending on where the game is installed. The alternate CRC is calculated by disassembling and reassembling the shader, which has the result of stripping any headers.

Currently only know to be used in DarkSiders2.

If this is true there are a couple of things to keep in mind in the shader dumps:

• Dumps/AllShaders/PixelShaders - files named by original CRC, headers intact
• Dumps/AllShaders/VertexShaders - files named by original CRC, headers intact
• Dumps/SingleShaders/PixelShasers - files named by alternate CRC, headers removed
• Dumps/SingleShaders/VertexShaders - files named by original CRC, headers removed

It is unknown whether the original or alternate CRC must be used in the ShaderOverride directory for vertex shaders and/or pixel shaders. The fact that vertex shaders are still dumped using the original CRC suggests they may need to use the original CRC, but it is unclear.

DefModuleName

This is used in conjunction with the separate helix launcher tool to define the name of the game executable to hook to. It was introduced to get around issues some games had with Steam, Uplay etc.

InitMouse

This is either true or false.

Set to false if you find a game where the mouse stops working.

ProxyLib

Used to specify another d3d9 proxy dll to pass onto after "finishing" the helix dll operation. Often used to specifiy other post-process injectors like sweetfx etc.

UseRenderedShaders

UseRenderedShaders=true is nearly always useful, because it trims the list of shaders seen while hunting down to just those active in the current scene. Disable this only if you get crashes during hunting.

DumpAll

DumpAll will generate ASM text files for every shader seen by the game. This is usually worth doing once, but not useful for every run.

DefPSSampler

Defines which sampler register is used to retrieve the stereo settings from pixel shaders.

Defaults to s13

DefVSSampler

Defines which sampler register is used to retrieve the stereo settings from vertex shaders.

Note that you need to add 257 to the desired sampler number (this quirk only applies to vertex shaders).

Defaults to s0

DefVSConst1

Defines which c register Const1 through Const4 will end up in in vertex shaders.

Note that all four constant values end up in the one register as x, y, z and w. e.g. to access Const2 you would use c200.y if DefVSConst1 is set to 200.

It's a good idea to search through the AllShaders dump to find a constant register that is not used by the game.

DefPSConst1

Same as DefVSConst1, but for pixel shaders.

DefVSConst2

Defines which c register Const5 through Const7 will end up in in vertex shaders.

NOTE THAT THIS IS NOT WHERE Const2 ENDS UP - THAT IS IN DefVSConst1!

Note that all four constant values end up in the one register as x, y, z and w.

DefPSConst2

Same as DefVSConst2, but for pixel shaders.

NOTE THAT THIS IS NOT WHERE Const2 ENDS UP - THAT IS IN DefVSConst1!

PresetsKeysList

Defines which KEY sections are used by the DLL. Note that every number in this list needs to be followed by a semicolon, including the last number.

UseEndScene

This can be "true" or "false". If you have issues with the rendering of the red CRC text, so either you can't see it, or on occasion it gets rendered *in game*, projected on objects, or perhaps it might be rendered as really large text, cycle these values.

bCalcTexCRCatStart

Enables cycling of textures using PrexTexKey and NextTexKey

PrevTexKey

Defines which key cycles backwards through textures. Must have bCalcTexCRCatStart = true

Default Value: Down

NextTexKey

Defines which key cycles forwards through textures. Must have bCalcTexCRCatStart = true

Default Value: Up

DefPSViewSizeConst

This has a default value of 221. It is used to store screen size in the x and y values, and the inverse screen sizes in the z and w values. This is primarilly useful when you need to map from x-y coordinates passed into a PS via the vPOS variable to "texture coordinates" for use in samplers.

DefSquareSurfaceMode

Sets the default stereoization rendering mode for all square surfaces & render targets:

0 = render according to Nvidia automatic

1 = render forcing this surface to be stereoized

2 = render forcing this surface to be monoscopic

This can be overridden by individual surface & render target declarations in the DX9Settings.ini file in sections labelled "[SFn]" (surfaces) and "[RTn]" (render targets), where n is a number. This is most relevant for shadow maps, which are usually square, and which must be forced to mono.

DefDepthStencilSurfaceMode

Sets the default stereoization rendering mode for all depth surfaces (render targets): 0 = render according to Nvidia automatic 1 = render forcing this surface to be stereoized 2 = render forcing this surface to be monoscopic This can be overridden by individual surface declaration in the DX9Settings.ini file in sections labelled "[SFn]", where n is a number.

DefSurfaceCreationMode

Sets the default stereoization rendering mode for all surfaces (except non-texture render targets): 0 = render according to Nvidia automatic 1 = render forcing this surface to be stereoized 2 = render forcing this surface to be monoscopic This can be overridden by individual surface declaration in the DX9Settings.ini file in sections labelled "[SFn]", where n is a number.

DefRtCreationMode

Sets the default stereoization rendering mode for all non-square render targets: 0 = render according to Nvidia automatic 1 = render forcing this surface to be stereoized 2 = render forcing this surface to be monoscopic

Default rendering mode for square render targets are instead set by DefSquareSurfaceMode, and individual render targets may be overridden in "[RTn]" sections.

SurfaceCreationModeList

Defines a list of of which surface properties defined in the DX9Settings.ini to load in an use for override purposes in sections labelled [SFn], where n is one of the list values. Usage: SurfaceCreationModeList = 0;2;3; Note - you must use ";" and you must have a ";" at the end of the list.

RtCreationModeList

This is like "SurfaceCreationModeList" but for render targets. Individual settings are defined in sections labelled [RTn], where n is one of the list values.

DepthStencilSurfaceModeList

Same as "SurfaceCreationModeList", but for all depth surfaces. Individual settings are defined in sections labelled [DSn], where n is one of the list values.

SkipSetScissorRect

This is set to either true or false. It is best to always default this to "true". It instructs the renderer to ignore (when it can) the application of a feature that tries to save memory by using a stencil cutout to limit the area that needs rendering. In 3D this leads to issues with parts of an object or effect being "cut-off" at the edges. It is not possible to always fix this in all games though.

OverrideMethod

Can have values of 0,1 or 2. It is unknown exactly what these are doing, and for most games it does not matter which one is used, but if any given game there seems to be an issue loading in shader fixes (e.g. if you press F10 and nothing happens), cycle through the options. The value of 2 seems to have been added to cater for preshaders. In this case you should be able to to just comment out the preshader sections in a shader. It is not clear if this always works.

GetCurDirAtLoad

Set to true if you want to force the dll to look in the game exe dir (where the dll is) for the settings file, shader folders etc. Set to false otherwise. Exists because some games get linked to the parent directory etc to look for shader folders. Mostly seems to work, and is a good default option.

UseExtInterfaceOnly

This can be either true or false. This enables wrapping games that use the Direct3DCreate9Ex() call instead of the regular call.

If Helix mod does not work with a game and the LOG.txt contains only the following lines, you need this option:

   Start logging..
   Direct3DCreate9Ex Created

It is known to be necessary for newer Telltale games such as Wolf Among Us and Walking Dead.

PSPREVKEY

DEBUG DLL ONLY - Defines which key cycles backwards through pixel shaders

Default Value: Numpad 1

PSNEXTKEY

DEBUG DLL ONLY - Defines which key cycles forwards through pixel shaders

Default Value: Numpad 2

PSSAVEKEY

DEBUG DLL ONLY - Defines which key dumps the currently disabled pixel shader to a file

Default Value: Numpad 3

VSPREVKEY

DEBUG DLL ONLY - Defines which key cycles backwards through vertex shaders

Default Value: Numpad 4

VSNEXTKEY

DEBUG DLL ONLY - Defines which key cycles forwards through vertex shaders

Default Value: Numpad 5

VSSAVEKEY

DEBUG DLL ONLY - Defines which key dumps the currently disabled vertex shader to a file

Default Value: Numpad 6

PSADDTOSKIPLSTKEY

DEBUG DLL ONLY - Add the currently disabled pixel shader to the skip list, to allow multiple shaders to be disabled simultaneously

Default Value: Numpad 7

PSRMFROMSKIPLSTKEY

DEBUG DLL ONLY - Remove the currently selected pixel shader from the skip list

Default Value: Numpad 8

PSCLRSKIPLSTKEY

DEBUG DLL ONLY - Remove all pixel shaders from the skip list

Default Value: Numpad 9

VSADDTOSKIPLSTKEY

DEBUG DLL ONLY - Add the currently disabled vertex shader to the skip list, to allow multiple shaders to be disabled simultaneously

Default Value: Home

VSRMFROMSKIPLSTKEY

DEBUG DLL ONLY - Remove the currently selected vertex shader from the skip list

Default Value: End

VSCLRSKIPLSTKEY

DEBUG DLL ONLY - Remove all vertex shaders from the skip list

Default Value: Insert

RELOADSHADERSKEY

DEBUG DLL ONLY - Defines which key reloads the shaders from the ShaderOverrides directory.

Note: Shaders must have been succesfully overridden at launch for the reload to work, therefore it is a good idea to start the game with known working shaders if you intend to edit them while the game is running

Default Value: F10

SHOWTEXTKEY

DEBUG DLL ONLY - Toggles the red debug text on and off

Default Value: Pause

SaveTextureLogKey

This key does several things:

- Writes out TEXTURESLOG.txt, which can be used to find texture CRCs, as well as other information about the vertex buffers passed to the shader. In order to have useful information in the log, you need [VSnnnnnnnn] and [VBnnnnnnnn.m] sections for a shader, with at least:

   [VSnnnnnnnn]
   CheckTexCRC = true
   VBOffsetList = 0;
   UseDefinedOnly = false
   
   [VBnnnnnnnn.0]

- If GetSamplerNFromReg is enabled on a shader, pressing this key will also save the texture captured from that sampler to TexN.dds.

- If MakeWTexture=true this will also save out Depth.dds, but so far I've only ended up with a blank texture.

Note that these DDS files may not be readable by all tools, depending on what format (fourCC) the texture is in and what formats the tools support.

If you get a crash when pressing this key, it may be due to a conflict with the screenshot feature of the Steam overlay. Remap one of the two functions to a different button, or kill the steam overlay.

Default Value: F12

SaveSettingsKey

Defines which key re-writes DX9Settings.ini with custom convergence and separation settings to the active preset.

Must have UseSepSettings = true and SaveSepSettings = true in a preset to be useful.

CAUTION: Comments are removed from the ini when this key is pressed!

Default Value: F7

GameProfile

Set the default stereo profile for the game. Set to the name of the executable in the desired profile, not the name of the profile.

This is useful to automate selecting an alternate stereo profile to enable various stereo tweaks in the driver, but should be considered potentially unreliable. If a game is already assigned to a profile this will be ignored, and further - a game can become assigned to a profile at any time (e.g. this happens when using Ctrl+F7 to save convergence settings) and may lose the desired settings from this profile.

Notably, the setting to enable stereo in windowed mode for DX9 titles seems to be preserved even if a profile is created with Ctrl+F7, so it seems safe to use for that purpose. I recommend using the "3D-Hub Player" profile for that purpose, as in:

GameProfile = fxdplayer

UNKNOWN FEATURES

These features have been discovered in Helix Mod, but need further testing to determine how and if they work. Please edit the page if you can fill in more details about them.

TexToMonoKey

Uncertain. Force the currently selected texture to mono?

Default Value: U

TexToStereoKey

Uncertain. Force the currently selected texture to stereo?

Default Value: I

DefPSIdxConst

Unknown. Probably defines which constant register the pixel shader index can be read from?

Default Value: 222

DefVSIdxConst

Unknown. Probably defines which constant register the vertexshader index can be read from?

Default Value: 222

ForceWidth

Type: Integer

ForceHeight

Type: Integer

BehaviourFlags

Type: Integer

UseAsm

Type: Boolean

StartDump

Logs any calls to SetViewport before the first Present call.

Type: Boolean

CalcMatrixOncePerFrame

Limits the number of times that GetMatrixFromReg and GetMatrixFromReg1 will work in a frame (unconfirmed if working at all).

BUG: If both GetMatrixFromReg and GetMatrixFromReg1 are used, only the first matrix will be copied, rendering the second copy slot useless.

Type: Boolean

CalcTexCRCatUpdate

Type: Boolean

MakeWTexture

Creates a new depth texture that can be passed into shaders. The texture will not automatically get depth information, but it can be passed into a shader as an extra render target with DepthWRT to allow the shader to copy depth (or presumably any other) information to it. It can then be added to another shader as a texture with DepthWReg.

Note that it is important that the depth texture resolution matches other render targets when using DepthWRT. DepthGetDepthResFrom can be used to set this, but there may be situations where the only option is to use DepthForceWidth and DepthForceHeight.

Note that in some cases this texture may be created in mono instead of stereo! To work around this (and related bugs) in Montague's Mount, I had to use DepthGetDepthResFrom = 2 and DefSurfaceCreationMode = 1 (since there is no way to force the surface creation mode with the default DepthGetDepthResFrom) to force it to stereo, then manually set DepthForceWidth and DepthForceHeight to match the resolution so it would not break the lighting shaders.

The texture can be dumped out with F12 as Depth.dds.

Type: Boolean

DepthGetDepthResFrom

Determines how to get the resolution to use for the depth texture created with MakeWTexture=true and not using DepthForceWidth/Height.

0 = use the back buffer resolution

1 = use the resolution of a render target created with CreateRenderTarget(), provided it is *greater than* 800x600

2 = use the resolution of a depth surface created with CreateDepthStencilSurface(), provided it is *greater than* 800x600

Note that the texture may be created in mono instead of stereo depending on a number of factors. Setting this to 2 and using DefSurfaceCreationMode=1 can indirectly force it to stereo.

DepthForceWidth

Use to override the width of the injected depth texture created with MakeWTexture=true

DepthForceHeight

Use to override the height of the injected depth texture created with MakeWTexture=true

DepthWFormat

The D3DFORMAT of the depth texture created with MakeWTexture=true

Default: 114 (D3DFMT_R32F)

Type: Integer

CheckDepthResolution

If true, the resolution of the depth texture must match the resolution of an active render target in order to set it as an extra render target with DepthWRT.

If false, the depth texture will be injected unconditionally as an extra render target on any shader with DepthWRT set (and if the size does not match the shader will stop working).

Note that for vertex shaders, this checks the first *render target*, while for pixel shaders this checks the *depth/stencil target*. In practice this means that in some cases the check will not be performed as expected.

Type: Boolean

DeptIsNilReg

Unknown. Seems to define a constant register which can be used to query if the depth render target has been used (?). Appears to be related to MakeWTexture and DepthWRT. The x component is initially set to 1 and will be set to 0 when the depth texture created with MakeWTexture is first set as a render target. The register is never set back to 1.

Note the misspelling of Depth as Dept.

Type: Integer (-1 is disabled, valid values are unknown)

ClearShaders

Appears to change what Helix mod does on device reset.

Type: Integer (1 to enable, "true" will not work)

ForceRefRate

Type: Boolean

ResetCRCatReload

Type: Boolean

ReloadTexturesListKey

Default Value: F8

[KEY*]

Replace * with a number. These sections are used to activate presets when pressing or holding various keys or mouse buttons.

Note that you must include all of these sections in the PresetsKeysList under [General] otherwise they will be ignored by HelixMod. For instance, if you have defined sections for [KEY1], [KEY3] and [KEY7], then you must set PresetsKeysList = 1;3;7;

Key

This specifies the keycode in decimal.

Microsoft virtual keycodes for Key= use. Especially helpful for those odd keys like Insert, or Pause or F-Keys or Numpad. Must be converted from Hexadecimal to Decimal: http://msdn.microsoft.com/en-us/library/ms927178.aspx

ASCII table for normal keyboard keys. Use the Dec column: http://www.asciitable.com/

501 is the right mouse button, which is useful to switch presets while holding aim in some games.

Type

Type=1 will activate when the key is pressed down.

Type=2 is momentary - it will activate the first preset when the key is pressed down, and the second preset when the key is released.

Presets

This specifies which PRES* sections are activated by this key.

Each number in this list should end with a semicolon, including the last one.

Note that the order in this list is unimportant, however the numerical value of each of the presets does!

For type 2 keys, there should be exactly two entries in the list - the lower numbered entry will be activated while the button is held and the higher numbered entry will be activated when the button is released.

For type 1 keys you can have one or more entries in this list. If you have more than one entry it will cycle through each of them in numerical order when the key is pressed, wrapping back to the first after the last one. A list of two presets would toggle between each of them.

Delay

Defines an optional delay in milliseconds before the next preset will be activated.

Only seems to affect the 'to' and not the 'from' when using Type=2

[PRES*]

Replace * with a number. These sections define various presets that can be activated with key presses.

These sections should be referenced from the Presets list in at least one KEY* section.

Const1, Const2, Const3, Const4, Const5, Const6, Const7, & Const8

Each of these can be used to set a value that can be accessed from shaders through the c register defined by DefVSConst1 and DefPSConst1 (or DefVSConst2/DefPSConst2). The first four of these make up the x, y, z and w values of a single c register. The notation is confusing, as Const2 will be the y value of DefVSConst1.

As an example:

DefVSConst1 = 240
Const1 = 240.x
Const2 = 240.y
Const3 = 240.z
Const4 = 240.w
DefVSConst2 = 241
Const5 = 241.x
Const6 = 241.y
Const7 = 241.z
Const8 = 241.w

These must be specified in hex (see below).

UseByDef

If true, this preset will be activated when the game is started.

If this preset can also be activated via a key press, it is recommended to make the numerically highest preset associated with that key the default. Otherwise the first time the key is pressed it may not appear to do anything as it activated the already active preset.

UseByDef can be set on multiple presets. This is useful if you have several independent preset groups - e.g. one group to control the convergence settings, and another to select different UI depths.

UseSepSettings

Set to true to allow this preset to change the separation and/or convergence settings.

SaveSepSettings

Set to true to allow custom separation & convergence settings to be saved in this preset.

To use it the preset must be activated in the game (UseByDef=true does not seem to be sufficient) while the user adjusts their settings via the normal keybindings for the driver. With the preset still active they then press F7 (not to be confused with Ctrl+F7) which will cause HelixMod to write the new settings to DX9Settings.ini

CAUTION: Pressing F7 will strip all comments from DX9Settings.ini!

Separation

Set a custom separation value between 0.0 and 100.0 when this preset is activated. You must also set UseSepSettings=true for this to work. The value must be specified in hex (see below).

Convergence

Set a custom convergence value when this preset is activated. You must also set UseSepSettings=true for this to work. The value must be specified in hex (see below).

[VSnnnnnnnn]

These sections define custom settings for specific vertex shaders. Replace nnnnnnnn with the 8 digit CRC32 of the vertex shader.

CheckTexCRC

Set to true to enable filtering by the textures in the DefinedTexturesVS list of this shader.

DefinedTexturesVS

Requires CheckTexCRC = true

List the texture CRCs to filter on in this shader. Note that there are several ways you can filter, refer to UseDefinedOnly and TexCounterReg for more details.

UseDefinedOnly

If this is true (default), the shader will only be used when a texture in DefinedTexturesVS is in use, otherwise it will be disabled (skipped?). It is almost always a good idea to set this to false and do the filtering in the shader, if for no other reason than you will still see it if it uses a new texture that you haven't seen yet.

TexCounterReg

This defines a constant register with an X component that can be tested in the shader to determine whether a texure in DefinedTexturesVS is in use, and possibly which one. If using this you will almost certainly want to set UseDefinedOnly = false as well.

e.g. TexCounterReg = 251 will allow you to test c251.x in the shader.

Set ValForDefined and ValNotDefined to distinct values for simple cases where you need to filter based on the texture being in the list, or not in the list.

If you need to know precisely which texture is in use, add [TEXnnnnnnnn] sections for the relevant texture CRCs and set index to a value in those sections. That index value will be accessible through TexCounterReg. You can use this in conjunction with ValForDefined/ValNotDefined to set a default value, and have specific textures override this with a different value.

ValForDefined

This will set the default value of the constant defined by TexCounterReg when the texture is in the DefinedTexturesVS list.

May be overridden by the index setting in a [TEXnnnnnnnn] section for a specific texture.

ValNotDefined

This will set the value of the constant defined by TexCounterReg when the texture is NOT in the DefinedTexturesVS list.

UseMatrix, UseMatrix1

Either "true" or "False".

Specifies whether this VS will re-use a matrix from another shader.

MatrixReg, MatrixReg1

Usage MatrixReg = nnn

where nnn is the register for a matrix that was specified in another shader subsection using the "GetMatrixFromReg" field. Note that this "get" statement can be in the same shader, it does not have to be a different shader - this is required if you want the inverse of a matrix.

GetMatrixFromReg, GetMatrixFromReg1

Usage: GetMatrixFromReg = nnn

Sets the matrix with register nnn in *this* shader to be a re-usable constant register in all other shaders (including itself).

InverseMatrix, InverseMatrix1

This is either true or false.

If true then the matrix specified in "MatrixReg" will actually be the inverse of the matrix that was re-used.

DoubleInverseMatrix, DoubleInverseMatrix1

This is either true or false.

If true then a *Second* register is created 4 values higher than the first one defined in "MatrixReg" which stores the Inverse of the Inverse i.e. gets back to the original matrix that was shared in the first place. This might seem odd but it provides significantly better numerical stability. An example would be that a shader "shares' its matrix that was in register 8. This is then set to register 200 in the shader that is reusing it. If both matrix inverse settings are true, the registers will be as follows: 200, 201, 202, 203 will have the inverse matrix; 204, 205, 206, 207 will have the original matrix.

Needs to be specified in *both* the source and destination shaders to work

GetSampler1FromReg, GetSampler2FromReg, GetSampler3FromReg

This allows a sampler from this shader to be reused in a different shader.

Setting this between 500 and 508 (inclusive) will copy the corresponding render target 0-8 instead of a texture. -1 also appears to be a special value, though it's not clear for what.

GetSampler3FromReg only works with pixel shaders, vertex shaders must use the first two.

BUG: Using GetSampler3FromReg with a render target (ie. 500-508), will set sampler 1 instead!

BUG: If using with a vertex shader OR a render target, the texture's width must match the resolution to be copied. See note below under S*TexW.

Sampler1RTType, Sampler2RTType, Sampler3RTType

Filters the textures copied with GetSamplerNFromReg to textures that match a specific format.

Applies when copying a texture from a vertex shader, or when copying a render target. NOT USED WHEN COPYING A TEXTURE FROM A PIXEL SHADER.

-1 to disable the filter and copy textures regardless of format.

S1TexW, S1TexH, S2TexW, S2TexH, S3TexW, S3TexH

Supposed to filter the textures copied with GetSamplerNFromReg to textures matching the corresponding width & height, however is broken due to a bug.

Applies when copying a texture from a vertex shader, or when copying a render target. NOT USED WHEN COPYING A TEXTURE FROM A PIXEL SHADER.

BUG: Can only match screen resolution, making it impossible to copy textures / render targets of other sizes.

Set both to -2 to match the current resolution

Supposed to use -1 to ignore one of the width/height and match on the other

Other values supposed to match a given width & height

SetSampler1ToReg, SetSampler2ToReg, SetSampler3ToReg

This allows a sampler that has been shared in another shader to be reused in this shader.

Usage: SetSampler1ToReg = 10

This will mean that in this shader, there will be accessible a sampler "s10" that can be used as if it was defined in the shader itself.

SetConst1ToReg, SetConst2ToReg, SetConst3ToReg

This allows a Constant (4-component) register that has been shared in another shader via GetConstNFromReg to be reused in this shader.

Usage: SetConst1ToReg = 10

This will mean that in this shader, there will be accessible a constant "c10" that can be used as if it was defined in the shader itself.

GetConst1FromReg, GetConst2FromReg, GetConst3FromReg

These allow up to three constant registers defined in this shader to be re-used in other shaders.

Usage: GetConst1FromReg = 123

This means that the register c123 will be made available to other shaders, and identified as accessed using the "SetConst1ToReg" field.

ResetConst1AfterSet, ResetConst2AfterSet, ResetConst3AfterSet

WARNING: Setting these may cause the relevant constant to always be 0 (possibly dependent on the scene draw order), as the reset flag doesn't get cleared after the first successful SetConstNToReg (confirmed in World of Diving).

After a constant copied from another shader has been set, this will clear it (set to 0) on the next DirectX Present call, effectively making them only have a non-zero value while the shader they were copied from is active in the scene.

An alternative method to determine if a constant is currently valid, is to use PresIndex in the shader(s) it was taken from to set a ConstN register to 1.0 which can be tested in the destination shader(s). This has been used in the World of Diving fix to determine if the projection matrix is available, or must be calculated from the inverse model-view and model-view-projection matrices.

MousePosReg

Specifies a constant register to store the X and Y coordinates of the mouse.

The coordinates are scaled too high and need to be divided by 1000, e.g:

[VS12345678]
MousePosReg = 210

ShaderOverride\VertexShaders\12345678.txt:
def c220, 0, 0, 0.0625, 0.001
...
mov r13.xy, c210.xy
mul r13.xy, r13.xy, c220.ww

InitMouse must be true (or not specified) for this to work.

NOTE: It may not work when the game is first launched - if it doesn't work alt+tab out of the game and back in.

NOTE: This will only work in games that do not grab the mouse.

NOTE: This only works in vertex shaders. If you need it in a pixel shader, you will have to pass it from the vertex shader as an additional output.

WARNING: It appears that in some games this can get out of sync with the real mouse position by moving it to the edge of the screen.

DefVSSampler

Used to override the global DefVSSampler in this vertex shader. Add 257 to the sampler number - e.g. DefVSSampler = 260 will use s3 in this shader.

DefVSViewSizeConst

Used to override the global DefVSViewSizeConst in this vertex shader.

DefVSIdxConst

Used to override the global DefVSIdxConst in this shader.

PresetConst1

Used to override DefVSConst1 in this shader (unconfirmed)

PresetConst2

Used to override DefVSConst2 in this shader (unconfirmed)

PresIndex

Used to activate a preset while this shader is active in the scene (unconfirmed). Note that this is in *DECIMAL*, but the [PRES%X] sections are in *HEXADECIMAL*, so these will need to be converted for values above 9.

DepthWReg

Defines the sampler register to inject the depth texture created with MakeWTexture = true. Add 257 to the sampler number for vertex shaders.

The depth texture will be blank unless it has been filled out by another shader using DepthWRT.

The Montague's Mount fix uses this feature.

DepthWRT

Injects the depth texture created with MakeWTexture = true into this shader as an additional render target. The shader can then be modified to write information to this new render which can be copied to other shaders later. Note that if the depth texture does not match the resolution of other render targets assigned to the shader the whole shader will stop working (and Helix Mod has several bugs that can complicate this)!

This option could be useful in e.g. a full-screen deferred lighting shader that can copy the depth buffer to the new render target (if copying the depth buffer directly with Helix Mod did not work).

The Montague's Mount fix uses this feature.

DefStage

Appears to affect which surface level (mip-map?) of a texture is used for the CRC calculation (unconfirmed).

VBOffsetList

Exact meaning uncertain, but necessary to use the [VBnnnnnnnn.m] sections to work with vertex buffers (inputs to vertex shaders) - Fill this list out with all values of m you need.

Note that if you have matched a texture using DefinedTexturesVS, this will be ignored for that draw call and the one in the matching [TEXnnnnnnnn] section will be used instead. In this case, the vertex buffer section must have the same hash as the matched TEXTURE.

Usage: VBOffsetList = 0;1;

FirstVertexPosReg

Stores the contents of the first entry of the first vertex in this constant register. This will usually be the input position of one one of the vertices.

It can be useful to get a consistent position across an entire icon/word for auto depth adjustments (used in Dreamfall Chapters), or to compare against to determine which corner a particular vertex is since DX9 has no SV_VertexID semantic.

To get the screen position you will need to duplicate any code in the shader that derives the output position from the input position - this may be as simple as copying a matrix multiplication.

I have observed that the input W may be 0, whereas the input W to dcl_position would usually be 1, which may throw out some calculations that depend on it.

Requires CheckTexCRC = true, UseDefinedOnly = false, GetVertex = true (either in the VS section, or possibly in a TEX, VB or PT section if they match the draw call), VBOffsetList = 0; and a (possibly empty) [VBnnnnnnnn.0] section to work.

NOTE: If you are using this in conjunction with a DefinedTexturesVS list, you must also define [TEXnnnnnnnn] sections for all matched textures, which must contain a VBOffsetList = 0; and then you must define a (possibly empty) [VBnnnnnnnn.0] section with the hash of the texture. In that case the VB section with the hash of the shader will be used when the texture did not match the list.

FirstTexVertexPosReg

This is similar to FirstVertexPosReg, but it will only be updated when a texture in the DefinedTexturesVS list is matched, and only when the texture changes.

The same requirements as FirstVertexPosReg apply here, and since this can only be used with DefinedTexturesVS it will always require the extra sections [TEX] and [VB] sections matching the texture hash.

GetVertex

Necessary to use FirstVertexPosReg, FirstTexVertexPosReg or GetMatrixTexFromReg. Possibly others.

Type: Boolean

UseAsm

GetMatrixTexFromReg

This will copy a matrix from the shader, but only when the same constraints as described in FirstTexVertexPosReg are met. (untested)

MatrixTexReg

This will copy the matrix copied via GetMatrixTexFromReg into the shader.

[VBnnnnnnnn.m]

This is of the form [VBnnnnnnnn.m], where the "m" relates to the value set in the "VBOffsetList" field of the related [VSnnnnnnnn] or [TEXnnnnnnnn] section. The way textures are stored and accessed is through Vertex Buffers, which are lists. No one really knows how this works, but it is the syntax that is necessary for it to work.

The nnnnnnnn will usually match the hash of the corresponding shader section, BUT if a texture in a DefinedTextureVS section has been matched it must match that texture hash instead (and in that case VBOffsetList must be set in the [TEXnnnnnnnn] section).

PointsList

Set to a numeric value. Currently believed only to be a way to identify this override operation in the LOG and/or textures.log files.

Usage: "PointsList = 554" OR "PointsList = 3E8B0000"

GroupsList

It is unknown what this does, but it appears to be related to the [GPnnnnnnnn] sections.

Offset

IsDisabledList

StartResW

StartResH

EndResW

EndResH

GetVertex

CompareType

Unknown exactly what this does. Appears to affect the offset into the vertex buffer used in some sort of comparison with the points list.

Valid Values: 0, 1 (multiplies offset by 2), 2 (multiplies offset by 4)

[TEXnnnnnnnn]

Used to identify one of the textures by the 8-digit CRC specified in the "DefinedTexturesVS" list for a vertex shader.

PresIndex

Usage: PresIndex = 8

Used to specify a particular preset index that is to be activated when the given texture is active. Its used for things like setting automatic convergence in different games scenes.

NOTE: PresIndex is in *DECIMAL*, but the [PRES%X] sections are in *HEXADECIMAL*, so if you are using a preset number above 9 you will need to convert them. e.g. PresIndex = 512 will match [PRES200].

Index

This replaces the value of the register defined by TexCounterReg in a [VSnnnnnnnn] section. It is used when a shader needs to know when a specific texture is in use.

Usage: Index = n

VBOffsetList

This replaces the VBOffsetList in the shader section when the texture from this section is matched. The [VBnnnnnnnn.m] section it refers to uses the hash of the TEXTURE, not the shader.

Usage: VBOffsetList = 0;

[PTnnnnnnnn]

Used to identify one of the points lists (?) by the 8-digit CRC. It is unknown where this information comes from.

PresIndex

Usage: PresIndex = 8

Used to specify a particular preset index that is to be activated when the given point list is active. Its used for things like setting automatic convergence in different games scenes.

NOTE: PresIndex is in *DECIMAL*, but the [PRES%X] sections are in *HEXADECIMAL*, so if you are using a preset number above 9 you will need to convert them. e.g. PresIndex = 512 will match [PRES200].

AddOffset

AddPoint

GetVertex

Unknown, but as a side effect it looks like the LOG.txt may print out a 'SecName4: PTnnnnnnn' for this section if this is true.

[GPnnnnnnnn]

Appears to be related to group lists. It is unknown how this works. Appears to support the following options, which seem to be similar to the standard ConstN options supported by Helix Mod, but are completely independent. Possibly provides a means for a shader to distinguish between different objects being drawn?

• Def1Val
• Def2Val
• Const1Reg
• Const2Reg
• Const1X
• Const1Y
• Const1Z
• Const1W
• Const2X
• Const2Y
• Const2Z
• Const2W

[PSnnnnnnnn]

These sections define custom settings for specific pixel shaders. Replace nnnnnnnn with the 8 digit CRC32 of the pixel shader.

UseMatrix

Either "true" or "False".

Specifies whether this VS will re-use a matrix from another shader.

MatrixReg

Usage MatrixReg = nnn

where nnn is the register for a matrix that was specified in another shader subsection using the "GetMatrixFromReg" field. Note that this "get" statement can be in the same shader, it does not have to be a different shader - this is required if you want the inverse of a matrix.

GetMatrixFromReg

Usage: GetMatrixFromReg = nnn

Sets the matrix with register nnn in *this* shader to be a re-usable constant register in all other shaders (including itself).

InverseMatrix

This is either true or false.

If true then the matrix specified in "MatrixReg" will actually be the inverse of the matrix that was re-used.

DoubleInverseMatrix

This is either true or false.

If true then a *Second* register is created 4 values higher than the first one defined in "MatrixReg" which stores the Inverse of the Inverse i.e. gets back to the original matrix that was shared in the first place. This might seem odd but it provides significantly better numerical stability. An example would be that a shader "shares' its matrix that was in register 8. This is then set to register 200 in the shader that is reusing it. If both matrix inverse settings are true, the registers will be as follows: 200, 201, 202, 203 will have the inverse matrix; 204, 205, 206, 207 will have the original matrix.

GetSampler1FromReg, GetSampler2FromReg, GetSampler3FromReg

This allows a sampler register defined in this shader to be re-used in other shaders.

Usage: GetSampler1FromReg = 12

This means that the sampler s12 will be made available to other shaders, and identified as accessed using the "SetSampler1ToReg" field.

The texture on these captured samplers can be dumped out by pressing the key assigned to SaveTextureLogKey (default F12) as Tex1.dds, Tex2.dds and Tex3.dds.

SetSampler1ToReg, SetSampler2ToReg, SetSampler3ToReg

This allows a sampler that has been shared in another shader to be reused in this shader.

Usage: SetSampler1ToReg = 10

This will mean that in this shader, there will be accessible a sampler "s10" that can be used as if it was defined in the shader itself.

SetConst1ToReg, SetConst2ToReg, SetConst3ToReg

This allows a Constant (4-component) register that has been shared in another shader to be reused in this shader.

Usage: SetConst1ToReg = 10

This will mean that in this shader, there will be accessible a constant "c10" that can be used as if it was defined in the shader itself.

GetConst1FromReg, GetConst2FromReg, GetConst3FromReg

This allows a constant register defined in this shader to be re-used in other shaders.

Usage: GetConst1FromReg = 123

This means that the register c123 will be made available to other shaders, and identified as accessed using the "SetConst1ToReg" field.

[SFn]

These are individual sections that define a set of characteristics for different surfaces (except non-texture render targets) which thus specifies a subset of all of the currently created surfaces, and then defines the stereo render mode for this subset of surfaces. There are a number of fields that can be set, and the more that are set, the more tightly defined and specific (and smaller) the subset of surfaces will be that are affected by the stereo setting. The information for these surfaces comes from the LOG.txt file - look for lines starting with D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL. The value of "n" is an integer from 0 - 9. The question immediately arises as to how on earth you know what surfaces are doing what. Bascially you don't, so you usually just need to systematically go through all (unique) surfaces listed in the LOG.txt file, setting the DefMode parameter to 0 and 1 and see what happens. That being said, if you read up on MSDN, the "Format" field can be used to work out what type of effect/operation is being done i.e. some formats are used for depth surfaces, some for lights, some for water etc. There is also information on the resolutions that are common for different effects (though games with multiple quality levels may have different resolutions, and also if you change the game resolution you may need to cover more etc). On the whole though this is a bit of a grind with some guesswork.

These sections must be referred to from the SurfaceCreationModeList or they will not be processed.

DefMode

This is the stereoization mode to apply to all surfaces that meet the criteria specified for this surface:

0 = render according to Nvidia automatic

1 = render forcing this surface to be stereoized

2 = render forcing this surface to be monoscopic

Note that attempting to force 256x256 format=21 textures to stereo may result in a red "Out Of Memory" error from the driver. It is not known if this is a universal problem or specific to certain games or hardware - seen in Life Is Strange and Dragon's Dogma: Dark Arisen using a 680m.

Format

This refers to the format of the surface and how the different components are encoded. You don't need to know this, the LOG.txt file will specify what the format is for each surface created. You can find out what the different codes mean by looking on MSDN. Usege: "Format = 21"

Usage

This parameter is also identified for a given surface in the LOG.txt file. It refers to whether a given surface is used as a depth buffer or not.

Height

The height of the particular surface in pixels.

Width

The width of the particular surface in pixels.

UseBackBufRes

This is either true or false and refers to setting the width and height to be that of the current back buffer.

Levels

Usage: Levels = 1

This parameter is also identified for a given surface in the LOG.txt file.

Pool

Usage: Pool = 0

This parameter is also identified for a given surface in the LOG.txt file.

UNKNOWN FEATURES

These features have been discovered, but need testing to determine how/if they work.

Index

IndexList

ResStartWidth

ResStartHeight

ResEndWidth

ResEndHeight

ExceptSquare

ForceWidth

ForceHeight

IsDisabled

[RTn]

This is similar to [SFn], but for render targets rather than surfaces. These are individual sections that define a set of characteristics for different render targets which thus specifies a subset of all of the currently created render targets, and then defines the stereo render mode for this subset of render targets. There are a number of fields that can be set, and the more that are set, the more tightly defined and specific (and smaller) the subset of render targets will be that are affected by the stereo setting. The information for these surfaces comes from the LOG.txt file in lines starting with CreateRenderTarget. The value of "n" is an integer from 0 - 9. All fields are the same as for [SFn].

These sections must be referred to in the RTCreationModeList to be processed.

[DSn]

Similar to [SFn] and [RTn], but for depth stencil surfaces. The information for these surfaces comes from the LOG.txt file in lines starting with CreateDepthStencilSurface.

These sections must be referred to in the DepthStencilSurfaceModeList to be processed.

Hex to Float conversion

Several values in the ini file are floating point values that must be specified in hex. These include Separation, Convergence, Const1, Const2, Const3 and Const4.

You can use this online converter to convert between float and hex: http://gregstoll.dyndns.org/~gregstoll/floattohex/

Alternatively, if you prefer working in a command line environment, you might considder this Python script: https://raw.githubusercontent.com/DarkStarSword/3d-fixes/master/float_to_hex.py

List of features supported by HelixMod, and all versions available.

Release versions from newest to oldest:

https://s3.amazonaws.com/-HeliX-/DLLS/DllsModPack1.zip

https://s3.amazonaws.com/-HeliX-/DllsModPack.zip

https://s3.amazonaws.com/Helixfix/DllsModPack.zip

https://s3.amazonaws.com/-HeliX-/DLLS/Release.zip

https://s3.amazonaws.com/HelixMods/*Mainfiles/Releasev2.zip

https://s3.amazonaws.com/HelixMods/*Mainfiles/Release.zip

https://s3.amazonaws.com/HelixMods/*Oldversion/Release.zip

https://s3.amazonaws.com/HelixMods/*Oldversion/Release.upd.zip

Debug From newest to oldest

https://s3.amazonaws.com/-HeliX-/DLLS/DllsModPack1.zip

https://s3.amazonaws.com/-HeliX-/DllsModPack.zip

https://s3.amazonaws.com/Helixfix/DllsModPack.zip

https://s3.amazonaws.com/-HeliX-/DLLS/Debug.zip

https://s3.amazonaws.com/HelixMods/*Mainfiles/Debug.zip

https://s3.amazonaws.com/HelixMods/*Oldversion/Debug.zip

DarkStarSword's binary patched version of the 140302 debug DLL:

• Allows the LOG.txt to be opened while the game is running

32bit: https://github.com/DarkStarSword/3d-fixes/raw/master/__HELIX__/2014-03-02-DEBUG-BINARY-PATCHED/d3d9.dll

64bit: https://github.com/DarkStarSword/3d-fixes/raw/master/__HELIX__/2014-03-02-DEBUG-BINARY-PATCHED/x64/d3d9.dll

List of versions by date

Horizontally across the top, we've got versions of the DLL, based on the mod-date found in the zip file. We are using the YYMMDD format.

Going down vertically, we have the different features that are available. Not all features are available or work in all DLLs.

Entries in the table are:

• blank if untested or unknown to work.
• OK if tested and known to work.
• X if tested and known to fail.