Thick lines in SSC's

[Ishan]

8th May 2003 09:41 UTC

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.

sidd

8th May 2003 13:14 UTC

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?

Tuggummi

8th May 2003 13:24 UTC

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.

sidd

9th May 2003 10:40 UTC

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.

IshanRocky

11th May 2003 10:37 UTC

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.

sidd

11th May 2003 16:19 UTC

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

shreyas_potnis

13th May 2003 10:05 UTC

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

sidd

13th May 2003 13:11 UTC

is same deal yes

shreyas_potnis

13th May 2003 15:09 UTC

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

Raz

13th May 2003 15:24 UTC

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.

NemoOrange

14th May 2003 06:24 UTC

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

Tuggummi

14th May 2003 07:02 UTC

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...

sidd

14th May 2003 07:05 UTC

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:

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.

IshanRocky

14th May 2003 09:10 UTC

we are going to wishlist are'nt we ?

Wiser87

14th May 2003 10:44 UTC

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

UnConeD

14th May 2003 12:19 UTC

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:

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:

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/....

shreyas_potnis

14th May 2003 12:52 UTC

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

sidd

14th May 2003 13:29 UTC

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..??

Raz

14th May 2003 15:53 UTC

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

shreyas_potnis

15th May 2003 09:31 UTC

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

sidd

15th May 2003 10:39 UTC

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..

Tuggummi

15th May 2003 11:49 UTC

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

sidd

15th May 2003 12:01 UTC

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

Tuggummi

15th May 2003 12:54 UTC

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 :)

shreyas_potnis

16th May 2003 10:15 UTC

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

dirkdeftly

16th May 2003 16:45 UTC

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

shreyas_potnis

18th May 2003 09:17 UTC

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

Nic01

18th May 2003 15:57 UTC

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.

shreyas_potnis

20th May 2003 10:24 UTC

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)

sidd

21st May 2003 07:41 UTC

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

shreyas_potnis

21st May 2003 16:18 UTC

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

sidd

22nd May 2003 09:16 UTC

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