Archive: linesize capped?


5th April 2004 06:28 UTC

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


5th April 2004 15:22 UTC

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


5th April 2004 23:25 UTC

Never noticed that before, kinda stupid.


6th April 2004 06:26 UTC

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?


6th April 2004 06:37 UTC

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

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á! :D


6th April 2004 15:28 UTC

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


6th April 2004 22:24 UTC

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

Yup.


7th April 2004 07:23 UTC

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.


7th April 2004 08:22 UTC

ok you won :)


7th April 2004 08:53 UTC

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


8th April 2004 00:31 UTC

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.


8th April 2004 02:48 UTC

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.

8th April 2004 08:19 UTC

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.


9th April 2004 16:34 UTC

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.


11th April 2004 21:26 UTC

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.


13th April 2004 03:17 UTC

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


13th April 2004 20:03 UTC

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.