Skip to content
Forum Archive

render / gradient

9 posts

dirkdeftly#

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#
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😉
Tuggummi#
[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 🧟 ) (just a note...)[/edit]
UnConeD#
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#
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.