00:00
00:00
mongoid
I'm a freelance game developer working for all sorts of companies big and small, as well as spending time pushing out my own indie titles.

James Dalby @mongoid

Age 45, Male

Game Developer

UC Irvine

Irvine, CA

Joined on 1/3/02

Level:
9
Exp Points:
740 / 900
Exp Rank:
91,895
Vote Power:
5.09 votes
Rank:
Civilian
Global Rank:
96,342
Blams:
28
Saves:
26
B/P Bonus:
0%
Whistle:
Normal
Trophies:
5
Medals:
300
Supporter:
4y 11m 3d

MageQuest: AS 3.0 scrolling bitmap background with parallax!

Posted by mongoid - February 13th, 2008


Hey everyone! I just finished the final prototype for a scrolling bitmap background with parallax in ActionScript 3.0. It turns out that doing it this way, as opposed to a tile-based scrolling background, is way more efficient! Oh boy, more overhead for more enemies and particles, or (dare I say) AS 3.0 filter effects!

You can check it out on my dev blog. I even give you some code to tinker around with. Now on to developing the platform engine!

Let me know what you think!


Comments

U impress me wit the smartness!

Haha, thanks.

So that's faster that changing the position of 2 clips cached as bitmap?

If the clips are 2400x1200 and 1200x600, like the ones in my example, then yes. You actually made me want to test that, so I did. Slapping two huge bitmaps on the stage and making them move in parallax is still pretty fast, but it was prone to spikes in CPU load for some odd reason and still wasn't as fast as my method. :-)

wankan! heheheh nice picture dude smarterr haha nice mate

Interesting. I figured the overhead of actually redrawing the bitmaps every frame would make scrolling two big, preloaded bitmaps more efficient. But I guess even then flash still has to redraw it every frame as it moves it.

It's actually pretty close to my method. But when skrimping and saving as much as I am for MageQuest, I'll take all that I can get. ~3% more CPU time means that I might have 6 more enemies on screen running their A* search and destroy algorithms without any noticeable lag. But then again, I could just be talking out of my ass since it's so early in development.

there's just something so unholy about the example D:

The planet scares me... though my laptop on weakest settings runs it without any problems whatsoever, so I guess you're doing something right :D!

haha, that's good!

If you wouldn't mind, tell me what kind of laptop you have (CPU, RAM, OS) and use your task manager to tell me what percentage of the CPU is being used while you run the example. I have a pretty powerful machine, so I'd really like to see how it performs on slower ones.

dude, your crazy good at AS! D:

Haha, thanks. :-P

Have you compared it to using a scrollRect on each image? It seems like that might be faster since there's no offscreen rendering and no need to copy pixels yourself.
I'm not sure if scrollRect gives you good performance used directly with bitmaps though. It might need you to use cacheAsBitmap which would mean twice the memory usage.

Hmmm, you're the second person to recommend that. From what I've read, scrollRect() is set when ImageViewer is drawn (by draw()), and copyPixels() has been proven to be more efficient than draw(). That's the best I can come up with without making a test case.

:-)

Sure no problems.

- I have 2 Gigs of RAM
- Windows Vista
- 1.6 Intel 2 Duo Core
- Run at weakest settings, it takes up about 12% of my CPU (task manager says 20-25, but I have other crap in the background, Firefox, the browser running the demo says 12-14% so i'm going with that.)

Awesome, thanks! That load on the CPU is well below my tolerance levels. :-)