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: [EMAIL PROTECTED] W: http://www.tactilemedia.com _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution