Multimedia Fusion's runtime engine.
|
|
Multimedia Fusion's runtime engine. |
|
Getting the most of the Multimedia Fusion's runtime engine. This tutorial is about what goes on inside the Multimedia Fusion runtime engine. What exactly does it do... and when... and how? How does it deal with conditions and actions, etc.? We lift the hood and take a look! If you're an advanced user - or are about to become one - you'll will find this especially valuable: here some explanations for the sometimes mysterious behaviours of Fusion's runtime engine as well as ways to make your applications run faster. But make sure you fasten your seat belts, this tutorial is a bit more complex than the previous ones! (Actually, the following information is valid for the whole click range: since Klik&Play, the main principles of the runtime engine has not changed - for compatibility reasons.)
Player object Keyboard object Timer object Storyboard
Object Question objects Any objects
in movements Any object
with an animation Any object All of the other conditions are not event-driven. A fake event starts with a non-event driven condition. The first conditions determines the behaviour of the event.
It can change a lot, specially the execution speed of your application. If a event-line starts with a true event-driven condition, Fusion only executes it when the event happens. For example, let's imagine an event that checks for a click and a complex calculation to end the frame:
The first condition is a true event-driven condition : Fusion ignores it completely until the Windows system indicates a click on the mouse. As a consequence, no processing power whatsoever is needed during 99.9% of the time. Let's reverse the order of the conditions, and insert the calculation before the click.
The calculation has to be evaluated for each loop of the application. In our example, Fusion looses valuable processing time each time round the loop calculating the sine and cosine. 99.9% of the time, the second condition is false, so Fusion does not execute the action: the result is of course the same than before, but the main loop has slowed down. The same is true with the collision detection: collision detection conditions should always come first in your lines of events. By inserting the true event-driven conditions first in your line of events, you'll maximise the efficiency of the Fusion runtime engine.
All the events beginning with a non-event-driven condition are evaluated one after the other at runtime, in the original order of the list. This should be taken in consideration when using counters and testing them. Let's create an example to demonstrate this. In the frame editor, drop one counter object, and three different text objects, placing them where you want in the frame.
Enter the following events in the event editor.
The example above initialises a counter at 1 when the frame starts. It then checks the value of the counter, and sets each of the string objects to the current value plus the position of the timer: this tells us exactly when the counter reached the given value during the run. Now run the frame, and you should get something like this:
Of
course, you could well get different timer values on different machines. Let's
see in detail what happens in our program : Now, change the order of the lines like this :
As you can see, we check for the counters in reverse order : 3, 2 then 1. Run this frame - the result should be very different :
Here
too, you may get different values for the timer depending on your machine.
Let's see what happens in the program: The same process as before now took 3 loops of the runtime to be executed, just by reversing the order of the events! You should take that into account when using counters in your list of events!
Groups
are certainly the best addition to the click range since Klik & Play.
I'm not going to go into their use in complex applications to structure
the list of events here - rather, I'll focus on the most handy feature
of a group of events: its ability to be activated or deactivated. Careful
use of this feature will dramatically reduce the complexity of your list
of events. Let's see how.... When creating a group of events, you have the
choice of activating it or deactivating it prior to running the frame.
A deactivated group of events will be completely ignored by Fusion. This
will not take any processing time (or very little). Passwords are used
in combination with the frames Run-Time option of Password. (which is
not part of this tutorial, sorry) Run the frame, you should get the following result.
- The group of
events is initialised at first: the first line of the group is executed
and the counter is set to 1 -> The position
of the deactivate action has no importance in the list of actions of
the line As you can see, one can very easily create complex lists of tasks to executed only once by using groups, always and deactivate. Imagine the creation of a complex character made of many different active objects and counters linked together. Place them in the same group of events, not activated at start of frame. Make sure that the last action of this group is to deactivate itself. To create one complex character, your program simply has to activate this group: it will perform the task only once and quit. It's a kind of routine inside events. Note: as we have seen before, if the activate action is placed before the group, the group will perform its task during the same loop of the runtime. If the activate action sits after the group, it will only be executed on the next loop...
Every game or demo programmer knows about it: a game is build around the main loop. Funnily enough, the main loop is a programmer's concept that the Click range of products hides completely, as its way of working is based on events and parallel programming. Despite the fact that the Click range does not mention the loop anywhere, it still exists! It is very much there - and it controls the way the runtime engine works! Every 1/50 of second, the Fusion's engine does the following : 1. Checks the
player inputs 1. Checks
the player inputs. 2. Animates
the objects one by one. - All the objects
are created one after the other, following the order in which they were
dropped on the frame in the frame editor. So if you drop object A, object
B and object C and immediately run the frame, that order will hold. Who cares, you might well ask? Well, this could explain some of the strange behaviours you might notice from time to time with the click range: sometimes an object bounces just fine and sometimes it just won't! Explanation of bizarre bounces with small objects... This kind of problems only occurs with small objects moving at fast pace.
The picture above represents two small objects moving toward each other at a fast pace. The scales of grey represent the last positions of the objects in movement. Let's imagine that the bat comes first in the animation loop. It will be the first to move, to the left, at its speed (slower than the ball).
As you can see above, after being moved to the left, the bat hits the ball. Fusion detects a collision, and the game works fine: the ball bounces on the bat. Now, let's image that the ball comes first in the animation loop. We will find ourselves with the following problematic situation :
As
the ball moves faster than the bat, it jumps over the bat and misses the
collision detection! The ball doesn't bounce on the bat and the game doesn't
work! We have programmed some specific routines in the Fusion engine to
prevent this kind of problem: fast movements are "cut" into
smaller chunks and a collision detection performed at each step. But
as this process is very time consuming, we had to limit it to objects
bigger than approximately 10 pixels for full speed. The object animation loop can call
the following event-driven conditions if they come first in a line
of events :
- Every is not called at this stage, but in the next stage, with the other events : it is not a true event-driven condition. 4. Performs
the other events. 5. Destroys
the objects. 6. Updates
the display 7. Handle
Windows messages 8. Checks
for end of loop
I hope this tutorial has shone some light on hidden aspects of the runtime engine. Knowing the way it works internally will allow you to program better and faster applications, and reduce the number of lines in the event editor.
|
|
Copyright © 2006 Clickteam. All
rights reserved. |
True and fake events.
Fusion runtime makes a distinction between a true event
and a fake event. 
