I've got a dx9 wrapper that supports basic HeliXmod fixes but is in pretty much alpha state.
I would consider my dx10 wrapper to be pre-alpha as most of the focus has been on dx11 with some recent work on dx9. My dx10 wrapper can dump shaders and swap shaders but I can't remember if it has the code for hunting shaders.
Is there something missing from HeliX dx9 tools or are they as good as they can get?
My big issue is that hunting shaders is a pain for probably personal reasons.
I press the next shader button once but the wrapper skips two shaders ahead. I try to backtrack and it skips two shaders back again. Because of this it's really painful to use. My guess is that other people don't have this particular problem.
I was happy for a while when loading the portal fix into my dx9 wrapper until I realize HeliX was doing a lot more than replacing shaders and there was loads of configuration details in the INI file.
At the end of the day it seems we don't need another dx9 wrapper but having access to the sourcecode does allow for changes to be made and improvements beyond what is currently possible.
It could fall into the category of waste of time or HeliX is way more advanced so no way to catch up.
If used in new projects it doesn't have to emulate HeliX perfectly and if being as compatible as possible fixes should be able to be ported in a straight forward fashion and then adding the desired ground breaking functionality that could be added to a wrapper with source code access.
I should reiterate that all my wrappers are open source under GPL v3 because I use Nektra hooks which is either licensed with GPL or extremely expensive $449 per developer per product.
DX9 could be considered to be a done deal given HeliXmod and the maturity there but without source code we are limited to the limitations of HeliXmod. I mean HeliX dx11 is pretty much useless in the state he left it in and no game other than Bioshook Infinite is using it. It's not because his wrapper is bad but it lacks all the debug features available in HeliX dx9 wrapper.
I'm not trying to oversell my dx9 wrapper as it is pretty much limited to replacing shaders with no fancy functionality yet.
I've got a dx9 wrapper that supports basic HeliXmod fixes but is in pretty much alpha state.
I would consider my dx10 wrapper to be pre-alpha as most of the focus has been on dx11 with some recent work on dx9. My dx10 wrapper can dump shaders and swap shaders but I can't remember if it has the code for hunting shaders.
Is there something missing from HeliX dx9 tools or are they as good as they can get?
My big issue is that hunting shaders is a pain for probably personal reasons.
I press the next shader button once but the wrapper skips two shaders ahead. I try to backtrack and it skips two shaders back again. Because of this it's really painful to use. My guess is that other people don't have this particular problem.
I was happy for a while when loading the portal fix into my dx9 wrapper until I realize HeliX was doing a lot more than replacing shaders and there was loads of configuration details in the INI file.
At the end of the day it seems we don't need another dx9 wrapper but having access to the sourcecode does allow for changes to be made and improvements beyond what is currently possible.
It could fall into the category of waste of time or HeliX is way more advanced so no way to catch up.
If used in new projects it doesn't have to emulate HeliX perfectly and if being as compatible as possible fixes should be able to be ported in a straight forward fashion and then adding the desired ground breaking functionality that could be added to a wrapper with source code access.
I should reiterate that all my wrappers are open source under GPL v3 because I use Nektra hooks which is either licensed with GPL or extremely expensive $449 per developer per product.
DX9 could be considered to be a done deal given HeliXmod and the maturity there but without source code we are limited to the limitations of HeliXmod. I mean HeliX dx11 is pretty much useless in the state he left it in and no game other than Bioshook Infinite is using it. It's not because his wrapper is bad but it lacks all the debug features available in HeliX dx9 wrapper.
I'm not trying to oversell my dx9 wrapper as it is pretty much limited to replacing shaders with no fancy functionality yet.
Thanks to everybody using my assembler it warms my heart.
To have a critical piece of code that everyone can enjoy!
What more can you ask for?
[quote="Flugan"]I press the next shader button once but the wrapper skips two shaders ahead. I try to backtrack and it skips two shaders back again. Because of this it's really painful to use. My guess is that other people don't have this particular problem.[/quote]
No, I too have this problem, and suspect everyone else does. I've even created macros for dumping all shaders in a scene, where I program the next shader button to only be pressed for 0.001 of a second, and it STILL will occasionally jump 2 in a row, so that definitely is a major grievance. I had also mentioned in your other recent thread quite a few other issues I have, so given that I'm still just learning what all these other functions in Helixmod are, I would appreciate and use a less functional, but much more user friendly wrapper as long as the 2 were compatible with one another (ie. start off with using yours, and then as I learn of certain other functions being needed, switch over to Helixmod as needed). And, with access to the source code, all the functionality could theoretically be added over time.
Also, keep in mind that the DX9 library is HUGE, there are still a ton of games that have not been fixed, and games are still being released in DX9 only (or at least compatible) as not every person has the hardware capable of DX11.
So, yeah, I definitely think there's a very welcome place for an open sourced DX9 wrapper.
Flugan said:I press the next shader button once but the wrapper skips two shaders ahead. I try to backtrack and it skips two shaders back again. Because of this it's really painful to use. My guess is that other people don't have this particular problem.
No, I too have this problem, and suspect everyone else does. I've even created macros for dumping all shaders in a scene, where I program the next shader button to only be pressed for 0.001 of a second, and it STILL will occasionally jump 2 in a row, so that definitely is a major grievance. I had also mentioned in your other recent thread quite a few other issues I have, so given that I'm still just learning what all these other functions in Helixmod are, I would appreciate and use a less functional, but much more user friendly wrapper as long as the 2 were compatible with one another (ie. start off with using yours, and then as I learn of certain other functions being needed, switch over to Helixmod as needed). And, with access to the source code, all the functionality could theoretically be added over time.
Also, keep in mind that the DX9 library is HUGE, there are still a ton of games that have not been fixed, and games are still being released in DX9 only (or at least compatible) as not every person has the hardware capable of DX11.
So, yeah, I definitely think there's a very welcome place for an open sourced DX9 wrapper.
3D Gaming Rig: CPU: i7 7700K @ 4.9Ghz | Mobo: Asus Maximus Hero VIII | RAM: Corsair Dominator 16GB | GPU: 2 x GTX 1080 Ti SLI | 3xSSDs for OS and Apps, 2 x HDD's for 11GB storage | PSU: Seasonic X-1250 M2| Case: Corsair C70 | Cooling: Corsair H115i Hydro cooler | Displays: Asus PG278QR, BenQ XL2420TX & BenQ HT1075 | OS: Windows 10 Pro + Windows 7 dual boot
If you hold down the "next shader" button, it will go through at a constant rate, meaning you're less likely to skip shaders. It still makes cycling back to the exact one you're looking for a little annoying though.
If you hold down the "next shader" button, it will go through at a constant rate, meaning you're less likely to skip shaders. It still makes cycling back to the exact one you're looking for a little annoying though.
There's a lot of problems with Helix Mod, but addressing those isn't useful (at least not to me - DJ-RK does have a point that there is a place for a DX9 wrapper that is easier to work with and doesn't crash when hunting vertex shaders) until (almost) all the features that Helix Mod supports has been reimplemented, and that would require a *huge* amount of effort for little return.
And I'm not saying that lightly - you may recall that a little over a year ago I fixed DreadOut Act 1. At the time I got *very lucky* that I was able to fix that with Helix Mod at all (the draw order was favourable). Act 2 came out about a month later and my luck ran out and it was beyond Helix Mod's feature set - I could make it playable, but I would have to sacrifice some or all of the shadows to do so (the tricky part is the dual render targets the game uses with differing FOVs, requiring four matrices to be copied to fix both, but Helix mod can only copy two matrices and there is no way to separate them into separate sets of matrices based on the render target - Helix Mod doesn't support render target filtering, let alone any way to copy matrices based on that).
Then about a month after that the dev updated the game to use borderless windowed mode and that totally broke the fix as forcing surface creation mode doesn't work in windowed mode, and that was not really optional in that game (or could have been, except for other limitations of Helix Mod, namely not being able to check which render target is active). And none of the tools I tried to force full screen mode would work, or if they did they interfered with Helix Mod in other ways that made them a dead end.
For a while I wasn't sure what to do about that, but I hatched a plan - since it was a Unity game I can force it to DX11 (and that actually works for DreadOut, which isn't the case with some other Unity games), which would then allow me to fix it with 3DMigoto instead. But, the fix had already pushed Helix Mod to it's limits, and at the time 3DMigoto lacked all the features that I was using from Helix Mod (and of course I needed features that were not in Helix mod as well).
So, while none of the features I've added to 3DMigoto have been specifically for DreadOut, re-fixing it has been a long term goal that I've been slowing working towards, because once 3DMigoto is capable of fixing that, it will be capable of fixing just about anything. I have a clear idea of how I'm going to solve copying matrices around and separating their render targets without adding a game-specific hack to 3DMigoto. At the moment about 80% of the pieces are in place - input handling, forced full screen, texture filtering, arbitrary resource copying and custom shader injection are all there now. Custom resource creation and scene detection are still missing, as is a DX11 version of shadertool to script the fix (I might use hlsltool instead, depending on whether there is any visible damage from the decompiler, and so I can use the view-space style lighting fix which needs new inputs and outputs added to shaders).
So, that would give you an idea of the amount of work that would need to go into a new DX9 wrapper to even catch up to Helix Mod. CommandList.{cpp,h} holds the bulk of the source code for a lot of these new features (arbitrary resource copying, part of texture filtering, custom shader injection and a few other things), and that currently stands at almost 3000 lines of code written over the last six months or so (plus however much is in other files, but counting those is harder) - and that will only grow more as the final few features are added and more edge cases are fixed (if it shrinks, it will only be because I split it into several files).
IMO, a better approach would be to start removing the DX11 dependency of a lot of this functionality from 3DMigoto to allow it to be used for DX12, DX10 and DX9 as well (of which DX9 will be the hardest as the API changes between DX9 and DX10 were greater than any API change since). That in itself is a fair chunk of work and not one I've given enough head space to to even hazard a guess as to how long it would take, how hard it would be and if it is even technically feasible.
Just off hand, here's a few other limitations I have personally hit in Helix Mod:
- A low limit to the number of matrices (2) and constant registers (3) that can be copied (plus one additional matrix copy slot tied to texture matching, but that has bugs and is only situationally useful to copy the MVP matrix of a single object per frame to match the depth of something else to it). Aside from DreadOut, this almost prevented the original Unity 4 fix of Dreamfall Chapters (I used up every spare output register from the directional shadow vertex shader and all of Helix Mod's copy slots and it was only just enough to do what I needed. The Unity 5 version dumped the custom shader, so I no longer do that), and the Unity 5 specular reflection fix (however I was able to rework the shadow fix to use the same matrices as the reflection fix to allow both to work together).
- No ability to disable injecting the stereo sampler, making it impossible to edit a vertex shader that uses all 4 samplers or a pixel shader that uses all 16 without damaging it (there are other ways to get the stereo information other than using samplers - the driver injects an undocumented stereo constant register, and the public list of functions in the nda version of nvapi suggests there is an API to inject our own).
- Samplers set by the game and replaced with Helix Mod's are not restored afterwards. The combination of this and the above causes problems for Unity games using Ceto water like The Forest and Stranded Deep - depending on the version of Ceto water, which sampler(s) are set by Helix Mod, the camera angle and relative position of the player (affects what other shaders are drawn and in what order) will cause glitches such as the water changing depth, the waves disappearing or not respecting the shoreline, and the water changing when convergence or separation is adjusted.
My plan with Stranded Deep is to convert it to DX11 (since the game started using DX11 specific effects anyway) where the problem won't exist, but The Forest does not (currently) render in DX11 - my plan there is to binary patch Helix Mod to disable injecting samplers into the vertex shader and use the undocumented stereo register, but this is not ideal (I will also have to disable the auto HUD). Either way I'm holding off until the game is out of EA since there is a possibility they will fix the effects in DX11 by then.
- Helix Mod can access the position of the first vertex of an effect, which I used for the auto HUD in Dreamfall Chapters. For that game I also really needed some related features that Helix Mod lacks - I needed the position of one of the UI elements to align the rest to it, but I was only able to get close by matching on particular textures I wanted to use as a reference and aligning the rest to them, but that didn't work if two textures I was matching were drawn simultaneously - I really needed to limit it to only the first in the frame.
This feature was useless for the auto HUD in The Forest where multiple icons were drawn in a single draw call and I needed the position of each individual icon, but could only get the position of one of them. 3DMigoto gives access to the entire vertex buffer to allow this (though we still depend on the game's HUD playing nice - if the HUD is drawn with an index buffer or icons are not drawn with 6 vertices things quickly get complicated).
- Helix Mod can create a custom depth texture and inject it into shaders as an additional render target or texture. I have used this once in Montague's mount when copying sampler registers was not working. I found a number of problems with this feature - Helix Mod fails to force it to stereo and it ends up being created mono, and as such I have had to use tricks to force it to stereo by tying it to be created along with a depth buffer, and forcing those to be stereo (and getting lucky that Helix Mod happens to still have the DefSurfaceCreationMode applied when it creates it using that method), but that had it's own set of problems as games can create depth buffers for other purposes so the size won't always match, which will break any shaders it is injected in to. My only option was to hardcode the resolution in the ini file.
- In games that require UseExtInterfaceOnly, most texture hashes are broken.
- No render target size filtering (for matching driver heuristics, and preventing some UI adjustments affection in-world objects or double-adjusting part of the UI)
- No depth buffer filtering (for matching driver heuristics)
- No support for the reverse stereo blit, so my auto crosshair has to calculate it's position independently in each eye, whereas in DX11 it can calculate it from both eyes simultaneously.
- Mouse coordinate injection is broken (and generally insufficient to implement a software mouse to fix all those games that use hardware cursors). I have some ideas to make this work in 3DMigoto, and one of the pieces (shader injection) is there already, but there's a lot more work needed and it's not clear if it is even possible yet.
There's probably others I've forgotten. But overall, Helix Mod has a huge amount of functionality that does work and it is a proven tool. Replacing it is something that I've thought about doing, as has bo3b and clearly you as well, but it just doesn't seem like a good use of time.
There's a lot of problems with Helix Mod, but addressing those isn't useful (at least not to me - DJ-RK does have a point that there is a place for a DX9 wrapper that is easier to work with and doesn't crash when hunting vertex shaders) until (almost) all the features that Helix Mod supports has been reimplemented, and that would require a *huge* amount of effort for little return.
And I'm not saying that lightly - you may recall that a little over a year ago I fixed DreadOut Act 1. At the time I got *very lucky* that I was able to fix that with Helix Mod at all (the draw order was favourable). Act 2 came out about a month later and my luck ran out and it was beyond Helix Mod's feature set - I could make it playable, but I would have to sacrifice some or all of the shadows to do so (the tricky part is the dual render targets the game uses with differing FOVs, requiring four matrices to be copied to fix both, but Helix mod can only copy two matrices and there is no way to separate them into separate sets of matrices based on the render target - Helix Mod doesn't support render target filtering, let alone any way to copy matrices based on that).
Then about a month after that the dev updated the game to use borderless windowed mode and that totally broke the fix as forcing surface creation mode doesn't work in windowed mode, and that was not really optional in that game (or could have been, except for other limitations of Helix Mod, namely not being able to check which render target is active). And none of the tools I tried to force full screen mode would work, or if they did they interfered with Helix Mod in other ways that made them a dead end.
For a while I wasn't sure what to do about that, but I hatched a plan - since it was a Unity game I can force it to DX11 (and that actually works for DreadOut, which isn't the case with some other Unity games), which would then allow me to fix it with 3DMigoto instead. But, the fix had already pushed Helix Mod to it's limits, and at the time 3DMigoto lacked all the features that I was using from Helix Mod (and of course I needed features that were not in Helix mod as well).
So, while none of the features I've added to 3DMigoto have been specifically for DreadOut, re-fixing it has been a long term goal that I've been slowing working towards, because once 3DMigoto is capable of fixing that, it will be capable of fixing just about anything. I have a clear idea of how I'm going to solve copying matrices around and separating their render targets without adding a game-specific hack to 3DMigoto. At the moment about 80% of the pieces are in place - input handling, forced full screen, texture filtering, arbitrary resource copying and custom shader injection are all there now. Custom resource creation and scene detection are still missing, as is a DX11 version of shadertool to script the fix (I might use hlsltool instead, depending on whether there is any visible damage from the decompiler, and so I can use the view-space style lighting fix which needs new inputs and outputs added to shaders).
So, that would give you an idea of the amount of work that would need to go into a new DX9 wrapper to even catch up to Helix Mod. CommandList.{cpp,h} holds the bulk of the source code for a lot of these new features (arbitrary resource copying, part of texture filtering, custom shader injection and a few other things), and that currently stands at almost 3000 lines of code written over the last six months or so (plus however much is in other files, but counting those is harder) - and that will only grow more as the final few features are added and more edge cases are fixed (if it shrinks, it will only be because I split it into several files).
IMO, a better approach would be to start removing the DX11 dependency of a lot of this functionality from 3DMigoto to allow it to be used for DX12, DX10 and DX9 as well (of which DX9 will be the hardest as the API changes between DX9 and DX10 were greater than any API change since). That in itself is a fair chunk of work and not one I've given enough head space to to even hazard a guess as to how long it would take, how hard it would be and if it is even technically feasible.
Just off hand, here's a few other limitations I have personally hit in Helix Mod:
- A low limit to the number of matrices (2) and constant registers (3) that can be copied (plus one additional matrix copy slot tied to texture matching, but that has bugs and is only situationally useful to copy the MVP matrix of a single object per frame to match the depth of something else to it). Aside from DreadOut, this almost prevented the original Unity 4 fix of Dreamfall Chapters (I used up every spare output register from the directional shadow vertex shader and all of Helix Mod's copy slots and it was only just enough to do what I needed. The Unity 5 version dumped the custom shader, so I no longer do that), and the Unity 5 specular reflection fix (however I was able to rework the shadow fix to use the same matrices as the reflection fix to allow both to work together).
- No ability to disable injecting the stereo sampler, making it impossible to edit a vertex shader that uses all 4 samplers or a pixel shader that uses all 16 without damaging it (there are other ways to get the stereo information other than using samplers - the driver injects an undocumented stereo constant register, and the public list of functions in the nda version of nvapi suggests there is an API to inject our own).
- Samplers set by the game and replaced with Helix Mod's are not restored afterwards. The combination of this and the above causes problems for Unity games using Ceto water like The Forest and Stranded Deep - depending on the version of Ceto water, which sampler(s) are set by Helix Mod, the camera angle and relative position of the player (affects what other shaders are drawn and in what order) will cause glitches such as the water changing depth, the waves disappearing or not respecting the shoreline, and the water changing when convergence or separation is adjusted.
My plan with Stranded Deep is to convert it to DX11 (since the game started using DX11 specific effects anyway) where the problem won't exist, but The Forest does not (currently) render in DX11 - my plan there is to binary patch Helix Mod to disable injecting samplers into the vertex shader and use the undocumented stereo register, but this is not ideal (I will also have to disable the auto HUD). Either way I'm holding off until the game is out of EA since there is a possibility they will fix the effects in DX11 by then.
- Helix Mod can access the position of the first vertex of an effect, which I used for the auto HUD in Dreamfall Chapters. For that game I also really needed some related features that Helix Mod lacks - I needed the position of one of the UI elements to align the rest to it, but I was only able to get close by matching on particular textures I wanted to use as a reference and aligning the rest to them, but that didn't work if two textures I was matching were drawn simultaneously - I really needed to limit it to only the first in the frame.
This feature was useless for the auto HUD in The Forest where multiple icons were drawn in a single draw call and I needed the position of each individual icon, but could only get the position of one of them. 3DMigoto gives access to the entire vertex buffer to allow this (though we still depend on the game's HUD playing nice - if the HUD is drawn with an index buffer or icons are not drawn with 6 vertices things quickly get complicated).
- Helix Mod can create a custom depth texture and inject it into shaders as an additional render target or texture. I have used this once in Montague's mount when copying sampler registers was not working. I found a number of problems with this feature - Helix Mod fails to force it to stereo and it ends up being created mono, and as such I have had to use tricks to force it to stereo by tying it to be created along with a depth buffer, and forcing those to be stereo (and getting lucky that Helix Mod happens to still have the DefSurfaceCreationMode applied when it creates it using that method), but that had it's own set of problems as games can create depth buffers for other purposes so the size won't always match, which will break any shaders it is injected in to. My only option was to hardcode the resolution in the ini file.
- In games that require UseExtInterfaceOnly, most texture hashes are broken.
- No render target size filtering (for matching driver heuristics, and preventing some UI adjustments affection in-world objects or double-adjusting part of the UI)
- No depth buffer filtering (for matching driver heuristics)
- No support for the reverse stereo blit, so my auto crosshair has to calculate it's position independently in each eye, whereas in DX11 it can calculate it from both eyes simultaneously.
- Mouse coordinate injection is broken (and generally insufficient to implement a software mouse to fix all those games that use hardware cursors). I have some ideas to make this work in 3DMigoto, and one of the pieces (shader injection) is there already, but there's a lot more work needed and it's not clear if it is even possible yet.
There's probably others I've forgotten. But overall, Helix Mod has a huge amount of functionality that does work and it is a proven tool. Replacing it is something that I've thought about doing, as has bo3b and clearly you as well, but it just doesn't seem like a good use of time.
2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit
What about Chiri's Force resolution refresh thingy, is there a chance to get a better documented version of it? So that it's possible to force exclusive fullscreen or stereo in some dx9/10 games?
Just curious, I was trying it on Pirates of the Caribbean: At Worlds End which only runs at 1024x768. Running at this resolution on my 1080P monitor stretches the image from top to bottom and makes it look like garbage. Using Chiri's tool, it forces the overall window to 1920x1080, but the image is still being rendered at 1024x768 in the back buffer. So you get the image rendered pixel for pixel in the top left corner of the screen. This at least makes it look good, but if the force resolution could be applied to the back buffer as well, it would be awesome.
BTW, the game has a demo if anyone wants to observe what I'm talking about for themselves.
I've tried launch commands and various ini settings with no luck. It's one of those console ports with minimal settings/user intervention.
What about Chiri's Force resolution refresh thingy, is there a chance to get a better documented version of it? So that it's possible to force exclusive fullscreen or stereo in some dx9/10 games?
Just curious, I was trying it on Pirates of the Caribbean: At Worlds End which only runs at 1024x768. Running at this resolution on my 1080P monitor stretches the image from top to bottom and makes it look like garbage. Using Chiri's tool, it forces the overall window to 1920x1080, but the image is still being rendered at 1024x768 in the back buffer. So you get the image rendered pixel for pixel in the top left corner of the screen. This at least makes it look good, but if the force resolution could be applied to the back buffer as well, it would be awesome.
BTW, the game has a demo if anyone wants to observe what I'm talking about for themselves.
I've tried launch commands and various ini settings with no luck. It's one of those console ports with minimal settings/user intervention.
[quote="D-Man11"]What about Chiri's Force resolution refresh thingy, is there a chance to get a better documented version of it? So that it's possible to force exclusive fullscreen or stereo in some dx9/10 games?[/quote]I believe we have the source for that as 3DMigoto appears to have been based upon it. But the DX9 project in 3DMigoto has some problems (bit rotted because no one uses it and there isn't any motivation to maintain it). For DreadOut I could potentially have gone down that path and considered it quite seriously, but without being able to fix the game with Helix Mod it seemed a bit pointless, and while fixing it with 3DMigoto has certainly been the long road, it was well worth it because the features I've added are already being applied in heaps of other games :)
[quote]Just curious, I was trying it on Pirates of the Caribbean: At Worlds End which only runs at 1024x768. Running at this resolution on my 1080P monitor stretches the image from top to bottom and makes it look like garbage. Using Chiri's tool, it forces the overall window to 1920x1080, but the image is still being rendered at 1024x768 in the back buffer. So you get the image rendered pixel for pixel in the top left corner of the screen. This at least makes it look good, but if the force resolution could be applied to the back buffer as well, it would be awesome.[/quote]Both Helix Mod and 3DMigoto can be used to force render targets to a given size, but while it should work in theory, in practice it doesn't seem to work so well, but you might get lucky. Something like this in Helix Mod *might* do the trick:
[code]
SurfaceCreationModeList=0;
RTCreationModeList=0;
DepthStencilSurfaceModeList=0;
[SF0]
Width = 1024
Height = 768
ForceWidth = 1920
ForceHeight = 1080
[RT0]
Width = 1024
Height = 768
ForceWidth = 1920
ForceHeight = 1080
[DS0]
Width = 1024
Height = 768
ForceWidth = 1920
ForceHeight = 1080
[/code]
To do the same in 3DMigoto you need to identify the render and depth target hashes (easiest way is probably to check ShaderUsage.txt for any with the expected size).
D-Man11 said:What about Chiri's Force resolution refresh thingy, is there a chance to get a better documented version of it? So that it's possible to force exclusive fullscreen or stereo in some dx9/10 games?
I believe we have the source for that as 3DMigoto appears to have been based upon it. But the DX9 project in 3DMigoto has some problems (bit rotted because no one uses it and there isn't any motivation to maintain it). For DreadOut I could potentially have gone down that path and considered it quite seriously, but without being able to fix the game with Helix Mod it seemed a bit pointless, and while fixing it with 3DMigoto has certainly been the long road, it was well worth it because the features I've added are already being applied in heaps of other games :)
Just curious, I was trying it on Pirates of the Caribbean: At Worlds End which only runs at 1024x768. Running at this resolution on my 1080P monitor stretches the image from top to bottom and makes it look like garbage. Using Chiri's tool, it forces the overall window to 1920x1080, but the image is still being rendered at 1024x768 in the back buffer. So you get the image rendered pixel for pixel in the top left corner of the screen. This at least makes it look good, but if the force resolution could be applied to the back buffer as well, it would be awesome.
Both Helix Mod and 3DMigoto can be used to force render targets to a given size, but while it should work in theory, in practice it doesn't seem to work so well, but you might get lucky. Something like this in Helix Mod *might* do the trick:
To do the same in 3DMigoto you need to identify the render and depth target hashes (easiest way is probably to check ShaderUsage.txt for any with the expected size).
2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit
[quote="DarkStarSword"]There's a lot of problems with Helix Mod, but addressing those isn't useful (at least not to me - DJ-RK does have a point that there is a place for a DX9 wrapper that is easier to work with and doesn't crash when hunting vertex shaders) until (almost) all the features that Helix Mod supports has been reimplemented, and that would require a *huge* amount of effort for little return.
And I'm not saying that lightly - you may recall that a little over a year ago I fixed DreadOut Act 1. At the time I got *very lucky* that I was able to fix that with Helix Mod at all (the draw order was favourable). Act 2 came out about a month later and my luck ran out and it was beyond Helix Mod's feature set - I could make it playable, but I would have to sacrifice some or all of the shadows to do so (the tricky part is the dual render targets the game uses with differing FOVs, requiring four matrices to be copied to fix both, but Helix mod can only copy two matrices and there is no way to separate them into separate sets of matrices based on the render target - Helix Mod doesn't support render target filtering, let alone any way to copy matrices based on that).
Then about a month after that the dev updated the game to use borderless windowed mode and that totally broke the fix as forcing surface creation mode doesn't work in windowed mode, and that was not really optional in that game (or could have been, except for other limitations of Helix Mod, namely not being able to check which render target is active). And none of the tools I tried to force full screen mode would work, or if they did they interfered with Helix Mod in other ways that made them a dead end.
For a while I wasn't sure what to do about that, but I hatched a plan - since it was a Unity game I can force it to DX11 (and that actually works for DreadOut, which isn't the case with some other Unity games), which would then allow me to fix it with 3DMigoto instead. But, the fix had already pushed Helix Mod to it's limits, and at the time 3DMigoto lacked all the features that I was using from Helix Mod (and of course I needed features that were not in Helix mod as well).
So, while none of the features I've added to 3DMigoto have been specifically for DreadOut, re-fixing it has been a long term goal that I've been slowing working towards, because once 3DMigoto is capable of fixing that, it will be capable of fixing just about anything. I have a clear idea of how I'm going to solve copying matrices around and separating their render targets without adding a game-specific hack to 3DMigoto. At the moment about 80% of the pieces are in place - input handling, forced full screen, texture filtering, arbitrary resource copying and custom shader injection are all there now. Custom resource creation and scene detection are still missing, as is a DX11 version of shadertool to script the fix (I might use hlsltool instead, depending on whether there is any visible damage from the decompiler, and so I can use the view-space style lighting fix which needs new inputs and outputs added to shaders).
So, that would give you an idea of the amount of work that would need to go into a new DX9 wrapper to even catch up to Helix Mod. CommandList.{cpp,h} holds the bulk of the source code for a lot of these new features (arbitrary resource copying, part of texture filtering, custom shader injection and a few other things), and that currently stands at almost 3000 lines of code written over the last six months or so (plus however much is in other files, but counting those is harder) - and that will only grow more as the final few features are added and more edge cases are fixed (if it shrinks, it will only be because I split it into several files).
IMO, a better approach would be to start removing the DX11 dependency of a lot of this functionality from 3DMigoto to allow it to be used for DX12, DX10 and DX9 as well (of which DX9 will be the hardest as the API changes between DX9 and DX10 were greater than any API change since). That in itself is a fair chunk of work and not one I've given enough head space to to even hazard a guess as to how long it would take, how hard it would be and if it is even technically feasible.
Just off hand, here's a few other limitations I have personally hit in Helix Mod:
- A low limit to the number of matrices (2) and constant registers (3) that can be copied (plus one additional matrix copy slot tied to texture matching, but that has bugs and is only situationally useful to copy the MVP matrix of a single object per frame to match the depth of something else to it). Aside from DreadOut, this almost prevented the original Unity 4 fix of Dreamfall Chapters (I used up every spare output register from the directional shadow vertex shader and all of Helix Mod's copy slots and it was only just enough to do what I needed. The Unity 5 version dumped the custom shader, so I no longer do that), and the Unity 5 specular reflection fix (however I was able to rework the shadow fix to use the same matrices as the reflection fix to allow both to work together).
- No ability to disable injecting the stereo sampler, making it impossible to edit a vertex shader that uses all 4 samplers or a pixel shader that uses all 16 without damaging it (there are other ways to get the stereo information other than using samplers - the driver injects an undocumented stereo constant register, and the public list of functions in the nda version of nvapi suggests there is an API to inject our own).
- Samplers set by the game and replaced with Helix Mod's are not restored afterwards. The combination of this and the above causes problems for Unity games using Ceto water like The Forest and Stranded Deep - depending on the version of Ceto water, which sampler(s) are set by Helix Mod, the camera angle and relative position of the player (affects what other shaders are drawn and in what order) will cause glitches such as the water changing depth, the waves disappearing or not respecting the shoreline, and the water changing when convergence or separation is adjusted.
My plan with Stranded Deep is to convert it to DX11 (since the game started using DX11 specific effects anyway) where the problem won't exist, but The Forest does not (currently) render in DX11 - my plan there is to binary patch Helix Mod to disable injecting samplers into the vertex shader and use the undocumented stereo register, but this is not ideal (I will also have to disable the auto HUD). Either way I'm holding off until the game is out of EA since there is a possibility they will fix the effects in DX11 by then.
- Helix Mod can access the position of the first vertex of an effect, which I used for the auto HUD in Dreamfall Chapters. For that game I also really needed some related features that Helix Mod lacks - I needed the position of one of the UI elements to align the rest to it, but I was only able to get close by matching on particular textures I wanted to use as a reference and aligning the rest to them, but that didn't work if two textures I was matching were drawn simultaneously - I really needed to limit it to only the first in the frame.
This feature was useless for the auto HUD in The Forest where multiple icons were drawn in a single draw call and I needed the position of each individual icon, but could only get the position of one of them. 3DMigoto gives access to the entire vertex buffer to allow this (though we still depend on the game's HUD playing nice - if the HUD is drawn with an index buffer or icons are not drawn with 6 vertices things quickly get complicated).
- Helix Mod can create a custom depth texture and inject it into shaders as an additional render target or texture. I have used this once in Montague's mount when copying sampler registers was not working. I found a number of problems with this feature - Helix Mod fails to force it to stereo and it ends up being created mono, and as such I have had to use tricks to force it to stereo by tying it to be created along with a depth buffer, and forcing those to be stereo (and getting lucky that Helix Mod happens to still have the DefSurfaceCreationMode applied when it creates it using that method), but that had it's own set of problems as games can create depth buffers for other purposes so the size won't always match, which will break any shaders it is injected in to. My only option was to hardcode the resolution in the ini file.
- In games that require UseExtInterfaceOnly, most texture hashes are broken.
- No render target size filtering (for matching driver heuristics, and preventing some UI adjustments affection in-world objects or double-adjusting part of the UI)
- No depth buffer filtering (for matching driver heuristics)
- No support for the reverse stereo blit, so my auto crosshair has to calculate it's position independently in each eye, whereas in DX11 it can calculate it from both eyes simultaneously.
- Mouse coordinate injection is broken (and generally insufficient to implement a software mouse to fix all those games that use hardware cursors). I have some ideas to make this work in 3DMigoto, and one of the pieces (shader injection) is there already, but there's a lot more work needed and it's not clear if it is even possible yet.
There's probably others I've forgotten. But overall, Helix Mod has a huge amount of functionality that does work and it is a proven tool. Replacing it is something that I've thought about doing, as has bo3b and clearly you as well, but it just doesn't seem like a good use of time.
[/quote]
All of this ^
I see no value in trying to emulate what is already there, just to perhaps correct a few missing features. Lets face it, there are few games that can't be fixed *at all*, and (fortunately) it was never AAA games (because I guess Helix was around to update the wrapper at the time). It usually pretty much works out the box, and its feature set is impressive, if hard to understand sometimes.
Either bo3b or eqzitara did ask Helix if he would give us the source code but he was unwilling to because it was "a mess" or something. Even on the promise that no one else would see it, he was unwilling. Maybe he would change his mind nowadays? That would be a much more efficient use of time.
If he did, and if it was possible, it would be better to daisy-chain/wrap his code into 3DMigoto so that a consistent set of features would be available from 3DMigoto. We now have Flugan's ASM wrapper in 3DMigoto which has added to the power and flexibility of 3DMigoto considerably, so something similar with Helix code (if he gave us the source code) would cut out a large amount of work, and allow "someone" to extend some of the missing features. Also, he did develop a DX11 version (for Bioshock Infinite) so information on how to merge that into 3DMigoto might be more readily available. As DSS notes, there was a major DX architectural change between 9 and 10 (11 and 12 are basically updates to 10) which is one reason why DX10 never really took off for so long, so adding DX9 to 3DMigoto from scratch would still be loads of work as the implementation of almost all features would be different.
To be honest though, aside from the LEGO games, I have not fixed a DX9 game for ages (I don't think) - even the updated Divinity Original Sin fix was DX11. So I really think the efforts of the few people developing this stuff should be focussed on DX11/12/VR.
DarkStarSword said:There's a lot of problems with Helix Mod, but addressing those isn't useful (at least not to me - DJ-RK does have a point that there is a place for a DX9 wrapper that is easier to work with and doesn't crash when hunting vertex shaders) until (almost) all the features that Helix Mod supports has been reimplemented, and that would require a *huge* amount of effort for little return.
And I'm not saying that lightly - you may recall that a little over a year ago I fixed DreadOut Act 1. At the time I got *very lucky* that I was able to fix that with Helix Mod at all (the draw order was favourable). Act 2 came out about a month later and my luck ran out and it was beyond Helix Mod's feature set - I could make it playable, but I would have to sacrifice some or all of the shadows to do so (the tricky part is the dual render targets the game uses with differing FOVs, requiring four matrices to be copied to fix both, but Helix mod can only copy two matrices and there is no way to separate them into separate sets of matrices based on the render target - Helix Mod doesn't support render target filtering, let alone any way to copy matrices based on that).
Then about a month after that the dev updated the game to use borderless windowed mode and that totally broke the fix as forcing surface creation mode doesn't work in windowed mode, and that was not really optional in that game (or could have been, except for other limitations of Helix Mod, namely not being able to check which render target is active). And none of the tools I tried to force full screen mode would work, or if they did they interfered with Helix Mod in other ways that made them a dead end.
For a while I wasn't sure what to do about that, but I hatched a plan - since it was a Unity game I can force it to DX11 (and that actually works for DreadOut, which isn't the case with some other Unity games), which would then allow me to fix it with 3DMigoto instead. But, the fix had already pushed Helix Mod to it's limits, and at the time 3DMigoto lacked all the features that I was using from Helix Mod (and of course I needed features that were not in Helix mod as well).
So, while none of the features I've added to 3DMigoto have been specifically for DreadOut, re-fixing it has been a long term goal that I've been slowing working towards, because once 3DMigoto is capable of fixing that, it will be capable of fixing just about anything. I have a clear idea of how I'm going to solve copying matrices around and separating their render targets without adding a game-specific hack to 3DMigoto. At the moment about 80% of the pieces are in place - input handling, forced full screen, texture filtering, arbitrary resource copying and custom shader injection are all there now. Custom resource creation and scene detection are still missing, as is a DX11 version of shadertool to script the fix (I might use hlsltool instead, depending on whether there is any visible damage from the decompiler, and so I can use the view-space style lighting fix which needs new inputs and outputs added to shaders).
So, that would give you an idea of the amount of work that would need to go into a new DX9 wrapper to even catch up to Helix Mod. CommandList.{cpp,h} holds the bulk of the source code for a lot of these new features (arbitrary resource copying, part of texture filtering, custom shader injection and a few other things), and that currently stands at almost 3000 lines of code written over the last six months or so (plus however much is in other files, but counting those is harder) - and that will only grow more as the final few features are added and more edge cases are fixed (if it shrinks, it will only be because I split it into several files).
IMO, a better approach would be to start removing the DX11 dependency of a lot of this functionality from 3DMigoto to allow it to be used for DX12, DX10 and DX9 as well (of which DX9 will be the hardest as the API changes between DX9 and DX10 were greater than any API change since). That in itself is a fair chunk of work and not one I've given enough head space to to even hazard a guess as to how long it would take, how hard it would be and if it is even technically feasible.
Just off hand, here's a few other limitations I have personally hit in Helix Mod:
- A low limit to the number of matrices (2) and constant registers (3) that can be copied (plus one additional matrix copy slot tied to texture matching, but that has bugs and is only situationally useful to copy the MVP matrix of a single object per frame to match the depth of something else to it). Aside from DreadOut, this almost prevented the original Unity 4 fix of Dreamfall Chapters (I used up every spare output register from the directional shadow vertex shader and all of Helix Mod's copy slots and it was only just enough to do what I needed. The Unity 5 version dumped the custom shader, so I no longer do that), and the Unity 5 specular reflection fix (however I was able to rework the shadow fix to use the same matrices as the reflection fix to allow both to work together).
- No ability to disable injecting the stereo sampler, making it impossible to edit a vertex shader that uses all 4 samplers or a pixel shader that uses all 16 without damaging it (there are other ways to get the stereo information other than using samplers - the driver injects an undocumented stereo constant register, and the public list of functions in the nda version of nvapi suggests there is an API to inject our own).
- Samplers set by the game and replaced with Helix Mod's are not restored afterwards. The combination of this and the above causes problems for Unity games using Ceto water like The Forest and Stranded Deep - depending on the version of Ceto water, which sampler(s) are set by Helix Mod, the camera angle and relative position of the player (affects what other shaders are drawn and in what order) will cause glitches such as the water changing depth, the waves disappearing or not respecting the shoreline, and the water changing when convergence or separation is adjusted.
My plan with Stranded Deep is to convert it to DX11 (since the game started using DX11 specific effects anyway) where the problem won't exist, but The Forest does not (currently) render in DX11 - my plan there is to binary patch Helix Mod to disable injecting samplers into the vertex shader and use the undocumented stereo register, but this is not ideal (I will also have to disable the auto HUD). Either way I'm holding off until the game is out of EA since there is a possibility they will fix the effects in DX11 by then.
- Helix Mod can access the position of the first vertex of an effect, which I used for the auto HUD in Dreamfall Chapters. For that game I also really needed some related features that Helix Mod lacks - I needed the position of one of the UI elements to align the rest to it, but I was only able to get close by matching on particular textures I wanted to use as a reference and aligning the rest to them, but that didn't work if two textures I was matching were drawn simultaneously - I really needed to limit it to only the first in the frame.
This feature was useless for the auto HUD in The Forest where multiple icons were drawn in a single draw call and I needed the position of each individual icon, but could only get the position of one of them. 3DMigoto gives access to the entire vertex buffer to allow this (though we still depend on the game's HUD playing nice - if the HUD is drawn with an index buffer or icons are not drawn with 6 vertices things quickly get complicated).
- Helix Mod can create a custom depth texture and inject it into shaders as an additional render target or texture. I have used this once in Montague's mount when copying sampler registers was not working. I found a number of problems with this feature - Helix Mod fails to force it to stereo and it ends up being created mono, and as such I have had to use tricks to force it to stereo by tying it to be created along with a depth buffer, and forcing those to be stereo (and getting lucky that Helix Mod happens to still have the DefSurfaceCreationMode applied when it creates it using that method), but that had it's own set of problems as games can create depth buffers for other purposes so the size won't always match, which will break any shaders it is injected in to. My only option was to hardcode the resolution in the ini file.
- In games that require UseExtInterfaceOnly, most texture hashes are broken.
- No render target size filtering (for matching driver heuristics, and preventing some UI adjustments affection in-world objects or double-adjusting part of the UI)
- No depth buffer filtering (for matching driver heuristics)
- No support for the reverse stereo blit, so my auto crosshair has to calculate it's position independently in each eye, whereas in DX11 it can calculate it from both eyes simultaneously.
- Mouse coordinate injection is broken (and generally insufficient to implement a software mouse to fix all those games that use hardware cursors). I have some ideas to make this work in 3DMigoto, and one of the pieces (shader injection) is there already, but there's a lot more work needed and it's not clear if it is even possible yet.
There's probably others I've forgotten. But overall, Helix Mod has a huge amount of functionality that does work and it is a proven tool. Replacing it is something that I've thought about doing, as has bo3b and clearly you as well, but it just doesn't seem like a good use of time.
All of this ^
I see no value in trying to emulate what is already there, just to perhaps correct a few missing features. Lets face it, there are few games that can't be fixed *at all*, and (fortunately) it was never AAA games (because I guess Helix was around to update the wrapper at the time). It usually pretty much works out the box, and its feature set is impressive, if hard to understand sometimes.
Either bo3b or eqzitara did ask Helix if he would give us the source code but he was unwilling to because it was "a mess" or something. Even on the promise that no one else would see it, he was unwilling. Maybe he would change his mind nowadays? That would be a much more efficient use of time.
If he did, and if it was possible, it would be better to daisy-chain/wrap his code into 3DMigoto so that a consistent set of features would be available from 3DMigoto. We now have Flugan's ASM wrapper in 3DMigoto which has added to the power and flexibility of 3DMigoto considerably, so something similar with Helix code (if he gave us the source code) would cut out a large amount of work, and allow "someone" to extend some of the missing features. Also, he did develop a DX11 version (for Bioshock Infinite) so information on how to merge that into 3DMigoto might be more readily available. As DSS notes, there was a major DX architectural change between 9 and 10 (11 and 12 are basically updates to 10) which is one reason why DX10 never really took off for so long, so adding DX9 to 3DMigoto from scratch would still be loads of work as the implementation of almost all features would be different.
To be honest though, aside from the LEGO games, I have not fixed a DX9 game for ages (I don't think) - even the updated Divinity Original Sin fix was DX11. So I really think the efforts of the few people developing this stuff should be focussed on DX11/12/VR.
Thanks for all the input.
When I think of HeliX wrapper I tend to think of it as it was in v1 when it first released.
At that point it was already fairly complex as HeliX didn't release until it was ready to be used.
I'm not that interested in perfectly replicating the complex features of latest HeliX just to make what already works still work in another wrapper. I've already had enough of that making DX11 work on Win8 while it was unsupported in 3DMigoto. It is not that fun even when you have source code access.
What I hear is a combination of limitations in the advanced features of HeliX and also underlying limitations of dx9 itself unless I'm mistaken. What I currently offer is a hunting environment without any double taps by mistake and ability to dump directly into folder without any rename needed. Pretty basic stuff. Maybe some more but I have not looked in a while.
Just getting dx9 to work with HeliX took me ages as it has really been on the backburner but my biggest stumbling block was getting the correct CRC value of the shader as otherwise it was pretty worthless.
Just updated my DX document and there were about 40 dx10 titles in total, pretty few.
When I think of HeliX wrapper I tend to think of it as it was in v1 when it first released.
At that point it was already fairly complex as HeliX didn't release until it was ready to be used.
I'm not that interested in perfectly replicating the complex features of latest HeliX just to make what already works still work in another wrapper. I've already had enough of that making DX11 work on Win8 while it was unsupported in 3DMigoto. It is not that fun even when you have source code access.
What I hear is a combination of limitations in the advanced features of HeliX and also underlying limitations of dx9 itself unless I'm mistaken. What I currently offer is a hunting environment without any double taps by mistake and ability to dump directly into folder without any rename needed. Pretty basic stuff. Maybe some more but I have not looked in a while.
Just getting dx9 to work with HeliX took me ages as it has really been on the backburner but my biggest stumbling block was getting the correct CRC value of the shader as otherwise it was pretty worthless.
Just updated my DX document and there were about 40 dx10 titles in total, pretty few.
Thanks to everybody using my assembler it warms my heart.
To have a critical piece of code that everyone can enjoy!
What more can you ask for?
There is literally no point to DX10. DX10 games were "pushed" by windows release by NVidia. Cause they knew that when people upgrade OS they generally upgrade system/card. Except the OS's were crap and buggy. -Millenium edition / 2000- Were such crap that 80% of users on steam had XP even two years into windows 7 release.
I ran dual boot so I know a lot of comparisons. Off the top of my head....
Red Faction - Huge performance issues. Light beams added. DX10 is disabled by default.
Devil May Cry 4 - Huge performance issues. Better shadows. DX10 is disabled by default.
Assassins Creed -Huge performance issues. EVENTUALLY REMOVED IN LATER PATCH.
Bioshock 1/2 - Minor lighting improvement. No one bothered since you could only force AA with DX9 though I guess that's irrelevant now.
The only games exclusive to DX10 were Halo 2 [which is almost impossible to get working on PC nowadays]. ShadowRun which is dead cause its multiplayer.
There is literally no point to DX10. DX10 games were "pushed" by windows release by NVidia. Cause they knew that when people upgrade OS they generally upgrade system/card. Except the OS's were crap and buggy. -Millenium edition / 2000- Were such crap that 80% of users on steam had XP even two years into windows 7 release.
I ran dual boot so I know a lot of comparisons. Off the top of my head....
Red Faction - Huge performance issues. Light beams added. DX10 is disabled by default.
Devil May Cry 4 - Huge performance issues. Better shadows. DX10 is disabled by default.
Assassins Creed -Huge performance issues. EVENTUALLY REMOVED IN LATER PATCH.
Bioshock 1/2 - Minor lighting improvement. No one bothered since you could only force AA with DX9 though I guess that's irrelevant now.
The only games exclusive to DX10 were Halo 2 [which is almost impossible to get working on PC nowadays]. ShadowRun which is dead cause its multiplayer.
Co-founder of helixmod.blog.com
If you like one of my helixmod patches and want to donate. Can send to me through paypal - eqzitara@yahoo.com
As far as I can tell Halo 2 is dx9 and the same with ShadowRun.
The amount of dx10 games are >40 but almost all have dx9 rendering paths.
I personally own about 20 of these games.
I'm not counting games with dx11 support in this list.
To be honest they are pretty rare but in some cases the DX10 effects were very apparent and I guess in others you mostly couldn't tell the difference.
With Devil May Cry 4 you choose which version to run in the launcher so how can one be the default.
The same with Resident Evil 5.
Finally the biggest difference I saw in Bioshock was the water effects.
While I'm not sure about the differences there must have been a difference between crysis dx9 and dx10.
As far as I can tell Halo 2 is dx9 and the same with ShadowRun.
The amount of dx10 games are >40 but almost all have dx9 rendering paths.
I personally own about 20 of these games.
I'm not counting games with dx11 support in this list.
To be honest they are pretty rare but in some cases the DX10 effects were very apparent and I guess in others you mostly couldn't tell the difference.
With Devil May Cry 4 you choose which version to run in the launcher so how can one be the default.
The same with Resident Evil 5.
Finally the biggest difference I saw in Bioshock was the water effects.
While I'm not sure about the differences there must have been a difference between crysis dx9 and dx10.
Thanks to everybody using my assembler it warms my heart.
To have a critical piece of code that everyone can enjoy!
What more can you ask for?
[quote="D-Man11"]Just curious, I was trying it on Pirates of the Caribbean: At Worlds End which only runs at 1024x768[/quote]
TsaebehT pointed me in the right direction by telling me about a dead link for a resolution patch.
Using the posters name, I was able to chase down a different post with the patch. Using the patch, I can run Pirates of the Caribbean: At Worlds End at 1920x1080. (PS2 port/controls suck)
Squ1zZy states: "Guys, I found a CD with all my sources and patches for e few older games. Could this be of any use? If so, where can I upload it?"
http://www.wsgf.org/forums/viewtopic.php?f=64&t=21680
List:
Patch Albatross18
Patch Close Combat 2
Patch DF Black Hawk Down
Patch EA Sports Cricket 07
Patch EA Sports FIFA 07
Patch EA Sports NBA Live 07
Patch EA Sports NHL 06
Patch EA Sports Tiger Woods PGA Tour 05
Patch EA Sports Tiger Woods PGA Tour 07
Patch Empire Earth 2
Patch Fahrenheit
Patch Hidden & Dangerous 2
Patch Need For Speed Carbon
Patch Need For Speed Underground
Patch Need For Speed Underground 2
Patch Onimusha 3
Patch Pirates Of The Caribbean Worlds End
Patch Prey
Patch Prince Of Persia The Sands Of Time
Patch Prince Of Persia Warrior Within
Patch Rainbow Six Vegas
Patch ScarFace
Patch Silent Hill 2
Patch Simpsons Hit & Run
Patch Soldier Of Fortune
Patch Soldier Of Fortune 2 Double Helix MP
Patch Soldier Of Fortune 2 Double Helix SP
Patch Sonic Adventure DX
Patch Spiderman 3
Patch SWKotor 2
Patch Warcraft 3
Patch X-Men The Official Game
D-Man11 said:Just curious, I was trying it on Pirates of the Caribbean: At Worlds End which only runs at 1024x768
TsaebehT pointed me in the right direction by telling me about a dead link for a resolution patch.
Using the posters name, I was able to chase down a different post with the patch. Using the patch, I can run Pirates of the Caribbean: At Worlds End at 1920x1080. (PS2 port/controls suck)
List:
Patch Albatross18
Patch Close Combat 2
Patch DF Black Hawk Down
Patch EA Sports Cricket 07
Patch EA Sports FIFA 07
Patch EA Sports NBA Live 07
Patch EA Sports NHL 06
Patch EA Sports Tiger Woods PGA Tour 05
Patch EA Sports Tiger Woods PGA Tour 07
Patch Empire Earth 2
Patch Fahrenheit
Patch Hidden & Dangerous 2
Patch Need For Speed Carbon
Patch Need For Speed Underground
Patch Need For Speed Underground 2
Patch Onimusha 3
Patch Pirates Of The Caribbean Worlds End
Patch Prey
Patch Prince Of Persia The Sands Of Time
Patch Prince Of Persia Warrior Within
Patch Rainbow Six Vegas
Patch ScarFace
Patch Silent Hill 2
Patch Simpsons Hit & Run
Patch Soldier Of Fortune
Patch Soldier Of Fortune 2 Double Helix MP
Patch Soldier Of Fortune 2 Double Helix SP
Patch Sonic Adventure DX
Patch Spiderman 3
Patch SWKotor 2
Patch Warcraft 3
Patch X-Men The Official Game
May be this will be of some interest here
DGVOODOO has a DX9 wrapper in development, many games can be wrapped to DX11 already
[url]https://www.vogons.org/viewtopic.php?f=59&t=51790[/url]
I read about it a few days ago. It's compatible with Shader Model 1.X games for now. This increases the chance of doing fixes with 3Dmigoto :).
I haven't tried it with any DX9 game yet because I'm very busy with other games. I'll have to check what games I own that need a fix and work with dgVoodoo.
I read about it a few days ago. It's compatible with Shader Model 1.X games for now. This increases the chance of doing fixes with 3Dmigoto :).
I haven't tried it with any DX9 game yet because I'm very busy with other games. I'll have to check what games I own that need a fix and work with dgVoodoo.
I would consider my dx10 wrapper to be pre-alpha as most of the focus has been on dx11 with some recent work on dx9. My dx10 wrapper can dump shaders and swap shaders but I can't remember if it has the code for hunting shaders.
Is there something missing from HeliX dx9 tools or are they as good as they can get?
My big issue is that hunting shaders is a pain for probably personal reasons.
I press the next shader button once but the wrapper skips two shaders ahead. I try to backtrack and it skips two shaders back again. Because of this it's really painful to use. My guess is that other people don't have this particular problem.
I was happy for a while when loading the portal fix into my dx9 wrapper until I realize HeliX was doing a lot more than replacing shaders and there was loads of configuration details in the INI file.
At the end of the day it seems we don't need another dx9 wrapper but having access to the sourcecode does allow for changes to be made and improvements beyond what is currently possible.
It could fall into the category of waste of time or HeliX is way more advanced so no way to catch up.
If used in new projects it doesn't have to emulate HeliX perfectly and if being as compatible as possible fixes should be able to be ported in a straight forward fashion and then adding the desired ground breaking functionality that could be added to a wrapper with source code access.
I should reiterate that all my wrappers are open source under GPL v3 because I use Nektra hooks which is either licensed with GPL or extremely expensive $449 per developer per product.
DX9 could be considered to be a done deal given HeliXmod and the maturity there but without source code we are limited to the limitations of HeliXmod. I mean HeliX dx11 is pretty much useless in the state he left it in and no game other than Bioshook Infinite is using it. It's not because his wrapper is bad but it lacks all the debug features available in HeliX dx9 wrapper.
I'm not trying to oversell my dx9 wrapper as it is pretty much limited to replacing shaders with no fancy functionality yet.
Thanks to everybody using my assembler it warms my heart.
To have a critical piece of code that everyone can enjoy!
What more can you ask for?
donations: ulfjalmbrant@hotmail.com
No, I too have this problem, and suspect everyone else does. I've even created macros for dumping all shaders in a scene, where I program the next shader button to only be pressed for 0.001 of a second, and it STILL will occasionally jump 2 in a row, so that definitely is a major grievance. I had also mentioned in your other recent thread quite a few other issues I have, so given that I'm still just learning what all these other functions in Helixmod are, I would appreciate and use a less functional, but much more user friendly wrapper as long as the 2 were compatible with one another (ie. start off with using yours, and then as I learn of certain other functions being needed, switch over to Helixmod as needed). And, with access to the source code, all the functionality could theoretically be added over time.
Also, keep in mind that the DX9 library is HUGE, there are still a ton of games that have not been fixed, and games are still being released in DX9 only (or at least compatible) as not every person has the hardware capable of DX11.
So, yeah, I definitely think there's a very welcome place for an open sourced DX9 wrapper.
3D Gaming Rig: CPU: i7 7700K @ 4.9Ghz | Mobo: Asus Maximus Hero VIII | RAM: Corsair Dominator 16GB | GPU: 2 x GTX 1080 Ti SLI | 3xSSDs for OS and Apps, 2 x HDD's for 11GB storage | PSU: Seasonic X-1250 M2| Case: Corsair C70 | Cooling: Corsair H115i Hydro cooler | Displays: Asus PG278QR, BenQ XL2420TX & BenQ HT1075 | OS: Windows 10 Pro + Windows 7 dual boot
Like my fixes? Dontations can be made to: www.paypal.me/DShanz or rshannonca@gmail.com
Like electronic music? Check out: www.soundcloud.com/dj-ryan-king
And I'm not saying that lightly - you may recall that a little over a year ago I fixed DreadOut Act 1. At the time I got *very lucky* that I was able to fix that with Helix Mod at all (the draw order was favourable). Act 2 came out about a month later and my luck ran out and it was beyond Helix Mod's feature set - I could make it playable, but I would have to sacrifice some or all of the shadows to do so (the tricky part is the dual render targets the game uses with differing FOVs, requiring four matrices to be copied to fix both, but Helix mod can only copy two matrices and there is no way to separate them into separate sets of matrices based on the render target - Helix Mod doesn't support render target filtering, let alone any way to copy matrices based on that).
Then about a month after that the dev updated the game to use borderless windowed mode and that totally broke the fix as forcing surface creation mode doesn't work in windowed mode, and that was not really optional in that game (or could have been, except for other limitations of Helix Mod, namely not being able to check which render target is active). And none of the tools I tried to force full screen mode would work, or if they did they interfered with Helix Mod in other ways that made them a dead end.
For a while I wasn't sure what to do about that, but I hatched a plan - since it was a Unity game I can force it to DX11 (and that actually works for DreadOut, which isn't the case with some other Unity games), which would then allow me to fix it with 3DMigoto instead. But, the fix had already pushed Helix Mod to it's limits, and at the time 3DMigoto lacked all the features that I was using from Helix Mod (and of course I needed features that were not in Helix mod as well).
So, while none of the features I've added to 3DMigoto have been specifically for DreadOut, re-fixing it has been a long term goal that I've been slowing working towards, because once 3DMigoto is capable of fixing that, it will be capable of fixing just about anything. I have a clear idea of how I'm going to solve copying matrices around and separating their render targets without adding a game-specific hack to 3DMigoto. At the moment about 80% of the pieces are in place - input handling, forced full screen, texture filtering, arbitrary resource copying and custom shader injection are all there now. Custom resource creation and scene detection are still missing, as is a DX11 version of shadertool to script the fix (I might use hlsltool instead, depending on whether there is any visible damage from the decompiler, and so I can use the view-space style lighting fix which needs new inputs and outputs added to shaders).
So, that would give you an idea of the amount of work that would need to go into a new DX9 wrapper to even catch up to Helix Mod. CommandList.{cpp,h} holds the bulk of the source code for a lot of these new features (arbitrary resource copying, part of texture filtering, custom shader injection and a few other things), and that currently stands at almost 3000 lines of code written over the last six months or so (plus however much is in other files, but counting those is harder) - and that will only grow more as the final few features are added and more edge cases are fixed (if it shrinks, it will only be because I split it into several files).
IMO, a better approach would be to start removing the DX11 dependency of a lot of this functionality from 3DMigoto to allow it to be used for DX12, DX10 and DX9 as well (of which DX9 will be the hardest as the API changes between DX9 and DX10 were greater than any API change since). That in itself is a fair chunk of work and not one I've given enough head space to to even hazard a guess as to how long it would take, how hard it would be and if it is even technically feasible.
Just off hand, here's a few other limitations I have personally hit in Helix Mod:
- A low limit to the number of matrices (2) and constant registers (3) that can be copied (plus one additional matrix copy slot tied to texture matching, but that has bugs and is only situationally useful to copy the MVP matrix of a single object per frame to match the depth of something else to it). Aside from DreadOut, this almost prevented the original Unity 4 fix of Dreamfall Chapters (I used up every spare output register from the directional shadow vertex shader and all of Helix Mod's copy slots and it was only just enough to do what I needed. The Unity 5 version dumped the custom shader, so I no longer do that), and the Unity 5 specular reflection fix (however I was able to rework the shadow fix to use the same matrices as the reflection fix to allow both to work together).
- No ability to disable injecting the stereo sampler, making it impossible to edit a vertex shader that uses all 4 samplers or a pixel shader that uses all 16 without damaging it (there are other ways to get the stereo information other than using samplers - the driver injects an undocumented stereo constant register, and the public list of functions in the nda version of nvapi suggests there is an API to inject our own).
- Samplers set by the game and replaced with Helix Mod's are not restored afterwards. The combination of this and the above causes problems for Unity games using Ceto water like The Forest and Stranded Deep - depending on the version of Ceto water, which sampler(s) are set by Helix Mod, the camera angle and relative position of the player (affects what other shaders are drawn and in what order) will cause glitches such as the water changing depth, the waves disappearing or not respecting the shoreline, and the water changing when convergence or separation is adjusted.
My plan with Stranded Deep is to convert it to DX11 (since the game started using DX11 specific effects anyway) where the problem won't exist, but The Forest does not (currently) render in DX11 - my plan there is to binary patch Helix Mod to disable injecting samplers into the vertex shader and use the undocumented stereo register, but this is not ideal (I will also have to disable the auto HUD). Either way I'm holding off until the game is out of EA since there is a possibility they will fix the effects in DX11 by then.
- Helix Mod can access the position of the first vertex of an effect, which I used for the auto HUD in Dreamfall Chapters. For that game I also really needed some related features that Helix Mod lacks - I needed the position of one of the UI elements to align the rest to it, but I was only able to get close by matching on particular textures I wanted to use as a reference and aligning the rest to them, but that didn't work if two textures I was matching were drawn simultaneously - I really needed to limit it to only the first in the frame.
This feature was useless for the auto HUD in The Forest where multiple icons were drawn in a single draw call and I needed the position of each individual icon, but could only get the position of one of them. 3DMigoto gives access to the entire vertex buffer to allow this (though we still depend on the game's HUD playing nice - if the HUD is drawn with an index buffer or icons are not drawn with 6 vertices things quickly get complicated).
- Helix Mod can create a custom depth texture and inject it into shaders as an additional render target or texture. I have used this once in Montague's mount when copying sampler registers was not working. I found a number of problems with this feature - Helix Mod fails to force it to stereo and it ends up being created mono, and as such I have had to use tricks to force it to stereo by tying it to be created along with a depth buffer, and forcing those to be stereo (and getting lucky that Helix Mod happens to still have the DefSurfaceCreationMode applied when it creates it using that method), but that had it's own set of problems as games can create depth buffers for other purposes so the size won't always match, which will break any shaders it is injected in to. My only option was to hardcode the resolution in the ini file.
- In games that require UseExtInterfaceOnly, most texture hashes are broken.
- No render target size filtering (for matching driver heuristics, and preventing some UI adjustments affection in-world objects or double-adjusting part of the UI)
- No depth buffer filtering (for matching driver heuristics)
- No support for the reverse stereo blit, so my auto crosshair has to calculate it's position independently in each eye, whereas in DX11 it can calculate it from both eyes simultaneously.
- Mouse coordinate injection is broken (and generally insufficient to implement a software mouse to fix all those games that use hardware cursors). I have some ideas to make this work in 3DMigoto, and one of the pieces (shader injection) is there already, but there's a lot more work needed and it's not clear if it is even possible yet.
There's probably others I've forgotten. But overall, Helix Mod has a huge amount of functionality that does work and it is a proven tool. Replacing it is something that I've thought about doing, as has bo3b and clearly you as well, but it just doesn't seem like a good use of time.
2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit
Alienware M17x R4 w/ built in 3D, Intel i7 3740QM, GTX 680m 2GB, 16GB DDR3 1600MHz RAM, Win7 64bit, 1TB SSD, 1TB HDD, 750GB HDD
Pre-release 3D fixes, shadertool.py and other goodies: http://github.com/DarkStarSword/3d-fixes
Support me on Patreon: https://www.patreon.com/DarkStarSword or PayPal: https://www.paypal.me/DarkStarSword
Just curious, I was trying it on Pirates of the Caribbean: At Worlds End which only runs at 1024x768. Running at this resolution on my 1080P monitor stretches the image from top to bottom and makes it look like garbage. Using Chiri's tool, it forces the overall window to 1920x1080, but the image is still being rendered at 1024x768 in the back buffer. So you get the image rendered pixel for pixel in the top left corner of the screen. This at least makes it look good, but if the force resolution could be applied to the back buffer as well, it would be awesome.
BTW, the game has a demo if anyone wants to observe what I'm talking about for themselves.
I've tried launch commands and various ini settings with no luck. It's one of those console ports with minimal settings/user intervention.
Both Helix Mod and 3DMigoto can be used to force render targets to a given size, but while it should work in theory, in practice it doesn't seem to work so well, but you might get lucky. Something like this in Helix Mod *might* do the trick:
To do the same in 3DMigoto you need to identify the render and depth target hashes (easiest way is probably to check ShaderUsage.txt for any with the expected size).
2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit
Alienware M17x R4 w/ built in 3D, Intel i7 3740QM, GTX 680m 2GB, 16GB DDR3 1600MHz RAM, Win7 64bit, 1TB SSD, 1TB HDD, 750GB HDD
Pre-release 3D fixes, shadertool.py and other goodies: http://github.com/DarkStarSword/3d-fixes
Support me on Patreon: https://www.patreon.com/DarkStarSword or PayPal: https://www.paypal.me/DarkStarSword
Or is it overriding the rendering resolution?
All of this ^
I see no value in trying to emulate what is already there, just to perhaps correct a few missing features. Lets face it, there are few games that can't be fixed *at all*, and (fortunately) it was never AAA games (because I guess Helix was around to update the wrapper at the time). It usually pretty much works out the box, and its feature set is impressive, if hard to understand sometimes.
Either bo3b or eqzitara did ask Helix if he would give us the source code but he was unwilling to because it was "a mess" or something. Even on the promise that no one else would see it, he was unwilling. Maybe he would change his mind nowadays? That would be a much more efficient use of time.
If he did, and if it was possible, it would be better to daisy-chain/wrap his code into 3DMigoto so that a consistent set of features would be available from 3DMigoto. We now have Flugan's ASM wrapper in 3DMigoto which has added to the power and flexibility of 3DMigoto considerably, so something similar with Helix code (if he gave us the source code) would cut out a large amount of work, and allow "someone" to extend some of the missing features. Also, he did develop a DX11 version (for Bioshock Infinite) so information on how to merge that into 3DMigoto might be more readily available. As DSS notes, there was a major DX architectural change between 9 and 10 (11 and 12 are basically updates to 10) which is one reason why DX10 never really took off for so long, so adding DX9 to 3DMigoto from scratch would still be loads of work as the implementation of almost all features would be different.
To be honest though, aside from the LEGO games, I have not fixed a DX9 game for ages (I don't think) - even the updated Divinity Original Sin fix was DX11. So I really think the efforts of the few people developing this stuff should be focussed on DX11/12/VR.
Rig: Intel i7-8700K @4.7GHz, 16Gb Ram, SSD, GTX 1080Ti, Win10x64, Asus VG278
When I think of HeliX wrapper I tend to think of it as it was in v1 when it first released.
At that point it was already fairly complex as HeliX didn't release until it was ready to be used.
I'm not that interested in perfectly replicating the complex features of latest HeliX just to make what already works still work in another wrapper. I've already had enough of that making DX11 work on Win8 while it was unsupported in 3DMigoto. It is not that fun even when you have source code access.
What I hear is a combination of limitations in the advanced features of HeliX and also underlying limitations of dx9 itself unless I'm mistaken. What I currently offer is a hunting environment without any double taps by mistake and ability to dump directly into folder without any rename needed. Pretty basic stuff. Maybe some more but I have not looked in a while.
Just getting dx9 to work with HeliX took me ages as it has really been on the backburner but my biggest stumbling block was getting the correct CRC value of the shader as otherwise it was pretty worthless.
Just updated my DX document and there were about 40 dx10 titles in total, pretty few.
Thanks to everybody using my assembler it warms my heart.
To have a critical piece of code that everyone can enjoy!
What more can you ask for?
donations: ulfjalmbrant@hotmail.com
I ran dual boot so I know a lot of comparisons. Off the top of my head....
Red Faction - Huge performance issues. Light beams added. DX10 is disabled by default.
Devil May Cry 4 - Huge performance issues. Better shadows. DX10 is disabled by default.
Assassins Creed -Huge performance issues. EVENTUALLY REMOVED IN LATER PATCH.
Bioshock 1/2 - Minor lighting improvement. No one bothered since you could only force AA with DX9 though I guess that's irrelevant now.
The only games exclusive to DX10 were Halo 2 [which is almost impossible to get working on PC nowadays]. ShadowRun which is dead cause its multiplayer.
Co-founder of helixmod.blog.com
If you like one of my helixmod patches and want to donate. Can send to me through paypal - eqzitara@yahoo.com
The amount of dx10 games are >40 but almost all have dx9 rendering paths.
I personally own about 20 of these games.
I'm not counting games with dx11 support in this list.
To be honest they are pretty rare but in some cases the DX10 effects were very apparent and I guess in others you mostly couldn't tell the difference.
With Devil May Cry 4 you choose which version to run in the launcher so how can one be the default.
The same with Resident Evil 5.
Finally the biggest difference I saw in Bioshock was the water effects.
While I'm not sure about the differences there must have been a difference between crysis dx9 and dx10.
Thanks to everybody using my assembler it warms my heart.
To have a critical piece of code that everyone can enjoy!
What more can you ask for?
donations: ulfjalmbrant@hotmail.com
TsaebehT pointed me in the right direction by telling me about a dead link for a resolution patch.
Using the posters name, I was able to chase down a different post with the patch. Using the patch, I can run Pirates of the Caribbean: At Worlds End at 1920x1080. (PS2 port/controls suck)
Squ1zZy states: "Guys, I found a CD with all my sources and patches for e few older games. Could this be of any use? If so, where can I upload it?"
http://www.wsgf.org/forums/viewtopic.php?f=64&t=21680
List:
Patch Albatross18
Patch Close Combat 2
Patch DF Black Hawk Down
Patch EA Sports Cricket 07
Patch EA Sports FIFA 07
Patch EA Sports NBA Live 07
Patch EA Sports NHL 06
Patch EA Sports Tiger Woods PGA Tour 05
Patch EA Sports Tiger Woods PGA Tour 07
Patch Empire Earth 2
Patch Fahrenheit
Patch Hidden & Dangerous 2
Patch Need For Speed Carbon
Patch Need For Speed Underground
Patch Need For Speed Underground 2
Patch Onimusha 3
Patch Pirates Of The Caribbean Worlds End
Patch Prey
Patch Prince Of Persia The Sands Of Time
Patch Prince Of Persia Warrior Within
Patch Rainbow Six Vegas
Patch ScarFace
Patch Silent Hill 2
Patch Simpsons Hit & Run
Patch Soldier Of Fortune
Patch Soldier Of Fortune 2 Double Helix MP
Patch Soldier Of Fortune 2 Double Helix SP
Patch Sonic Adventure DX
Patch Spiderman 3
Patch SWKotor 2
Patch Warcraft 3
Patch X-Men The Official Game
DGVOODOO has a DX9 wrapper in development, many games can be wrapped to DX11 already
https://www.vogons.org/viewtopic.php?f=59&t=51790
Inofficial VorpX Gamelist -- VorpX news on Twitter -- RJ's VorpX Game Requester
I haven't tried it with any DX9 game yet because I'm very busy with other games. I'll have to check what games I own that need a fix and work with dgVoodoo.
CPU: Intel Core i7 7700K @ 4.9GHz
Motherboard: Gigabyte Aorus GA-Z270X-Gaming 5
RAM: GSKILL Ripjaws Z 16GB 3866MHz CL18
GPU: Gainward Phoenix 1080 GLH
Monitor: Asus PG278QR
Speakers: Logitech Z506
Donations account: masterotakusuko@gmail.com