Pixel Color from point
by Scott Johnson · in Torque Game Builder · 05/27/2008 (11:52 pm) · 2 replies
I just wante to drop a request in here for a script exposed function that would return a color from a static sprite (or any sprite for that matter), given a local coordinate.
It seems like a simple request, however since I don't have the pro code base, I'm not sure of the effort required.
This function would allow for some flexibility by being able to use a large color key image to determine sprite selection when there's the possibility of overlapping sprites such as in a board game or similar.
See this thread
Thanks!
It seems like a simple request, however since I don't have the pro code base, I'm not sure of the effort required.
This function would allow for some flexibility by being able to use a large color key image to determine sprite selection when there's the possibility of overlapping sprites such as in a board game or similar.
See this thread
Thanks!
About the author
#2
Overcoming that would leave the issue of doing something that was generically useful and didn't kill performance with abuse.
When you start getting down to pixel-level it starts smelling of there being a better solution, especially in this day and age.
I think the best way forward would be to have support for concave polygon picking. If it were me, I'd create a T2D object that allowed you to generate a concave polygon and use it for picking (probably via the castCollision).
Although many people say that T2D doesn't support concave collision detection and whilst that is mostly true, I did write-in a method that allows any single body to have multiple child bodies. This would allow you to define a arbitrary polygon and have the object decompose it into multiple convex polygons. This object could then be used for picking/collision-detection etc. That's possible in a few hours. It'd take more effort to enable that object-editting in the builder though.
If you absolutely wanted to work with access to a dataset then I'd go for developing an object that allows import of image-data and provides access functions. I'd probably allow that object to have its own coordinate system that would allow the user to map their own coordinate space whether this be screen-space, world-space or whatever. Then I'd provide some accessor functions to allow accessing this dataset. It would seem best to stick with image-data as the source data but it wouldn't have to be so.
I think though that no matter what the solution, you do need to encode something, polygon, colours, whatever and that's quite tedious but unavoidable.
Melv.
05/28/2008 (4:20 am)
The biggest issue here is that the image-data isn't necessarily available as it's a texture on the graphics card, not like alot of 2D engines which blit image-data from main memory. With that said, the image-map datablocks can maintain that data for when texture-ressurection occurs on the graphics card.Overcoming that would leave the issue of doing something that was generically useful and didn't kill performance with abuse.
When you start getting down to pixel-level it starts smelling of there being a better solution, especially in this day and age.
I think the best way forward would be to have support for concave polygon picking. If it were me, I'd create a T2D object that allowed you to generate a concave polygon and use it for picking (probably via the castCollision).
Although many people say that T2D doesn't support concave collision detection and whilst that is mostly true, I did write-in a method that allows any single body to have multiple child bodies. This would allow you to define a arbitrary polygon and have the object decompose it into multiple convex polygons. This object could then be used for picking/collision-detection etc. That's possible in a few hours. It'd take more effort to enable that object-editting in the builder though.
If you absolutely wanted to work with access to a dataset then I'd go for developing an object that allows import of image-data and provides access functions. I'd probably allow that object to have its own coordinate system that would allow the user to map their own coordinate space whether this be screen-space, world-space or whatever. Then I'd provide some accessor functions to allow accessing this dataset. It would seem best to stick with image-data as the source data but it wouldn't have to be so.
I think though that no matter what the solution, you do need to encode something, polygon, colours, whatever and that's quite tedious but unavoidable.
Melv.
Associate Phillip O'Shea
Violent Tulip