UnConeD

11th June 2003 02:10 UTC

AVS mysteries
GODDAMNIT. I had just nearly finished typing up a LONG, informative post with commented code, when I was going to do some final debugging. Except that I accidentally hit the 'Power' button instead of 'F11'. And that button just happens to shut down my computer in 2 seconds. Poof. Bye.

That key has now been pried off the keyboard.

I won't type it up all again, I'll just summarize my conclusions. If you want to know the how's and why's, you'll have to do it yourself.
--------------------------

Using MSVC++'s debugger and one of my APEs, I got down and dirty with AVS's internals. Lots of messy assembly to figure out.

The basic procedure is to make an APE in debug mode. Then make a preset with only the APE and then e.g. a scope. Now put a breakpoint at the end of the APE's render function and start winamp with the debugger. Open AVS and the preset. Turn on the breakpoint and it'll kick in. Now press F11 to step out of the render function and into vis_avs.dll. Set a breakpoint at the line that called your ape (the one before the current one normally) and hit F5 to run until it arrives back at that point. Now it's time for the scope to get called. Hit F11 again and you'll be inside the superscope code. Place a breakpoint here so you don't have to find it again, and start digging :rolleyes:.


- AVS does not optimize anything. '5/2' will be calculated explicitly, it will not get replaced by '2.5'. Similarly, x/a, where a is a constant will not be replaced by x*(1/a). So use x*.5 instead of x/2.

- AVS uses function calls for EVERYTHING. Loading a source variable is done by putting the variable's address in the eax register. This is done using a mini-function call per var.
The compiler probably splits an expression into a tree of operations, with variable and constants at the leafs, operations at the branches and target variables at the roots.
However these are naked jumps and calls, without any of the extra stuff (parameter passing, stack pushing, local vars, ...) that is normally associated with a function call. So the performance hit could be minor on a modern cpu.

- if(a,b,c) calculates b and c, regardless of a. Proven using test statement if(cos(1),cos(2),cos(3)) because I've figured out where the cosine gets calculated. cos was called both with argument 2.0 and 3.0.

- AVS uses 64-bit double floats internally.


Conclusion: AVS was never made for rollercoasters...

dirkdeftly

11th June 2003 03:41 UTC

r4wk ucd.
because i don't know a damn thing about this kind of stuff and i'd rather not go hunting it down in any of my books, does a 64-bit double float imply 63 bits of precision + the sign bit?

Zevensoft

11th June 2003 04:38 UTC

Normally, it's 3/4 of the bits for number, 1/4-1 bits for floating point, and the sign bit.

So for 64 bit, it would be 48 bits number, 11 bits float, and 1 bit sign.

UnConeD

11th June 2003 13:20 UTC

Atero: it's in that PDF I sent you, chapter on the floating point unit (14), section IEEE Floating Point Formats :rolleyes:. If you'd bothered to read it, you wouldn't say stuff like that anymore...

IEEE 64-bit float = 53 bits of mantissa, 11-bits of exponent + 1 sign bit.
This makes 65 bits and not 64, because the highest bit of the mantissa is always 1, so it is left out, and only 52 and saved.

dirkdeftly

11th June 2003 14:00 UTC

well excuse me mr fancy pants

seriously, i really do have more pressing issues than assembler language...i'm almost sorry i asked for that pdf now...:|

Deamon

11th June 2003 21:36 UTC

how very friendly...

Phaze1987

11th June 2003 22:58 UTC

if(a,b,c) calculates b and c, regardless of a. Proven using test statement if(cos(1),cos(2),cos(3)) because I've figured out where the cosine gets calculated. cos was called both with argument 2.0 and 3.0.

mikm

11th June 2003 23:15 UTC

take the equation if(equal(x,y),a*c-b,b*c-a);

the equations a*c-b and b*c-a will always be calculated regardless of the state of equal(x,y)

Phaze1987

11th June 2003 23:29 UTC

aaah...so this slows AVS a little right ?

Raz

12th June 2003 00:28 UTC

And all these, "slow AVS a little"'s accumulate into one big slow program.

UnConeD

12th June 2003 02:34 UTC

Yup. You can test it like this:
a=if(1,1,sqrt(2)/sqrt(3)/sqrt(4)/sqrt(5) ...);

Extend up to enough square roots, copy/paste this line a bunch of times and notice the slowdown.

I'll illustrate with a practical example. Suppose you have a scope that can switch between 5 shapes. You'd have something like this in the per-point:

x=if(equal(shape,0),...,if(equal(shape,1)..., . ...);

However, AVS will calculate all 5 shapes every frame (and throw 4 away). So instead, it is better to make 5 scopes that are synchronized, and set 'n=0' for 4 of them. That way only 1 will be evaluated every frame.

If you don't think this is serious, suppose the scope above had 300 points. It would be doing the equivalent of 1500 points every frame...

If you can't avoid it, you should try putting as much common elements outside the if function (or save them in variables) so that they only get calculated once. Like:

x=if(a,cos(t)*sin(t)*p,sqr(cos(t))*q);

=

x=cos(t)*if(a,sin(t)*p,cos(t)*q);

dirkdeftly

12th June 2003 02:46 UTC

that is an awesome idea (turning scopes off like that)...thanks for the tip :)

Zevensoft

12th June 2003 06:16 UTC

I used that ages ago... geez :rolleyes:

Magic.X

12th June 2003 07:27 UTC

But this would mean that avs is going to run faster on my new Athlon 64 right? At least faster than it does now, splitting up 64 bit into 2*32 or something like that, given a 64 Bit supporting OS.

Anyway, UCD do you know where to find the transition mode settings within the avs memory block. I'd like to access them out of hotlist but i can't get the handles of the control elements if they're hidden. I don't know anything about hacking maybe you have any idea... ;)

UnConeD

12th June 2003 12:21 UTC

Unlikely. That value is only read once every thousand frames or so, and has nothing to do with the rendering buffer itself. Locating it would be a pain.

Plus, you'd need an APE to get its memory location anyway.

Phaze1987

12th June 2003 23:14 UTC

thanks for the tips...i really understood smth out of them :)

Magic.X

16th June 2003 12:02 UTC

It has to be read on transition anyway. But i dont feel like learn hacking, i'd rather bug justin (or his successor) to add some funktions.

It would be so easy to make avs customizeble (in this case). They only need to declare some WM's, thats it.

horse-fly

23rd June 2003 19:01 UTC

:igor:

mikm

23rd June 2003 19:03 UTC

you revived this post and didn't add anything except a smiley?

pity Atero didn't get here first.

Magic.X

23rd June 2003 20:43 UTC

:p he will read, sooner or later.

Anyway, to update this topic: Found a way to "cheat" AVS and to pass a input to the check and combo boxes (besides i found ot the laser stuff which ya all already seem to know :-( ) you'll see in Hotlist 2.3 wheter i get it to work in a stabile way :D

UnConeD

23rd June 2003 22:52 UTC

MagicX: send the appropriate menu WM_COMMAND's, find the HWND of the config dialog and then send the command to the appropriate control. Nothing hard about that ;).

Not sure if I mentioned this already, but I have some code sitting here to modify the onbeat value through an APE, allowing for Custom BPM II. Should get around to making that once really.

Magic.X

1st July 2003 18:44 UTC

Ok, this is quite easy. (as you describe it)

But i hafta go a damn painfull way to open the appropriate dialog. But even i got it open, checking and unchecking things wont have any effect unless you can send a hex coded notification message to the parent handle includeing the controls internal id.

I did it anyway. *cough* :)

PM me if you want to know in detail or some code.

NemoOrange

3rd July 2003 01:32 UTC

c'mon Steve, just write AVS 3.0 by yourself. We all know it'd be so much better than what we have now. Enough teasing us with posts like these.

horse-fly

3rd July 2003 05:22 UTC

atero, i laugh at him *HA*

Magic.X

3rd July 2003 17:12 UTC

Horse Fly, please stop argueing.

horse-fly

5th July 2003 06:55 UTC

me argue? never!! me play around? always!!

Deamon

5th July 2003 09:39 UTC

screwing around you mean...

horse-fly

7th July 2003 08:04 UTC

playing, screwing, both have sexual conotations.

dirkdeftly

7th July 2003 08:40 UTC

shut.

the.

fuck.

up.

horse-fly

9th July 2003 06:42 UTC

well excuse me...

mikm

9th July 2003 06:55 UTC

We don't look kindly upon postpumping here. Run along to GD. Shoo!