Generating images at run-time and storing them?

What is the best way (efficient and fast) to generate several images (pixel-by-pixel) during run-time and store them in the app's memory - in some kind of drawing buffer - for later use?

I'm trying to write a mobile app in Construct 2 that features the capability to morph one image into another based on certain parameters. This will require me to generate frames of the morph animation at run-time, store them in the game's memory, and then display them as an animation sequence to the user.

The approach I have thought out so far:

I can use R0j0hound's Canvas plugin to calculate a given frame of the animation (using pixel-by-pixel processing), but I am not sure what the optimal way to store a frame would be. My first thought was to use a 2D array, with each element representing a pixel's color as an integer. By this approach, if I had 30 frames in my morph animation, I would then have 30 gigantic (up to 1024x768) 2D arrays representing the animation.

Problems with it:

One major problem with this approach is that displaying the images as an animation might be too time consuming, because I have to convert the arrays back into pixels to display on the canvas. For a smooth animation, I'd still want to draw the images to a buffer somewhere first.

Second, I am also concerned about the pixel processing itself taking up too much time by virtue of being a software process rather a hardware one. Is there a way to utilize the hardware to do the image processing? Especially on conversion to an iOS app via AppMobi or eventually CocoonJS.

How you can help:

Any input like tips/techniques/insights that you can provide will be very much appreciated! I feel that Construct 2 is good for the job, it's just a matter of figuring out how to do it.

Thanks,

Dalal

Hmm... I would worry this would be too performance-intensive to work on mobile devices...

The way I'm doing it, it won't be too performance-intensive. I'm specifically targeting iOS devices for the first version, and a web prototype I did with Javascript and Canvas ran perfectly on an iPhone 4. It works well because I'm not calculating every single frame of the morph. I'm calculating about 30 frames spaced equally apart, and fading between them to produce the animation. That's all I need for my app.

In the web prototype, however, I was able to store the images using Javascript and 'new Image()'. I would calculate a frame by dumping the image in the canvas, doing my processing, and then converting from canvas back to image, and storing the result in an array of images. Then I would later make continuous draw calls to the canvas, drawing images from the array to display the animation.

If I were to write a plugin for Construct 2 that does the same thing (using the Javascript image type), what are the guarantees that it will convert gracefully to AppMobi for use with DirectCanvas? Otherwise, are there any other approaches anyone can suggest to achieving what I want.

Thanks!

In Rojo's Canvas you can paste the object, frame by frame, after your processing is done.

Where you plan to store those frames is another matter all together.

Yes, it looks like for my animation I can paste the images frame by frame using the Canvas plugin. My two questions:

1. On export to AppMobi using DirectCanvas, will Rojo's Canvas plugin use DirectCanvas, because I may need it to be hardware accelerated?

2. What would be a good way to store these frames?

You could use Pode's inject-base64 behaviors and store the frames as strings in the webstorage.

But I don't know if any of the plugins will work once exported through AppMobi.

There is a message in the SDK forum about this, and for now this is a testing period.

For now, best to try some tests export and see if each plugin/behavior is supported as of now. If not, it might be good to report it to the plugins authors and see if they can make a compatible version.

Now that sounds like a great option. I will look into it. Thanks Kyatric!