tweakable constants
category: code [glöplog]
A friend (hi Flavien) sent me this, a very helpful trick for many people here, specially those hardcoding doing 4k intros (yey!!).
http://www.gamedev.net/reference/snippets/features/tweakVal/
It's some nice macros to keep hardcoding all those magic constants in your intros while still being able to modify them on the fly without recompiling nor relaunching your application. Sounds impossible, hardcoding constants right there in the source code as usual, yet modifying then on the fly, right? Tweakable Constants is a clever technique I didn't know about.
Example (from the guys linker above):
Now change the source code, but do NOT recompile, et voila, see the program printf-ing the new values.
http://www.gamedev.net/reference/snippets/features/tweakVal/
It's some nice macros to keep hardcoding all those magic constants in your intros while still being able to modify them on the fly without recompiling nor relaunching your application. Sounds impossible, hardcoding constants right there in the source code as usual, yet modifying then on the fly, right? Tweakable Constants is a clever technique I didn't know about.
Example (from the guys linker above):
Code:
#include <windows.h>
#include <stdio.h>
#include <time.h>
int main( int argc, char *argv[] )
{
while (1)
{
int val = _TV( 50 ), val2 = _TV( 19 );
float fval = _TV( 3.14152f );
printf("value is %d, %d, valuef is %f\n", val, val2, fval );
Sleep( 1000 );
// call this once per frame (or whatever interval you want to
// check for updates)
#ifndef RELEASE_PROD
ReloadChangedTweakableValues();
#endif
}
}
Now change the source code, but do NOT recompile, et voila, see the program printf-ing the new values.
Well this is certainly rather useful! I'll have to use this in the next project :)
i don't get it. so you put a _TV(50) in your code which is a value that is actually loaded from some tweak-file, which infers that _TV(50) could evaluate to 99 ??
That looks nice! Thanks for posting.
macaw: as far as i understood, the source becomes the tweak-file instead. i.e. you change the source, and the _TV() macro, on reload, parses the original source if you changed it since. useful if you want to cut down the time of syncing back the values in the source.
besides, hugi already had an article about this ;)
besides, hugi already had an article about this ;)
yes, the source itself becomes the config-file. So you edit the code as usual but simply don't need to recompile. At release time, _TV() gets defined to nothing, and the intro is ready for crinkler.
Gargaj, awesome. The _TV() macro is less intrusive than all those WHDD thou. I'm still amazed by the power of macros, templates and all the black magic one can do in C(++).
Gargaj, awesome. The _TV() macro is less intrusive than all those WHDD thou. I'm still amazed by the power of macros, templates and all the black magic one can do in C(++).
Indeed, there are many ways to make code completely unreadable using macro's in C++ :)
This is what I do all the time:
Have 5 independent variables (3 mouse, 2 arrow keys) to change whatever needs changing on the fly. When I press esc the values are copied into the copy/paste buffer, and then I paste these magic values into the code.
And for the shaders I just update and reload them on the fly (most of the code is shaderwork these days anyway).
If I do all this I have to do a recompile once every 2 minutes max.
Have 5 independent variables (3 mouse, 2 arrow keys) to change whatever needs changing on the fly. When I press esc the values are copied into the copy/paste buffer, and then I paste these magic values into the code.
And for the shaders I just update and reload them on the fly (most of the code is shaderwork these days anyway).
If I do all this I have to do a recompile once every 2 minutes max.
trc: that must be why bjarne was bitching about it back in the day ;).
navis: sometimes im so glad i have a tool.. :)
I was honestly wondering, with tools:
lets say you have a scene with a good ol' single spinning cube. How long would it take to make its color a function of time, the function defined outside the shader as a combination of sin/cos and a float[] lookup table.
How would you do it, is it by dragging dropping boxes on a canvas, writing C code or combination? would it take 20 seconds (assume that you know all about the function) 1 minute or 5?
lets say you have a scene with a good ol' single spinning cube. How long would it take to make its color a function of time, the function defined outside the shader as a combination of sin/cos and a float[] lookup table.
How would you do it, is it by dragging dropping boxes on a canvas, writing C code or combination? would it take 20 seconds (assume that you know all about the function) 1 minute or 5?
iq, did you actually READ that article? THROUGHOUT? :D
Quote:
How long would it take to make its color a function of time, the function defined outside the shader as a combination of sin/cos and a float[] lookup table.
The question isn't "how", but "why". Why would I insist on something like that if I can just draw a spline instead which would probably look the same?
just code it inside the tool. thanks to one of chaos's hobbies being compiler construction, wz4 allows you to script animations :)
(wz3 did as well, but it was still based on boxes. that was originally thought to be more artist-friendly, but a simple expression is easier to parse when written as text not only by coders and compilers but also by artists. so we switched to text, and there was much rejoicing).
(wz3 did as well, but it was still based on boxes. that was originally thought to be more artist-friendly, but a simple expression is easier to parse when written as text not only by coders and compilers but also by artists. so we switched to text, and there was much rejoicing).
also, it's not like adding a script language like lua or angelscript is impossible :)
A problem i see with _TV macro is that you still need to find the 'right' value by dichotomy.
Navis: I did something a bit similar with a dual analog joypad (4 variables)... then I to memorized the 4 values and if success replaced them in the code. The copy/paste trick is neat :)
Most variables are best tweaked with a log curve.
Navis: I did something a bit similar with a dual analog joypad (4 variables)... then I to memorized the 4 values and if success replaced them in the code. The copy/paste trick is neat :)
Most variables are best tweaked with a log curve.
A problem i see with _TV macro is that you still need to find the 'right' value by dichotomy.
Navis: I did something a bit similar with a dual analog joypad (4 variables)... then I to memorized the 4 values and if success replaced them in the code. The copy/paste trick is neat :)
Most variables are best tweaked with a log curve.
Navis: I did something a bit similar with a dual analog joypad (4 variables)... then I to memorized the 4 values and if success replaced them in the code. The copy/paste trick is neat :)
Most variables are best tweaked with a log curve.
>The question isn't "how", but "why". Why would I insist on something like >that if I can just draw a spline instead which would probably look the same?
Not necessarily. It could be a function that is procedurally evolving, for example over noise or depends on some other events (proximity to other objects etc.). In this case, is it faster to just write the function in C/lua/whatever or you can do it in some other way and do it faster?
I'm still trying to understand what a tool is and what it can do for you.
Not necessarily. It could be a function that is procedurally evolving, for example over noise or depends on some other events (proximity to other objects etc.). In this case, is it faster to just write the function in C/lua/whatever or you can do it in some other way and do it faster?
I'm still trying to understand what a tool is and what it can do for you.
navis:
there are a few options. we've had angelscript in the tool for about 18 months. you can attach a piece of script as a modifier to any property/node. however i rarely if ever do that. id rather key it and/or use a couple of modifiers (noise/sin) chained together. or, i could fall back to writing a piece of code - if it's a common function then it's probably useful to have as a modifier with some exposed properties to tweak, and it doesnt take very long to add it to the demoengine (minutes).
but even if it is slightly less efficient to do it than the fastest hardcoded solution, id rather take the hit of a slightly longer path to do the odd hardcoded movement but gain the benefit of actually being able to move things around with manipulators.. :)
there are a few options. we've had angelscript in the tool for about 18 months. you can attach a piece of script as a modifier to any property/node. however i rarely if ever do that. id rather key it and/or use a couple of modifiers (noise/sin) chained together. or, i could fall back to writing a piece of code - if it's a common function then it's probably useful to have as a modifier with some exposed properties to tweak, and it doesnt take very long to add it to the demoengine (minutes).
but even if it is slightly less efficient to do it than the fastest hardcoded solution, id rather take the hit of a slightly longer path to do the odd hardcoded movement but gain the benefit of actually being able to move things around with manipulators.. :)
Imho, it is much faster for your development to use realtime update using mouse or pad rather than the _TV macro. First of all, these macros are fugly.
Second, as ponce notes you have to try quite a few values by means of dichotomy before you settle for the best one. But if you can have a varying variable you can get there much faster, no need to switch windows back and forth, no need to type anything (meaning you can just relax back and not have to look at the keyboard in the darkness).
Second, as ponce notes you have to try quite a few values by means of dichotomy before you settle for the best one. But if you can have a varying variable you can get there much faster, no need to switch windows back and forth, no need to type anything (meaning you can just relax back and not have to look at the keyboard in the darkness).
I'm under the impression that what we need is also to tweak concurrently 2 (or more) variables to find the desired "sweet spot" in parameter and _TW does really help here.
Like tweaking cutoff and resonance at the same time for a filter.
Like tweaking cutoff and resonance at the same time for a filter.
smash:
so if this function is (lets say) color=vec4 (sin(time))+Pos_Cube2; <- where color is the color of cube1 and Pos_Cube2 the position of another cube, what do you do? Is there a provision for that in the tool, or it has to be written in script or C.
My understanding is that both happen: you have the tool for cameras/moving things around and animate them but use C for slightly more complex things. Only I can't see where the line is drawn.
so if this function is (lets say) color=vec4 (sin(time))+Pos_Cube2; <- where color is the color of cube1 and Pos_Cube2 the position of another cube, what do you do? Is there a provision for that in the tool, or it has to be written in script or C.
My understanding is that both happen: you have the tool for cameras/moving things around and animate them but use C for slightly more complex things. Only I can't see where the line is drawn.
Navis: (Shameless plug) It's even faster to use GNU Rocket!!! That way you define the "variables" (or, tracks as they really are) once in the code, and edit any one at any time without any recompiling to switch tweak-parameter, or any need to paste in the values into the source code. You should really use it, there's no reason not to ;)
navis, feature comparision between tools is not really interesting. the interesting part is if you can do impressive stuff, which i think smash has proven.
(i.e. "it's not what the tool can do for you, but what you can do with the tool" :-))
(i.e. "it's not what the tool can do for you, but what you can do with the tool" :-))
Not strictly a demo tool, but I really like the way quartz composer handles this stuff. It's "drag boxes around screen" based, but for tweaking parameters there's a few really useful boxes:
- LFO. Gives you your basic sin/pulse/noise/etc outputs
- Keyframe based spline editor for a custom curve
- Programmable patch (javascript in this case) for anything else
- Various input device patches (mouse & HID are the main ones, but there's plugins for stuff like wiimotes and multitouch surfaces if you want something fancier)
- Maths expression patch. Kind of like the programmable patch, but purely maths based, i reckon this is pretty much perfect for combining the inputs. You just write something like "mouseX + sin(time)"
All of that would be overkill perhaps for a demo tool, but i reckon the maths patch and an input device patch or two would be a pretty major benefit.
- LFO. Gives you your basic sin/pulse/noise/etc outputs
- Keyframe based spline editor for a custom curve
- Programmable patch (javascript in this case) for anything else
- Various input device patches (mouse & HID are the main ones, but there's plugins for stuff like wiimotes and multitouch surfaces if you want something fancier)
- Maths expression patch. Kind of like the programmable patch, but purely maths based, i reckon this is pretty much perfect for combining the inputs. You just write something like "mouseX + sin(time)"
All of that would be overkill perhaps for a demo tool, but i reckon the maths patch and an input device patch or two would be a pretty major benefit.
