A Flash Developer Resource Site

Page 1 of 2 12 LastLast
Results 1 to 20 of 25

Thread: BigAssCanvas

  1. #1

    BigAssCanvas

    kp just posted his BigAssCanvas class and I thought I would link to the post here.

    http://www.bit-101.com/blog/?p=1199

    Basically it allows for creation of larger bitmapdatas. Currently we are limited to 2880x2880 this class can create a large BigAssCanvas that stitches the BitmapDatas together and also alows many of the same functions as the original BitmapData.

  2. #2
    Hype over content... Squize's Avatar
    Join Date
    Apr 2001
    Location
    Lost forever in a happy crowd...
    Posts
    5,926
    Cool link mate.

    Also I'd never heard of changeRect, I found this about it:
    http://www.kirupa.com/forum/showthre...238&styleid=79

    Looks like it could prove handy for blitting displays.

    Squize.

  3. #3
    FK founder & general loiterer Flashkit's Avatar
    Join Date
    Feb 2000
    Location
    Sydney
    Posts
    1,149
    been looking for something like this, thanks for the link
    Regards Mark Fennell - Flash Kit Founder, general loiterer
    -------------------------------
    I Hate Zombies - iPhone Game | markfennell.com

  4. #4
    ....he's amazing!!! lesli_felix's Avatar
    Join Date
    Nov 2000
    Location
    London UK
    Posts
    1,506
    Nice work!

    I'd watch the memory/performance though. There's a good reason there's a 2880 limit on bitmapData objects.

    2880*2880 = 32mb

    5760*5760 = 128mb

    11520*11520 = 512mb

    etc.
    Last edited by lesli_felix; 03-24-2008 at 04:21 AM.

  5. #5
    Senior Member rachil0's Avatar
    Join Date
    Jul 2007
    Location
    Columbus, OH.
    Posts
    465
    I'd make a wrapper for graphics.beginBitmapFill, too. I'd expect that method would have pretty similar semantics to BitmapData.draw so it might be an easy tack-on.

  6. #6
    FK founder & general loiterer Flashkit's Avatar
    Join Date
    Feb 2000
    Location
    Sydney
    Posts
    1,149
    hey rachil0,
    how would you go about writing a wrapper for the graphics.beginBitmapFill as thats something that would make that class very useful to me... but I'm not quite sure how to start it....
    Regards Mark Fennell - Flash Kit Founder, general loiterer
    -------------------------------
    I Hate Zombies - iPhone Game | markfennell.com

  7. #7
    Senior Member rachil0's Avatar
    Join Date
    Jul 2007
    Location
    Columbus, OH.
    Posts
    465
    Although you can't add a new "canvasFill" operation to the graphics class because it is final, you can get pretty close. I'd make a method on the canvas class with a signature like:

    Code:
    public function convexPolygonFill (m : Matrix, pointArray : Array /* of Points */, g : Graphics );
    The Matrix m works just like the argument to beginBitmapFill - it maps coordinates in bitmap (Canvas) space into points in screen space. Here's how you can split the canvas.convexPolygonFill operation into multiple graphics.beginBitmapFill operations:

    The top figure shows the screen footprint (which would be passed through the pointArray argument), and the canvas which is really a bunch of bitmapDatas subpanels, where each is at most 2880x2880. The first thing you need to do is transform the screen polygon into a polygon in canvas space, so take each screen point and apply M.inverse() to it. [Don't quote me on it, but I think the affine transform of a convex polygon is another convex polygon.].

    Once you have this polygon in canvas space, you need to clip it against every subpanel. The sutherland-hodgman algorithm is suitable for this. The second figure shows how the result of clipping the canvas footprint against the [0][0] subpanel. Once you have this polygon fragment, you need to project it back to screen space (using the Matrix m again). This gives you another convex polygon in screen space that is suitable for being filled using graphics.beginBitmapFill and a closed sequence of lineTo operations. Note that the origin of the [0][0] subpanel is the same as the origin for the canvas, so for this beginBitmapFill(m,bmp) call we can just use the same Matrix m.

    However, other subpanels need a modified transformation matrix. When you clip against the [1][1] pane (as in the third figure), you need to do a translation step to reconcile the difference between the canvas origin and the origin of the [1][1] pane. You'd need to do something like:

    Code:
    var T : Matrix;
    T.translate(2880,2880);
    var bbfMatrix : Matrix = M.clone();
    bbfMatrix.concatenate(T);
    graphics.beginBitmapFill (bbfMatrix, pane[1][1]);
    There could be some signs off, and you might need to do the concatenation the other way, ie T.concatenate(bbfMatrix). The documentation is a little vague. But I would try that snippet first.

    The bottom line of the algorithm is to walk over each pane, clip the canvas footprint to that rectangle, transform that polygon fragment back into screen space, call graphics.beginBitmapFill and draw the polygon fragment.

    There are a few subtleties. I think the approach will have a problem with cracks/dropouts in between screen space fragments, and you have to also address the case where the footprint spills outside the limits of the canvas. Like gfx.bbf, you can either wrap the coordinates back around in canvas space, or just pad with some border value. I think the latter will be easier to implement and that's all I would support. To pull it off, you just need to transform that tip fragment back into screen space and do a plain color fill. If you try to do the wrapping approach, that really opens a whole new can of worms.

    Last edited by rachil0; 03-25-2008 at 12:19 PM.

  8. #8
    Senior Member rachil0's Avatar
    Join Date
    Jul 2007
    Location
    Columbus, OH.
    Posts
    465
    Edit: Now that I think about it, you probably just want to implement a Mode7 view that supports textures larger than 2880x2880. You can simplify the algorithm somewhat for that case, because you don't need a full-blown polygon clipper like Sutherland-Hodgman. You can just raycast across the canvas, which is easier to program and would also be faster. After you digest this algorithm, it should give you some ideas on how to implement the Mode7 case (which draws a single scanline from screen space instead of a convex polygon).

  9. #9
    Senior Member realMakc's Avatar
    Join Date
    Oct 2002
    Posts
    927
    how would one do beginBitmapFill on bitmap data?
    who is this? a word of friendly advice: FFS stop using AS2

  10. #10
    Senior Member rachil0's Avatar
    Join Date
    Jul 2007
    Location
    Columbus, OH.
    Posts
    465
    Quote Originally Posted by realMakc
    how would one do beginBitmapFill on bitmap data?
    This operation is already supported natively as a method of flash.display.graphics. The prior 2 posts are all about extending it to work on raster images greater than 2880x2880 (a "canvas").

    A canvas is implemented as a collection of bitmapDatas. So beginBitmapFill using a canvas as a source raster image is implemented through multiple beginBitmapFills using each bitmapData as a source raster image.

    [not sure I understood the question properly?]

  11. #11
    Senior Member hatu's Avatar
    Join Date
    Jan 2007
    Posts
    480
    Looks neat. What do people need single this big bitmapdatas for?

  12. #12
    FK founder & general loiterer Flashkit's Avatar
    Join Date
    Feb 2000
    Location
    Sydney
    Posts
    1,149
    hatu: I'm looking at a bigbitmapdata for a mode7 implementation, so thats about the only place really for me. Otherwise I'd use a tile engine

    Rachil0, thanks for the post, I'm going to digest it now and see how I go You are definitely the mode7 man!

    A mode7 question for you then... have you had any success implementing pseudo hills in a mode7 engine... and do you have any pointers for the mode7 learner?
    Regards Mark Fennell - Flash Kit Founder, general loiterer
    -------------------------------
    I Hate Zombies - iPhone Game | markfennell.com

  13. #13
    Senior Member rachil0's Avatar
    Join Date
    Jul 2007
    Location
    Columbus, OH.
    Posts
    465
    I don't have any experience with doing smooth hills, just the polyhedral 3D primitives that were mixed into Pinball Racers.

    A simple solution is to use the border padding option in bitmapFill so you get a solid color (like grass green) extended to the horizon and extents. Then you can make hill billboards which have bottom fringe that matches up to the green color are painted upwards like mountains (green to earth brown to snow white, w/e).


    Another thing that would be interesting to try (might work, might not) for pseuodohills is a displacement map operation performed purely in screen space as a post-process. Render the frame as usual and grab it into a bitmapData. Next, define a hill as anchored at some point in the texture, with some characteristic size/radius. Project that point through to screen coordinates, and then use that point to create displacement map layer that will push pixels upwards along screen y wherever a hill exists. For instance, a hill on the left side of the screen could be implemented with a displacement map that looks something like:

    Code:
    [ 0 0 0 0 0 0 0 0 0 0 0 0 0]
    [ 0 0 0 1 1 0 0 0 0 0 0 0 0]
    [ 0 0 1 2 2 1 0 0 0 0 0 0 0]
    [ 0 1 2 3 3 2 1 0 0 0 0 0 0]
    [ 0 1 2 3 3 2 1 0 0 0 0 0 0]
    This will push pixels up around the hill, warping the texture somewhat and even allowing it to push above the horizon scanline (layer the panorama sprite under the mode7 sprite). You could take that basic "stencil" and stretch it about to make different shaped hills. It might look totally stupid, or it might look awesome. (Smart money is on the former)

    I think a future project will use this effect to make a game visually similar to a mode7 racer, but will have 3D terrain based on a height map. Thinking something along the lines of marble madness (slopes, curves, etc) but with a more free moving camera.

  14. #14
    Senior Member realMakc's Avatar
    Join Date
    Oct 2002
    Posts
    927
    Quote Originally Posted by rachil0
    This operation is already supported natively as a method of flash.display.graphics. The prior 2 posts are all about extending it to work on raster images greater than 2880x2880 (a "canvas").
    ah, you mean filling graphics with bigasscanvas content, then it's ok.

    I was thinking it was about making fills in canvas itself.
    who is this? a word of friendly advice: FFS stop using AS2

  15. #15
    Senior Member rachil0's Avatar
    Join Date
    Jul 2007
    Location
    Columbus, OH.
    Posts
    465
    Quote Originally Posted by realMakc
    I was thinking it was about making fills in canvas itself.
    Ah I see, the original author already supported this operation by implementing the draw() method.

  16. #16
    Senior Member realMakc's Avatar
    Join Date
    Oct 2002
    Posts
    927
    but unlike bitmap fill, you cant fill some polygon with draw
    who is this? a word of friendly advice: FFS stop using AS2

  17. #17
    Senior Member rachil0's Avatar
    Join Date
    Jul 2007
    Location
    Columbus, OH.
    Posts
    465
    I believe you can fill a polygon using the graphics context of a Sprite, and then draw that Sprite into a BitmapData. IIRC, draw will accept any DisplayObject (they all implement IBitmapDrawable).

  18. #18
    Senior Member realMakc's Avatar
    Join Date
    Oct 2002
    Posts
    927
    ...which isnt exactly handy
    who is this? a word of friendly advice: FFS stop using AS2

  19. #19
    Senior Member rachil0's Avatar
    Join Date
    Jul 2007
    Location
    Columbus, OH.
    Posts
    465
    I completely disagree. Anything you can draw into a Sprite graphics handle can be rasterized into a bitmapData - I use this functionality all the time. On top of that, anything that's a displayObject can be rasterized too (which includes the whole family of buttons, textboxes, UI widgets galore). They've done a very good job in Flash of separating the definition of drawn geometry from its (lossy) projection onto a raster display, they really respect its heritage as a vector art content creator.

  20. #20
    Senior Member realMakc's Avatar
    Join Date
    Oct 2002
    Posts
    927
    the thing is that drawing to sprite takes its time and in the end makes re-drawing it into bitmap pretty pointless, since I could just use sprite with everything drawn there.
    who is this? a word of friendly advice: FFS stop using AS2

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  




Click Here to Expand Forum to Full Width

HTML5 Development Center