How big is the support for my wrapper
  5 / 6    
I have basic transitions implemented.
I have basic transitions implemented.

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

#61
Posted 02/12/2015 10:14 PM   
@rustyk Are you talking about going past 100% depth or going past the limited depth in certain games. I don't see the point in going above 100% depth as that would cause your eyes to diverge not very pleasant especially on monitors due to the short viewing distance.
@rustyk
Are you talking about going past 100% depth or going past the limited depth in certain games.

I don't see the point in going above 100% depth as that would cause your eyes to diverge not very pleasant especially on monitors due to the short viewing distance.

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

#62
Posted 02/12/2015 10:18 PM   
transitions now work with type=hold correctly.
transitions now work with type=hold correctly.

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

#63
Posted 02/12/2015 10:44 PM   
I'm talking about going past 100%. For projector users, the default slider often isn't enough, believe me :-) Can't remember all the details off the top of my head but when you go over a certain screen size the way Nvidia works it out isn't enough. Unless they've changed it recently, which I doubt.
I'm talking about going past 100%. For projector users, the default slider often isn't enough, believe me :-)
Can't remember all the details off the top of my head but when you go over a certain screen size the way Nvidia works it out isn't enough. Unless they've changed it recently, which I doubt.

GTX 1070 SLI, I7-6700k ~ 4.4Ghz, 3x BenQ XL2420T, BenQ TK800, LG 55EG960V (3D OLED), Samsung 850 EVO SSD, Crucial M4 SSD, 3D vision kit, Xpand x104 glasses, Corsair HX1000i, Win 10 pro 64/Win 7 64https://www.3dmark.com/fs/9529310

#64
Posted 02/12/2015 10:46 PM   
It's actually the other way around. Nvidia sets a fixed projector screen size and if you use a larger screen you are already above 100%. Depth hack involves setting the nvidia screen to a smaller value than the actual screen. I might be wrong.
It's actually the other way around. Nvidia sets a fixed projector screen size and if you use a larger screen you are already above 100%. Depth hack involves setting the nvidia screen to a smaller value than the actual screen.

I might be wrong.

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

#65
Posted 02/12/2015 10:53 PM   
I think you're right about the way the hack works, but you don't get problems with divergent eyes on big screens. Was wondering if it's the kind of thing a wrapper can do. Maybe I'm the only person who wants more depth :-)
I think you're right about the way the hack works, but you don't get problems with divergent eyes on big screens. Was wondering if it's the kind of thing a wrapper can do. Maybe I'm the only person who wants more depth :-)

GTX 1070 SLI, I7-6700k ~ 4.4Ghz, 3x BenQ XL2420T, BenQ TK800, LG 55EG960V (3D OLED), Samsung 850 EVO SSD, Crucial M4 SSD, 3D vision kit, Xpand x104 glasses, Corsair HX1000i, Win 10 pro 64/Win 7 64https://www.3dmark.com/fs/9529310

#66
Posted 02/12/2015 10:58 PM   
I can call Nvidia API and request 100 separation which is 100% depth but there is no way to specify values above 100. I don't see the point in going beyond 100% as that does diverge the Eyes just measure separation in cm. Depth hack can utilize more depth pixels so I guess thats the reason. Viewing distance is far enough for it to be a problem with divvergence.
I can call Nvidia API and request 100 separation which is 100% depth but there is no way to specify values above 100. I don't see the point in going beyond 100% as that does diverge the Eyes just measure separation in cm. Depth hack can utilize more depth pixels so I guess thats the reason. Viewing distance is far enough for it to be a problem with divvergence.

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

#67
Posted 02/12/2015 11:03 PM   
From memory the depth hack just edits the screen size reg key. Not sure how Nvidia calculate it but going over 100% doesn't diverge the eyes believe me. Maybe someone else will chime in.
From memory the depth hack just edits the screen size reg key. Not sure how Nvidia calculate it but going over 100% doesn't diverge the eyes believe me. Maybe someone else will chime in.

GTX 1070 SLI, I7-6700k ~ 4.4Ghz, 3x BenQ XL2420T, BenQ TK800, LG 55EG960V (3D OLED), Samsung 850 EVO SSD, Crucial M4 SSD, 3D vision kit, Xpand x104 glasses, Corsair HX1000i, Win 10 pro 64/Win 7 64https://www.3dmark.com/fs/9529310

#68
Posted 02/12/2015 11:17 PM   
Did you actually measure. I'm not saying it is a problem but something that happens Always when going above 100% and I'm not talking nvidia's scale but rather the 6,3cm separation found on a monitor. I Believe it was just editing the registry key at the right time as nvidia keeps resetting their value. My latest impression is that it has become impossible. The Little window of time where you could set the screensize has closed so you can't pretend to have a 40" screen. Edit: ancient hack http://3dvision-blog.com/tag/depth-hack/ more recent: https://forums.geforce.com/default/topic/519243/3d-vision/maximum-depth-hack-go-beyond-100-/5/
Did you actually measure. I'm not saying it is a problem but something that happens Always when going above 100% and I'm not talking nvidia's scale but rather the 6,3cm separation found on a monitor.

I Believe it was just editing the registry key at the right time as nvidia keeps resetting their value. My latest impression is that it has become impossible. The Little window of time where you could set the screensize has closed so you can't pretend to have a 40" screen.

Edit: ancient hack http://3dvision-blog.com/tag/depth-hack/
more recent: https://forums.geforce.com/default/topic/519243/3d-vision/maximum-depth-hack-go-beyond-100-/5/

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

#69
Posted 02/12/2015 11:25 PM   
[quote="Flugan"]I extended and later removed XInput for performance reasons.[/quote] I also got a significant performance hit after initially implementing XInput support (like the menu in Far Cry 4 dropped from 40fps to 10fps). To mitigate this I reduced how often input is checked in 3Dmigoto - it was checking it on every single draw call, which was excessive. Now it will only process input once at least 8ms has past (125Hz). This code is in the RunFrameActions() call. The second mitigation I do is to only poll unconnected controllers once every four seconds (The XInput documentation recommends something like this) - and it's staggered so they don't all get checked at once. Once a controller is connected it will be polled on every frame so it will be responsive. This code is in the DispatchInputEvents() call. [quote="Flugan"] delay=1000 type=hold [/quote] Syntax looks good to me. For an optional delay after releasing the button I'm planning to use "releasedelay=1000". I'm undecided on the syntax for transitioning yet (probably need to concentrate on getting it working first). It could either be a separate "transition=1" and "releasetranslation=1" boolean options that uses the delay=1000 value to set the time, or replace delay with "transition=1000". One extra thing to consider is that transitions do not necessarily have to be linear - when I've done transitions in the past I've often found interpolating using cosine from 0 to pi can look nicer as the transition is slower towards the start, faster in the middle and slower again at the end. For this to work having "transition=linear" or "transition=cosine" might be a better option. I realise I won't have much time to work on this over the weekend due to some real life events - namely a multicultural festival and Valentine's day.
Flugan said:I extended and later removed XInput for performance reasons.

I also got a significant performance hit after initially implementing XInput support (like the menu in Far Cry 4 dropped from 40fps to 10fps).

To mitigate this I reduced how often input is checked in 3Dmigoto - it was checking it on every single draw call, which was excessive. Now it will only process input once at least 8ms has past (125Hz). This code is in the RunFrameActions() call.

The second mitigation I do is to only poll unconnected controllers once every four seconds (The XInput documentation recommends something like this) - and it's staggered so they don't all get checked at once. Once a controller is connected it will be polled on every frame so it will be responsive. This code is in the DispatchInputEvents() call.
Flugan said:
delay=1000
type=hold

Syntax looks good to me. For an optional delay after releasing the button I'm planning to use "releasedelay=1000".

I'm undecided on the syntax for transitioning yet (probably need to concentrate on getting it working first). It could either be a separate "transition=1" and "releasetranslation=1" boolean options that uses the delay=1000 value to set the time, or replace delay with "transition=1000".

One extra thing to consider is that transitions do not necessarily have to be linear - when I've done transitions in the past I've often found interpolating using cosine from 0 to pi can look nicer as the transition is slower towards the start, faster in the middle and slower again at the end. For this to work having "transition=linear" or "transition=cosine" might be a better option.

I realise I won't have much time to work on this over the weekend due to some real life events - namely a multicultural festival and Valentine's day.

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

#70
Posted 02/13/2015 12:13 AM   
I think rustyk is referring to an older version of my DepthHack, the one Eqzitara linked on the HelixBlog. If so, it was working perfectly fine last time I checked(although maybe not with CM as they broke them all at one point by ignoring MonitorSize and I haven't checked it recently) ... I didn't know about the 'ancient' one, just a constant registry writing loop and the 'more recent' locking version when I came up with mine. Mine writes the registry key, loop reads key until the Drivers rewrites it, then it writes it again and exits. My MonitorSize is set for a 73" screen, even though mine is only 65" ... so 100% isn't exactly '100%' on my screen, not sure if this is something that can be rectified with an EDID hack or not as I've never looked into them, but it might be a possibility.
I think rustyk is referring to an older version of my DepthHack, the one Eqzitara linked on the HelixBlog. If so, it was working perfectly fine last time I checked(although maybe not with CM as they broke them all at one point by ignoring MonitorSize and I haven't checked it recently) ... I didn't know about the 'ancient' one, just a constant registry writing loop and the 'more recent' locking version when I came up with mine. Mine writes the registry key, loop reads key until the Drivers rewrites it, then it writes it again and exits.

My MonitorSize is set for a 73" screen, even though mine is only 65" ... so 100% isn't exactly '100%' on my screen, not sure if this is something that can be rectified with an EDID hack or not as I've never looked into them, but it might be a possibility.
#71
Posted 02/13/2015 12:18 AM   
For the projector problem - I've always assumed (never confirmed) that the projector is simply advertising a massive screen size, while the actual screen size will vary depending on how far it is from the wall, and probably smaller. This makes the driver calibrate 100% depth to be less than 6.3cm by default so you need a depth hack to tell it the correct size of the display so it can calibrate the correct value for 100%. I'm not sure the wrapper is the right place to implement a depth hack. The problem is that there is no one right answer that we can set which will work for everyone, and if the existing solutions are working for people it might be better to stick to them. The one case where it might work to have it in the wrapper is when a game's geometry is scaled so that it never produces a distant object that would appear towards infinity. Scaling the monitor size down to compensate for the difference between the game's far clipping plane and infinity might be beneficial in these cases - provided we can do so in a way that will not exceed 6.3cm at the far clipping plane regardless of monitor size. Thief is one game where this might be what's happening (unconfirmed and otherwise doesn't need a fix so depth hack still seems like a better idea). Are there any other DX11 games where this happens?
For the projector problem - I've always assumed (never confirmed) that the projector is simply advertising a massive screen size, while the actual screen size will vary depending on how far it is from the wall, and probably smaller. This makes the driver calibrate 100% depth to be less than 6.3cm by default so you need a depth hack to tell it the correct size of the display so it can calibrate the correct value for 100%.

I'm not sure the wrapper is the right place to implement a depth hack. The problem is that there is no one right answer that we can set which will work for everyone, and if the existing solutions are working for people it might be better to stick to them.

The one case where it might work to have it in the wrapper is when a game's geometry is scaled so that it never produces a distant object that would appear towards infinity. Scaling the monitor size down to compensate for the difference between the game's far clipping plane and infinity might be beneficial in these cases - provided we can do so in a way that will not exceed 6.3cm at the far clipping plane regardless of monitor size. Thief is one game where this might be what's happening (unconfirmed and otherwise doesn't need a fix so depth hack still seems like a better idea). Are there any other DX11 games where this happens?

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

#72
Posted 02/13/2015 12:45 AM   
Since we are talking about the syntax and how to setup presets, I wanted to raise one idea that is worth some consideration. Should we just use the syntax that Helix set up? That would make it easier for people who already know HelixMod to get up to speed quickly, and unify our ideas of what the keys do and how they work. No new documentation would be necessary. The syntax is essentially arbitrary, right? Just wondering how much value keeping them consistent would provide. Since we are just now adding presets, it's a good time to consider it. What do you think?
Since we are talking about the syntax and how to setup presets, I wanted to raise one idea that is worth some consideration.

Should we just use the syntax that Helix set up?

That would make it easier for people who already know HelixMod to get up to speed quickly, and unify our ideas of what the keys do and how they work. No new documentation would be necessary.

The syntax is essentially arbitrary, right? Just wondering how much value keeping them consistent would provide.


Since we are just now adding presets, it's a good time to consider it. What do you think?

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

#73
Posted 02/13/2015 12:57 AM   
I kind of want to consider this on a case by case basis. Helix uses delay=N, which is sensible so we might as well go with that, and there is other syntax from Helix mod that is sensible to use as well, so where it makes sense I think we might as well. The cases I'm less keen on is when the syntax is superfluous, unclear, confusing or inconsistent with itself. Since 3Dmigoto is open source we have the advantage that nothing will be mysterious or unknown since the source code always provides the ultimate documentation (plus, our template ini file is well documented too), which already helps mitigate this a huge amount. When an option may have several settings with different meanings, I'd rather spell them out than choose an easy to mix up number (e.g. type=hold instead of type=2). Also, there are some cases where Helix mod is inconsistent with itself (e.g. Preset is hex, PRES is hex, PresIndex is decimal), which we should not copy. Also, PresIndex itself seems pointless since it means the same thing as Preset, and you have to remember the correct one to use depending on which section it is in. Presets is something I've been thinking about a bit recently - and one where the Helix mod syntax tends tends to make my DX9Settings.ini overly cluttered with lots of presets that might be clearer to specify inside the key binding, like this (just an idea - feedback most definitely welcome): [code] [Key1] Key = q type = cycle x = 0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 0.995 [/code] or even: [code] [Key2] Key = ] Type = add x = 0.1 xMin = 0 xMax = 10 xWrap = true [Key3] Key = [ Type = add x = -0.1 xMin = 0 xMax = 10 xWrap = true [/code] As you can imagine there are a few edge cases to consider here (what do we do if type=cycle and two variables are used, but with different length lists? If type=add with wrapping, do we wrap when equal the max, or grater than it? If wrapping x=10.1, min=0 and max=10, do we end up with x=0 or x=0.1?) The time when having a dedicated preset section is beneficial, is when it can be activated by multiple means (e.g. key binding and scene change). For these I'm thinking it might be nice to have a more descriptive name of the section like [PresetCinematic] rather than requiring a number (though a number would work as well in this case since it can be treated as a string).
I kind of want to consider this on a case by case basis. Helix uses delay=N, which is sensible so we might as well go with that, and there is other syntax from Helix mod that is sensible to use as well, so where it makes sense I think we might as well.

The cases I'm less keen on is when the syntax is superfluous, unclear, confusing or inconsistent with itself. Since 3Dmigoto is open source we have the advantage that nothing will be mysterious or unknown since the source code always provides the ultimate documentation (plus, our template ini file is well documented too), which already helps mitigate this a huge amount.

When an option may have several settings with different meanings, I'd rather spell them out than choose an easy to mix up number (e.g. type=hold instead of type=2).

Also, there are some cases where Helix mod is inconsistent with itself (e.g. Preset is hex, PRES is hex, PresIndex is decimal), which we should not copy. Also, PresIndex itself seems pointless since it means the same thing as Preset, and you have to remember the correct one to use depending on which section it is in.


Presets is something I've been thinking about a bit recently - and one where the Helix mod syntax tends tends to make my DX9Settings.ini overly cluttered with lots of presets that might be clearer to specify inside the key binding, like this (just an idea - feedback most definitely welcome):
[Key1]
Key = q
type = cycle
x = 0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 0.995

or even:
[Key2]
Key = ]
Type = add
x = 0.1
xMin = 0
xMax = 10
xWrap = true

[Key3]
Key = [
Type = add
x = -0.1
xMin = 0
xMax = 10
xWrap = true


As you can imagine there are a few edge cases to consider here (what do we do if type=cycle and two variables are used, but with different length lists? If type=add with wrapping, do we wrap when equal the max, or grater than it? If wrapping x=10.1, min=0 and max=10, do we end up with x=0 or x=0.1?)

The time when having a dedicated preset section is beneficial, is when it can be activated by multiple means (e.g. key binding and scene change). For these I'm thinking it might be nice to have a more descriptive name of the section like [PresetCinematic] rather than requiring a number (though a number would work as well in this case since it can be treated as a string).

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

#74
Posted 02/13/2015 01:48 AM   
I'd like to suggest that we adopt the "When in Rome, do as the Romans do" approach for these constants. The coding style in the rest of the d3dx.ini file is to use the lower_case_underbar style for these parameters, so I would prefer if we can use: release_transition release_delay Others I might have missed. The header sections are mostly CamelCase. It's not fully consistent now, but I think it's really helpful to avoid having it degenerate into a mishmash of everyone's style. I'm also fine with a full refactoring if you guys hate this style, I just need it to be consistent, and I think this also helps our shaderhackers. For the idea of using Helix syntax instead, it doesn't seem like anyone else has an opinion, and I very much agree that the Helix syntax tends to be odd and fragile, so it seems like making a clean break on the syntax to make it as easy as we can is a better approach. For the presets keys, the type=cycle with a list of items seems OK, within the constraints of needing consistent lists. That's not a huge problem, but is worth noting. What if we were to make them redefine the keys in use? Like: [code][Key2] Key = F2 Type = cycle x = 0.1 convergence = 0 xMax = 10 xWrap = true [Key3] Key = F2 Type = cycle x = -0.1 y = 0.1 xMin = 0 xMax = 10 xWrap = true[/code] That would allow us to change the parameters applied without having any conflict, as they'd be stored as a specific preset, and the cycling nature just uses a vector of presets to cycle. The type=cycle would make it clear that it's part of a set of presets, the Key=F2 makes it clear which key is used, and which presets belong to it. This would not allow a specific preset to be used for both a key and texture, but in practice we've never seen that case. Having a duplicate in that case would not seem too onerous, and it would keep the clarity of what is expected to happen for a given condition, which is my main concern (and my main problem with Helix syntax).
I'd like to suggest that we adopt the "When in Rome, do as the Romans do" approach for these constants. The coding style in the rest of the d3dx.ini file is to use the lower_case_underbar style for these parameters, so I would prefer if we can use:

release_transition
release_delay

Others I might have missed. The header sections are mostly CamelCase. It's not fully consistent now, but I think it's really helpful to avoid having it degenerate into a mishmash of everyone's style. I'm also fine with a full refactoring if you guys hate this style, I just need it to be consistent, and I think this also helps our shaderhackers.


For the idea of using Helix syntax instead, it doesn't seem like anyone else has an opinion, and I very much agree that the Helix syntax tends to be odd and fragile, so it seems like making a clean break on the syntax to make it as easy as we can is a better approach.

For the presets keys, the type=cycle with a list of items seems OK, within the constraints of needing consistent lists. That's not a huge problem, but is worth noting.

What if we were to make them redefine the keys in use? Like:

[Key2]
Key = F2
Type = cycle
x = 0.1
convergence = 0
xMax = 10
xWrap = true

[Key3]
Key = F2
Type = cycle
x = -0.1
y = 0.1
xMin = 0
xMax = 10
xWrap = true


That would allow us to change the parameters applied without having any conflict, as they'd be stored as a specific preset, and the cycling nature just uses a vector of presets to cycle. The type=cycle would make it clear that it's part of a set of presets, the Key=F2 makes it clear which key is used, and which presets belong to it.

This would not allow a specific preset to be used for both a key and texture, but in practice we've never seen that case. Having a duplicate in that case would not seem too onerous, and it would keep the clarity of what is expected to happen for a given condition, which is my main concern (and my main problem with Helix syntax).

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

#75
Posted 02/16/2015 05:08 AM   
  5 / 6    
Scroll To Top