linesize capped?

Well while trying to do a fullscreen linear gradient with one superscope alone and with the help of linesize, i noticed that for some very very odd reason it is capped at certain point and it doesn't fill the whole screen 🙁

Just try to make a fullscreen gradient with:
frame
linesize=w ; n=h

pixel
y=i*2-1 ; x=0 ; red=i ; green=red ; blue=red


I think the linesize is a very powerful and useful variable and i can't just understand why it is limited this way... I hope they could update this or we will have to go on using a superscope and a movement 😔

yes, i noticed that too i think it's capped at 256 🙁

Never noticed that before, kinda stupid.

I think it is 255 not 256 and its not stupid at all, you can use
unsigned char in c++ that ofcourse optimizes avs code, but do you really need more line width?

Jaak...
Now would i be posting this and whining and bitching about it if i would be happy with such great restrictions. 🙄

Now if i make a simple 2D square by using linesize, i want it to look correct even at 1024x768 resolution. And if i want to make a linear fullscreen gradient i sure as hell want that to look correct in all resolutions.

The coded parts in the new avs version seem to run so fast that a single linesize free superscope would be faster than the superscope+movement combo /me thinks. Also i wouldn't have to use a effect list if i for example want to multiply blend it with something, just misc render mode and voilá! 😁

single SSC fullscreen gradient 🙂

you need a single superscope fullscreen gradient? here it is 😁
tested at 1152x864 🙂
it's done using the same system you use when wallpapering 🙂
it simply does multiple gradients next to each other

if (lw<1) lw=1;
else if (lw>255)lw=255;

Yup.

Ok, now do me a square that is 50% size of the screen, with linesize.
After that do me a solid oscilliscope that is 75% of the height, with linesize.

ok you won 🙂

I just want it to be fixed, not a alternative solution. I don't think that it's a sin to ask for it 🙁

it is. there is absolutely no feasable reason any sane man would ever, ever want to have a line width greater than 64 to begin with. there are alternative ways to make gradients. i don't think i have to ennumerate them for you.

Just wanted to point this out, sorry.

I just want it to be fixed

If Jaak is right about why it doesn't work, then it isn't really a bug, but a slightly overly agressive optimization. So it needs to be changed, not fixed.

Atero, and i don't think i have to tell you the slowness of using a fullscreen solid scope with something like s=bnot(s) or a scope, movement and effect list just to get a different blend mode than replace.

Slowness isn't the only problem, if you use s=bnot(s) it gets less solid looking when the window gets bigger which forces you to use crazy high values for n.

using unsigned char's isn't a speed optimization though... using UCHARs will actually be slower than using int's. Modern processors run fastest with 32bit data so it would actually make more since to use int's. I think tuggummi's request is 100% valid.

It doesn't actually use unsigned chars, it just caps the linesize.

Another downside of the s=bnot(s) thing is the 1 pixel shift. You won't notice this on n=w(or h)*2+2 with 100% fill, but it is inaccurate. If the problem could be changed, this would be an optimization. It sure is faster and more accurate.