|
Moczan
|
 |
« Reply #405 on: May 25, 2012, 02:30:19 AM » |
|
Why is that? Shouldn't screen panning be just a change to X and Y of a camera, the amount of stuff being drawn being roughly the same all the time?
|
|
|
|
|
Logged
|
|
|
|
|
Craig Stern
|
|
« Reply #406 on: May 25, 2012, 04:06:10 AM » |
|
No--Flash only redraws regions of the screen where there are changes. (And if memory serves, it actually does this when there are changes offscreen as well.) So if the background is static, it only redraws the things moving on the background; if the background moves, it has to redraw the entire background.
That said, this didn't cause any slowdown on the netbook back when I first implemented it, so I'm not sure why the panning is killing the framerate now.
|
|
|
|
|
Logged
|
|
|
|
|
st33d
Guest
|
|
« Reply #407 on: May 25, 2012, 05:35:41 AM » |
|
You blitting or using just MovieClips? If using the latter, your limit is about 300 to 400 (including nested).
Flash does some really weird optimisation trick with non-moving movieclips. In benchmark tests I did it had no upper limit on static movieclips. Move them, and then it chugs.
So you might already be over the limit and Flash is hiding it from you. You might be able to pull it back by transferring rendering of some stuff like special effects to copyPixels.
|
|
|
|
|
Logged
|
|
|
|
|
Craig Stern
|
|
« Reply #408 on: May 25, 2012, 05:58:35 AM » |
|
I'm exclusively using Sprites and Bitmaps for objects nested in the battlefield (Sprites for characters and destructible objects, Bitmaps for level tiles). The Battlefield itself extends Movieclip--or it did until just now. (I just changed it to extend Sprite and it works just as well.)
Does that limit apply to sprites as well as movieclips?
|
|
|
|
|
Logged
|
|
|
|
|
st33d
Guest
|
|
« Reply #409 on: May 25, 2012, 06:12:57 AM » |
|
DisplayObjects are all the same beast. There's very little benefit in using Sprite over MovieClip really.
If you've got lots of tiles and lots of them are static then you could print them all to one big ass bitmap with bitmapData.draw. That would get you a fair bit of speed back.
I personally use a flixel-style rendering system in combination with some of the old school stuff.
|
|
|
|
|
Logged
|
|
|
|
|
Craig Stern
|
|
« Reply #410 on: May 25, 2012, 06:26:10 AM » |
|
Well, I learned something today! I'm going to try that little trick right now.  |
|
|
|
|
Logged
|
|
|
|
|
Craig Stern
|
|
« Reply #411 on: May 25, 2012, 07:56:41 AM » |
|
Well, that was easy: the battlefield now draws all of its individual tiles' BitMapData into a single, giant Bitmap upon loading. The game already ran fast on my netbook notebook, but this seems to have given it a little extra oomph! I'll have to wait till later, when I get home, to see how this affects performance on the netbook.
|
|
|
|
« Last Edit: May 25, 2012, 04:04:37 PM by Craig Stern »
|
Logged
|
|
|
|
|
st33d
Guest
|
|
« Reply #412 on: May 25, 2012, 08:10:04 AM » |
|
 You can get a little extra by setting visibility to false on items offscreen. It won't factor those into the redraw.
|
|
|
|
|
Logged
|
|
|
|
|
Craig Stern
|
|
« Reply #413 on: May 25, 2012, 01:47:30 PM » |
|
You don't say? I seem to remember from my AS2 days that setting _visible to false didn't do anything for performance. Does visible behave differently in AS3?
|
|
|
|
|
Logged
|
|
|
|
|
st33d
Guest
|
|
« Reply #414 on: May 25, 2012, 02:41:44 PM » |
|
It won't execute the render, though it will stay in the display list (which means that Flash still has an extra item to iterate through, just not process).
|
|
|
|
|
Logged
|
|
|
|
|
Moczan
|
|
« Reply #415 on: May 25, 2012, 02:49:16 PM » |
|
Yeah, I was surprised because Flash is capable of easily displaying and scrolling a screenful of tiles. With copyPixels I was able to fill a 640x480 screen with 32x32 tiles (300 tiles), tens of enemies and call awfully non-optimal collision detection and it ran 30 fps on older gear, so I imagine only things that can choke turn-based game performance (in Flash) are alpha-blending (which you probably experienced while playing with fog of war) and AI logic.
|
|
|
|
|
Logged
|
|
|
|
|
Craig Stern
|
|
« Reply #416 on: May 25, 2012, 02:54:25 PM » |
|
Confirmed: netbook performance is good once more. Whenever I port this to Android, I expect I'll use opaque black blob shadows to avoid alpha blending and its associated performance hit. |
|
|
|
|
Logged
|
|
|
|
|
Moczan
|
|
« Reply #417 on: May 26, 2012, 02:45:01 AM » |
|
Confirmed: netbook performance is good once more. Whenever I port this to Android, I expect I'll use opaque black blob shadows to avoid alpha blending and its associated performance hit. Actually AIR for mobile has non-Stage3D GPU rendering using your typical DisplayObjects, so it can have better performance than same non-Stage3D desktop/web version. Andy Moore (Steambirds) wrote about it on his blog http://www.andymoore.ca/2012/01/how-to-improve-your-mobile-as3air-performance/ |
|
|
|
|
Logged
|
|
|
|
|
Craig Stern
|
|
« Reply #418 on: May 26, 2012, 07:05:15 AM » |
|
Nice--bookmark'd! |
|
|
|
|
Logged
|
|
|
|
|
Craig Stern
|
|
« Reply #419 on: May 26, 2012, 11:05:18 AM » |
|
As sort of an experiment, I added touchscreen controls to Telepath Tactics and tried exporting it to my Android phone, just to see how it would run. The answer: it runs perfectly right up until I tell it to start a battle; then it freezes on the loading screen. Maybe there's something about the way it dynamically loads external assets that Android doesn't like? Honestly, I'm not sure. Mobile development is still a mystery to me at this point.
But no matter! Getting it finished on PC is top priority.
|
|
|
|
|
Logged
|
|
|
|
|
Developer
