Tue, 13 Dec 2011 14:48:29 +0000 http://flintparticles.org/forum/ Lussumo Vanilla 1.1.10 & Feed Publisher http://flintparticles.org/forum/comments.php?DiscussionID=18&Focus=86#Comment_86 http://flintparticles.org/forum/comments.php?DiscussionID=18&Focus=86#Comment_86 Mon, 14 Apr 2008 10:19:33 +0100 Richard BitmapRenderer and PixelRenderer classes.

The BitmapRenderer and PixelRenderer create a canvas for drawing the particles in. In previous versions this canvas covered the stage. This has caused problems for some developers who want more flexibility over the size and placement of this canvas.

It makes sense for the generic BitmapRenderer to allow the developer to specify the size and position of this canvas, so that is what it now does. This requires a single parameter in the constructor for the BitmapRenderer. This parameter is a rectangle and specifies what region within the renderer (i.e. within the coordinate space of the particle system) where the canvas should be drawn. The same change has been made to the PixelRenderer.

The old behaviour, a canvas that covers the stage, now exists within two more specific classes - the FullStageBitmapRenderer and the FullStagePixelRenderer. Changing all references to BitmapRenderer and PixelRenderer to these new classes will enable any previous scripts to work as before.

Other minor changes - all renderers now have mouseEnabled and mouseChildren set to false by default, so that they don't respond to mouse events and it is possible to click through renderers to buttons and other objects below. To enable mouse events, set one or both of these properties to true as required. ]]> http://flintparticles.org/forum/comments.php?DiscussionID=18&Focus=88#Comment_88 http://flintparticles.org/forum/comments.php?DiscussionID=18&Focus=88#Comment_88 Mon, 14 Apr 2008 15:51:46 +0100 ericr
Further, because BitmapRenderer extends Sprite, calculating things based on BitmapRenderer width and height are unstable (especially if someone modifies the canvas repeatedly - the Sprite boundaries grow but do not shrink... this has the side effect that all of its containers will also grow in kind.

This was all handled by the code that I posted because it extended the Bitmap object instead of Sprite (less overhead and faster, too). Further, you didn't need to add another two classes to the mix (two classes that break once someone resizes the stage).

What happened to the backwards compatibility you were looking for? From your blog post: "Changing all references to BitmapRenderer and PixelRenderer to these new classes will enable any previous scripts to work as before."

How is that any better than telling people to: "Change new BitmapRenderer() to new BitmapRenderer(stage.stageWidth, stage.stageHeight)" and be done with it?

... ]]> http://flintparticles.org/forum/comments.php?DiscussionID=18&Focus=89#Comment_89 http://flintparticles.org/forum/comments.php?DiscussionID=18&Focus=89#Comment_89 Mon, 14 Apr 2008 15:56:51 +0100 ericr
You've locked down the emitter within the BitmapRenderer world and asked us to move around the "Viewport" by redefining its boundaries?? This rather than to move stuff around within the viewport? To move paint around the canvas? ]]> http://flintparticles.org/forum/comments.php?DiscussionID=18&Focus=91#Comment_91 http://flintparticles.org/forum/comments.php?DiscussionID=18&Focus=91#Comment_91 Mon, 14 Apr 2008 17:47:33 +0100 Richard
Positioning the emitter within the BitmapRenderer is now confusing: Do we use emitter.x/y or do we redefine the coordinate space using negative values in our Rectangle declaration?

You move the emitter. Because you can't redefine the coordinate space. Defining the canvas doesn't move the coordinate space, it defines what region of that coordinate space is drawn.

it's even more inconvenient to have to move the entire coordinate system around within an object

Have you tried this? You can't move the coordinate system around within the renderer.

You've locked down the emitter within the BitmapRenderer

No I haven't. You can place the emitter anywhere you would like to within the coordinate system of the particle system. also, the coordinate system of the particle system is mapped directly to the coordinate system of the renderer, so by inference you can place the emitter anywhere you would like to within the coordinate system of the BitmapRenderer.

the Sprite boundaries grow but do not shrink

This is due to an error in the code - the fix is checked in to SVN and will be in the next version for download.

you didn't need to add another two classes to the mix

As explained in the docs, these classes are there to aid backward compatibility and because some developers like them. Perhaps you'd like everyone to programme like you, but they don't. These classes are useful.

How is that any better than telling people to: "Change new BitmapRenderer() to new BitmapRenderer(stage.stageWidth, stage.stageHeight)" and be done with it?

Because your suggestion fails in Flex if you place it in the document class. Something to do with the execution order for the code - the stage hasn't been initialized yet so stageWidth and stageHeight are zero. It would work fine in Flash. ]]> http://flintparticles.org/forum/comments.php?DiscussionID=18&Focus=93#Comment_93 http://flintparticles.org/forum/comments.php?DiscussionID=18&Focus=93#Comment_93 Mon, 14 Apr 2008 19:28:13 +0100 ericr
Quoting myself: Positioning the emitter within the BitmapRenderer is now confusing: Do we use emitter.x/y or do we redefine the coordinate space using negative values in our Rectangle declaration?
We can do both. This all depends on how you initially define your Rectangle. See the "Speed Enhancements" thread, post 32 for a discussion on this and an explanation of why this can lead to confusion.

Have you tried this? You can't move the coordinate system around within the renderer.
You are right. We can move the camera around however (the Rectangle is your camera into the canvas). So there's two ways to move stuff: move the camera or move the emitter. I want to move an effect from (0,0) to the (5,5). To do this with the camera, I have to redefine the Rectangle as such: renderer.canvas = new Rectangle(-5, -5, width, height);. To do this with the emitter, I simply do the following: emitter.x = 5; emitter.y = 5. Both have the same viewer-facing result. One has side-effects (outlined in the "Speed Enhancements" thread) and one does not.

This is due to an error in the code - the fix is checked in to SVN and will be in the next version for download.

Please don't tell me that your setting _bitmap to be a public variable is final.

Because your suggestion fails in Flex if you place it in the document class. Something to do with the execution order for the code - the stage hasn't been initialized yet so stageWidth and stageHeight are zero. It would work fine in Flash.

Ahh, yes. I came across that exact issue when modifying the code on my own. The issue came up in Flash CS3, too. I managed to work around it, though, and the code I wrote should work. There's a way to do it. ]]> http://flintparticles.org/forum/comments.php?DiscussionID=18&Focus=95#Comment_95 http://flintparticles.org/forum/comments.php?DiscussionID=18&Focus=95#Comment_95 Mon, 14 Apr 2008 19:36:49 +0100 Richard Please don't tell me that your setting _bitmap to be a public variable is final.

I suspect you know that was a mistake and are just trying to annoy me.

I've answered your concerns in the other thread. Shall we leave this one alone now. ]]> http://flintparticles.org/forum/comments.php?DiscussionID=18&Focus=100#Comment_100 http://flintparticles.org/forum/comments.php?DiscussionID=18&Focus=100#Comment_100 Mon, 14 Apr 2008 22:41:01 +0100 ericr public designation was a work-around and not an oversight.

I have never intended to annoy you through any of our discussions. I apologize if I came off that way.

For anyone else who happens to read this far, a lot of my grievances came from a small misunderstanding of Flash's Display Object system. Go check out the "A-Ha!" moment in these two posts.

Yay progress! ]]>