 |
Author |
Topic: return pixels from line(), etc. (Read 313 times) |
|
depth
 
|
return pixels from line(), etc.
« on: Jul 8th, 2003, 10:46pm » |
|
what if the line(), curve(), quad(), etc. functions could return an array of all of the pixels they affect?
would be nice to be able to manipulate shapes (to some extent) after they're drawn, pseudo-vector-wise.
|
|
|
|
|
benelek
 
|
Re: return pixels from line(), etc.
« Reply #1 on: Jul 10th, 2003, 3:31am » |
|
you should be able to find out which pixels were affected by drawing something, by making a copy of the pixels array before and comparing it with the pixel array afterwards.
|
|
|
|
|
toxi
|
Re: return pixels from line(), etc.
« Reply #2 on: Jul 12th, 2003, 7:11pm » |
|
also what should the array contain? x/y coords or indexes in the pixel array? what about antialiased shapes where pixels are only modified to certain extend? can't see much use in it really. you already have pseudo vector gfx by using statements like line() etc. in this case you specify the vectors to the start and end points.
|
http://toxi.co.uk/
|
|
|
fry
|
Re: return pixels from line(), etc.
« Reply #3 on: Jul 14th, 2003, 9:58pm » |
|
i think this would be a cool feature, and can think of many ways to use it, though the issues that toxi brings up are a barrier. for non-antialiased, especially single pixel, shapes it's no biggie.
but it's more a matter of how confusing it gets.. what data gets returned? an array of some sort of object that wraps up a color and a point location? if there were an elegant way (or at least something that fits with the rest of the api) to implement this, it'd be cool to have it in there. but i'm trying to think of something that would make sense. anyone have ideas?
|
|
|
|
|
depth
|
Re: return pixels from line(), etc.
« Reply #4 on: Jul 15th, 2003, 11:51pm » |
|
benelek - duh, good idea. that's pretty much what i was thinking - a list of indices in pixels[].
toxi - good points...especially the anti-aliasing one. the reason i was thinking about it was as a way to access pixels that have already been drawn, with noBackground()...but then you have the issue of drawing over pixels that are already drawn, and once again it gets messy.
just wanted to see what ideas people had....
|
|
|
|
|
benelek
|
Re: return pixels from line(), etc.
« Reply #5 on: Jul 16th, 2003, 4:33am » |
|
hm, depth that sounds like a good one: a function that returns an array of integers referring to places in the pixel array that have been drawn on.
|
|
|
|
|
toxi
|
Re: return pixels from line(), etc.
« Reply #6 on: Jul 16th, 2003, 12:27pm » |
|
okay, i do get your drift now 
i was thinking a bit more about it on the train this morning, so here're some more points.
we could introduce a new "change buffer" (same size as pixel buffer) which is being cleared/reset at the beginning of every frame. every participating drawing operation will then store the indices of changed pixels in the pixel array in this buffer. re: antialiasing. it actually doesn't matter really if a pixel has been modified only slightly. the bottomline is, it still has been changed and as such should not be treated differently than aliased "normal" pixels.
furthermore there could be a new statement like "usedPixels()" to get hold of this current list of changed pixels. only the sub array of actual used pixels is returned. this function would also reset the ChangeBuffer so that calling it repeatedly inbetween drawing operations will only return pixels changed since the last call.
i'm still quite worried though about the potential speed hit a feature like this will cause. so IMHO this all should be optional and e.g. could be turned on via hints(USE_PIXELCHANGES); or along those lines.
another alternative to the ChangeBuffer would be that each drawing function returns it's list of pixels directly, however this will not be as efficient (loads of array creations/memory allocations going on)
whaddyareckon?
|
http://toxi.co.uk/
|
|
|
|
