SWFSheet 1.1 Final

Posted on January 19, 2011 by keith

Here’s the link.

Haven’t actually added anything in quite a while, but haven’t had any bug reports or problems with it, so I thought I’d make it official.

This entry was posted in General. Bookmark the permalink.

13 Responses to SWFSheet 1.1 Final

  1. Karim says:
    February 4, 2011 at 10:52 am

    Hi Keith, not sure if you’ve seen this or not: http://www.blooddy.by/en/crypto/ – much faster PNG encoder compiled with Haxe.

  2. Gabriel says:
    February 24, 2011 at 4:56 pm

    Hi Keith, I’ve been trying your tool a bit, and I keep bumping into a pretty odd problem which I’m sure comes from my end, since I’m kind of new to Flash.

    I generate my animations as movie clips to mess around with on stage, then export my movie clips to swfs. I do this so my stage size will be the size of the images, since I haven’t found any way for Flash to crop it’s stage size to the size of my animations. When I open the generated swfs, the total area seems to be fine. So when I import the swf generated from the movie clip into SWFSheet, I notice that my sprites might be centered in the Live SWF window, as well as the frame. However, when I try to make the frame bigger, it only grows down and right, and anything about 1/3rd of the screen up or left from that area cannot be selected. Moving X and Y only takes the frame further offscreen that way, and no negative values are possible to make the frame be positioned so that it may select anything above or to the left of the default point.
    I noticed that the locked location where the frame begins is the registration point for the movie clip. This seems to be the biggest issue I’m having. Is there any way to move that once the animation is done? There’s a lot of keyframes involved, and moving every single frame to a new position so that I can export it with your software would be a bummer, and I’d love to know if there’s any other solution.
    Thanks!

  3. jacob says:
    March 4, 2011 at 3:05 pm

    Thanks for putting this together. It’s a great tool for sure.

    I ran into one problem yesterday where the x,y coordinates for where the rects begin was off by a substantial amount. My sprite sheet would look fine, but the xml file wouldn’t have the right values. I was able to manually update it, but thought I’d mention. It only happened when I was usually larger images. each frame was about 300 x 285

    Any chance you want to open this up so others can add to it?

    • Tim says:
      August 24, 2011 at 2:40 am

      Hi Keith,

      First up, awesome tool! It’s so handy. Thanks! 😀

      I too am experiencing this issue when using custom sizes (that’ll teach me!). The generated MetaData x/y values are wrong when exporting to Sparrow, Generic XML, and Raw Text, however they are correct when exporting to Zwoptex and Corona. The bug produces inconsistent erroneous x/y values depending on the target output too.

      Any chance of having a fixed build released sometime in the future please?

      Below are examples of the first frame from each export option (hopefully the XML tags wont kill my post):

      // Sparrow (incorrect – should be x=”0″, y=”0″)

      // Generic XML (incorrect – should be x=”0″, y=”0″)

      // Raw Text (incorrect – should be 0,0,98,113)
      294,678,98,113

      // Corona (correct x/y)
      name = “0001.png”,
      spriteColorRect = { x = 0, y = 0, width = 98, height = 113 },
      textureRect = { x = 0, y = 0, width = 98, height = 113 },
      spriteSourceSize = { width = 512, height = 800 },
      spriteTrimmed = false,
      textureRotated = false

      // Zwoptex/Cocos2D (correct x/y)
      frame_0001.png

      x
      0
      y
      0
      width
      98
      height
      113
      offsetX
      0
      offsetY
      0
      originalWidth
      98
      originalHeight
      113

      Cheers,

      Tim

  4. Juwal Bose says:
    March 14, 2011 at 4:56 am

    returning to post a bug (may be not) which i noticed when i was working with this on a recent project. I had 100+ frames for a character which was arranged on timeline. For some reason the first frame appears at the end on the sheet rather than first as it should 🙂 No idea why this happened. seems i just have to move everything by one frame.

  5. IQpierce says:
    July 26, 2011 at 12:34 pm

    Neat tool, but I’m interested in doing this spritesheet creation dynamically at runtime. If you open-sourced it I could adapt the code for that purpose…

    Why give a tool away for free but not share the source code? I feel like I’m being told I can use the cart for free but the horse is unavailable (for no particular reason).

    Let me know if you ever open-source it!

    • keith says:
      July 26, 2011 at 1:04 pm

      You know, I love open source, and god knows I’ve given freely, but it really annoys me when people get pushy about it. Why give it away free but not share the code? Would you feel better if I charged you for it and didn’t give you the code? Sorry if I come off snappy. It’s just a point that really bugs me.

  6. Tom Lee says:
    October 27, 2011 at 9:52 pm

    Hey Keith,

    Great tool, I really appreciate you putting this out there for free. Lord knows you could probably charge for it.

    I did run into one issue though – I have a character that is completely controlled by ActionScript. A walk loop is 40 frames long, and the swf runs at 60 fps. What I have found is that I have to set the number of frames to upwards of 500 in order to get all the frames, and I wind up with many duplicate images. For now, I have a shell script using ImageMagick which I can use to de-dupe the PNG sequence I export, and then I can use TexturePacker to actually create the sprite sheet and plist file… But it’d be a lot nicer if I could just use your tool. 🙂

    FYI, I’d be happy to pay for a product like this if it were supported, and I’d be equally happy if it were open source so I could debug it myself and not trouble you with it.

    Thanks!!!

  7. Keats says:
    November 1, 2011 at 2:34 am

    Hi,
    i think you have a small bug that messes things :
    when we export things like the xml Sparrow thing the x and y values are non-ok because they start at the end of the previous loop. For example I click on capture i and j index are set to the end spritesheet portion but since you seem to use the same variables when we export and you forgot to set them back to 0 they continue where you let them. I think you didn’t see the bug because you always tested with the default so if you let the default you don’t have to redo a “capture click” so your i and j remain at 0 and the export work as it should.

  8. Noar says:
    December 31, 2011 at 8:19 am

    Greet work! You could let set the offset can be negative.

  9. Nico says:
    March 20, 2012 at 4:46 pm

    Hi Keith,

    Thanks for a great tool, it really boosted my productivity. I do have a question however.

    There seems to be bug regarding gradients in SWFsheet. Some sheets I created display a strange flicker at the edges. At first I thought the problem came from my swf’s, but after exporting them to PNG sequences and then using ‘Sprite Sheet Maker’ the problem was gone.
    Are you aware of this issue? Is there a workaround (other than going the PNG sequence route)?

    Thanks,
    Nico

  10. Mihai Morosanu says:
    July 6, 2012 at 3:09 am

    No negative offset makes this program useless

  11. Aaron says:
    June 13, 2013 at 10:22 am

    Hi Keith,

    It’s a great tool, one problem I have is for the size of the outputted frames.

    Say one project I wanted to use this for would need a 960px wide output. If you could add that in I would be veryhappy!

Leave a Reply