Animation Bug - TGBX
by Sean T. Boyette · in Torque X 2D · 05/11/2007 (10:39 pm) · 12 replies
This error is easily recreatable.
I have an image (png) that is 484x488 and I create an animation that has 121x122 cell width and height.
This equate to 16 frames of an animation, 4x4 frames.
It imports, however the last line of pixels on each cell is on the top.
This is not the case in TGB Pro/TGB beta is you use the proper cell count x and y (not -1, teh default) and use 4. Although you get the same result if you do not change the cell count after you put in the cell width.
The stray bottom pixel on the topis always there in TGBX. In fact it is there if you use a 14 cell wide image that is only 122 in height (one single row of images)
This is the case in TGBX even when I change the cell count, or width/heights.
One important thing to note, is that the pixels of the cells sometime fill the entire pixel width and height, that is how I notice the stray pixel.
Kind Regards,
Sean
I have an image (png) that is 484x488 and I create an animation that has 121x122 cell width and height.
This equate to 16 frames of an animation, 4x4 frames.
It imports, however the last line of pixels on each cell is on the top.
This is not the case in TGB Pro/TGB beta is you use the proper cell count x and y (not -1, teh default) and use 4. Although you get the same result if you do not change the cell count after you put in the cell width.
The stray bottom pixel on the topis always there in TGBX. In fact it is there if you use a 14 cell wide image that is only 122 in height (one single row of images)
This is the case in TGBX even when I change the cell count, or width/heights.
One important thing to note, is that the pixels of the cells sometime fill the entire pixel width and height, that is how I notice the stray pixel.
Kind Regards,
Sean
About the author
#2
I dont think that it would be intended to be a feature..
05/12/2007 (11:07 am)
It happens In game as well.I dont think that it would be intended to be a feature..
#3
As for the cell count vs cell dimensions, that's a bit of a bug... or just kinda not "fully supported" by the engine. The issue is that cell count is checked before width and height in the engine, so if those fields appear in the .txscene file at all, they will take priority no matter what the values are. The editor always writes out both in the same order: count then dimensions, so the result is that the count fields are always used.
This is fixed in post-1.0 as part of the celled/keyed material addition, but for now and as of 1.0 if you need to use a cell width or cell height that can't be evenly divided into the dimensions of the image you'll need to edit the xml (the .txscene file) and remove move CellCountX and CellCountY from the animation data definition (you can Find it by name). The only issue with that sollution is that the cell count x and y values will be rewritten every time you save your level. Rest assured, that issue is taken care of in post-1.0.
05/15/2007 (3:03 pm)
Mark M just posted a great explanation of the problem and how to fix bleeding png files here. It's actually an issue with the image, not the engine. As for the cell count vs cell dimensions, that's a bit of a bug... or just kinda not "fully supported" by the engine. The issue is that cell count is checked before width and height in the engine, so if those fields appear in the .txscene file at all, they will take priority no matter what the values are. The editor always writes out both in the same order: count then dimensions, so the result is that the count fields are always used.
This is fixed in post-1.0 as part of the celled/keyed material addition, but for now and as of 1.0 if you need to use a cell width or cell height that can't be evenly divided into the dimensions of the image you'll need to edit the xml (the .txscene file) and remove move CellCountX and CellCountY from the animation data definition (you can Find it by name). The only issue with that sollution is that the cell count x and y values will be rewritten every time you save your level. Rest assured, that issue is taken care of in post-1.0.
#5
i have the following PNG -
and am getting the following results after trying Mark M's solution and superpng:
any ideas?
06/22/2007 (12:44 pm)
I spoke a little too soon!i have the following PNG -
and am getting the following results after trying Mark M's solution and superpng:any ideas?
#6
06/22/2007 (2:42 pm)
That looks like his shoe
#7
And that would imply that one of your cells is out of alignment...maybe check the image sheet and see if that's a possibility?
06/22/2007 (2:49 pm)
Will's right, it does--great eyes man!And that would imply that one of your cells is out of alignment...maybe check the image sheet and see if that's a possibility?
#8
06/22/2007 (3:43 pm)
It is his shoe I have attached the spritesheet - so you can reproduce it. The imagesheet is not misaligned. 
#9
I think you need to have a little bit more space between the head and the shoes.
Any reason why you made it vertical and not horizontal ? or matrix ?
I think I can give this a bit of try.
06/23/2007 (3:04 pm)
SeanI think you need to have a little bit more space between the head and the shoes.
Any reason why you made it vertical and not horizontal ? or matrix ?
I think I can give this a bit of try.
#10
SO when I try putting a ruler guide just touching the bottom edge of left shoe the guide is also touching the hair of the next character sprite , i believe thats the problem, there must be at least one pixel gap between the two images.
Thats the reason TXB is cutting one pixel row of the shoes because it requires at least one pixel row gap to make a cell.
06/23/2007 (3:11 pm)
The first thing I noticed after importing in photoshop that his left shoes is one pixel below the line of his right shoes.SO when I try putting a ruler guide just touching the bottom edge of left shoe the guide is also touching the hair of the next character sprite , i believe thats the problem, there must be at least one pixel gap between the two images.
Thats the reason TXB is cutting one pixel row of the shoes because it requires at least one pixel row gap to make a cell.
#11
Thanks for working on it.
I have tried it with multiple types, veritcal and horizontal, square. I found the same thing about a buffer - I added a nice buffer around all the images - which in turn helped with not having to scale the sprites.
06/27/2007 (7:45 am)
@WickedThanks for working on it.
I have tried it with multiple types, veritcal and horizontal, square. I found the same thing about a buffer - I added a nice buffer around all the images - which in turn helped with not having to scale the sprites.
#12
Anyhow with the buffer what frame pixel size you took? (for one cell)
06/29/2007 (7:12 am)
That's Good.Anyhow with the buffer what frame pixel size you took? (for one cell)
Torque Owner Matias Kiviniemi