A fast, easy to use, free, and community supported 2D game engine
Hey all,
Before I go scratching a feature set that is currently available in the online web version on the desktop version I was curious to ask if anyone actually uses any "untrimmed" sprites in their sprite sheets. Untrimmed sprites would be sprites in which you disallow the tool to trim the transparent pixels off.
If you do use untrimmed sprites could you provide any insight into why and when you do as it would be greatly helpful.
Thanks,
Robert
I ended up writing a fireworks script to draw boxes that were 2 pixels wider in all directions than the bounds of each sprite. This was only so I could then pass them into zwopple and then use your packing algo. It also generates a header file with the coordinates of each sprite as laid out in the original png.
A final step used XSLT against the generated plist to generate all my sprite setup code (removing the border) and animation actions depending on the original layer name (which became the layer name).
This saved time initially but updates became a nightmare, looking forward to getting acquainted with the new version :)
edit: I started all this boxing around my sprites stuff because when I used the auto packing on sprites that butted up closely e.g 2 coloured squares I was experiencing bleed when using the AtlasSprites.
Can you explain the artifacts a bit? Currently the web version trims the sprites regardless of whether it is set to be trimmed or not. The trim setting just modifies it's bounds and position but the pixel data is always trimmed.
Thanks,
Robert
randomtruth
Member
Most of my sprites use pre rendered glow's and lots of transparency. When I had the trim setting enabled certain sprite's would overlap each other causing sections of one sprite's glow to pop up on another sprite and when two of the glowing portions of a sprite overlap, it gets really noticeable.
Ok I'll leave the trim/untrim option. By default of course images will be trimmed since it is normally preferred for pixel-packing. The alpha 1 version may not include an option to toggle trim off on sprites but it will present in a future alpha build for sure.
Hi Robert and thanks for excellent work :)
About untrimmed pixels... There is known problem with cocos2d and sub-pixel algo that sometimes show "blurred" sprites/images. E.g. if the size of your sprite is 101x51 pixels, that sprite will not be sharp on screen. There is a workaround by positioning such sprite with small offsets like (0.33, 0.33) but I prefer making my sprites with even sizes if I want them to be "sharp" on screen (like text messages and so on). So I manually set canvas size for some sprites and leave them untrimmed in zwoptex...
But as you suggested, trimmed option is preferred and most used one.
Flipping an sprite is not working correctly if the image was trimmed.
The workaround is to scale it by -1, but that will modify the anchor point too.
It would be great to know how many pixels were trimmed from left,right,top,bottom in order to flip correctly the image.
@riq I modified the flipX code in my version of CCSprite to avoid the call to setContentSize with the trimmed size :
-(void)setFlipX:(BOOL)b
{
if( flipX_ != b ) {
flipX_ = b;
[self updateTextureCoords:rect_];
// rendering using SpriteSheet
if( usesSpriteSheet_ ) {
dirty_ = YES;
}
// self rendering
else
{
// Atlas: Vertex
float x1 = 0 + offsetPosition_.x;
float y1 = 0 + offsetPosition_.y;
float x2 = x1 + rect_.size.width;
float y2 = y1 + rect_.size.height;
// Don't update Z.
quad_.bl.vertices = (ccVertex3F) { x1, y1, 0 };
quad_.br.vertices = (ccVertex3F) { x2, y1, 0 };
quad_.tl.vertices = (ccVertex3F) { x1, y2, 0 };
quad_.tr.vertices = (ccVertex3F) { x2, y2, 0 };
}
}
}That seemed to fix the problems I was running into and I don't think my anchor point changed ... But now I'm curious ... what bugs does that cause ;)
@riq the left,top,right,bottom trim information will be included with the Desktop Version. I anticipate a public release within the next 2-4 weeks.
You must log in to post.