[quote="Flugan"]I find it difficult to fit this inside my existing code at this moment. I will wait and see how it used in reality. Here the example is hud depth but I see it better written permanently in the ini file as it would save the value between play sessions. Obviously it has more uses.[/quote]Obviously this was just one example (that I was using for testing). In many games it does make sense to set a constant HUD depth, but not all. For instance, in a point and click adventure game like The Book of Unwritten Tales 2, there is no one suitable HUD depth and it has to be adjusted on the fly to suit each individual scene (although for that game I use all the keys on the number row to set specific depths rather than a cycle key). One instance where I have used this example in practice was in Legends of Aethereus where thanks to being a 3rd person game the crosshair did not have a good single depth that was always useful so I added a cycle binding to change it on the fly:
[code]
[KEY0]
; Q key cycles crosshair depth presets
Key = 81
Presets = 0;1;2;3;4;
Type = 1
[PRES0]
; 0.95
Const1 = 0x3f733333
[PRES1]
; 0.5
Const1 = 0x3f000000
[PRES2]
; 0.625
Const1 = 0x3f200000
[PRES3]
; 0.75
Const1 = 0x3f400000
[PRES4]
; 0.85
Const1 = 0x3f59999a
UseByDef = true
[/code]
Which in this syntax would be:
[code]
[Key1]
Key = Q
type = cycle
x = 0.95, 0.5, 0.625, 0.75, 0.85
[Constants]
x = 0.85
[/code]
[quote]I also have not looked into how whitespace is handled in default parsing I'm doing.
type = cycle
vs
type=cycle
One of these Key sections would crash my current implementation unless I'm mistaken.[/quote]3Dmigoto can handle both, but I haven't checked whether this is true of every setting. For type=cycle I explicitly skip over whitespace around commas in the list.
[quote]By the way leaving the last entry empty looks like
transition=100,
not
transition=100,,[/quote]
Right now in the code it has to have two commas at the end of the list to explicitly make the final entry blank, as the final comma is optional and will be ignored if present. This is really just an artefact of the parsing routine though and I could change it (but it seemed reasonable to me at the time since the double comma is very explicit so I left it as is) - does anyone have a strong opinion on this one way or the other?
[quote]cycle obviously has much more parsing.[/quote]Indeed. I used a helper class to parse each list - you can take a look at KeyOverrideCycle::ParseIniSection() and the KeyOverrideCycleParam class to see how I did this.
[quote]I assume cycle loops actually making the transition from last to first the biggest. [/quote]It does loop from last to first, though I'm not sure I would use the term 'biggest' to describe it - surely the magnitude a given value changes depends entirely on what values have been defined and is not inherent to the code? In my Legends of Aethereus example above the 'biggest' change would be the second key press from 0.95 to 0.5, and not the first, which only goes from 0.85 to 0.95.
To be clear - the numeric order of the values is not relevant to the cycle order - the order is simply left to right (In Helix mod the numeric order of the presets WAS the cycle order, and it was a royal pain as a result).
[quote]Or the first keypress when we don't know where we are.[/quote]The first key press will select the first entry in the list - I don't want to do anything fancy here as it would just be confusing. If someone needs value set on the first key press to be 0.4 instead of 0, then they just make the first value 0.4. Default values are still read from the [Constants] section and are independent of this list.
[quote]Are we happy with this syntax? It is pretty flexible and concise.[/quote]I'm pretty happy with it - unless someone has a major objection (which really should have been raised earlier while we were discussing syntax proposals and not now that I've implemented it) I say we go with it.
I am happy to change the requirement for two commas at the end of the list to one for a blank entry if people think it's better, but unless I hear back I have a slight preference to leaving it as a double comma.
[quote]Another special case would be specifying elements at the end.
transition=...,100,300
But that would be a weird special case.[/quote]I agree it's weird, but I did test some cases like that and they work as expected:
[code]
[Key1]
Key = tilde
Type = cycle
x = 0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 0.995
separation = 100,50,100
transition = ,,,1000,100,,,300,,[/code]
Was interpreted as:
[code]
Cycle 1: x=0 separation=100
Cycle 2: x=0.1 separation=50
Cycle 3: x=0.2 separation=100
Cycle 4: x=0.3 separation=100 transition=1000
Cycle 5: x=0.4 separation=100 transition=100
Cycle 6: x=0.5 separation=100
Cycle 7: x=0.6 separation=100
Cycle 8: x=0.7 separation=100 transition=300
Cycle 9: x=0.8 separation=100
Cycle 10: x=0.9 separation=100
Cycle 11: x=0.995 separation=100
[/code]
Flugan said:I find it difficult to fit this inside my existing code at this moment. I will wait and see how it used in reality. Here the example is hud depth but I see it better written permanently in the ini file as it would save the value between play sessions. Obviously it has more uses.
Obviously this was just one example (that I was using for testing). In many games it does make sense to set a constant HUD depth, but not all. For instance, in a point and click adventure game like The Book of Unwritten Tales 2, there is no one suitable HUD depth and it has to be adjusted on the fly to suit each individual scene (although for that game I use all the keys on the number row to set specific depths rather than a cycle key). One instance where I have used this example in practice was in Legends of Aethereus where thanks to being a 3rd person game the crosshair did not have a good single depth that was always useful so I added a cycle binding to change it on the fly:
[Key1]
Key = Q
type = cycle
x = 0.95, 0.5, 0.625, 0.75, 0.85
[Constants]
x = 0.85
I also have not looked into how whitespace is handled in default parsing I'm doing.
type = cycle
vs
type=cycle
One of these Key sections would crash my current implementation unless I'm mistaken.
3Dmigoto can handle both, but I haven't checked whether this is true of every setting. For type=cycle I explicitly skip over whitespace around commas in the list.
By the way leaving the last entry empty looks like
transition=100,
not
transition=100,,
Right now in the code it has to have two commas at the end of the list to explicitly make the final entry blank, as the final comma is optional and will be ignored if present. This is really just an artefact of the parsing routine though and I could change it (but it seemed reasonable to me at the time since the double comma is very explicit so I left it as is) - does anyone have a strong opinion on this one way or the other?
cycle obviously has much more parsing.
Indeed. I used a helper class to parse each list - you can take a look at KeyOverrideCycle::ParseIniSection() and the KeyOverrideCycleParam class to see how I did this.
I assume cycle loops actually making the transition from last to first the biggest.
It does loop from last to first, though I'm not sure I would use the term 'biggest' to describe it - surely the magnitude a given value changes depends entirely on what values have been defined and is not inherent to the code? In my Legends of Aethereus example above the 'biggest' change would be the second key press from 0.95 to 0.5, and not the first, which only goes from 0.85 to 0.95.
To be clear - the numeric order of the values is not relevant to the cycle order - the order is simply left to right (In Helix mod the numeric order of the presets WAS the cycle order, and it was a royal pain as a result).
Or the first keypress when we don't know where we are.
The first key press will select the first entry in the list - I don't want to do anything fancy here as it would just be confusing. If someone needs value set on the first key press to be 0.4 instead of 0, then they just make the first value 0.4. Default values are still read from the [Constants] section and are independent of this list.
Are we happy with this syntax? It is pretty flexible and concise.
I'm pretty happy with it - unless someone has a major objection (which really should have been raised earlier while we were discussing syntax proposals and not now that I've implemented it) I say we go with it.
I am happy to change the requirement for two commas at the end of the list to one for a blank entry if people think it's better, but unless I hear back I have a slight preference to leaving it as a double comma.
Another special case would be specifying elements at the end.
transition=...,100,300
But that would be a weird special case.
I agree it's weird, but I did test some cases like that and they work as expected:
[quote="Flugan"]I find it difficult to fit this inside my existing code at this moment.[/quote]
Man I wish C++ supported Duck typing - it would have made the class hierarchy a lot simpler.
I have implemented cycle and it's in build v2.4.
Both test cases work as intended. Pretty stable might be some bugs left. I have not tested the delay function.
Edit: It does not require double comma at the end as the last void entry is repeated. Using FLT_MAX to represent missing values.
That's all OK with me too. I have a medium preference for not having automatic entries added from missing items in the list. Our target audience are not always computer people, and having auto-shortcut stuff like this is sometimes hard for them.
As a convenience for more saavy users, I think it's fine, but for any examples that we give, and documentation in the .ini file I think they should be fully spelled out. The fewer 'gotchas' the better. The examples we have so far are all contrived, right? As a general author thought, I recommend that we should avoid adding stuff that doesn't have a clear use, because it [i]always[/i] adds complexity to the code. We need to keep it simple, and clear.
Along that lines- how do we handle errors? What is the mechanism for the user to know that something went wrong? The biggest knock on HelixMod is the silent failures for syntax errors including stuff like missing semicolons. Highly annoying for everyone I'm sure.
That's all OK with me too. I have a medium preference for not having automatic entries added from missing items in the list. Our target audience are not always computer people, and having auto-shortcut stuff like this is sometimes hard for them.
As a convenience for more saavy users, I think it's fine, but for any examples that we give, and documentation in the .ini file I think they should be fully spelled out. The fewer 'gotchas' the better. The examples we have so far are all contrived, right? As a general author thought, I recommend that we should avoid adding stuff that doesn't have a clear use, because it always adds complexity to the code. We need to keep it simple, and clear.
Along that lines- how do we handle errors? What is the mechanism for the user to know that something went wrong? The biggest knock on HelixMod is the silent failures for syntax errors including stuff like missing semicolons. Highly annoying for everyone I'm sure.
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
[quote="bo3b"]That's all OK with me too. I have a medium preference for not having automatic entries added from missing items in the list. Our target audience are not always computer people, and having auto-shortcut stuff like this is sometimes hard for them.[/quote]My preference is for it to be repeated, because users may not expect all settings to need to be repeated, and it seems less surprising if a setting like 'transition=100' (or 'transition_type=cosine', or 'SaveSepSettings=true', etc) applies to all cycles by default rather than only the first. In my opinion NOT applying a setting to all iterations is going to be the uncommon case and so I'd rather that situation have to be explicit and verbose rather than the common case.
And I'd really *really* hate to have to count how many times I've specified transition=100,100,100,100,100,100,100,100,100,100,100,100,100,100,100,100...
[quote]Along that lines- how do we handle errors? What is the mechanism for the user to know that something went wrong? The biggest knock on HelixMod is the silent failures for syntax errors including stuff like missing semicolons. Highly annoying for everyone I'm sure.[/quote]
This is something I need to add (for a bunch of parameters, not just this one) - it seems that the boop error tone is good, because it prompts people to look at the log file to find out what went wrong. One consideration is that we don't currently have a way to detect if a bad section or keyword has been used (e.g. transformation=100 instead of transition=100, or [TexutreOverride1], etc), so there are some cases that will still fail silently even if we can detect parse errors.
[quote="Flugan"]Edit: It does not require double comma at the end as the last void entry is repeated.[/quote]
Ok, in that case I'll change 3Dmigoto to use one comma - I think defining this unambiguously now and being consistent between the two wrappers is more important than worrying about how many commas we need.
bo3b said:That's all OK with me too. I have a medium preference for not having automatic entries added from missing items in the list. Our target audience are not always computer people, and having auto-shortcut stuff like this is sometimes hard for them.
My preference is for it to be repeated, because users may not expect all settings to need to be repeated, and it seems less surprising if a setting like 'transition=100' (or 'transition_type=cosine', or 'SaveSepSettings=true', etc) applies to all cycles by default rather than only the first. In my opinion NOT applying a setting to all iterations is going to be the uncommon case and so I'd rather that situation have to be explicit and verbose rather than the common case.
And I'd really *really* hate to have to count how many times I've specified transition=100,100,100,100,100,100,100,100,100,100,100,100,100,100,100,100...
Along that lines- how do we handle errors? What is the mechanism for the user to know that something went wrong? The biggest knock on HelixMod is the silent failures for syntax errors including stuff like missing semicolons. Highly annoying for everyone I'm sure.
This is something I need to add (for a bunch of parameters, not just this one) - it seems that the boop error tone is good, because it prompts people to look at the log file to find out what went wrong. One consideration is that we don't currently have a way to detect if a bad section or keyword has been used (e.g. transformation=100 instead of transition=100, or [TexutreOverride1], etc), so there are some cases that will still fail silently even if we can detect parse errors.
Flugan said:Edit: It does not require double comma at the end as the last void entry is repeated.
Ok, in that case I'll change 3Dmigoto to use one comma - I think defining this unambiguously now and being consistent between the two wrappers is more important than worrying about how many commas we need.
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
Regarding error handling I find it difficult enough to handle well supported syntax.
transition=Umbrella
will fail in some matter in function stof() producing an incorrect value where no correct value exists.
The apparent case sensitivity of ini files is another issue. Might not be a problem if using a custom parser.
You really can't test every upper/lowercase variant of a variable.
I just find it too easy to break stuff. My assembler is not very verbose when it comes to errors it really only supports compiling unchanged shahders back into cbo. Have not gotten around to make it more robust to human changes. It won't assemble Helix Bioshock Infinite shaders due to at least some naming conflicts.
Regarding error handling I find it difficult enough to handle well supported syntax.
transition=Umbrella
will fail in some matter in function stof() producing an incorrect value where no correct value exists.
The apparent case sensitivity of ini files is another issue. Might not be a problem if using a custom parser.
You really can't test every upper/lowercase variant of a variable.
I just find it too easy to break stuff. My assembler is not very verbose when it comes to errors it really only supports compiling unchanged shahders back into cbo. Have not gotten around to make it more robust to human changes. It won't assemble Helix Bioshock Infinite shaders due to at least some naming conflicts.
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="DarkStarSword"][quote="Flugan"]Edit: It does not require double comma at the end as the last void entry is repeated.[/quote]
Ok, in that case I'll change 3Dmigoto to use one comma - I think defining this unambiguously now and being consistent between the two wrappers is more important than worrying about how many commas we need.[/quote]
This change is done, so now if someone wants to suppress the default repeating behavior they would do this:
[code]
[Key5]
Key = tilde
Type = cycle
x = 0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 0.995
transition = 100,
[/code]
Now I've actually looked at a concrete example of this I've decided that I prefer it this way - the trailing comma makes it clear that transition is a list, and therefore pretty clear that only the first element is set.
If the comma was not there the transition setting would not look like one that applies to the whole [Key5] section (just like Key=tilde and Type=cycle) and thanks to the repeating behaviour the user doesn't need to care that under the hood it is still a list and it would behave as expected.
Thanks for changing my mind Flugan :)
Flugan said:Edit: It does not require double comma at the end as the last void entry is repeated.
Ok, in that case I'll change 3Dmigoto to use one comma - I think defining this unambiguously now and being consistent between the two wrappers is more important than worrying about how many commas we need.
This change is done, so now if someone wants to suppress the default repeating behavior they would do this:
Now I've actually looked at a concrete example of this I've decided that I prefer it this way - the trailing comma makes it clear that transition is a list, and therefore pretty clear that only the first element is set.
If the comma was not there the transition setting would not look like one that applies to the whole [Key5] section (just like Key=tilde and Type=cycle) and thanks to the repeating behaviour the user doesn't need to care that under the hood it is still a list and it would behave as expected.
Thanks for changing my mind Flugan :)
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
Sorry, I was not clear on my earlier comment.
I really think that this auto repeat mechanism, either with or without commas is a mistake.
Look at the last 5 posts here- where we are talking about whether a single comma makes it more clear that it repeats or not. I humbly suggest that if our syntax depends upon a single comma, that is a poor syntax. Yes, comma at the end of a line in Python- blargh.
[quote]And I'd really *really* hate to have to count how many times I've specified transition=100,100,100,100,100,100,100,100,100,100,100,100,100,100,100,100...[/quote]
Yeah, it's a pain for these things. But I want to step back and ask whether we are doing this for us, or for our end users?
The full form syntax is much, much more clear, especially with formatting. When I'm trying to teach people about how to use stuff, having tweaky things based on commas, or having to focus upon a single closing comma is always trouble.
Conversely, I'm going to really hate to have to say, "Don't forget the closing comma if you want a blank list of entries, otherwise you'll accidentally get your first item duplicated." How is this different than "Don't forget that every element must have a semi-colon, including the last one."
Contrived example:
[code][Key5]
Key = tilde
Type = cycle
x = 0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 0.995
transition = 100,,,,,,33,
[/code]
Quick, which of the levels switches to 33?
Why not stay simple, clear, verbose? I'm not at all interested in saving keystrokes at the expense of clarity, ever.
[code][Key5]
Key = tilde
Type = cycle
x = 0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 0.995
transition = 100, 100, 100, 100, 100, 33, 33, 33, 33, 33, 33
[/code]
Even more to the point- this is a super rare use case. 1/100 people are going to use this.
I'm not going to make any demands one way or the other, because I defer to whoever is implementing it as much as possible. But I will say that building mechanisms that are rarely, if ever, used adds unnecessary complexity both for the code and the user.
It's fine if you want to use this special syntax, but I really want to avoid making it any sort of default. Our users can learn it, hell, they learned the Helix syntax. But we can expand our group of hackers by avoiding this sort of featurism and keeping it vanilla.
Do we have any actual use case for this level of complexity?
I really think that this auto repeat mechanism, either with or without commas is a mistake.
Look at the last 5 posts here- where we are talking about whether a single comma makes it more clear that it repeats or not. I humbly suggest that if our syntax depends upon a single comma, that is a poor syntax. Yes, comma at the end of a line in Python- blargh.
And I'd really *really* hate to have to count how many times I've specified transition=100,100,100,100,100,100,100,100,100,100,100,100,100,100,100,100...
Yeah, it's a pain for these things. But I want to step back and ask whether we are doing this for us, or for our end users?
The full form syntax is much, much more clear, especially with formatting. When I'm trying to teach people about how to use stuff, having tweaky things based on commas, or having to focus upon a single closing comma is always trouble.
Conversely, I'm going to really hate to have to say, "Don't forget the closing comma if you want a blank list of entries, otherwise you'll accidentally get your first item duplicated." How is this different than "Don't forget that every element must have a semi-colon, including the last one."
Even more to the point- this is a super rare use case. 1/100 people are going to use this.
I'm not going to make any demands one way or the other, because I defer to whoever is implementing it as much as possible. But I will say that building mechanisms that are rarely, if ever, used adds unnecessary complexity both for the code and the user.
It's fine if you want to use this special syntax, but I really want to avoid making it any sort of default. Our users can learn it, hell, they learned the Helix syntax. But we can expand our group of hackers by avoiding this sort of featurism and keeping it vanilla.
Do we have any actual use case for this level of complexity?
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 am aiming this at the common case. The point is that most users don't need to know about the repeat mechanism - they will either do this:
[code]
[Key1]
key = q
type = cycle
x = 1, 2, 3, 4, 5
transition = 100
convergence = 0.3
[/code]
or they might do this:
[code]
[Key1]
key = q
type = cycle
x = 1, 2, 3, 4, 5
transition = 300, 100, 100, 100, 100
convergence = 0.3
[/code]
Either case is valid with the repeat mechanism, but they didn't have to know about it. You don't have to teach the ways to do anything more advanced than that - an advanced user can figure it out for themselves.
------ Everything below this line is for advanced users only -------
Note that without the repeat mechanism, that second example looks ok but is actually an error since convergence wasn't repeated 5 times. Oops.
What if they do this:
[code]
[Key1]
key = q
type = cycle
x = 1, 2, 3, 4, 5
delay = 100
[/code]
At the moment delay isn't supported for type=cycle, so this is a bit contrived. But this syntax *is* valid - the delay applies to the key binding and is a single value, whereas in the transition example applies at the override level and has to be a list. Now, suppose in the future I move the implementation of delay into the override list - Without the repeat mechanism I've just broken everyone who used this syntax - oops :(
[quote="bo3b"][quote]And I'd really *really* hate to have to count how many times I've specified transition=100,100,100,100,100,100,100,100,100,100,100,100,100,100,100,100...[/quote]
Yeah, it's a pain for these things. But I want to step back and ask whether we are doing this for us, or for our end users?[/quote]
Both. The syntax is simple and makes things easier to add/remove/change elements. Repeating by default makes it easier to do this as they don't need to keep changing now many entries are in the transition= list just to add another x= entry.
A shaderhacker can learn this either way. What if someone who is not a shaderhacker wants to add an extra crosshair depth preset? Do they want to know that they also need to add an extra ", 100" to the end of the transition list as well? We didn't teach them either way, so the simpler syntax that uses the repeat mechanism in order to just work seems better for this case as well.
[quote]The full form syntax is much, much more clear, especially with formatting. When I'm trying to teach people about how to use stuff, having tweaky things based on commas, or having to focus upon a single closing comma is always trouble.[/quote]
So don't teach them about the commas at all - it's not really about commas (that's a minor implementation detail), it's about specifying that a particular setting is not set in one specific cycle (that is not changed at all), but is set in others - this is for advanced cases that most people won't need to know or care about. The common case that people do need to know about is simple.
[quote]
Conversely, I'm going to really hate to have to say, "Don't forget the closing comma if you want a blank list of entries, otherwise you'll accidentally get your first item duplicated." How is this different than "Don't forget that every element must have a semi-colon, including the last one."
[/quote]
No again - it is going to be very uncommon that someone would want a blank entry in a list, so it's not something that needs to be taught. What you need to say is "unlike Helix mod, lists don't end with a comma (or semicolon in the case of Helix mod)".
Even if someone does add a trailing comma without meaning to it's not going to matter very often. x, y, z, w, separation and convergence will still be set from an earlier cycle so the fact that it doesn't get applied again will only be noticed if something else has changed them in the meantime. If multiple things can change these values we are talking about an advanced use case already.
[quote]
Contrived example:
[code][Key5]
Key = tilde
Type = cycle
x = 0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 0.995
transition = 100,,,,,,33,
[/code]
Quick, which of the levels switches to 33?
[/quote]
No matter what syntax we use people aren't always going to align their commas, so I fail to see how counting six commas or six "100," is any different.
[quote][code][Key5]
Key = tilde
Type = cycle
x = 0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 0.995
transition = 100, 100, 100, 100, 100, 33, 33, 33, 33, 33, 33
[/code]
[/quote]Actually, that's wrong - the syntax you have used does not repeat entries (that only happens to the final value in the list). By omitting values in the transition list you are explicitly asking to NOT have a transition on those cycles at all, so it would be:
[code][Key5]
Key = tilde
Type = cycle
x = 0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 0.995
transition = 100, , , , , , 33, , , ,
[/code]
Transitions only occur on the first (100ms) and seventh (33ms) key press - all others will not have any transition.
[quote]Even more to the point- this is a super rare use case. 1/100 people are going to use this.[/quote]
Blanking out an entry is a super rare use case. Repeating an entry is something that 99% of people will use, probably without realising because it's just how it should behave by default.
Either case is valid with the repeat mechanism, but they didn't have to know about it. You don't have to teach the ways to do anything more advanced than that - an advanced user can figure it out for themselves.
------ Everything below this line is for advanced users only -------
Note that without the repeat mechanism, that second example looks ok but is actually an error since convergence wasn't repeated 5 times. Oops.
What if they do this:
[Key1]
key = q
type = cycle
x = 1, 2, 3, 4, 5
delay = 100
At the moment delay isn't supported for type=cycle, so this is a bit contrived. But this syntax *is* valid - the delay applies to the key binding and is a single value, whereas in the transition example applies at the override level and has to be a list. Now, suppose in the future I move the implementation of delay into the override list - Without the repeat mechanism I've just broken everyone who used this syntax - oops :(
bo3b said:
And I'd really *really* hate to have to count how many times I've specified transition=100,100,100,100,100,100,100,100,100,100,100,100,100,100,100,100...
Yeah, it's a pain for these things. But I want to step back and ask whether we are doing this for us, or for our end users?
Both. The syntax is simple and makes things easier to add/remove/change elements. Repeating by default makes it easier to do this as they don't need to keep changing now many entries are in the transition= list just to add another x= entry.
A shaderhacker can learn this either way. What if someone who is not a shaderhacker wants to add an extra crosshair depth preset? Do they want to know that they also need to add an extra ", 100" to the end of the transition list as well? We didn't teach them either way, so the simpler syntax that uses the repeat mechanism in order to just work seems better for this case as well.
The full form syntax is much, much more clear, especially with formatting. When I'm trying to teach people about how to use stuff, having tweaky things based on commas, or having to focus upon a single closing comma is always trouble.
So don't teach them about the commas at all - it's not really about commas (that's a minor implementation detail), it's about specifying that a particular setting is not set in one specific cycle (that is not changed at all), but is set in others - this is for advanced cases that most people won't need to know or care about. The common case that people do need to know about is simple.
Conversely, I'm going to really hate to have to say, "Don't forget the closing comma if you want a blank list of entries, otherwise you'll accidentally get your first item duplicated." How is this different than "Don't forget that every element must have a semi-colon, including the last one."
No again - it is going to be very uncommon that someone would want a blank entry in a list, so it's not something that needs to be taught. What you need to say is "unlike Helix mod, lists don't end with a comma (or semicolon in the case of Helix mod)".
Even if someone does add a trailing comma without meaning to it's not going to matter very often. x, y, z, w, separation and convergence will still be set from an earlier cycle so the fact that it doesn't get applied again will only be noticed if something else has changed them in the meantime. If multiple things can change these values we are talking about an advanced use case already.
No matter what syntax we use people aren't always going to align their commas, so I fail to see how counting six commas or six "100," is any different.
Actually, that's wrong - the syntax you have used does not repeat entries (that only happens to the final value in the list). By omitting values in the transition list you are explicitly asking to NOT have a transition on those cycles at all, so it would be:
Transitions only occur on the first (100ms) and seventh (33ms) key press - all others will not have any transition.
Even more to the point- this is a super rare use case. 1/100 people are going to use this.
Blanking out an entry is a super rare use case. Repeating an entry is something that 99% of people will use, probably without realising because it's just how it should behave by default.
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
Here's another point. If we don't auto-repeat lists and require them to all be the same length, why isn't this valid:
[code]
[Key1]
Key = tilde, tilde, tilde, tilde, tilde
type = cycle, cycle, cycle, cycle, cycle
x = 1, 2, 3, 4, 5
[/code]
It's obvious to us, but that's not the point. If we require that users to manually repeat some things in the section, than surely we should require them to manually repeat everything even though it does not make sense?
The whole point of the auto repeat mechanism is that users only need to manually repeat the things that matter to the cycle and everything else will do the correct thing whether they explicitly repeated them or not.
It's obvious to us, but that's not the point. If we require that users to manually repeat some things in the section, than surely we should require them to manually repeat everything even though it does not make sense?
The whole point of the auto repeat mechanism is that users only need to manually repeat the things that matter to the cycle and everything else will do the correct thing whether they explicitly repeated them or not.
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
OK. From my perspective, once you've defined a list, that is the clear indication that you are in list-mode, and that all follow on items should be in a list. I'm just telling you that a single entry does not say 'auto-repeat' to me, it says 'ambiguous'. First item only? All of them? Wrong syntax? I really don't think this is at all obvious for the modest savings of not having to write a list.
You keep saying that manually repeating things doesn't make sense, and I keep saying that not repeating items doesn't make sense, so I'd say we are at an impasse and we'll should just agree to disagree until end-users hit it. In general, if someone runs into something weird that costs them time, I want to try to smooth it over. Even if it makes no sense to me.
I have no problem with having features that only you use, that's great, and part of being open source. I can do things the way I think is more sensible, and so there is no harm.
The only problem here, and the reason I'm even arguing about it is because this also affects Flugan who has to implement these other variants.
Adding the convergence or separation or default other parameters to a Key list is also confusing the issue. The original Constants allows default constants, and it should also allow default convergence and separation so that they do not need to be added to lists like this.
OK. From my perspective, once you've defined a list, that is the clear indication that you are in list-mode, and that all follow on items should be in a list. I'm just telling you that a single entry does not say 'auto-repeat' to me, it says 'ambiguous'. First item only? All of them? Wrong syntax? I really don't think this is at all obvious for the modest savings of not having to write a list.
You keep saying that manually repeating things doesn't make sense, and I keep saying that not repeating items doesn't make sense, so I'd say we are at an impasse and we'll should just agree to disagree until end-users hit it. In general, if someone runs into something weird that costs them time, I want to try to smooth it over. Even if it makes no sense to me.
I have no problem with having features that only you use, that's great, and part of being open source. I can do things the way I think is more sensible, and so there is no harm.
The only problem here, and the reason I'm even arguing about it is because this also affects Flugan who has to implement these other variants.
Adding the convergence or separation or default other parameters to a Key list is also confusing the issue. The original Constants allows default constants, and it should also allow default convergence and separation so that they do not need to be added to lists like this.
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
[quote="bo3b"]You keep saying that manually repeating things doesn't make sense, and I keep saying that not repeating items doesn't make sense, so I'd say we are at an impasse and we'll should just agree to disagree until end-users hit it. In general, if someone runs into something weird that costs them time, I want to try to smooth it over. Even if it makes no sense to me.
I have no problem with having features that only you use, that's great, and part of being open source. I can do things the way I think is more sensible, and so there is no harm.
[/quote]ok
[quote]Adding the convergence or separation or default other parameters to a Key list is also confusing the issue.[/quote]Not really - In The Book of Unwritten Tales 2 I have a bunch of presets for scenes that require very specific separation, convergence and UI depth settings completely different to the rest of the game (plus some depth adjustments conditional on texture matching). Granted there I've been able to match textures in these scenes so it is automatic, but that is not always possible so key bindings allows this when it can't happen automatically.
for instance it can make sense to have several presets that set both convergence and HUD depth to suit e.g. cinematics with a medium convergence and subtitles at 50% depth vs gameplay with low convergence and crosshair at 99.5% depth.
[quote]The original Constants allows default constants, and it should also allow default convergence and separation so that they do not need to be added to lists like this.
[/quote]Agreed, and I have some work in progress code to do this - I've just got a bit side tracked by other features that seemed more important.
bo3b said:You keep saying that manually repeating things doesn't make sense, and I keep saying that not repeating items doesn't make sense, so I'd say we are at an impasse and we'll should just agree to disagree until end-users hit it. In general, if someone runs into something weird that costs them time, I want to try to smooth it over. Even if it makes no sense to me.
I have no problem with having features that only you use, that's great, and part of being open source. I can do things the way I think is more sensible, and so there is no harm.
ok
Adding the convergence or separation or default other parameters to a Key list is also confusing the issue.
Not really - In The Book of Unwritten Tales 2 I have a bunch of presets for scenes that require very specific separation, convergence and UI depth settings completely different to the rest of the game (plus some depth adjustments conditional on texture matching). Granted there I've been able to match textures in these scenes so it is automatic, but that is not always possible so key bindings allows this when it can't happen automatically.
for instance it can make sense to have several presets that set both convergence and HUD depth to suit e.g. cinematics with a medium convergence and subtitles at 50% depth vs gameplay with low convergence and crosshair at 99.5% depth.
The original Constants allows default constants, and it should also allow default convergence and separation so that they do not need to be added to lists like this.
Agreed, and I have some work in progress code to do this - I've just got a bit side tracked by other features that seemed more important.
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've just pushed up support for using cosine interpolation in transitions instead of linear interpolation. Cosine interpolation can look smoother than linear interpolation as it starts slow, accelerates towards the middle, then decelerates to slow down by the end of the transition.
In my testing in Far Cry 4 it looked significantly better for UI depth adjustments (even fairly fast ones), and also looked slightly better for aiming convergence overrides, though that was less noticeable due to the simultaneous change in perspective. Depending on the game's animations it may or may not be better, but it is worth trying. The syntax is:
[code]
[Key]
Key = RBUTTON
Type = hold
Convergence = 0.1
transition = 300
transition_type = cosine
release_transition = 400
release_transition_type = cosine
[/code]
This works will all key binding types, including type=cycle:
[code]
[Key2]
Key = tilde
Type = cycle
x = 0.0, 0.2, 0.4, 0.6, 0.8, 0.995
transition = 100
transition_type = cosine
[/code]
I've just pushed up support for using cosine interpolation in transitions instead of linear interpolation. Cosine interpolation can look smoother than linear interpolation as it starts slow, accelerates towards the middle, then decelerates to slow down by the end of the transition.
In my testing in Far Cry 4 it looked significantly better for UI depth adjustments (even fairly fast ones), and also looked slightly better for aiming convergence overrides, though that was less noticeable due to the simultaneous change in perspective. Depending on the game's animations it may or may not be better, but it is worth trying. The syntax is:
[quote="DarkStarSword"][quote]The original Constants allows default constants, and it should also allow default convergence and separation so that they do not need to be added to lists like this.
[/quote]Agreed, and I have some work in progress code to do this - I've just got a bit side tracked by other features that seemed more important.[/quote]
I haven't been able to get this to work reliably yet - it seemed to work OK in Lichdom, but Far Cry 4 was a no go. I think that the manner and timing of how the game creates it's window and enables full-screen mode can lose the custom settings. I tried setting them on the first draw call, but even that was too early.
I think I might be able to get it to work if I can determine when the window is switched into fullscreen, but I think that is part of DXGI?
The original Constants allows default constants, and it should also allow default convergence and separation so that they do not need to be added to lists like this.
Agreed, and I have some work in progress code to do this - I've just got a bit side tracked by other features that seemed more important.
I haven't been able to get this to work reliably yet - it seemed to work OK in Lichdom, but Far Cry 4 was a no go. I think that the manner and timing of how the game creates it's window and enables full-screen mode can lose the custom settings. I tried setting them on the first draw call, but even that was too early.
I think I might be able to get it to work if I can determine when the window is switched into fullscreen, but I think that is part of DXGI?
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
Which in this syntax would be:
3Dmigoto can handle both, but I haven't checked whether this is true of every setting. For type=cycle I explicitly skip over whitespace around commas in the list.
Right now in the code it has to have two commas at the end of the list to explicitly make the final entry blank, as the final comma is optional and will be ignored if present. This is really just an artefact of the parsing routine though and I could change it (but it seemed reasonable to me at the time since the double comma is very explicit so I left it as is) - does anyone have a strong opinion on this one way or the other?
Indeed. I used a helper class to parse each list - you can take a look at KeyOverrideCycle::ParseIniSection() and the KeyOverrideCycleParam class to see how I did this.
It does loop from last to first, though I'm not sure I would use the term 'biggest' to describe it - surely the magnitude a given value changes depends entirely on what values have been defined and is not inherent to the code? In my Legends of Aethereus example above the 'biggest' change would be the second key press from 0.95 to 0.5, and not the first, which only goes from 0.85 to 0.95.
To be clear - the numeric order of the values is not relevant to the cycle order - the order is simply left to right (In Helix mod the numeric order of the presets WAS the cycle order, and it was a royal pain as a result).
The first key press will select the first entry in the list - I don't want to do anything fancy here as it would just be confusing. If someone needs value set on the first key press to be 0.4 instead of 0, then they just make the first value 0.4. Default values are still read from the [Constants] section and are independent of this list.
I'm pretty happy with it - unless someone has a major objection (which really should have been raised earlier while we were discussing syntax proposals and not now that I've implemented it) I say we go with it.
I am happy to change the requirement for two commas at the end of the list to one for a blank entry if people think it's better, but unless I hear back I have a slight preference to leaving it as a double comma.
I agree it's weird, but I did test some cases like that and they work as expected:
Was interpreted as:
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
Man I wish C++ supported Duck typing - it would have made the class hierarchy a lot simpler.
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
Both test cases work as intended. Pretty stable might be some bugs left. I have not tested the delay function.
Edit: It does not require double comma at the end as the last void entry is repeated. Using FLT_MAX to represent missing values.
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
As a convenience for more saavy users, I think it's fine, but for any examples that we give, and documentation in the .ini file I think they should be fully spelled out. The fewer 'gotchas' the better. The examples we have so far are all contrived, right? As a general author thought, I recommend that we should avoid adding stuff that doesn't have a clear use, because it always adds complexity to the code. We need to keep it simple, and clear.
Along that lines- how do we handle errors? What is the mechanism for the user to know that something went wrong? The biggest knock on HelixMod is the silent failures for syntax errors including stuff like missing semicolons. Highly annoying for everyone I'm sure.
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
And I'd really *really* hate to have to count how many times I've specified transition=100,100,100,100,100,100,100,100,100,100,100,100,100,100,100,100...
This is something I need to add (for a bunch of parameters, not just this one) - it seems that the boop error tone is good, because it prompts people to look at the log file to find out what went wrong. One consideration is that we don't currently have a way to detect if a bad section or keyword has been used (e.g. transformation=100 instead of transition=100, or [TexutreOverride1], etc), so there are some cases that will still fail silently even if we can detect parse errors.
Ok, in that case I'll change 3Dmigoto to use one comma - I think defining this unambiguously now and being consistent between the two wrappers is more important than worrying about how many commas we need.
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
transition=Umbrella
will fail in some matter in function stof() producing an incorrect value where no correct value exists.
The apparent case sensitivity of ini files is another issue. Might not be a problem if using a custom parser.
You really can't test every upper/lowercase variant of a variable.
I just find it too easy to break stuff. My assembler is not very verbose when it comes to errors it really only supports compiling unchanged shahders back into cbo. Have not gotten around to make it more robust to human changes. It won't assemble Helix Bioshock Infinite shaders due to at least some naming conflicts.
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
This change is done, so now if someone wants to suppress the default repeating behavior they would do this:
Now I've actually looked at a concrete example of this I've decided that I prefer it this way - the trailing comma makes it clear that transition is a list, and therefore pretty clear that only the first element is set.
If the comma was not there the transition setting would not look like one that applies to the whole [Key5] section (just like Key=tilde and Type=cycle) and thanks to the repeating behaviour the user doesn't need to care that under the hood it is still a list and it would behave as expected.
Thanks for changing my mind Flugan :)
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 really think that this auto repeat mechanism, either with or without commas is a mistake.
Look at the last 5 posts here- where we are talking about whether a single comma makes it more clear that it repeats or not. I humbly suggest that if our syntax depends upon a single comma, that is a poor syntax. Yes, comma at the end of a line in Python- blargh.
Yeah, it's a pain for these things. But I want to step back and ask whether we are doing this for us, or for our end users?
The full form syntax is much, much more clear, especially with formatting. When I'm trying to teach people about how to use stuff, having tweaky things based on commas, or having to focus upon a single closing comma is always trouble.
Conversely, I'm going to really hate to have to say, "Don't forget the closing comma if you want a blank list of entries, otherwise you'll accidentally get your first item duplicated." How is this different than "Don't forget that every element must have a semi-colon, including the last one."
Contrived example:
Quick, which of the levels switches to 33?
Why not stay simple, clear, verbose? I'm not at all interested in saving keystrokes at the expense of clarity, ever.
Even more to the point- this is a super rare use case. 1/100 people are going to use this.
I'm not going to make any demands one way or the other, because I defer to whoever is implementing it as much as possible. But I will say that building mechanisms that are rarely, if ever, used adds unnecessary complexity both for the code and the user.
It's fine if you want to use this special syntax, but I really want to avoid making it any sort of default. Our users can learn it, hell, they learned the Helix syntax. But we can expand our group of hackers by avoiding this sort of featurism and keeping it vanilla.
Do we have any actual use case for this level of complexity?
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
or they might do this:
Either case is valid with the repeat mechanism, but they didn't have to know about it. You don't have to teach the ways to do anything more advanced than that - an advanced user can figure it out for themselves.
------ Everything below this line is for advanced users only -------
Note that without the repeat mechanism, that second example looks ok but is actually an error since convergence wasn't repeated 5 times. Oops.
What if they do this:
At the moment delay isn't supported for type=cycle, so this is a bit contrived. But this syntax *is* valid - the delay applies to the key binding and is a single value, whereas in the transition example applies at the override level and has to be a list. Now, suppose in the future I move the implementation of delay into the override list - Without the repeat mechanism I've just broken everyone who used this syntax - oops :(
Both. The syntax is simple and makes things easier to add/remove/change elements. Repeating by default makes it easier to do this as they don't need to keep changing now many entries are in the transition= list just to add another x= entry.
A shaderhacker can learn this either way. What if someone who is not a shaderhacker wants to add an extra crosshair depth preset? Do they want to know that they also need to add an extra ", 100" to the end of the transition list as well? We didn't teach them either way, so the simpler syntax that uses the repeat mechanism in order to just work seems better for this case as well.
So don't teach them about the commas at all - it's not really about commas (that's a minor implementation detail), it's about specifying that a particular setting is not set in one specific cycle (that is not changed at all), but is set in others - this is for advanced cases that most people won't need to know or care about. The common case that people do need to know about is simple.
No again - it is going to be very uncommon that someone would want a blank entry in a list, so it's not something that needs to be taught. What you need to say is "unlike Helix mod, lists don't end with a comma (or semicolon in the case of Helix mod)".
Even if someone does add a trailing comma without meaning to it's not going to matter very often. x, y, z, w, separation and convergence will still be set from an earlier cycle so the fact that it doesn't get applied again will only be noticed if something else has changed them in the meantime. If multiple things can change these values we are talking about an advanced use case already.
No matter what syntax we use people aren't always going to align their commas, so I fail to see how counting six commas or six "100," is any different.
Actually, that's wrong - the syntax you have used does not repeat entries (that only happens to the final value in the list). By omitting values in the transition list you are explicitly asking to NOT have a transition on those cycles at all, so it would be:
Transitions only occur on the first (100ms) and seventh (33ms) key press - all others will not have any transition.
Blanking out an entry is a super rare use case. Repeating an entry is something that 99% of people will use, probably without realising because it's just how it should behave by default.
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
It's obvious to us, but that's not the point. If we require that users to manually repeat some things in the section, than surely we should require them to manually repeat everything even though it does not make sense?
The whole point of the auto repeat mechanism is that users only need to manually repeat the things that matter to the cycle and everything else will do the correct thing whether they explicitly repeated them or not.
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
You keep saying that manually repeating things doesn't make sense, and I keep saying that not repeating items doesn't make sense, so I'd say we are at an impasse and we'll should just agree to disagree until end-users hit it. In general, if someone runs into something weird that costs them time, I want to try to smooth it over. Even if it makes no sense to me.
I have no problem with having features that only you use, that's great, and part of being open source. I can do things the way I think is more sensible, and so there is no harm.
The only problem here, and the reason I'm even arguing about it is because this also affects Flugan who has to implement these other variants.
Adding the convergence or separation or default other parameters to a Key list is also confusing the issue. The original Constants allows default constants, and it should also allow default convergence and separation so that they do not need to be added to lists like this.
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
Not really - In The Book of Unwritten Tales 2 I have a bunch of presets for scenes that require very specific separation, convergence and UI depth settings completely different to the rest of the game (plus some depth adjustments conditional on texture matching). Granted there I've been able to match textures in these scenes so it is automatic, but that is not always possible so key bindings allows this when it can't happen automatically.
for instance it can make sense to have several presets that set both convergence and HUD depth to suit e.g. cinematics with a medium convergence and subtitles at 50% depth vs gameplay with low convergence and crosshair at 99.5% depth.
Agreed, and I have some work in progress code to do this - I've just got a bit side tracked by other features that seemed more important.
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
In my testing in Far Cry 4 it looked significantly better for UI depth adjustments (even fairly fast ones), and also looked slightly better for aiming convergence overrides, though that was less noticeable due to the simultaneous change in perspective. Depending on the game's animations it may or may not be better, but it is worth trying. The syntax is:
This works will all key binding types, including type=cycle:
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
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 haven't been able to get this to work reliably yet - it seemed to work OK in Lichdom, but Far Cry 4 was a no go. I think that the manner and timing of how the game creates it's window and enables full-screen mode can lose the custom settings. I tried setting them on the first draw call, but even that was too early.
I think I might be able to get it to work if I can determine when the window is switched into fullscreen, but I think that is part of DXGI?
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