Some of the finest software and a lot of the ground breaking innovations on the Internet were not founded by Netscape, or Microsoft or even Sun Microsystems, rather they were kicked off by smaller companies made up of groups of computer enthusiasts. More than the big guys, it is these people who keep the flame of innovation burning bright. Once again, it is these tiny companies who are leading the pack when it comes to animation languages and other products for the Internet. The 'net is in such a state of flux that I wouldn't be to shocked if tomorrow one of this insignificant little enterprises grew to prominence on the strength of their products, beating the big fish at their own game. If mBED lives up to it's promises, it could be the one.
We've used a Pentium 66 with 16 MB RAM, a large hard disk, Windows95 and a Display adapter set to 256 colors. As I say every time, I don't know if it will work on anything less, but it doesn't hurt to try.
It is these languages that reinforce my belief that specialization is the future. C and Java are great languages. You can do almost anything you want using them, create applications, compilers, anything. You can also do great animation in C, but it's just too much effort. C lets you do too many things, it gives you too many choices. On the other hand, mBED is tailored for animation, especially on the Web. Another thing in their favor is, as I've mentioned before, that the guys behind mBED have promised to release an application which will make it extremely easy for non-programmers to use mBED. This may be the key to their success, so it's vital that they deliver and soon.
After reading this tutorial, you'll probably send us email about how you adore us and how you'll give everything you own to meet us and how, if we don't supply regular updates, you'll go into withdrawal. But spare a thought for the guys at mBED, if you like their product, send them mail too. It's the least you can do
As I mentioned earlier, mBED bears more than a passing resemblance to HTML and if you're comfortable with the latter, you'll pick up the former real fast. In the same way as HTML documents started off with <html> and ended with </html>, mBED programs start with <mbedlet> and end with </mbedlet>. It's also case insensitive, just like HTML. The word mbedlet proves that mBED is a Java wanna be, but hey, who doesn't hanker after fame and fortune ?
m1.mbd
<mbedlet>
<players>
<sprite name=bg>
<data>
backgrnd.gif
</data>
<properties>
visible=true
</properties>
</sprite>
</players>
</mbedlet>
Every mbedlet can have a number of players which are mBED's functions. A player maybe something you see on the screen, like pictures and animation, or it could be sound. These pre-defined players, or functions, whatever you want to call them, are quite useful and let you perform a range of operations. We have only one player at present, a sprite ( GK. A sprite's real meaning is imp or elf ). We generally use sprites for animation and each sprite has to be given a separate, unique name. Living up to our chatty image, we've give out sprite the descriptive name bg.
Every sprite must have data, nicely enclosed within data tags. The minimum amount of information one can have is the name of the .gif or .jpg file to be animated. Here we've used a file that comes along with the development package, backgrnd.gif. The sprite also has a certain set of properties. The only one we've use is visible and we've set it to true. If you don't do this then your sprite will appear for a fraction of a second and then disappear.
Save the program with the extension .mbd and load on mbedplay32.exe. Load the correct file and run it. Notice that this language, like Java, is compiled at run time. Wonder of wonders, the .gif will appear displayed on the screen. It worked !!. Okay, now cut down on the euphoria, even HTML can do this, but read on and be amazed !
m2.mbd
<mbedlet>
<players>
<sprite name=bg>
<data>
backgrnd.gif
</data>
<properties>
visible=true
location = 140,10
blend = 50
</properties>
</sprite>
</players>
</mbedlet>
Not much difference is there, but this time we've added two new properties, location and blend. Location obviously states where on the screen the image should appear and this is given by the coordinates 140,10 ( in pixels ). Blend stands for the opacity of the gif. The range is from 0 to 100, the higher the value the less transparent it is. A little extra, -- is used to comment code in mBED.
m3.mbd
<mbedlet>
<players>
<sprite name=bg>
<data>
backgrnd.gif
</data>
<properties>
visible=true
location = 140,10
blendcolor = 0,255,0
</properties>
</sprite>
</players>
</mbedlet>
Blend color still has us confused. It's stated function is changing the color of an image , but it really doesn't seem to work out that way. When we try to set the color to deep red, it turns the image light pink !! We really can't figure it out. HELP US !!!
Now lets look at the next program
m4.mbd
<mbedlet>
<players>
<sprite name=bg>
<data>
backgrnd.gif
</data>
<properties>
visible=true
location = 140,10
blend = 50
blendcolor = 0,255,0
</properties>
<handlers>
<mouseenter>
me set blend = 100
</mouseenter>
<mouseleave>
me set blend = 0
</mouseleave>
</handlers>
</sprite>
</players>
</mbedlet>
It's now that you will realize why these animation languages are so good and why we believe you should learn them. We are going to add a handler to our player, enabling it to detect mouse movements. Handlers let you assign tasks to a particular player and give you the power to bring your gifs alive !!
In this program, we're using the reserved words mouseenter and mouseleave. These words lets the program sense when the mouse pointer enters the players area ( it's playground, if you will !! ). We have also detailed the action to be taken when the users mouse invades the sprites gif. In this program we change the blend levels depending on the location of the mouse in the window, so each time you enter and leave the image frame, the blend effect changes.
me is a pointer to the presently activated sprite, bg. If you have more than one sprite, or you want to ' handle ' it from outside, you might run into difficulties as the pointer only represents the player it is used in.
Ofcourse, there is a simple way out, as demonstrated below....
m5.mbd
<mbedlet>
<players>
<sprite name=bg>
<data>
backgrnd.gif
</data>
<properties>
visible=true
-- blend = 50
-- blendcolor = 0,255,0
</properties>
</sprite>
<sprite name=ag>
<data>
backgrnd.gif
</data>
<properties>
visible=true
location = 140,10
blend = 50
blendcolor = 0,255,0
</properties>
<handlers>
<mouseenter>
bg set blend = 100
</mouseenter>
<mouseleave>
bg set blend = 0
</mouseleave>
</handlers>
</sprite>
</players>
</mbedlet>
In this here program, we have two sprites, bg and ag. Instead of ' handling ' bg from inside it, we decided to link it up with ag. The net effect is that when you enter the picture frame of ag, bg's blend levels fluctuate, but when you enter bg, nothing happens. In this way we've transferred bg's handlers over to ag, linking up the two in the process.
If you were programming in C under DOS, you'd have to keep a constant eye on your mouse, it would be your responsibility. However, in mBED, as in Windows programming, the mouse is provided and looked after by the program and this really takes a load off the programmers mind !
m6.mbd
<mbedlet>
<players>
<sprite name=bg>
<data>
comet1.gif
</data>
</sprite>
<path name = c3>
<properties>
duration = 1000
startpoint = 0,90
endpoint = 320,90
</properties>
</path>
<score name = s1>
<data>
0000 c3 play bg
6000 me end
</data>
<properties>
playforever = true
</properties>
</score>
</players>
<handlers>
<startup>
s1 play
</startup>
</handlers>
</mbedlet>
Now in the above program , we've got two player, path and score. We also have a global handler, containing the name of the score to be played at startup. Unlike the earlier local handlers, which only affected their respective players, a global handler affects all the players.
s1, the score to be played at startup, contains data, which further contains the properties of the score. At the moment score only contains one property, playforever, set to true. Playforever forces the program to loop continuously.
The score sets the pace of the whole program and it is the place where a lot of the rules are specified. It contains the instructions to run a particular player, at a specified time. Think of the commands in score as a sort of timeline, with each specific player given a certain amount of time to work its magic. Here, in this program, we've instructed score to play the sprite bg with the path c3 at 0000, i.e. at the beginning of the program. Play decides how a player ( the sprite ), will act. Imagine doing all of this in C/C++ or Java. I can't !!
Lets tackle the path ( c3 )first. A path is a player that decides how other players, namely sprites, will behave. In path, we define the track that the sprite bg is to follow in it's traverse across the screen. We've given a starting and an ending point along with the duration. So the image comet1.gif will start from 0,90 and travel to 320,90, in just one second ( duration = 1000 milliseconds ). Once the image has reached the end of its sprint, it will wait for five more seconds ( 6000 me end ) and then stop. But because playforever is equal to true, it will start its journey once again. Try out different setting for the duration and the me end statement in the score. You'll understand the concept better.
The score, as mentioned before ( Hey, that rhymes !! ), times the graceful ballet as the comet streaks across the window, again and again. All the actual animations are stated in the score, while the path guides the sprite across the screen.
Onward to program 7 .
m7.mbd
<mbedlet>
<players>
<sprite name=bg>
<data>
comet1.gif
</data>
<properties>
visible = true
</properties>
</sprite>
<path name = c3>
<properties>
duration = 7000
startpoint = 0,90
endpoint = 320,90
</properties>
</path>
<path name = c4>
<properties>
duration = 6000
startpoint = 0,0
endpoint = 0,200
</properties>
</path>
<score name = s1>
<data>
0000 c3 play bg
4000 c4 play bg
7000 me end
</data>
<properties>
playforever = true
</properties>
</score>
</players>
<handlers>
<startup>
s1 play
</startup>
</handlers>
</mbedlet>
The animation flickers about a bit, but it's better than a lot of other products we've seen.
Forward to program no. 8
m8.mbd
<mbedlet>
<slots>
ptime = 3000
</slots>
<prototypes>
<path name=pn1>
<properties>
duration = $ptime
curvetype = bezier
</properties>
</path>
</prototypes>
<players>
<sprite name=m>
<data>
m.gif
</data>
</sprite>
<pn1 name=c1>
<properties>
startpoint = 10,10
endpoint =120,200
controlpoint1=10,200
controlpoint2=120,60
</properties>
</pn1>
<score name=s1>
<data>
0000 c1 play m
6000 me end
</data>
<properties>
playforever = true
</properties>
</score>
</players>
<handlers>
<startup>
s1 play
</startup>
</handlers>
</mbedlet>
In program no. 8, we introduce two new tags . Slots and prototypes. Every programming language must have variables and mBED is no exception. Slots are simply compartments into which we stuff all our variables. At the moment we're using only one, ptime, which represents 3000 milliseconds. Although Ptime is a variable, we've used it more like a macro ( since we don't change it's value at all ). To use a variables value in a statement, it must be proceeded by a $ sign, or else the program will not work.
Prototypes are like classes and their data can be added to our own properties. So, we can use the properties of the path pn1, because it is global. This really is just a time saving feature of mBED, using with we can reduce the length of our code.
The program also uses the curve type function, set to bezier. Since we are using this function we have to define the four points of a bezier curve. They are the start, the end and the two control points where the curve bends. The function curve type is in the global path pn1, but since we've said <pn1 name = c1>, the properties of c1 are supplemented by pn1.
I guess you can figure out the rest for yourself. Experiment, experiment, it is the best way to learn.
Now to Program no. 9
m9.mbd
<mbedlet>
<slots>
ptime = 1000
</slots>
<prototypes>
<path name=pn1>
<properties>
duration = $ptime
curvetype = bezier
</properties>
</path>
</prototypes>
<players>
<sprite name=m>
<data>
m.gif
</data>
</sprite>
<sprite name=b>
<data>
b.gif
</data>
</sprite>
<sprite name=e>
<data>
e.gif
</data>
</sprite>
<sprite name=d>
<data>
d.gif
</data>
</sprite>
<pn1 name=c1>
<properties>
startpoint = 10,10
endpoint =120,200
controlpoint1=400,200
controlpoint2=120,60
</properties>
</pn>
<pn1 name=c2>
<properties>
startpoint = 10,10
endpoint =170,200
controlpoint1=10,200
controlpoint2=170,60
</properties>
</pn>
<pn1 name=c3>
<properties>
startpoint = 10,10
endpoint =205,200
controlpoint1=10,200
controlpoint2=205,60
</properties>
</pn>
<pn1 name=c4>
<properties>
startpoint = 10,10
endpoint =240,200
controlpoint1=10,200
controlpoint2=120,60
</properties>
</pn>
<score name=s1>
<data>
0000 c1 play m
0000 c2 play b
0000 c3 play e
0000 c4 play d
4000 m hide
4000 b hide
4000 e hide
4000 d hide
6000 me end
</data>
<properties>
playforever = true
</properties>
</score>
</players>
<handlers>
<startup>
s1 play
</startup>
</handlers>
</mbedlet>
Program 9 and 10 are very similar, only the output differs a bit. Here we have complicated the code a little by adding more sprites and functions like hide, which makes the specified sprite vanish. It is now that the true value of this structured code is seen. Without its rigidity, you could never have been able to follow the thread of the program. Just remember, somtimes, it's easier to read the listing from the bottom up.
Program no. 10
m10.mbd
<mbedlet>
<slots>
ptime = 1000
</slots>
<prototypes>
<path name=pn1>
<properties>
duration = $ptime
curvetype = bezier
</properties>
</path>
</prototypes>
<players>
<sprite name=m>
<data>
m.gif
</data>
</sprite>
<sprite name=b>
<data>
b.gif
</data>
</sprite>
<sprite name=e>
<data>
e.gif
</data>
</sprite>
<sprite name=d>
<data>
d.gif
</data>
</sprite>
<pn1 name=c1>
<properties>
startpoint = 10,10
endpoint =120,200
controlpoint1=400,200
controlpoint2=120,60
</properties>
</pn>
<pn1 name=c2>
<properties>
startpoint = 10,10
endpoint =170,200
controlpoint1=600,200
controlpoint2=170,60
</properties>
</pn>
<pn1 name=c3>
<properties>
startpoint = 10,10
endpoint =205,200
controlpoint1=10,200
controlpoint2=205,60
</properties>
</pn>
<pn1 name=c4>
<properties>
startpoint = 10,10
endpoint =240,200
controlpoint1=10,200
controlpoint2=120,60
</properties>
</pn>
<score name=s1>
<data>
0000 c1 play m
0000 c2 play b
0000 c3 play e
0000 c4 play d
4000 m hide
4000 b hide
4000 e hide
4000 d hide
6000 me end
</data>
<properties>
playforever = true
</properties>
</score>
</players>
<handlers>
<startup>
s1 play
</startup>
</handlers>
</mbedlet>
This is program no. 11.
m11.mbd
<mbedlet>
<prototypes>
<sprite name=s1>
<data>
m.gif
b.gif
</data>
<properties>
visible=true
</properties>
<handlers>
<mouseup>
me flip
</mouseup>
</handlers>
</sprite>
</prototypes>
<players>
<s1 name=sp1>
<properties>
location = 100,100
</properties>
</s1>
</players>
</mbedlet>
In this program, we have provided sprite with two images, scrunched between the data tags. Each time you activate mouseup by releasing the left mouse button, the images are switched ,or flipped if you will. There is another, related function named mousedown, which is activated when the left mouse button is pressed. In this way, it is possible to associate two actions with one complete, two stage, mouse click. There are only two images present in this program, but there could have been twenty two, it all up to you. ( A poet, and I didn't even know it !!)
m12.mbd
<mbedlet>
<prototypes>
<sprite name=s1>
<data>
m.gif
b.gif
</data>
<properties>
visible=true
</properties>
<handlers>
<mouseup>
me flip
</mouseup>
</handlers>
</sprite>
</prototypes>
<players>
<path name = path1>
<properties>
duration = 2000
flipinterval = 50
startpoint = 110,210
endpoint = 110, 210
easein = 10
easeout = 110
playforever = true
curvetype=bezier
</properties>
</path>
<s1 name = ball>
<handlers>
<mouseup>
me flip
path1 play me
</mouseup>
</handlers>
</s1>
</players>
</mbedlet>
In this program, after, the first mouse click, the images m.gif and b.gif will flip continuously and at the same time will travel up and down the pre-defined path. Play around with ease in and ease out to fully understand their effect on the program output.
Mr. Vijay Mukhi
Ms. Sonal Kotecha
Mr. Arsalan Zaidi