mTropolis Refugees

John Tregea john at debraneys.com
Thu Nov 17 03:27:12 EST 2005


I used mTropolis 2.0 for an interactive CD/ROM that was used to promote
Singapore. We had QTVR's of Raffles hotel and other famous landmarks,
quicktime video, stills, maps and most innovatively at that time live links
to the updatable information on the web for hotel bookings and theme park
availability etc. Oh, those were the days.

What a fantastic product it was, and I still say "Damn Adobe and Quark" for
killing it between them...

Cheers 

John T

-----Original Message-----
From: use-revolution-bounces at lists.runrev.com
[mailto:use-revolution-bounces at lists.runrev.com] On Behalf Of Scott Rossi
Sent: Thursday, November 17, 2005 11:37 AM
To: How to use Revolution
Subject: Re: mTropolis Refugees

Recently,Janus Jakaterina wrote:

> Are there many mTropolis folk now residing in the land of Revolution?

Not a refugee, more like a second cousin's nephew, twice removed, who
visited once in a while...

 
> If so, how is Revolution for behaviors, aliasing, and messaging?

Again, I'm no mTropolis expert (mTropolis was a long time ago by the way),
but you can give objects their own behaviors that allow them to live, act
and die on their own using something like "send xyz to me..."  Messages can
also be passed from objects to the "environment" of the card and stack,
either using the previous "send..." command or automatically via Rev's
message hierarchy (see here for a good explanation of Rev's message path:
<http://www.fourthworld.com/embassy/articles/revolution_message_path.html>).

The issue you have to watch out for is having dozens of things happening on
screen at once; Rev is not really optimized for this kind of thing across
the board (low end graphics cards and/or processors can affect performance),
but with careful design (and lots of testing) you can get away with some
decent animation/movement.

 
> Other than the arcade engine, which seems to be a 3rd party product, 
> can Revolution handle multiple moving objects or collision detection?

Yes to both.  You can search the list archives for more info on this, and
the following was posted just the other day:

Date: Mon, 14 Nov 2005 20:01:57 -0800
Subject: Re: maze wall algorithm
From: Scott Rossi
To: How to use Revolution

Recently,N Cueto wrote:

> If given a maze in the form of a
> grid
> ...
> then, what would be the
> ideal scripting for limiting
> "movement" between only
> contiguous squares that are
> not separated by a wall

The way I've done something like this in the past is to use physical
boundaries, in other words, using the intersect and/or within functions to
prevent/constrain movement in certain directions.  From your example, it's
not clear if you *need* to limit movement based on numerical progression,
but this could be handled easily via the loc property, as you guessed.

You could use rectangle "wall" graphics combined with the above functions to
allow for moveable obstacles, and test for collision with the graphics on
the current maze/screen.  Alternatively, if you were able to use a single
image as your maze, this would allow for testing intersect/within results
within a single object -- the image.  This is the benefit of using images
for collision detection in that you can test for non-transparent pixel
collisions, as opposed to using graphics which only allow for rects.  I
don't know if images would work in your situation but that was the technique
I used and it's reliable.

Let me know if this makes sense (or if not, maybe I can dig up an old demo).

Of course, one must also keep in mind Malte Brill's Arcade Engine...

[end post]


Regards,

Scott Rossi
Creative Director
Tactile Media, Multimedia & Design
-----
E: scott at tactilemedia.com
W: http://www.tactilemedia.com

_______________________________________________
use-revolution mailing list
use-revolution at lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution




More information about the Use-livecode mailing list