Hey, new here just small questions.
Moderators: BTT, andy55, b.dwall, juxtiphi
Hey, new here just small questions.
Hey everyone, I just bought G-Force Platinum a couple days ago and I must say it's awesome and the screensaver is all i use now i even lowered the time it takes for the screensaver to start lol,anyway my questions are is there are other programs that kinda go hand in hand with g-force to improve the plug-in even more? or is there plug-ins to add more visuals to it? But this was differently worth the buy and it was a good job making it as well.
Get all the extras including the latest from JayPro at http://www.icubed.com/~chkman/GForce/
And scripts to run them as well.
Welcome to G-Force!
And scripts to run them as well.
Welcome to G-Force!
You're welcome. I hope you enjoy them. I make a few, the ones in the chkman folders. Most were done by others as indicated by the folder names (look under the 'extras' folders).
I do like my colormaps, the rest of my stuff is so-so. Other people have done some really great flowfields, such as Rovastar and JayPro, to name two. Combined with my colors, that's what I'm talking about.
I do like my colormaps, the rest of my stuff is so-so. Other people have done some really great flowfields, such as Rovastar and JayPro, to name two. Combined with my colors, that's what I'm talking about.
I just added 16 'lost' colormaps and re-did the scripts last nite.
http://www.icubed.com/~chkman/GForce/
JayPro: no reply on the issue of compile errors!?!?!?!?!???
http://www.icubed.com/~chkman/GForce/
JayPro: no reply on the issue of compile errors!?!?!?!?!???
-
JayPro
- Posts: 738
- Joined: Sat May 01, 2004 10:51 pm
- Location: Huntington Station, Long Island, New York
Well...
First of all, I'm still using v3.0.1 because of issues I've been encountering with how the new VectorC engine makes a lot of configs bundled in my copy (not all of them mine BTW) turn out.
Maybe these suggestions, based on what I've been able to make of the updated code, can be of help.
Instead of flor>>>floor
" " " " sgn>>>>>sign
" " " " clip >>>>>clamp.
I *did* find out that using the outdated funcs in the left in 3.1> and replacing them with the others as shown above can be of help.
Another issue, which I still am confused on---and I'm asking for pro advice here---is the use of B and C and D variables.
This also, BTW, may be of help in making my Flows work better.
Basic question: Do I now use C vars when in the old language B ones would be proper?
I'm confused and hope that any explanation would help here.
First of all, I'm still using v3.0.1 because of issues I've been encountering with how the new VectorC engine makes a lot of configs bundled in my copy (not all of them mine BTW) turn out.
Maybe these suggestions, based on what I've been able to make of the updated code, can be of help.
Instead of flor>>>floor
" " " " sgn>>>>>sign
" " " " clip >>>>>clamp.
I *did* find out that using the outdated funcs in the left in 3.1> and replacing them with the others as shown above can be of help.
Another issue, which I still am confused on---and I'm asking for pro advice here---is the use of B and C and D variables.
This also, BTW, may be of help in making my Flows work better.
Basic question: Do I now use C vars when in the old language B ones would be proper?
I'm confused and hope that any explanation would help here.
"God is syntax."
Well, I'm hardly a pro but I'll throw some advice at ya anyway.
But 1st, how exactly did changing to the updated functions help? I thought G-Force was supposed to automatically substitute the new for the old when it encountered them?
But back to my so called advice, I didn't read anything about the use of variables being any different. A vars are evaluated once and remain the same for the life of the config. A0 = "rnd(1)" might give A0 = .5 which would stay .5 as long as the wave or colormap is on the screen (unless you hit the U key).
B vars are evaluated at the beginning of each frame. For example, B0="rnd(1)" might give B0 a value of .75 which will remain .75 thru out that frame. So in a wave B0 * s will be .75 * s for the whole of the wave (the value of s changing for 0 to 1). For a colormap B0 * i will be .75 * i for every color in the pallet. Next frame B0 might be .5 and likewise be .5 * s or .5 * i for that frame.
Now using C0="rnd(1)" in a wave could give you .25 * s for s=1/256 then .8 * s when s=2/256 and .1 * s when s = 3/256. (s goes from 0 to 1 in 256 increments). In other words the C0*s could be all over the place. Confused yet?
Now in flowfields, I'm not sure if you can use B or C vars. If you can and do use B vars they would have to be the same as A vars because basically there is only one 'frame' of calculation. While Cs are used in waves and colors they apply to something linear - the time of the wave sample or the pallete register number. But in a flow you have X changing and Y changing thru out the calculation. That's where the D vars come in. It will recalculate for each change in X as well as Y.
So unless I've totally missed the boat, A, B and C vars for waves and colors. Only A and D vars for flows and unions.
What I've seen in some configs (not naming names) are things like B0 = "sin(i)" or B0 = "fft(s)" which simply don't fly. i and s change thru out the frame but B0 or any B var doesn't. You have to use a C var so that it can change as i or s changes. Now, B0 = sin(t) is okay because t will change from from frame to frame. I don't think t has much time to change during a frame so C0="sin(t)" is no better than B0="sin(t)". But again throw in i or s, C0="sin(t)*s" will change thru the frame while B0="sin(t)*s" will not change. And I'm not sure what s is at the beginning of a frame, probably zero.
And again for flows and unions A vars for something constant like the diameter of the center circle or size of a square but D vars for everything else. For a small 800 x 600 display it must calculate every D var and both srcX and srcY (or srcR and srcT) for each pixel, 800x600 = 480,000 times. But then it's done untill it starts the next flowfield. Waves and colors have much less per frame but can go what? 30? frames per second.
You should upgrage to at least 3.1 because 1. it does calculate the flowfields faster and 2. it displays the compile error messages. The missing ) or misspelled function etc. In the older versions if you type sqtr instead of sqrt you will just get a zero for that part of the expression. Nowadays you will be warned. I do miss that incremental number thing but I think I have finally figured out how to use multiplication instead.
And the other good thing is 3. the new functions like <,> and Min, max etc.
Check out my colormap chk_Four51a in V it has +(float)(i>.9)*2. Keeps the wave bright even if the rest of the colormap gets dark.
That wore me out, I think I'll watch some G-Force and get some sleep.
But 1st, how exactly did changing to the updated functions help? I thought G-Force was supposed to automatically substitute the new for the old when it encountered them?
But back to my so called advice, I didn't read anything about the use of variables being any different. A vars are evaluated once and remain the same for the life of the config. A0 = "rnd(1)" might give A0 = .5 which would stay .5 as long as the wave or colormap is on the screen (unless you hit the U key).
B vars are evaluated at the beginning of each frame. For example, B0="rnd(1)" might give B0 a value of .75 which will remain .75 thru out that frame. So in a wave B0 * s will be .75 * s for the whole of the wave (the value of s changing for 0 to 1). For a colormap B0 * i will be .75 * i for every color in the pallet. Next frame B0 might be .5 and likewise be .5 * s or .5 * i for that frame.
Now using C0="rnd(1)" in a wave could give you .25 * s for s=1/256 then .8 * s when s=2/256 and .1 * s when s = 3/256. (s goes from 0 to 1 in 256 increments). In other words the C0*s could be all over the place. Confused yet?
Now in flowfields, I'm not sure if you can use B or C vars. If you can and do use B vars they would have to be the same as A vars because basically there is only one 'frame' of calculation. While Cs are used in waves and colors they apply to something linear - the time of the wave sample or the pallete register number. But in a flow you have X changing and Y changing thru out the calculation. That's where the D vars come in. It will recalculate for each change in X as well as Y.
So unless I've totally missed the boat, A, B and C vars for waves and colors. Only A and D vars for flows and unions.
What I've seen in some configs (not naming names) are things like B0 = "sin(i)" or B0 = "fft(s)" which simply don't fly. i and s change thru out the frame but B0 or any B var doesn't. You have to use a C var so that it can change as i or s changes. Now, B0 = sin(t) is okay because t will change from from frame to frame. I don't think t has much time to change during a frame so C0="sin(t)" is no better than B0="sin(t)". But again throw in i or s, C0="sin(t)*s" will change thru the frame while B0="sin(t)*s" will not change. And I'm not sure what s is at the beginning of a frame, probably zero.
And again for flows and unions A vars for something constant like the diameter of the center circle or size of a square but D vars for everything else. For a small 800 x 600 display it must calculate every D var and both srcX and srcY (or srcR and srcT) for each pixel, 800x600 = 480,000 times. But then it's done untill it starts the next flowfield. Waves and colors have much less per frame but can go what? 30? frames per second.
You should upgrage to at least 3.1 because 1. it does calculate the flowfields faster and 2. it displays the compile error messages. The missing ) or misspelled function etc. In the older versions if you type sqtr instead of sqrt you will just get a zero for that part of the expression. Nowadays you will be warned. I do miss that incremental number thing but I think I have finally figured out how to use multiplication instead.
And the other good thing is 3. the new functions like <,> and Min, max etc.
Check out my colormap chk_Four51a in V it has +(float)(i>.9)*2. Keeps the wave bright even if the rest of the colormap gets dark.
That wore me out, I think I'll watch some G-Force and get some sleep.
Yep, Alan, you nailed it all!chkman wrote:
Now in flowfields, I'm not sure if you can use B or C vars. If you can and do use B vars they would have to be the same as A vars because basically there is only one 'frame' of calculation. While Cs are used in waves and colors they apply to something linear - the time of the wave sample or the pallete register number. But in a flow you have X changing and Y changing thru out the calculation. That's where the D vars come in. It will recalculate for each change in X as well as Y.
So unless I've totally missed the boat, A, B and C vars for waves and colors. Only A and D vars for flows and unions.
A vars are in all config types and are evaluated once (when the config "starts").
B vars are in WaveShapes and ColorMaps and are evalauted at the start of every frame (note for WaveShapes where NUM > 1, they're evalaued once per NUM).
C vars are in WaveShapes and ColorMaps and are evaluated for every value of s (for WaveShapes, i for ColorMaps). Like Alan said, this is why you should never expect to see an s, i, r, theta, x, or y in a A or B var.
D vars are in FlowFields and FlowField Unions and are basically C vars except that in FlowFields and FlowField Unions, there is no s or ii (only x, y, r, and theta). I could have used 'C' vars in these two config types, but I just wanted to denote that they were n/a for s and i.
Andy