[quote="bo3b"]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[/quote]Sounds good - I'll change them now before anyone starts using them.
[quote]Others I might have missed. The header sections are mostly CamelCase.[/quote]I'm pretty sure the GetPrivateProfileString/Int functions are actually case insensitive, but I think that style is fine for section headers.
[quote]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.[/quote]Agreed.
[quote]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.[/quote]That's an interesting idea, and it certainly gives us the flexibility to have things like delays or transitions vary for each stage of the cycle to better suit the change in value. On the other hand we could also do that with dedicated preset sections like Helix mod and I don't see much advantage of this syntax over that.
I'm also not quite sure if we are on the same page about type=cycle vs type=add, because I can't see how the min, max and wrap options would work with type=cycle. I was thinking type=cycle would handle the case where one or two parameters needed to be cycled between several values, and type=add could add more flexibility to allow for things like arbitrary and more precise UI adjustments without having to explicitly define each and every distinct preset.
It also seems that syntax would tie the numeric order of the [KeyN] sections with the order of the cycle though, which is something I really want to avoid (a similar thing happens with Helix mod), since it makes it tedious to reorder the presets.
I already actually want to move away from the requirement that the key sections be numbered consecutively so the only requirement is that they begin with "Key" and are unique (and the only reason they have to be unique is because it's an ini file). I often find myself copying a whole slab of key bindings from one config to another and it's a bit annoying having to renumber them all - if the naming requirements were relaxed I could give each of them a unique name (like [KeyUIAdjust10Percent]) and not have to worry.
[quote]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).[/quote]I have entertained the idea of allowing a texture to say 'Preset=Key1', but I'm not sure if it's really a good idea - and duplicating the preset is probably fine in these cases.
We can make the textures sections support the same override options as the Key sections (that was part of the idea of Override::ParseIniSection), thereby removing the need for dedicated preset sections entirely.
bo3b said: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
Sounds good - I'll change them now before anyone starts using them.
Others I might have missed. The header sections are mostly CamelCase.
I'm pretty sure the GetPrivateProfileString/Int functions are actually case insensitive, but I think that style is fine for section headers.
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.
Agreed.
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.
That's an interesting idea, and it certainly gives us the flexibility to have things like delays or transitions vary for each stage of the cycle to better suit the change in value. On the other hand we could also do that with dedicated preset sections like Helix mod and I don't see much advantage of this syntax over that.
I'm also not quite sure if we are on the same page about type=cycle vs type=add, because I can't see how the min, max and wrap options would work with type=cycle. I was thinking type=cycle would handle the case where one or two parameters needed to be cycled between several values, and type=add could add more flexibility to allow for things like arbitrary and more precise UI adjustments without having to explicitly define each and every distinct preset.
It also seems that syntax would tie the numeric order of the [KeyN] sections with the order of the cycle though, which is something I really want to avoid (a similar thing happens with Helix mod), since it makes it tedious to reorder the presets.
I already actually want to move away from the requirement that the key sections be numbered consecutively so the only requirement is that they begin with "Key" and are unique (and the only reason they have to be unique is because it's an ini file). I often find myself copying a whole slab of key bindings from one config to another and it's a bit annoying having to renumber them all - if the naming requirements were relaxed I could give each of them a unique name (like [KeyUIAdjust10Percent]) and not have to worry.
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 have entertained the idea of allowing a texture to say 'Preset=Key1', but I'm not sure if it's really a good idea - and duplicating the preset is probably fine in these cases.
We can make the textures sections support the same override options as the Key sections (that was part of the idea of Override::ParseIniSection), thereby removing the need for dedicated preset sections entirely.
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"]That's an interesting idea, and it certainly gives us the flexibility to have things like delays or transitions vary for each stage of the cycle to better suit the change in value. On the other hand we could also do that with dedicated preset sections like Helix mod and I don't see much advantage of this syntax over that.
I'm also not quite sure if we are on the same page about type=cycle vs type=add, because I can't see how the min, max and wrap options would work with type=cycle. I was thinking type=cycle would handle the case where one or two parameters needed to be cycled between several values, and type=add could add more flexibility to allow for things like arbitrary and more precise UI adjustments without having to explicitly define each and every distinct preset.[/quote]
To be honest, I didn't grasp the idea on a first read. I understand what you are saying now, but based on that, I think this is going to be too complicated. It's nicely general, but for these use cases I think that clarity and simplicity are of higher value than generality.
I also agree that the extra level of a specific Preset (like the PRES0) is extra complexity that is rarely if ever used, just makes it harder to define the normal cases.
As a starting spot, I think I have a slight preference for your 'cycle' syntax.
[code][Key_hud_depth]
Key = F2
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]
[quote="DarkStarSword"]It also seems that syntax would tie the numeric order of the [KeyN] sections with the order of the cycle though, which is something I really want to avoid (a similar thing happens with Helix mod), since it makes it tedious to reorder the presets.
I already actually want to move away from the requirement that the key sections be numbered consecutively so the only requirement is that they begin with "Key" and are unique (and the only reason they have to be unique is because it's an ini file). I often find myself copying a whole slab of key bindings from one config to another and it's a bit annoying having to renumber them all - if the naming requirements were relaxed I could give each of them a unique name (like [KeyUIAdjust10Percent]) and not have to worry.[/quote]
Sounds good to me. Do you already have a way to fetch Key* variants without stepping through them? The API doesn't seem all that flexible to me, but maybe you already have something in mind (maybe GetPrivateProfileSectionNames, then index through them). I'd say sooner is better than later for changing this, since key presets are so new here, we might as well make it as good as we can on this pass.
DarkStarSword said:That's an interesting idea, and it certainly gives us the flexibility to have things like delays or transitions vary for each stage of the cycle to better suit the change in value. On the other hand we could also do that with dedicated preset sections like Helix mod and I don't see much advantage of this syntax over that.
I'm also not quite sure if we are on the same page about type=cycle vs type=add, because I can't see how the min, max and wrap options would work with type=cycle. I was thinking type=cycle would handle the case where one or two parameters needed to be cycled between several values, and type=add could add more flexibility to allow for things like arbitrary and more precise UI adjustments without having to explicitly define each and every distinct preset.
To be honest, I didn't grasp the idea on a first read. I understand what you are saying now, but based on that, I think this is going to be too complicated. It's nicely general, but for these use cases I think that clarity and simplicity are of higher value than generality.
I also agree that the extra level of a specific Preset (like the PRES0) is extra complexity that is rarely if ever used, just makes it harder to define the normal cases.
As a starting spot, I think I have a slight preference for your 'cycle' syntax.
[Key_hud_depth]
Key = F2
type = cycle
x = 0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 0.995
DarkStarSword said:It also seems that syntax would tie the numeric order of the [KeyN] sections with the order of the cycle though, which is something I really want to avoid (a similar thing happens with Helix mod), since it makes it tedious to reorder the presets.
I already actually want to move away from the requirement that the key sections be numbered consecutively so the only requirement is that they begin with "Key" and are unique (and the only reason they have to be unique is because it's an ini file). I often find myself copying a whole slab of key bindings from one config to another and it's a bit annoying having to renumber them all - if the naming requirements were relaxed I could give each of them a unique name (like [KeyUIAdjust10Percent]) and not have to worry.
Sounds good to me. Do you already have a way to fetch Key* variants without stepping through them? The API doesn't seem all that flexible to me, but maybe you already have something in mind (maybe GetPrivateProfileSectionNames, then index through them). I'd say sooner is better than later for changing this, since key presets are so new here, we might as well make it as good as we can on this pass.
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
For deciding on the key preset layout, let's try looking at an actual use case as a way of seeing if we like it? Let's take an eqzitara fix as a start. This is a change convergence setup based on a single key.
This is the original Helix style directly from a .ini file:
[code][General]
PresetsKeysList = 10;
[KEY10]
Key = 502
Presets = 12;13;14;
Type = 1
[PRES12]
UseSepSettings = true
SaveSepSettings = true
Convergence = 0x423a7070
Separation = 0x42a00001
[PRES13]
UseSepSettings = true
SaveSepSettings = true
UseByDef = true
Convergence = 0x425a7153
Separation = 0x42a00001
[PRES14]
UseSepSettings = true
SaveSepSettings = true
Convergence = 0x4276009f
Separation = 0x42a00001[/code]
Now what if we were to fix some of the obvious problems there (like hex numbers) but keep the basic structure? Does this seem better than our variants because of the familiarity, minus the tweaky hex vs. dec problems? i.e. Just making it more friendly.
[code][General]
PresetsKeysList = 10;
[KEY10]
Key = VK_MBUTTON
Presets = 12;13;14;
Type = toggle
[PRES12]
UseSepSettings = true
SaveSepSettings = true
Convergence = 46.6
Separation = 80
[PRES13]
UseSepSettings = true
SaveSepSettings = true
UseByDef = true
Convergence = 54.6
Separation = 80
[PRES14]
UseSepSettings = true
SaveSepSettings = true
Convergence = 61.5
Separation = 80[/code]
Then maybe one step further in still using Helix syntax, just removing unnecessary complexity and keywords. Like PresetsKeyList is not necessary, if a KEYN has a list of Presets, that should be clear. No type=toggle on the KEYN, because a cycle style is implied by Presets=a;b;c;. No UseSepSettings, because that is always expected.
[code]
[KEY10]
Key = VK_MBUTTON
Presets = 12;13;14;
[PRES12]
SaveSepSettings = true
Convergence = 46.6
Separation = 80
[PRES13]
SaveSepSettings = true
UseByDef = true
Convergence = 54.6
Separation = 80
[PRES14]
SaveSepSettings = true
Convergence = 61.5
Separation = 80[/code]
Then versus a dummied up variant of your cycle syntax? (I remove UseSepSettings as that is implicit)
[code][Key_cycle_convergence]
Key = VK_MBUTTON
type = cycle
convergence = 46.6, 54.6, 61.5
separation = 80, 80, 80
SaveSepSettings = true, true, true[/code]
Then maybe a variant of my Key style format.
[code][Key_cycle_1]
Key = VK_MBUTTON
type = cycle
convergence = 46.6
separation = 80
SaveSepSettings = true
[Key_cycle_2]
Key = VK_MBUTTON
type = cycle
convergence = 54.6
separation = 80
SaveSepSettings = true
[Key_cycle_3]
Key = VK_MBUTTON
type = cycle
convergence = 61.5
separation = 80
SaveSepSettings = true[/code]
For deciding on the key preset layout, let's try looking at an actual use case as a way of seeing if we like it? Let's take an eqzitara fix as a start. This is a change convergence setup based on a single key.
This is the original Helix style directly from a .ini file:
Now what if we were to fix some of the obvious problems there (like hex numbers) but keep the basic structure? Does this seem better than our variants because of the familiarity, minus the tweaky hex vs. dec problems? i.e. Just making it more friendly.
[General]
PresetsKeysList = 10;
[KEY10]
Key = VK_MBUTTON
Presets = 12;13;14;
Type = toggle
Then maybe one step further in still using Helix syntax, just removing unnecessary complexity and keywords. Like PresetsKeyList is not necessary, if a KEYN has a list of Presets, that should be clear. No type=toggle on the KEYN, because a cycle style is implied by Presets=a;b;c;. No UseSepSettings, because that is always expected.
I remember when Quadcore,8 gb RAM computer was unstoppable. Now I'm doing a second test to see if my computer can even handle this game in 3D. So far...nope.
I remember when Quadcore,8 gb RAM computer was unstoppable. Now I'm doing a second test to see if my computer can even handle this game in 3D. So far...nope.
[quote="bo3b"]Then versus a dummied up variant of your cycle syntax? (I remove UseSepSettings as that is implicit)
[code][Key_cycle_convergence]
Key = VK_MBUTTON
type = cycle
convergence = 46.6, 54.6, 61.5
separation = 80, 80, 80
SaveSepSettings = true, true, true[/code]
[/quote]I think out of all the options this is my preference - it's nice, simple, concise, unambiguous, keeps everything together, and should be fairly straight forward to implement as a vector of override instances.
The only change that I think would make this better is relaxing the requirement that all lists be the same length and repeating the final value of any short lists to make up the difference - that would make this valid and have the separation and SaveSepSettings apply to all three presets:
[code]
[Key_cycle_convergence]
Key = VK_MBUTTON
type = cycle
convergence = 46.6, 54.6, 61.5
separation = 80
SaveSepSettings = true
[/code]
[quote="bo3b"][quote="DarkStarSword"]I'm also not quite sure if we are on the same page about type=cycle vs type=add, because I can't see how the min, max and wrap options would work with type=cycle. I was thinking type=cycle would handle the case where one or two parameters needed to be cycled between several values, and type=add could add more flexibility to allow for things like arbitrary and more precise UI adjustments without having to explicitly define each and every distinct preset.[/quote]
To be honest, I didn't grasp the idea on a first read. I understand what you are saying now, but based on that, I think this is going to be too complicated. It's nicely general, but for these use cases I think that clarity and simplicity are of higher value than generality.[/quote]Agreed. The override code is already becoming complicated and this would just add a bunch more edge cases and make bugs all the more likely. If someone desperately wants it we can revisit it at a later date.
[quote][quote="DarkStarSword"]I already actually want to move away from the requirement that the key sections be numbered consecutively so the only requirement is that they begin with "Key" and are unique (and the only reason they have to be unique is because it's an ini file). I often find myself copying a whole slab of key bindings from one config to another and it's a bit annoying having to renumber them all - if the naming requirements were relaxed I could give each of them a unique name (like [KeyUIAdjust10Percent]) and not have to worry.[/quote]
Sounds good to me. Do you already have a way to fetch Key* variants without stepping through them? The API doesn't seem all that flexible to me, but maybe you already have something in mind (maybe GetPrivateProfileSectionNames, then index through them). I'd say sooner is better than later for changing this, since key presets are so new here, we might as well make it as good as we can on this pass.[/quote]GetPrivateProfileSectionNames is exactly what I was thinking of using :)
I think out of all the options this is my preference - it's nice, simple, concise, unambiguous, keeps everything together, and should be fairly straight forward to implement as a vector of override instances.
The only change that I think would make this better is relaxing the requirement that all lists be the same length and repeating the final value of any short lists to make up the difference - that would make this valid and have the separation and SaveSepSettings apply to all three presets:
DarkStarSword said:I'm also not quite sure if we are on the same page about type=cycle vs type=add, because I can't see how the min, max and wrap options would work with type=cycle. I was thinking type=cycle would handle the case where one or two parameters needed to be cycled between several values, and type=add could add more flexibility to allow for things like arbitrary and more precise UI adjustments without having to explicitly define each and every distinct preset.
To be honest, I didn't grasp the idea on a first read. I understand what you are saying now, but based on that, I think this is going to be too complicated. It's nicely general, but for these use cases I think that clarity and simplicity are of higher value than generality.
Agreed. The override code is already becoming complicated and this would just add a bunch more edge cases and make bugs all the more likely. If someone desperately wants it we can revisit it at a later date.
DarkStarSword said:I already actually want to move away from the requirement that the key sections be numbered consecutively so the only requirement is that they begin with "Key" and are unique (and the only reason they have to be unique is because it's an ini file). I often find myself copying a whole slab of key bindings from one config to another and it's a bit annoying having to renumber them all - if the naming requirements were relaxed I could give each of them a unique name (like [KeyUIAdjust10Percent]) and not have to worry.
Sounds good to me. Do you already have a way to fetch Key* variants without stepping through them? The API doesn't seem all that flexible to me, but maybe you already have something in mind (maybe GetPrivateProfileSectionNames, then index through them). I'd say sooner is better than later for changing this, since key presets are so new here, we might as well make it as good as we can on this pass.
GetPrivateProfileSectionNames is exactly what I was thinking of using :)
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
type=cycle support is now implemented in 3Dmigoto - see this post:
[url]https://forums.geforce.com/default/topic/685657/3d-vision/3dmigoto-now-open-source-/post/4464399/#4464399[/url]
If list lengths are uneven the final value of any short lists is repeated. I also made it possible to omit a setting from a given cycle by leaving it blank so that it will not get set on that cycle (e.g. x=1,2,,3,4). This can be used as the last item in a short list to prevent the final item being repeated (e.g. y=1,2,3,,)
If list lengths are uneven the final value of any short lists is repeated. I also made it possible to omit a setting from a given cycle by leaving it blank so that it will not get set on that cycle (e.g. x=1,2,,3,4). This can be used as the last item in a short list to prevent the final item being repeated (e.g. y=1,2,3,,)
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
Sounds good. I was surprised by how much I liked the Helix syntax after removing the bizarre parts. Using that would be very confusing though, because if it were too similar anybody switching back and forth would get tricked a lot.
So, making a clean break is good, and I think the cycle syntax will work nicely. I don't personally care for the automatic addition of missing params because I always like things to be fully explicit, but since both ways work I'll just fill out my lists.
Thanks for implementing all these pieces! And Flugan, thanks for keeping parity with these, very helpful.
Sounds good. I was surprised by how much I liked the Helix syntax after removing the bizarre parts. Using that would be very confusing though, because if it were too similar anybody switching back and forth would get tricked a lot.
So, making a clean break is good, and I think the cycle syntax will work nicely. I don't personally care for the automatic addition of missing params because I always like things to be fully explicit, but since both ways work I'll just fill out my lists.
Thanks for implementing all these pieces! And Flugan, thanks for keeping parity with these, very helpful.
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
Just about implemented cycle keys. It took some shuffling around and some parsing. String.find() and stof(). There is some pressure to keep up on certain features so they can be used freely.
Reading from d3dx.ini puts preasure on understanding the parts needed to run the fix.
I would really like to add some hunting of some sort back into the shader as it would be helpful if an issue is found while playing with my wrapper. Dumping cbo with hash can bring the resulting shader into HLSL land to become fixable hopefully. But that is for another time.
Finally I could not fall too far behind on certain features like key bindings and Xbox integration. Soon key names will be more flexible. I can implement in anticipation but until 3Dmigoto supports the feature no-one will use it. It really becomes a collaboration in certain parts with mostly dual implementations.
Just about implemented cycle keys. It took some shuffling around and some parsing. String.find() and stof(). There is some pressure to keep up on certain features so they can be used freely.
Reading from d3dx.ini puts preasure on understanding the parts needed to run the fix.
I would really like to add some hunting of some sort back into the shader as it would be helpful if an issue is found while playing with my wrapper. Dumping cbo with hash can bring the resulting shader into HLSL land to become fixable hopefully. But that is for another time.
Finally I could not fall too far behind on certain features like key bindings and Xbox integration. Soon key names will be more flexible. I can implement in anticipation but until 3Dmigoto supports the feature no-one will use it. It really becomes a collaboration in certain parts with mostly dual implementations.
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?
Would you be interested in or use a drop in object for key handling? My original plan for adding key handling via GetAsyncKeys was to build a set of C++ objects that were standalone so you'd be able to copy or import those.
Would you be interested in or use a drop in object for key handling? My original plan for adding key handling via GetAsyncKeys was to build a set of C++ objects that were standalone so you'd be able to copy or import those.
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
At this point my button handling is working so no point in changing it.
Having a fairly simple class structure:
A class for each kind of button (Xbox/GetAsyncKeys)
And a button handler working on the status of the buttons.
Getting XInput state is not ideal in this scenario as you call more update requests than immediately necessary. Moved button handling from afterDraw to ClearRenderTargetView.
This move have not been widely tested across games.
At this point my button handling is working so no point in changing it.
Having a fairly simple class structure:
A class for each kind of button (Xbox/GetAsyncKeys)
And a button handler working on the status of the buttons.
Getting XInput state is not ideal in this scenario as you call more update requests than immediately necessary. Moved button handling from afterDraw to ClearRenderTargetView.
This move have not been widely tested across games.
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?
Just implemented general sectionnames starting with Key but no other limitations using GetPrivateProfileSectionNames:
[code]
vector<string> Keys;
char sectionNames[10000];
GetPrivateProfileSectionNames(sectionNames, 10000, INIfile);
int position = 0;
int length = strlen(§ionNames[position]);
while (length != 0) {
if (strncmp(§ionNames[position], "Key", 3) == 0)
Keys.push_back(§ionNames[position]);
position += length + 1;
length = strlen(§ionNames[position]);
}
for (int i = 0; i < Keys.size(); i++) {
const char* id = Keys[i].c_str();
if (!GetPrivateProfileString(id, "Key", 0, key, MAX_PATH, INIfile))
continue;
[/code]
I realize that GetPrivateProfileString(NULL, ...) can be used instead.
With everything else being lowercase should Key remain upper case inside the section.
Just implemented general sectionnames starting with Key but no other limitations using GetPrivateProfileSectionNames:
vector<string> Keys;
char sectionNames[10000];
GetPrivateProfileSectionNames(sectionNames, 10000, INIfile);
int position = 0;
int length = strlen(§ionNames[position]);
while (length != 0) {
if (strncmp(§ionNames[position], "Key", 3) == 0)
Keys.push_back(§ionNames[position]);
position += length + 1;
length = strlen(§ionNames[position]);
}
for (int i = 0; i < Keys.size(); i++) {
const char* id = Keys[i].c_str();
if (!GetPrivateProfileString(id, "Key", 0, key, MAX_PATH, INIfile))
continue;
I realize that GetPrivateProfileString(NULL, ...) can be used instead.
With everything else being lowercase should Key remain upper case inside the section.
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"]Just implemented general sectionnames starting with Key but no other limitations using GetPrivateProfileSectionNames:[/quote]I have also implemented this in 3Dmigoto, but in a more general way that also applies to [TextureOverride*] and [ShaderOverride*] sections, and can easily be reused if we need the same for other section types later on.
I've also added the beginnings of some error checking to 3Dmigoto, which will detect duplicate section names (including ones that only vary by case) and sound an audible warning, which should help reduce time wasted due to copy + paste errors.
[quote]With everything else being lowercase should Key remain upper case inside the section.[/quote]Nothing is case sensitive at the moment, and if it is that is a bug. When I did add a case sensitive option by mistake a few weeks ago people noticed and complained.
We generally use CamelCase for the section names and lower case for the values, but that is only by
By convention - the GetPrivateProfile family of APIs are not case sensitive and we treat the returned strings as case insensitive as well.
You should use a case insensitive string compare instead of strncmp() in the above code.
Flugan said:Just implemented general sectionnames starting with Key but no other limitations using GetPrivateProfileSectionNames:
I have also implemented this in 3Dmigoto, but in a more general way that also applies to [TextureOverride*] and [ShaderOverride*] sections, and can easily be reused if we need the same for other section types later on.
I've also added the beginnings of some error checking to 3Dmigoto, which will detect duplicate section names (including ones that only vary by case) and sound an audible warning, which should help reduce time wasted due to copy + paste errors.
With everything else being lowercase should Key remain upper case inside the section.
Nothing is case sensitive at the moment, and if it is that is a bug. When I did add a case sensitive option by mistake a few weeks ago people noticed and complained.
We generally use CamelCase for the section names and lower case for the values, but that is only by
By convention - the GetPrivateProfile family of APIs are not case sensitive and we treat the returned strings as case insensitive as well.
You should use a case insensitive string compare instead of strncmp() in the above code.
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="Flugan"]At this point my button handling is working so no point in changing it.[/quote]
To clarify- the advantage of using a single code base with a good API means that you can always stay in parity without having to do extra work. It's not the past that matters for code-reuse, it's the future changes that will continue to require updates as each code base changes.
The current object structure in 3Dmigoto does not have a good API, so it's not possible at the moment, but we could prioritize that if it was helpful. If not, no problem.
Flugan said:At this point my button handling is working so no point in changing it.
To clarify- the advantage of using a single code base with a good API means that you can always stay in parity without having to do extra work. It's not the past that matters for code-reuse, it's the future changes that will continue to require updates as each code base changes.
The current object structure in 3Dmigoto does not have a good API, so it's not possible at the moment, but we could prioritize that if it was helpful. If not, no problem.
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'm pretty sure the GetPrivateProfileString/Int functions are actually case insensitive, but I think that style is fine for section headers.
Agreed.
That's an interesting idea, and it certainly gives us the flexibility to have things like delays or transitions vary for each stage of the cycle to better suit the change in value. On the other hand we could also do that with dedicated preset sections like Helix mod and I don't see much advantage of this syntax over that.
I'm also not quite sure if we are on the same page about type=cycle vs type=add, because I can't see how the min, max and wrap options would work with type=cycle. I was thinking type=cycle would handle the case where one or two parameters needed to be cycled between several values, and type=add could add more flexibility to allow for things like arbitrary and more precise UI adjustments without having to explicitly define each and every distinct preset.
It also seems that syntax would tie the numeric order of the [KeyN] sections with the order of the cycle though, which is something I really want to avoid (a similar thing happens with Helix mod), since it makes it tedious to reorder the presets.
I already actually want to move away from the requirement that the key sections be numbered consecutively so the only requirement is that they begin with "Key" and are unique (and the only reason they have to be unique is because it's an ini file). I often find myself copying a whole slab of key bindings from one config to another and it's a bit annoying having to renumber them all - if the naming requirements were relaxed I could give each of them a unique name (like [KeyUIAdjust10Percent]) and not have to worry.
I have entertained the idea of allowing a texture to say 'Preset=Key1', but I'm not sure if it's really a good idea - and duplicating the preset is probably fine in these cases.
We can make the textures sections support the same override options as the Key sections (that was part of the idea of Override::ParseIniSection), thereby removing the need for dedicated preset sections entirely.
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
To be honest, I didn't grasp the idea on a first read. I understand what you are saying now, but based on that, I think this is going to be too complicated. It's nicely general, but for these use cases I think that clarity and simplicity are of higher value than generality.
I also agree that the extra level of a specific Preset (like the PRES0) is extra complexity that is rarely if ever used, just makes it harder to define the normal cases.
As a starting spot, I think I have a slight preference for your 'cycle' syntax.
Sounds good to me. Do you already have a way to fetch Key* variants without stepping through them? The API doesn't seem all that flexible to me, but maybe you already have something in mind (maybe GetPrivateProfileSectionNames, then index through them). I'd say sooner is better than later for changing this, since key presets are so new here, we might as well make it as good as we can on this pass.
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
This is the original Helix style directly from a .ini file:
Now what if we were to fix some of the obvious problems there (like hex numbers) but keep the basic structure? Does this seem better than our variants because of the familiarity, minus the tweaky hex vs. dec problems? i.e. Just making it more friendly.
Then maybe one step further in still using Helix syntax, just removing unnecessary complexity and keywords. Like PresetsKeyList is not necessary, if a KEYN has a list of Presets, that should be clear. No type=toggle on the KEYN, because a cycle style is implied by Presets=a;b;c;. No UseSepSettings, because that is always expected.
Then versus a dummied up variant of your cycle syntax? (I remove UseSepSettings as that is implicit)
Then maybe a variant of my Key style format.
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
The only change that I think would make this better is relaxing the requirement that all lists be the same length and repeating the final value of any short lists to make up the difference - that would make this valid and have the separation and SaveSepSettings apply to all three presets:
Agreed. The override code is already becoming complicated and this would just add a bunch more edge cases and make bugs all the more likely. If someone desperately wants it we can revisit it at a later date.
GetPrivateProfileSectionNames is exactly what I was thinking of using :)
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
https://forums.geforce.com/default/topic/685657/3d-vision/3dmigoto-now-open-source-/post/4464399/#4464399
If list lengths are uneven the final value of any short lists is repeated. I also made it possible to omit a setting from a given cycle by leaving it blank so that it will not get set on that cycle (e.g. x=1,2,,3,4). This can be used as the last item in a short list to prevent the final item being repeated (e.g. y=1,2,3,,)
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
So, making a clean break is good, and I think the cycle syntax will work nicely. I don't personally care for the automatic addition of missing params because I always like things to be fully explicit, but since both ways work I'll just fill out my lists.
Thanks for implementing all these pieces! And Flugan, thanks for keeping parity with these, very helpful.
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
Reading from d3dx.ini puts preasure on understanding the parts needed to run the fix.
I would really like to add some hunting of some sort back into the shader as it would be helpful if an issue is found while playing with my wrapper. Dumping cbo with hash can bring the resulting shader into HLSL land to become fixable hopefully. But that is for another time.
Finally I could not fall too far behind on certain features like key bindings and Xbox integration. Soon key names will be more flexible. I can implement in anticipation but until 3Dmigoto supports the feature no-one will use it. It really becomes a collaboration in certain parts with mostly dual implementations.
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
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
Having a fairly simple class structure:
A class for each kind of button (Xbox/GetAsyncKeys)
And a button handler working on the status of the buttons.
Getting XInput state is not ideal in this scenario as you call more update requests than immediately necessary. Moved button handling from afterDraw to ClearRenderTargetView.
This move have not been widely tested across games.
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 realize that GetPrivateProfileString(NULL, ...) can be used instead.
With everything else being lowercase should Key remain upper case inside the section.
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've also added the beginnings of some error checking to 3Dmigoto, which will detect duplicate section names (including ones that only vary by case) and sound an audible warning, which should help reduce time wasted due to copy + paste errors.
Nothing is case sensitive at the moment, and if it is that is a bug. When I did add a case sensitive option by mistake a few weeks ago people noticed and complained.
We generally use CamelCase for the section names and lower case for the values, but that is only by
By convention - the GetPrivateProfile family of APIs are not case sensitive and we treat the returned strings as case insensitive as well.
You should use a case insensitive string compare instead of strncmp() in the above code.
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
To clarify- the advantage of using a single code base with a good API means that you can always stay in parity without having to do extra work. It's not the past that matters for code-reuse, it's the future changes that will continue to require updates as each code base changes.
The current object structure in 3Dmigoto does not have a good API, so it's not possible at the moment, but we could prioritize that if it was helpful. If not, no problem.
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