next »

[archagon]

DrPetter mentioned that he used a single bitmap for Chup's graphics: "The bitmap graphics are all done by simply copying rectangular regions between different bitmaps and having a single 320x240 one attached to the scene at 2x scaling. It all basically ends up being exactly like coding pixel games in any traditional language/api."

The flixel framework, on the other hand, uses more conventional display list techniques.

What are the pros and cons of each method?

[Matt Thorson]

I was brand new to Flash development when I wrote my engine, which is similar to Flixel.  I didn't even know of the 'direct' method you speak of which is used in Chup.

I haven't run into any performance problems, but I'm not doing anything all that taxing either.  I'll probably give the other method a shot too for my next game, just to see the differences.

[Problem Machine]

Oh shit Flixel's online now? I'll have to check that out.
For the engine I've been piecing together for work, I have it set up to use DisplayObject, BitmapData, and two custom classes (BitmapAnimation and ParticleSystem) interchangeably. The performance boost you get for direct blitting is really tremendous, but losing the ability to rotate and scale is a bitch. Mixing the two is a pretty good way to play it if you can pull it off, IMO.

[John Nesky]

The flixel framework, on the other hand, uses more conventional display list techniques.

No it doesn't, unless I'm confused. It does the same thing as Chup. It draws the sprites into an internal buffer in the FlxSprite.render() function.

[archagon]

Oh, really? I haven't looked at the framework yet, but grumblebee on MeFi says otherwise.

It's also possible that I'm completely and utterly confused.

[John Nesky]

What he's saying is that you have the option to render vector graphics into flixel's internal screen buffer, which then gets displayed on the screen as a simple bitmap without any other fancy display objects.

[archagon]

Ah! I see.

The question still stands though, because other people (like Matt) are using the display list method.

[John Nesky]

Basically, if you want to use pixel art, use the raster method.

If you want to use non-pixel art, but you don't want to think too hard about optimization, use the display list.

If you want to use non-pixel art, but you care a lot about optimization, study both methods, learn how they work and why they're useful, and use a hybrid approach that is a good fit for your application. I like to create vector graphics, and then render them to a bitmap once, and then parade that bitmap around my display list as a sprite instead of the original vector graphics.

[Problem Machine]

Hey, yeah, I should add something like that to my thing! Man, people keep giving me great ideas today 

[Sam]

There's a nice brief article on GamePoetry about just this:
http://www.gamepoetry.com/blog/2008/10/17/fastest-frame-rates-with-optimized-rendering/

He gives three cases for rendering:

1.  DisplayList with vectors/bitmaps/anything and everything.

2.  Raster method of copyPixel'ing all your graphics to a single bitmap which is your "screen".

3.  DisplayList, but limiting yourself to bitmaps without any fancy effects applied to them.

Unsurprisingly 1 is pretty damn slow.  2 and 3 however are very similar in speed, and he actually found 3 to be slightly faster (not sure how much optimisation of 2 he did though - like only clearing areas of the bitmapdata that have changed since the last frame.)

I happily used rastering for my first Flash projects, as I'm used to working with setting pixels on a screen.  For my current project I'm working with the displaylist, and limiting myself to bitmaps.  I'm doing just fine with performance so far, and it looks just the same as if I were copyPixel'ing to a screen.  I figure it will also do me good to get to grips with what's a pretty central component of Flash.

[raigan]

I find it pretty ironic that Flash started off as a vector graphics tool, but is now best at sprite-based games

[John Nesky]

Raster graphics is inherently computationally easy. It would be a shame if Flash *couldn't* do that. But Flash also gives you the option to do much more complicated stuff, and I applaud that.

[archagon]

Salt, thank you! That's brilliant. (And everyone else, too! Especially John.)

[Johan Peitz]

It's not that hard implementing a display list (shouldn't that be display tree?) on a blitting engine. And having the possibility to assign children to an object is extremely convinient. I do have a hard time beliving that option 3 should be faster than option 2. Flash does so many crappy things. If you optimize a blitting engine it should become much faster.