Merging ImagesMonkey Forums/Monkey Beginners/Merging Images
I'm just wondering if there is a way to merge two images in a code? I am trying to create a coloring book app for my niece.
My first approach here would be to draw colored circles on the screen when they hold a button and dragging, and merge these colors when they release the button to an object.
| sounds like a good idea. that way you can isolate the update area when you WritePixels() to the permanent paint layer.|
one possible concern is that it may not be fast enough when someone scribbles over then entire area for a long time (like on a retina tablet). in that case, a FILO deque/stack could be used for each colored circle, and on each update frame, the circle is merged with the permanent paint layer.
you may also need to draw lines (or splines if you want to be really fancy) for fast fingers in between each update.
| I have heard them quite a lot on WritePixels() and ReadPixels() in the forum. Think it's my time to apply them myself. |
Thanks for the advice, Adam.
| Yes, WritePixels() and ReadPixels() are the way to go, once a painting action is completed. For super-long painting actions you will have to decide how to handle it. But even doing it in the simplest way, the user will get feedback because the framerate will start to fall if they make a continuous squiggle that is too long. |
| I do something similar in my new game "Ballerburg". Here the player can "reconstruct" a castle by "panting with his fingers. Therefore I have all the time two arrays that already contains the original undestroyed castle and the temporary destroyed castle. |
By moving the fingers on the screen the app copies parts from original to the temporary. Then build a new image from the second one and use this to draw it on the screen. I looks like working in real time....
| Midimaster does your code handle alpha ? and if so do you have an example ?|
I was thinking about something like this to create light sources, imagining an all black rectangle that covers the screen and then an alpha gradient circle to remove the black and show the level bellow, I though that having multipul light sources might be as simple as taking two of these all black images and merging them to give a single new black/light mask, but people have said a lot of times in various other threads that write and read pixels are far to slow for realtime use.
IIRC, ballerburg only generates the landscape once, then re-uses the resource it generated as a static background. With clever scissoring you can create your own light sources in a pitch black setting (ie: only exposing the areas where light would be, then blitting gradient on top within the scissor to "fade out" the light), but in theory you could also generate a static image of sufficient size to "cover" the screen with the darkest color+alpha with the acception of a single light source and scroll it around a bit. Both solutions have obvious disadvantages but neither should show stitching when scaling the screen.
| I would create an array which represents the dimensions of the screen. Now you can manipulate the bytes in the array and then create a new image from the result:|
Move the mouse over the black mask. The alpha will get transparent
In this way "alpha" would be no problem, because you manipulate the array bytes directly without screengrab.
| I'm having an array of circles. If the framerate starts dropping or it reaches a certain number of circles I merge them to the permanent layer. It works for me but more testing should be done though.|
I love your idea, midimaster. Is your game done?
I'm getting huge flux of ideas for WritePixels(). I'm thinking of Magic that you have to form with your finger to produce a spell or puzzle games that involve cutting ropes, destroying boulders or creating platforms with your finger to fulfill the task. Not trying to get ahead of myself but its great motivation.
| yes, the game Ballerburg is on GooglePlay|
I have updated the code above to demontrate alpha manipulation....
| Yeah that's kinda cool, just wondering how fast it will be at manipulating the alpha of a few light sources when each light source would be dynamic in size, I think yeah it would be fine for static lights as they wont move once created, but for something that follows a game object around the screen it may not allow for much frame time for collisions and other game stuff ..|
worth a try tho I guess. thanks for posting your code.
| You just have to be careful because mobile devices are not designed to have the graphics pipeline go that way, and you are at the mercy of how well the particular system decides to do it.|
Still, there is scope to do a lot of things - I've certainly started using procedurally-created graphics more. It can be a choice of two ways of doing things, one of which is better for artists and one for programmers.