[GEM-dev] pix_set new features

Antoine Villeret antoine.villeret at gmail.com
Tue Dec 11 19:24:45 CET 2012


and what about the opposite ?
stay in discrete coordinate in the code and add a normalized message ?
in that way the conversion is done only once (when the ROI is set in
normalized coord) and not each time we set the data (for pix_set)
maybe i'm going wrong...

+
a


--
do it yourself
http://antoine.villeret.free.fr
http://drii.ensad.fr
--
Google lit ce mail...
si vous refusez cela, utilisez l'adresse antoine.villeret [at] free.fr
pour me contacter


2012/12/11 IOhannes m zmoelnig <zmoelnig at iem.at>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2012-12-11 19:00, IOhannes m zmoelnig wrote:
>> On 2012-12-11 18:48, Antoine Villeret wrote:
>>> is does
>>
>>> thanks
>>
>>> while i understood the need of normalized coordinates for
>>> texture in OpenGL, i dislike it in pix_objets, because we deal
>>> with array of pix and i think it's more human readable to use
>>> pixel coordinate in this case this also add some conversion both
>>> in the code and in the patch but this is only my point of view
>>
>> i understand that (esp. in the context of pix_set), but i want ROI
>> to also work with simpler effects where you might want to specify
>> an area, where the effect is applied, without having to care about
>> the pix dimensions. also Gem uses normalized values whenever
>> possible.
>>
>
> however, i'm not so much opposed to add a special message to specify
> the ROI in absolute values and [pix_roi] would then normalize the
> values internally.
>
> fgmadr
> IOhannes
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAlDHeHAACgkQkX2Xpv6ydvTIGQCeO2tuvkrwvMWD85eYk7wV17CE
> o6AAoJjTHpoqTjp+UDuiK95zQHiWDbIm
> =8jSq
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev



More information about the GEM-dev mailing list