guenter geiger wrote:
MANIPS polygon_smooth
I think the naming concept is a bit strange with that. The underscore suggests that it belongs to a group of objects (like pix_ part_ ext), while it doesn't, and it is rather a "normal" gem OpenGL command.
It would be more consistent to call it "smooth", plain, like "alpha".
very right, in my last mail, concerning the "blend" functionality, i have forwarded this old email, where "polygon_smooth" was considered a bad name (but better than "pix_a_2grey") but i had no other idea.
so i will remove "polygon_smooth" and call it "smooth", as i guess nobody has really used it - chris ? (i think you might be the only one...). and we could really add an alias for compatibilty.
MARKEX abs m_control? multiselect? reson? strcat?
I think they should go away ...
should go away from GEM ?
probably we should really remove all the markEX-objects that are not referred too by the help/example-patches (and as time permits, rewrite them, so that they don't need markEX)
Yep. What about producing a template for the help-* patches (we have to rename them for pd-0.37 too, right ?)
i don't fully understand this.
and ask gem users to help
with the documentation effort.
yes, this would probably result in better help-patches (because they might show real needs)
I think it would be nice if the help patches have a minimal functionality too, so the user can see the effect directly.
so, without a [gemwin] but with a [gemhead] ?
...beyond that, some of my "soon todo" list includes:
- adding other model formats
right, i have been talking about this for years. btw. is quake2 available for macOS ? are quake2-models used ? this might be a common format for animated models.
- fullscreen motion blur
i think i even added a message to [gemwin] for this (but i stopped working...)
- "snap to tex" that results in a further processable image
isn't that what pix_snap does ?
that's what i thought too. but probably it's more like snapping to texture *and* getting the image into user-space.
mfg.as.rd IOhannes