A variable-less option might be to have a 'Trigger Once' 'Else' structure as sub-events for each condition. Still a bit repetitive, but now you only have one event block, have to define the conditions only once, and use no variables.

<font face="Courier New, Courier, mono">

-------------------------------

|[Condition A ]:              |

|    [Trigger-Once]:[Action A]|

|    [Else]        :[Action B]|

|[Condition B ]:              |

|    [Trigger-Once]:          |

|    [Else]        :[Action C]|

|[Condition C ]:              |

|    [Trigger-Once]:          |

|    [Else]        :[Action D]|

|[Condition D ]:              |

|    [Trigger-Once]:          |

|    [Else]        :[Action E]|

|[Condition E ]:              |

|    [Trigger-Once]:          |

|    [Else]        :[Action F]|

-------------------------------

</font>

How's that?

The smoothing of the scrolling algorithm is very simple as far as I can tell. Let's say you have two positions A (X = 0) and B (X = 360). To smoothly move from position A to position B, start at position A and then add a fraction of the difference between A and B. The number you divide by determines the speed of the scroll. It provides a nice smooth scrolling effect without the need for any fancy calculations. Something like:

Scroll.X = A.X + (B.X - A.X)/30 (experiment with that number 30, the higher it is, the slower the scroll). In this example, on the first frame, Scroll.X will be 0. On the last frame of this algorithm, it will be 360. The only thing that changes based on the '30' is the speed at which the scroll takes place. The starting and ending points will remain the same (which is one of the things Mulkaccino was talking about when he mentioned stick-to points). So this (the 30) is the number that should be tweaked based on the flick velocity. We can call this number the 'smoothing ratio'.

To determine the smoothing ratio (which is what I'm calling the number to divide by i.e 30 in the example), take the flick velocity into account. Whenever they let go, get the difference between the initial touch point X and the release point X and divide by the time it took for them to perform this action (which will get you the velocity = distance/time). So you'll need to record the time the initial touch occurs, and then find the difference when they release, and then calculate your speed. The greater the speed, the lower your smoothing ratio should be, creating a faster scroll.

A simple way to determine the smoothing ratio might be something like 30/speed. So now when you have really high speeds, you'll get a really low smoothing ratio. Experiment with numbers until you get something that looks natural based on the velocity of the flick. I chose 30 randomly. The best part about this technique is that no matter the speed of the flick, it will always scroll to the same position, and smoothly too. All the flick will determine is how fast this scroll will take place.

Alternatively, you could do what Mulkaccino was talking about, which is a great way to do it that offers the user control over HOW much they scroll based on velocity. Calculate the velocity using what I said above and then apply that velocity to the scroll as follows:

Scroll.X = Scroll.X + Velocity * dt.

Every frame, keep decreasing the Velocity (by a multiple of dt I guess) until it equals zero.

The only problem with my version of this approach is that you won't have a defined end point for the scroll. They could potentially flick too fast, causing the scroll to go on for way longer than expected. You could limit the speed of the scroll, but then it may feel unnatural because the speed did not initially correspond to the flick. Mulkaccino may be able to offer more insight in this area.

If I'm understanding this right, the first event block handles the first occurrence of those conditions, and the second block handles all subsequent occurrences of those conditions. Is that correct?

If so, could you get by with setting a Boolean from ON to OFF when these conditions are run, and include Action A in a sub-event of Condition A that only runs when this Boolean is ON? Likewise, include Action B in another sub-event for Condition A that only runs when the Boolean is OFF. Alternatively, use the new 'else' logic so you only have to test for the Boolean once. Does that work? And let me know if I need to elaborate.

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