I wrote a game that uses a rev app as a level editor. I used the same tilemap approach that is being discussed, with a grid of buttons which take on different images depending on what is being 'painted' on the level. There are close to 600 buttons in all and the speed is remarkable. Painting objects takes place in real time. Entire levels load in a few seconds on my 400 Mhz G4. I don't know about scrolling though..
Both the game and the level editor are available at: http://www.crystalpiersw.com There are both Macintosh and Windows versions, but you need to register to use the Macintosh world editor (soon to be changed). Windows users can already use the world editor without registering. I found that it is imperative for decent performance to NOT keep the information about what is in what position in the buttons themselves. For instance, to query what is in grid pos (2,4), you should NOT have to find the button at (2,4), and then access some custom property of that button (or the button's name or icon) to determine what occupies that grid spot. A much faster approach is to keep a behind-the-scenes field of what is where, each line representing a row of the grid and each item representing a column. When you need to find out what is at pos (2,4), inspect item 2 of line 4 of your field. Also, I found it helpful to keep a separate 'lookup' field of button ids, again each line representing a row of the grid and each item representing a column. When you need set the button's icon at (2,4), you can lookup the button's ID from item 2 of line 4 of your lookup field. Probably both these fields could be replaced by arrays (perhaps with a speed bonus?), but I have had some trouble with two dimensional arrays in the past and opted to steer clear. Abstracting the logic that keeps track of what is where in the level as well as giving the right icons to the right buttons into a 'brick wall' library was also helpful. >From what I've seen I think a scrolling game could be feasible using the button-grid approach but speed would definately be a problem it it wasn't structured correctly. All game logic should take place 'behind the scenes' and should NOT depend on getting or storing information in the buttons themselves. Just my 2-sense. Good luck! Dave _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution