Is there a way now to use a snapshot or other screen element as a paint input?
Right now it looks like inputs can only be image files, is this correct?
paint1={ type=“image”, filename=“blob1c.png” },
paint2={ type=“image”, filename=“blob1n2.png” }
Or perhaps there’s an undocumented… paint1 = {type = “snapshot”, snapshot1} or something
along those lines?
***********
In the case I"m thinking of I’d like to explicitly composite snapshotA over snapshotB (subtract, add, whatever), snapshotC over snapshotD, then composite the resulting B and D over whatever happens to be on the screen below it.
The question is where does the snapshot live? Our thinking is that this would go offscreen (i.e. not render) once the snapshot is used as another object’s fill paint.
Walter, regarding snapshots - have you given any more thoughts to my suggestion that they stop being an actual image (of sorts), and instead become a factory resource a la imagesheet, so you can spawn sprites from them? I can’t think of any other conceptual way of having multiple images sharing a single snapshot that doesn’t end up with a system that is alien to corona’s current way of doing things?
I wouldn’t assume that snapshots will just be used for rendering to the screen - at least, not directly. Their greatest strengths are to use them as more than just a filterable container anyway
What I envisage is that a snapshot works as it does, but you can’t apply it directly to the screen. You’d need to spawn images from it, which gives you the ability to clone them. Something like:
local sprite = display.newImageRect( snapshotAsSource, width, height ).
Or, and this would be even more awesome - make it so you can create image sheets from a snapshot - this would add a TON of useful abilities (for example I am stuck in a demo I am working on because I need to create 10 strips from a single snapshot - currently the only way to do it is to cycle through them 1 at a time per frame).
Creating spritesheets and animations from a snapshot might not seem very intuitive, but being able to spawn sprites based on only sections of a snapshot would greatly increase flexibility, and make the snapshot very useful for setting up graphics to be re-used throughout the project.
Last two posts = most eloquence ever seen in this forum - I am in total agreement. Walter, my only concern is that I’m not fully conversant on the behaviour of fills - as long as an image based upon a snapshot (however it is done, via fill or cloning or something) distorts properly when you do things like distort in 2.75d etc then I’m going to be a happy bunny
The question is where does the snapshot live? Our thinking is that this would go offscreen (i.e. not render) once the snapshot is used as another object’s fill paint.
Walter, regarding snapshots - have you given any more thoughts to my suggestion that they stop being an actual image (of sorts), and instead become a factory resource a la imagesheet, so you can spawn sprites from them? I can’t think of any other conceptual way of having multiple images sharing a single snapshot that doesn’t end up with a system that is alien to corona’s current way of doing things?
I wouldn’t assume that snapshots will just be used for rendering to the screen - at least, not directly. Their greatest strengths are to use them as more than just a filterable container anyway
What I envisage is that a snapshot works as it does, but you can’t apply it directly to the screen. You’d need to spawn images from it, which gives you the ability to clone them. Something like:
local sprite = display.newImageRect( snapshotAsSource, width, height ).
Or, and this would be even more awesome - make it so you can create image sheets from a snapshot - this would add a TON of useful abilities (for example I am stuck in a demo I am working on because I need to create 10 strips from a single snapshot - currently the only way to do it is to cycle through them 1 at a time per frame).
Creating spritesheets and animations from a snapshot might not seem very intuitive, but being able to spawn sprites based on only sections of a snapshot would greatly increase flexibility, and make the snapshot very useful for setting up graphics to be re-used throughout the project.
Last two posts = most eloquence ever seen in this forum - I am in total agreement. Walter, my only concern is that I’m not fully conversant on the behaviour of fills - as long as an image based upon a snapshot (however it is done, via fill or cloning or something) distorts properly when you do things like distort in 2.75d etc then I’m going to be a happy bunny
we are converting snapshot images into png files via Flash and using as image files, we have had some successful results with scaling small simple objects. We have not looked into any bump mapping yet. Testing the idea of setting these up in sprite sheets for object textures. We are going to try building the sprite sheets using texture packer.
