Tilebased games in Flash 5 - Part 10

And now a little more about scolling, this is not much of a tutorial, but more some ideas that I have tested and some rant about those...
I think you should have read and understood the first tutorial about scrolling if you want this to make some sense.

So you know the example in tutorial number 4, the technique there is to attach and remove tiles as the world scrolls. One thought I had was that it would be faster if the whole map is predrawn and instead of attach/remove, we alter the _visible state of the tiles as the world scrolls. One might think that this should use less of the cpu than attach/remove.

The downside should be that it might occupy more ram, but we should be able to live with that, since the bottleneck is almost always cpu-usage over ram-usage.
One more thing is that, if the map is very big, the for-loop that draws the map will freeze the flashplayer for a while. That could be solved by replacing the outer for-loop with a frameloop instead, and have a waiting-screen while it draws the map or something.

So is that faster? Well I donīt know... :) It dosenīt look like itīs faster. I havenīt been able to really measure if thereīs any difference. But something in my stomage tells me it should be... but donīt take my word for it.

Now the next thing I thougth about is only useful when the world only scrolls either horisontaly(like Super Mario) OR verticaly, not all directions(like Bombman).

The idea is that instead of attaching and removing tile by tile, we attach/remove a column of tiles at a time. The difference should be that instead of referencing to each tile, we now only need to reference to one column, should save some time.

So letīs use Super Mario as an example.

This is the first example, it uses the attach/remove technique, just like in tutorial number 4. The fla.

And hereīs another example, this one uses the column-technique instead. And it draws the entire map at once, it also alters the _visible-state instead of attach/remove. The fla.

Try running them at high speeds(not both at the same time though :)), is there any difference? Hmm... Iīm not sure... the second one maybe feels a little faster when the speed is like 6 and above, but not that much... or?
So my conclusion is that this dosenīt seem to matter that much, both works ok if itīs not a very fast scrolling game, but for faster scrolling... well I just donīt know.

I had very intersting mail-discussion with a fellow aliased as "mmlabs"(not sure if I can write his real name here) about this. He suggested that it might be faster to not have the 1 pixel transparent border around the bitmap-tiles(you know the 1 pixel border to get rid of distortion), and set the _xscale and _yscale of the _root to something like 98.98. I donīt really know whatīs up with distortion thing, seems to different results from time to time... :)
Anyway, we tried that, but I canīt say it helped as much as we wanted... :(

So what if we wanted to do a really fast scrolling game then?
Well we could allways try to get nit-picky about the syntax, you know using eval("t"+i) instead of this["t"+i], name tiles/columns to just integers instead of "t"+i since strings isnīt as fast and so on... Or we could try to optimize the bytecodes with Flasm or some similar app... But I donīt think any of that will help.

I think the real bottleneck is the way the flashplayer updates the stage or something like that. So the alternative as I see it(youīre not gonna like this...), is moving over to Director, which is much more powerful when it comes to stuff like this.
But I donīt think many flashers are willing to do that once they have gotten used to flash :) So if you got any suggestions/ideas, try them or let me know so I can try...

... oh yeah, you could always have the entire map in one big gif, scroll that and have the array only for collision-references :)) But that kinda ruins the idea with tilebased games, and your gonna end up with one huge swf...

(C) OutsideOfSociety 2002.