dirkdeftly

16th April 2004 17:47 UTC

render / gradient
why don't we just make a codable gradient fill renderer, so people stop having to use the el(ssc, movement) method? my ideal interface would be radio buttons for horizontal/vertical, init/frame/beat/row code blocks and some incarnation of some pertebution of colormap's mapping procedure, and radio buttons to switch between the two. i don't know how easy this would be to integrate directly into avs (since colormap hasn't yet been integrated), but i doubt it'd be that hard for someone knowledgable *coughunconedorjherikocough* to code an ape for it.

TomyLobo

16th April 2004 21:29 UTC

very good idea! now we just need to find somone who knows C++ (and the APE SDK) well enough to write this :)
hmm maybe optionally different gradient types:
linear gradient (y=0;x=x)
circle gradient (x=1-2*sqrt(sqr(x)+sqr(y));y=0;)
square gradient
a different circle gradient (x=1-r/$pi;y=0;)

Warrior of the Light

18th April 2004 14:16 UTC

lol..
Don't you just LOVE smilies?

But yeah, that'd rock

TomyLobo

18th April 2004 16:55 UTC

oops that was the automatic smiley conversion... that was supposed to bei ; ) not ;) :)

Tuggummi

22nd April 2004 08:24 UTC

[offtopic]This still doesn't remove the need to fix the linesize ;)[/offtopic]

But yeah, that would rock :)

[edit]If someone makes this, it would be nice to have rotation, sliding & "zooming" support too not to mention color shift ( although that is obvious :igor: ) (just a note...)[/edit]

UnConeD

22nd April 2004 18:04 UTC

C++ is not enough for fast apes (especially not ones which do a lot of color blending, like a gradient), you need MMX asm ;).

OnionRingOfDoom

5th May 2004 21:47 UTC

I definatly agree on the cooless of something like this. I could probabbly do it in C++, but like UCD said, it's not fast enough.

hungryskull

6th May 2004 01:16 UTC

Good idea. It would allow for much nicer looking gradients.

NemoOrange

6th May 2004 03:04 UTC

this would make my life a whole lot easier.