Version 1.3.4 without hunt and no XInput is released on my OneDrive.
It appears to work fairly well. Nice to be able to hold P during cinematics. Sprint also appeared to work.
[quote="Flugan"]@Jason20910
When you have time to look at DA:I we could work together to nail down the most stable settings.
I work best if I can get quick feedback. There are loads of builds that are essentially the same thing with progression in both directions.[/quote]
I appreciate the offer! I will send you a PM.
I'm using the first release of your wrapper for DA:I originally posted by Helifax
I haven't had success in getting any of the updates to work off your one drive, not sure if I am doing something wrong or they have issues. (game wont start)
I am using your wrapper for this game because it allows me to run Post processing on Medium where the 3dmoto version appears to create issues.
I have a perfectly stable game with 3dmoto but am trading off a bit of stability for the extra graphics options.
I would say keep at it man. If you find fixing the actual games difficult. Choice is always good....
Can you clarify what files you need to update from your one drive though? I got a feeling I'm just doing something wrong...
I'm using the first release of your wrapper for DA:I originally posted by Helifax
I haven't had success in getting any of the updates to work off your one drive, not sure if I am doing something wrong or they have issues. (game wont start)
I am using your wrapper for this game because it allows me to run Post processing on Medium where the 3dmoto version appears to create issues.
I have a perfectly stable game with 3dmoto but am trading off a bit of stability for the extra graphics options.
I would say keep at it man. If you find fixing the actual games difficult. Choice is always good....
Can you clarify what files you need to update from your one drive though? I got a feeling I'm just doing something wrong...
i7-4790K CPU 4.8Ghz stable overclock.
16 GB RAM Corsair
EVGA 1080TI SLI
Samsung SSD 840Pro
ASUS Z97-WS
3D Surround ASUS Rog Swift PG278Q(R), 2x PG278Q (yes it works)
Obutto R3volution.
Windows 10 pro 64x (Windows 7 Dual boot)
v1.3.5 has been released removing almost all traces of hunting.
Install instructions are follow the instructions on helixmod blog and unzip shaderfixes from my games directory.
Excellent, thanks Flugan. Will try it when I get home from work. Been playing in both Windows 8.1 and Windows 10 recently but with both I'm suffering from SLI and broken 3D using the standard profile or working 3D (mostly) but broken SLI using the Battlefield 4 profile. Lot more work to go to even work out the best profile set up for me but if I can get all the broken shadows to disappear it will make that a much happier process :)
Excellent, thanks Flugan. Will try it when I get home from work. Been playing in both Windows 8.1 and Windows 10 recently but with both I'm suffering from SLI and broken 3D using the standard profile or working 3D (mostly) but broken SLI using the Battlefield 4 profile. Lot more work to go to even work out the best profile set up for me but if I can get all the broken shadows to disappear it will make that a much happier process :)
i7 5930k @ 4.5GHz
Asus Sabertooth X99 Motherboard
2 x EVGA GTX 980 Ti SC @ 1380MHz/7.5GHz
Twin loop, triple rad water cooled
16GB Kingston Predator 3GHz
256GB Samsung XP941 M.2 SSD (OS)
2 x 256GB SSD RAID0 (Games)
2 x 2TB Mechanical (storage)
Asus ROG Swift PG278Q 1440p/144MHz 3D/G-sync monitor
Avermedia ExtremeCap U3 Video Capture for PS4 passthrough
Phanteks Enthoo Primo Gold case
Adding support for mapping the primary xbox controller.
buttons specified by XB prefix like below. Keys are case insensitive:
Key=xb_a
complete list:
XB_A
XB_B
XB_X
XB_Y
XB_START
XB_BACK
XB_DPAD_RIGHT
XB_DPAD_LEFT
XB_DPAD_UP
XB_DPAD_DOWN
XB_RIGHT_SHOULDER
XB_LEFT_SHOULDER
XB_RIGHT_THUMB
XB_LEFT_THUMB
XB_LEFT_TRIGGER
XB_RIGHT_TRIGGER
Adding support for mapping the primary xbox controller.
buttons specified by XB prefix like below. Keys are case insensitive:
Key=xb_a
complete list:
XB_A
XB_B
XB_X
XB_Y
XB_START
XB_BACK
XB_DPAD_RIGHT
XB_DPAD_LEFT
XB_DPAD_UP
XB_DPAD_DOWN
XB_RIGHT_SHOULDER
XB_LEFT_SHOULDER
XB_RIGHT_THUMB
XB_LEFT_THUMB
XB_LEFT_TRIGGER
XB_RIGHT_TRIGGER
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?
It's weird cause the version of your wrapper posted by Helifax works fine.
i7-4790K CPU 4.8Ghz stable overclock.
16 GB RAM Corsair
EVGA 1080TI SLI
Samsung SSD 840Pro
ASUS Z97-WS
3D Surround ASUS Rog Swift PG278Q(R), 2x PG278Q (yes it works)
Obutto R3volution.
Windows 10 pro 64x (Windows 7 Dual boot)
@Flugan - I just pushed xinput support to 3Dmigoto last night. I don't use quite the same syntax as you, so we might want to think about deciding on which to use if we want to make it easier for people to migrate from one wrapper to the other. This is the syntax I'm using:
Key=XINPUT:LEFT_TRIGGER>128
The threshold is optional (defaults to any non-zero value), and it's case insensitive and allows extra whitespace, so this will also work:
Key = XInput : right_trigger
You can also specify a controller number 0-3 - by default it will activate when the button is pressed on any controller:
Key = XInput 0 : dpad_down
And the same syntax works with hunting bindings (including those that use bo3b's new auto-repeat functionality):
next_pixelshader = xInput : right_shoulder
The parsing code isn't elegant or anything (I did try regular expressions, but hit what looks to be a bug in MS's implementation of them) - you can take it from NewXInputAction() if you like.
@Flugan - I just pushed xinput support to 3Dmigoto last night. I don't use quite the same syntax as you, so we might want to think about deciding on which to use if we want to make it easier for people to migrate from one wrapper to the other. This is the syntax I'm using:
Key=XINPUT:LEFT_TRIGGER>128
The threshold is optional (defaults to any non-zero value), and it's case insensitive and allows extra whitespace, so this will also work:
Key = XInput : right_trigger
You can also specify a controller number 0-3 - by default it will activate when the button is pressed on any controller:
Key = XInput 0 : dpad_down
And the same syntax works with hunting bindings (including those that use bo3b's new auto-repeat functionality):
next_pixelshader = xInput : right_shoulder
The parsing code isn't elegant or anything (I did try regular expressions, but hit what looks to be a bug in MS's implementation of them) - you can take it from NewXInputAction() if you like.
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
For the XInput support, I confess to not looking into it in detail, but aren't there already predefined constants or names that we can use without making up new ones?
They have these Virtual Keycodes here that would be a good match to our GetAsyncKeyState VK codes, and more consistent for end users.
[url]https://msdn.microsoft.com/en-us/library/windows/desktop/microsoft.directx_sdk.reference.xinput_keystroke(v=vs.85).aspx[/url]
Not at all sure, just suggesting that if something already exists, we'd be better off to use that, instead of creating new syntax.
As a general idea I think we definitely need to have them match, whatever we decide upon. Requiring alternate .ini files is not good for the end-users and will be prone to bugs.
For the XInput support, I confess to not looking into it in detail, but aren't there already predefined constants or names that we can use without making up new ones?
They have these Virtual Keycodes here that would be a good match to our GetAsyncKeyState VK codes, and more consistent for end users.
Not at all sure, just suggesting that if something already exists, we'd be better off to use that, instead of creating new syntax.
As a general idea I think we definitely need to have them match, whatever we decide upon. Requiring alternate .ini files is not good for the end-users and will be prone to bugs.
Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607 Latest 3Dmigoto Release Bo3b's School for ShaderHackers
Those names are from the XInputGetKeystroke call, which we don't use because it would interfere with a game that also uses the same call. Instead we use the XInputGetState call, which uses these names that both of us are have followed:
https://msdn.microsoft.com/en-us/library/windows/desktop/microsoft.directx_sdk.reference.xinput_gamepad(v=vs.85).aspx
The difference is which prefix we chose instead of XINPUT_GAMEPAD_ and in my case I also added optional syntax to specify the controller number and threshold for triggers.
Part of the reason I opted to use XINPUT: as the prefix is to unambiguously indicate which input backend was in use, and so that if someone wanted to add yet another backend in the future there would be an existing precedent they could follow for the backend's own binding names, by specifying their backend's name before a colon.
The difference is which prefix we chose instead of XINPUT_GAMEPAD_ and in my case I also added optional syntax to specify the controller number and threshold for triggers.
Part of the reason I opted to use XINPUT: as the prefix is to unambiguously indicate which input backend was in use, and so that if someone wanted to add yet another backend in the future there would be an existing precedent they could follow for the backend's own binding names, by specifying their backend's name before a colon.
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
I'm using XINPUT_GAMEPAD_TRIGGER_THRESHOLD which is a predefined constant,
I invented LEFT_TRIGGER as it was consistent with the buttons.
For my usage I only needed controller 1 and I've had trouble dealing with multiple controllers. Loads of games use any controller without separation. Hunting using XInput never worked well.
I believe your syntax is too verbose and why specify the trigger treshhold when it is just given to us on a plate.
I like my current syntax and it's simple to use.
You can Always add numbers to specify which controller.
XB_ <- controller 1 (index 0)
X1_ <- controller 1 (index 0)
X2_ <- controller 2 (index 1)
All the keyboard keys are like
VK_
So by prefix XB_ I could separate easily.
What third input layer do you anticipate or do you complicate things just in case something comes along.
Currrently my code only understand XB_ and I see no reason to change that. I am fully aware that we need to resolve the situation. I am currently using d3dx.ini to simplify things. No need for copy paste between ini files. But if I am unable to parse keys or the syntax is different there will be hard to use.
Please contenplate why you want to bind the same key simultanously on multiple controllers which appears to be your defauult. It does not make sense to me although many games do just that. Which is what make hunting using XInput pretty hard.
Please support a simplified syntax for controller 1 preferably the same as mine. I hope we'll sort it out swiftly.
I'm using XINPUT_GAMEPAD_TRIGGER_THRESHOLD which is a predefined constant,
I invented LEFT_TRIGGER as it was consistent with the buttons.
For my usage I only needed controller 1 and I've had trouble dealing with multiple controllers. Loads of games use any controller without separation. Hunting using XInput never worked well.
I believe your syntax is too verbose and why specify the trigger treshhold when it is just given to us on a plate.
I like my current syntax and it's simple to use.
You can Always add numbers to specify which controller.
XB_ <- controller 1 (index 0)
X1_ <- controller 1 (index 0)
X2_ <- controller 2 (index 1)
All the keyboard keys are like
VK_
So by prefix XB_ I could separate easily.
What third input layer do you anticipate or do you complicate things just in case something comes along.
Currrently my code only understand XB_ and I see no reason to change that. I am fully aware that we need to resolve the situation. I am currently using d3dx.ini to simplify things. No need for copy paste between ini files. But if I am unable to parse keys or the syntax is different there will be hard to use.
Please contenplate why you want to bind the same key simultanously on multiple controllers which appears to be your defauult. It does not make sense to me although many games do just that. Which is what make hunting using XInput pretty hard.
Please support a simplified syntax for controller 1 preferably the same as mine. I hope we'll sort it out swiftly.
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?
OK, good to know. As noted, I haven't looked closely at this part, so I'll defer to both your judgment.
I think I would agree that the current syntax for 3Dmigoto is probably one step more abstract than it needs to be, unless we already know of a controller we'd like to support. In general my preference is to add abstraction later as it proves to be necessary, rather than early.
OK, good to know. As noted, I haven't looked closely at this part, so I'll defer to both your judgment.
I think I would agree that the current syntax for 3Dmigoto is probably one step more abstract than it needs to be, unless we already know of a controller we'd like to support. In general my preference is to add abstraction later as it proves to be necessary, rather than early.
Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607 Latest 3Dmigoto Release Bo3b's School for ShaderHackers
I assume 1.3.1 to 1.3.3 makes no difference.
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
It appears to work fairly well. Nice to be able to hold P during cinematics. Sprint also appeared to work.
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 appreciate the offer! I will send you a PM.
CPU: i7 5930K, 4.5 (125x36) with Corsair H100i | MB: Asus Rampage V Extreme (1401 Bios) | GPU: NVIDIA Titan X (Pascal) & EVGA GTX 980 Ti ACX 2.0 | RAM: Corsair Vengeance 32 GB DDR4 2666MHz (4x8GB) | Storage: Crucial MX100 512 GB SSD (OS & Apps), 2 Seagate 1TB Serial ATA HD 7200/32MB/SATA-3G (Data - RAID 1) | PSU: Corsair HX1000W | Chassis: Cooler Master HAF X | OS: Win 10 Pro 1607
I haven't had success in getting any of the updates to work off your one drive, not sure if I am doing something wrong or they have issues. (game wont start)
I am using your wrapper for this game because it allows me to run Post processing on Medium where the 3dmoto version appears to create issues.
I have a perfectly stable game with 3dmoto but am trading off a bit of stability for the extra graphics options.
I would say keep at it man. If you find fixing the actual games difficult. Choice is always good....
Can you clarify what files you need to update from your one drive though? I got a feeling I'm just doing something wrong...
i7-4790K CPU 4.8Ghz stable overclock.
16 GB RAM Corsair
EVGA 1080TI SLI
Samsung SSD 840Pro
ASUS Z97-WS
3D Surround ASUS Rog Swift PG278Q(R), 2x PG278Q (yes it works)
Obutto R3volution.
Windows 10 pro 64x (Windows 7 Dual boot)
The 1.3.4 version works exactly like 3Dmigoto.
i will update with this version.
MY WEB
Helix Mod - Making 3D Better
My 3D Screenshot Gallery
Like my fixes? you can donate to Paypal: dhr.donation@gmail.com
Install instructions are follow the instructions on helixmod blog and unzip shaderfixes from my games directory.
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
i7 5930k @ 4.5GHz
Asus Sabertooth X99 Motherboard
2 x EVGA GTX 980 Ti SC @ 1380MHz/7.5GHz
Twin loop, triple rad water cooled
16GB Kingston Predator 3GHz
256GB Samsung XP941 M.2 SSD (OS)
2 x 256GB SSD RAID0 (Games)
2 x 2TB Mechanical (storage)
Asus ROG Swift PG278Q 1440p/144MHz 3D/G-sync monitor
Avermedia ExtremeCap U3 Video Capture for PS4 passthrough
Phanteks Enthoo Primo Gold case
Dual Boot OS Windows 8.1/Windows 10
buttons specified by XB prefix like below. Keys are case insensitive:
Key=xb_a
complete list:
XB_A
XB_B
XB_X
XB_Y
XB_START
XB_BACK
XB_DPAD_RIGHT
XB_DPAD_LEFT
XB_DPAD_UP
XB_DPAD_DOWN
XB_RIGHT_SHOULDER
XB_LEFT_SHOULDER
XB_RIGHT_THUMB
XB_LEFT_THUMB
XB_LEFT_TRIGGER
XB_RIGHT_TRIGGER
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 guess we are both using windows 7?
It's weird cause the version of your wrapper posted by Helifax works fine.
i7-4790K CPU 4.8Ghz stable overclock.
16 GB RAM Corsair
EVGA 1080TI SLI
Samsung SSD 840Pro
ASUS Z97-WS
3D Surround ASUS Rog Swift PG278Q(R), 2x PG278Q (yes it works)
Obutto R3volution.
Windows 10 pro 64x (Windows 7 Dual boot)
Key=XINPUT:LEFT_TRIGGER>128
The threshold is optional (defaults to any non-zero value), and it's case insensitive and allows extra whitespace, so this will also work:
Key = XInput : right_trigger
You can also specify a controller number 0-3 - by default it will activate when the button is pressed on any controller:
Key = XInput 0 : dpad_down
And the same syntax works with hunting bindings (including those that use bo3b's new auto-repeat functionality):
next_pixelshader = xInput : right_shoulder
The parsing code isn't elegant or anything (I did try regular expressions, but hit what looks to be a bug in MS's implementation of them) - you can take it from NewXInputAction() if you like.
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
They have these Virtual Keycodes here that would be a good match to our GetAsyncKeyState VK codes, and more consistent for end users.
https://msdn.microsoft.com/en-us/library/windows/desktop/microsoft.directx_sdk.reference.xinput_keystroke(v=vs.85).aspx
Not at all sure, just suggesting that if something already exists, we'd be better off to use that, instead of creating new syntax.
As a general idea I think we definitely need to have them match, whatever we decide upon. Requiring alternate .ini files is not good for the end-users and will be prone to bugs.
Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers
https://msdn.microsoft.com/en-us/library/windows/desktop/microsoft.directx_sdk.reference.xinput_gamepad(v=vs.85).aspx
The difference is which prefix we chose instead of XINPUT_GAMEPAD_ and in my case I also added optional syntax to specify the controller number and threshold for triggers.
Part of the reason I opted to use XINPUT: as the prefix is to unambiguously indicate which input backend was in use, and so that if someone wanted to add yet another backend in the future there would be an existing precedent they could follow for the backend's own binding names, by specifying their backend's name before a colon.
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
I invented LEFT_TRIGGER as it was consistent with the buttons.
For my usage I only needed controller 1 and I've had trouble dealing with multiple controllers. Loads of games use any controller without separation. Hunting using XInput never worked well.
I believe your syntax is too verbose and why specify the trigger treshhold when it is just given to us on a plate.
I like my current syntax and it's simple to use.
You can Always add numbers to specify which controller.
XB_ <- controller 1 (index 0)
X1_ <- controller 1 (index 0)
X2_ <- controller 2 (index 1)
All the keyboard keys are like
VK_
So by prefix XB_ I could separate easily.
What third input layer do you anticipate or do you complicate things just in case something comes along.
Currrently my code only understand XB_ and I see no reason to change that. I am fully aware that we need to resolve the situation. I am currently using d3dx.ini to simplify things. No need for copy paste between ini files. But if I am unable to parse keys or the syntax is different there will be hard to use.
Please contenplate why you want to bind the same key simultanously on multiple controllers which appears to be your defauult. It does not make sense to me although many games do just that. Which is what make hunting using XInput pretty hard.
Please support a simplified syntax for controller 1 preferably the same as mine. I hope we'll sort it out swiftly.
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 think I would agree that the current syntax for 3Dmigoto is probably one step more abstract than it needs to be, unless we already know of a controller we'd like to support. In general my preference is to add abstraction later as it proves to be necessary, rather than early.
Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers
I think we are covered when it comes to input.
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