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…


    Sorry, no Tweets were found.