Archive: Testing Needed


22nd January 2006 07:20 UTC

Testing Needed
This is a test for fps independancy, musical influence, and interactivity. For those who have seen my latest pack, reincarnation, this preset is a simpler version of Zenith.

I've finally had some time to work on AVS, but decided that for my next pack, I'm going to lay down a basic guideline and structure that I can use at different times for the presets. However, since I wasn't sure where to start: Credits to Pak-9 and Tuggummi for some code and ideas which this code was modeled from. This will probably be changed many many times again before it becomes final (even though the preset name may be deceiving :p), but I felt it best to credit you guys for it anyway.

The main reason I posted this is that I need some help, advice, critiques, et cetera. I'm only concerned with the very first scope, but I'm not really sure if this even works all that well or if I've done everything, or anything, correctly (even though I'm sure there is no "right" way). I guess I just want to make sure that it all works. I know the code for the sound data is ugly at best, but does it work sufficiently? Anyway so, if I can get some feedback I would be very grateful.

Thanks in advance!


22nd January 2006 13:37 UTC

Well the fps fix seems to be working like it should (which im glad you finally decided to add to your presets ;)), but im not sure what else kind of feedback you're looking for it. The control keys worked too.

Well im not much of a technical assistant so i can't do anything beyond confirming that your preset works :p


23rd January 2006 07:15 UTC

Everything works really fine. Nothing to say means nothing's wrong :p

This preset is great and cool, it's respond to music very well..

and yeah, I like it.. much..


23rd January 2006 20:03 UTC

x5=x4/(1+(2+z4)/2)*-1;
y5=y4/(1+(2+z4)/2)*-1;

i dunno where to start on what is wrong with that :P

here is how i would have done it:

opt=-1/(2+.5*z4);
x5=x4*opt;
y5=y4*opt;


explaination why:

(1+(2+z4)/2)*-1 is divided by twice. / is slow and * is faster, so much faster that doing one div and two muls is faster than two divs so

opt = 1/(1+(2+z4)/2)*-1;

x5=x4*opt;
y5=y4*opt;

is the first step i took. i then simplified the opt line to remove the spurrious bits, again because / is slower than * i replace /2 with *.4, because *-1 is the same as placeing - at the beginning i did that.. i also expanded the redundant brackets in the statement to reduce it even further.

opt = 1/(1+(2+z4)/2)*-1;
opt = -1/(1+(2+z4)/2);
opt = -1/(1+(2+z4)*.5);
opt = -1/(1+2*.5+z4*.5);
opt = -1/(1+1+z4*.5);
opt = -1/(2+z4*.5);

this may seem long winded, but it took me hundreds of times longer to write out than to 'just do' in code... it gets easier and more automatic with practice.


23rd January 2006 20:24 UTC

:p That's already been optimized, you're just seeing the outdated version of this preset.

But again, that wasn't really my concern. I suppose I am mainly concerned with whether or not the fps fix and the music data is working as it should.

Either way, thanks for the comment. :D


23rd January 2006 20:58 UTC

Well the fps independent code is broken too...

beat=(beat+1)%40;
bf1=above(beat,10)*fps*0.5;
bf2=above(beat,20)*fps*0.8;
bf3=above(beat,30)*fps*0.5;

doing it on beat is wrong

fps isnt actually storing the framerate per second which confused me at first i must add too :P

you need to do it every frame because the framerate fluctuates: e.g.

frame:
time=gettime(0);dt=time-old;old=time;
rotate = rotate + rotatespeed*dt;


24th January 2006 07:45 UTC

Well if he used my code for inspiration, that would be my fault... I used to "fix" the framerate in Extra Dimension on-beat :hang:


24th January 2006 17:48 UTC

:) That does seem to make a difference.

I suppose the only other question I have now is why it speeds up gradually to start with, then when it peaks it drops off to move at about half the speed, then continues at normal. Does that have something to do with the beat code?


24th January 2006 23:22 UTC

Basically stuff like this a=a*.99; also needs to be made time independent, you have done this somewhere in code:

rxm=rxm+(rxe-rxm)*.01+up-down;

and stuff like this too is prolly not fps independent either (*.01). instead of copying and guessing based on someone else code take a logical approach


The framerate/delta t between frames alters potentially every frame. this means that any line which does a 'fixed amount' of change to a variable per frame is going to need changing:

where a,b,c,d are some constants and ka,kb,kc,kd are values which give similar results with framerate independent code:

t=t+a; becomes t=t+dt*ka;
t=t-b; becomes t=t-dt*kb;
t=t*c; becomes t=t*pow(kc,dt);
t=t/d; becomes t=t*pow(kd,-dt);


27th January 2006 01:21 UTC

This makes sense, but where have I constants that need changing? If you referring to this:

rxm=rxm+(rxe-rxm)*.01+up-down;

I'll agree that multiplying by one hundredth isn't making the variable independant of the framerate, but the varible rxe is:

rxe=(bf1+bf2)*fps+engine;

So is this not enough then? Perhaps I may have misinterpreted your previous post, but it seems to do the trick.


30th January 2006 02:43 UTC

maybe i didnt read the code enough :)

i assumed that was targeting code for some reason, which it clearly isn't on further inspection. however, that whole block is still not fps independent...

rxm=rxm+(rxe-rxm)*k

rxe-rxm is confusing, personally I can't work out in my head if it breaks or not, but subtracting a time independant value from some constant (its constant this frame) doesn't seem like it should produce something time independent, it may change rxe time independently, but it is being altered then applied to make rxm change per frame:

rxm=rxm+(rxe-rxm)*k*dt would be much better

also you then go and add up and subtract down, which means you need to do this:

rxm=rxm+(rxe-rxm)*k*dt +up*dt + down*dt

basically when you have:

time_dependant = time_dependant + some_stuff

you want:

time_dependant = time_dependant + f(some_stuff, delta_t)

normally:

time_dependant = time_dependant + k*some_stuff*delta_t


btw, if you want to make your code more readable, don't use fps as the variable name in that context. fps means frames per second in a lot of contexts, what you are measuring is the number of seconds elapsed per frame, i.e. "seconds per frame" which is usually referred to simply as the change in time, or in more maths/science/computing contexts "delta t(ime)"

if you want the actual framerate in fps, do:

fps = 1/delta_t



EDIT: okay i worked out the rxe-rxm thing. It IS targeting, I just got confused trying to read and work it out:

rxm = .9*rxm+.1*rxe;

rxm -> rxe over time

the .9 and .1 need to change to match the time so that the targetting moves independently of framerate, e.g. for shorter frames you want to move less, for longer frames you want to move more. i think the correct way is like this:

optimiser = pow(.9,30*dt);
rxm = optimiser*rxm + (1-optimiser)*rxe;

this would give the same effect as using the current targetting at 30fps, except it adapts to the framerate changes.

On a side note, this trick is useful for making a sort-of time independent fadout effect, do a color modifier like this:

[code]
init:
t=gettime(0);
curve=.9;speed=60;
curve=max(0,min(curve,1));

frame:
oldt=t;t=gettime(0);dt=t-oldt;
opt=pow(curve,speed*dt);

level:
red=red*opt;
blue=blue*opt;
green=green*opt;
[code]

curve and speed control the speed and the 'brightness curve' used for the fadeout.

there are still differences at different framerates, but the overall brightness should remain roughly the same, eliminating the classic 'white preset' problems.


30th January 2006 03:29 UTC

Slow down! :p

Really though, you've lost me. It took me two days to understand everything you were saying in your previous post. Now I honestly have no idea what's going on. Where did k come from? What are dt and f?! I don't mean to, so to speak, bite the hand that feeds, but it's just not making sense.

For better or for worse, for the time being, I'm going to hold off on this stuff until I can get a better grasp on it. I think I'm just going to use what I know technically, but combine it with my style and use of trans effects.

I'm hoping that you're not upset, and that you don't see all the help you've given as have been done in vain. On the contrary, I'm very grateful for it! It's been enligtening, and certainly educational. But unfortunately, as I told Pak, I see myself as more of an artist than a programmer.


1st February 2006 05:19 UTC

Originally posted by denkensiefursich
Where did k come from? What are dt and f?! I don't mean to, so to speak, bite...
k is any constant, i used it to remove the discrepencies in several lines from changing them from non-fps to fps independent. e.g. if we make a=a+da; into a=a+da*dt; we need to modify the original da to get a visually similar result: a=a+k*da*dt; then by some little axioms it follows that for any system changing by adding or subtracting a linear combination of constants, e.g.

f(x+1)=f(x)+a0+a1+a2...+an etc
then
f(x+1) = f(x) +(a0+a1+a2...+an)*dt*k

dt, as i pointed out, is delta-time, the change in time. what you called 'fps' in your code.

f is the generic symbol used for a function, e.g.

f(x,y) = a*x+b*y+c^x+sqrt(y) etc...



Its not that hard to make a preset time independent. Its just better to design it that way first, with a proper understanding (which I assume is automatic :p) of how the effects of changing a variable may be dependent on the framerate. I think I probably confused you by complaining about how confusing I found your code. :)

Also the first bit about rxe-rxm can be ignored... i left it in so the edit wasn't out of context...

5th March 2006 06:20 UTC

Sorry to drag this back up, but I've finally found some time to dig through everything and apply what I had learned to this preset.

Jheriko, let me know if I've got a better handle on things now, or if I'm still missing something. The only thing I still don't know what to do with is the beat section. Right now, the camera seems to follow a set path, never veering from it. Is there someway to change this without it becoming too erratic?


5th March 2006 06:22 UTC

Shit, forgot the zip. :p


5th March 2006 20:30 UTC

would be better to choose filenames with legal characters


6th March 2006 00:15 UTC

:rolleyes: The filename is not the concern. However, if you insist...


26th March 2006 14:10 UTC

Testing successful
The original preset's interactivity and music vis' quality were great! It worked well (in average fps only, because of pos/fps speed dependancy that was described by Jheriko, i admit that i didn't look at the cause, never, i just believe it's fixed). The final preset was much worse, because of lost interactivity. i just look forward for the preset where fps independancy and interactivity come together.


27th March 2006 07:10 UTC

Well if I understood Jheriko correctly, the preset now looks as if it runs at 30fps. As he said, it "give[s] the same effect as using the current targetting at 30fps, except it adapts to the framerate changes." If you change the variable "optimizer", I would assume that you can run the preset any fps you prefer. I still don't fully understand it, but the logic would seem to agree.

As for the interactivity, it was just a bit of a test. I personally don't find much use for it, I just wanted to know if I could do it and make sure it worked, just in case a use came up later on in my career.

Anyway, thanks for the comment. :)