Thick lines in SSC's
 

Thick lines in SSC's?
i am never able to draw thick lines in ssc's, i always have to use texer.
could someone help me out?
[\edit] i know i should have posted this thread in avs trouble shooting forum but since it is here any way please help me.

you mean like misc/set render mode, line width

you just set it there to any number. and put the scope in after. only works on lnes, not dots.

is that what you mean?

Or do you want solid scopes?

A simple solid superscope analyzer

Per frame
n=w ; sz=0.3

Per Pixel
s=1-s ;
x=i*2-1 ;
y=s*sz-sz*0.5+getosc(i,0.1,0)


Then put the Misc / set render mode above the scope and use line width 2.


To make any scope "solid" try adding the value S somehow in your scopes, i recommend experimenting since i don't know exactly how it works.

tg:
you should probably put the code
i=if(s,i-1/n,i)
in your code after the first perpoint line

that way the values correspond properly and you need less 'n's to make the scope solid.

Sorry for not replying for so long,
had some problem with my id so i have changed it ,
and thanx to both of u tugg and sid, both of you'll tricks worked.

just thought id say that that s=1-s trick is freekin wickid! im using it heaps now. cheers tugga!

s=1-s would be s=bnot[s] wouldnt it?

is same deal yes

i think s=bnot[s] will be faster altho it doesnt matter

should be able to put line width in with the scope i think. Then you could set it to width instead of those silly x=0 movements. I wont even bother putting it in the wishlist though because it wont get added.

s=-s kinda does the same thing, & its a little easier to understand what it does.

s=bnot(s) & s=1-s are the same thing, i don't know which one is faster, i remember someone saying 1-s is faster instead of calling a function to do it...

But honestly, i dunno :) I dunnot care that much :)

Raz, you're talking about a solid fullscreen scope? Those x=0 movements combined with a scope are much faster than using a hella big solid scope...

s=-s is pos/neg swith, you have to assign 's' in init, for egsample to 1. then it will switch from 1 to negative 1 every time the code is run.

s=bnot(s) and s=1-s are boolean switches, they switch from 0 to 1 every time through, they dont need to be pre-assigned because 0 is default.

a solid osciliscope (like the 'render/simple' one, as apposed to tuggs example) would be:

code:
s=bnot(s);

i=(if,s,i-1/n,i);

y=s*v*0.5;

x=2*i-1;

line width should be >1

<edit> maybe it would be alot nicer if avs had a render/'dynamic-fill-space" tool hehe-hoho-haha.

we are going to wishlist are'nt we ?

Either that or we're going to have to shove the requests down Nullsoft's throat ;)

Tug: I think bnot is fastest, because it only accesses one constant/variable rather than two (though if the script library is smart, it'll use fld1 to get 1 instead of a memory fetch).

Forget about the whole 'calling functions is slow' thing. It only applies when there is an actual clear mapping between the code you write and how the computer executes them, which doesn't go for a highlevel language like AVS.

Heck, it doesn't even apply to C/C++ sometimes.

Some people are so proud when they can exchange 2 variables using simple code like this:

code:
int a, b;

a ^= b;

b ^= a;

a ^= b;

But in fact, unless your compiler specifically recognizes that code (not likely), it'll be much slower than simply doing this:

code:
int a, b;

register int c;

c = a;

a = b;

b = c;

Any decent compiler will turn that second piece of code into the most efficient piece of code possible for an x86.

Plus there's the fact that an x86 doesn't support direct memory-to-memory copies, you always have to go through the cpu registers first (*), which is exactly what the second piece of code does.

(*) I believe string ops like "rep stos" are exceptions to this, but they're only useful for big chunks afaik, not an int/float/....

i predicted s=bnot[s] is faster after the argument that y=x*x is slower than y=sqr[x] :)

i really really dont think it matters whatsoever..

eg, do you think one single bnot[var], or 1-[var] per point/pixel/frame is really going to make or break your preset.

ucd, how the fuck do you know so much about compiler preference and assembly language efficiency blah blah blah..??

Tug i meant being able to set the line width to the width of the screen and there not being a limit to it.

i think UnconeD knows a lot too much about such stuff, how does he? did he help make c++?

yes, ive heard he tutored Carmack everything he knows..
not to mention bill fricken gates.
I think. if memory servs, he invented windows..

...
and the first computer.

wow, i really milked that joke..

The set line width is buggy & slow, why would anyone wanna use that instead of bnot(s) ? O_o

because it can occasionally be slower, as it requires atleast twice as many n's as a normal scope. depending on the shape of your scope, you may need to use line width anyway to fill in the gaps. it depends on how you implement the switch variable anyway. As i said above.. withthe whole i=i-1/n stuff

Yeah, well both have their advantages, it's just a matter of taste. But if you don't already know then you should know that using line width to create big solid scopes won't work the same in all resolutions. When you use the S thing, it always looks the same in all resolutions, because it grows/shrinks depending on it. Line width stays always the same.

Anyway, no more of this please :)

there should be an option ot set the line width according to the width, height or both, eg line_width=w/100

well i think if there's a spacefilling/solidifying component in the next release, that won't be necessary. but it would be nice, just in case

but s=1-s woudnt work if s=10 or something

That's because any non-init custom var starts out as 0, not 10 or something.

Common sense, duh!

As for Siddharta, on :
i really really dont think it matters whatsoever..

eg, do you think one single bnot[var], or 1-[var] per point/pixel/frame is really going to make or break your preset.

--

These small optimizing moments are pretty crucial because they're everywhere... You should be able to milk out a few extra FPS with optimization tricks. Besides, small things like this would matter on high-res DMs or high-n SSCs.

and they do matter when you are having about 30 to 40 ssc's.
i managed to increse fps by about 4 (?i dont exactly remember) when i optimized blue-spectrum by el-vis)

shreyas, you can just do
s=bnot(s); s2=10*s
so it switches between 0 and 10 instead.

well, i know that. i just said that if initial value of s=10, then s would to -9 and then go on decreasing by 1

oh.. lovely.
although that dont work for the bnot version.
it would go 20,0,1,0,1 etc etc