[T2D iPhone 1.3 Beta] White Lines on Images
by Joe Virgin · in iTorque 2D · 09/24/2009 (4:16 pm) · 9 replies
I'm trying out the 1.0 Beta and using iTGB 1.2
For the new beta, I'm noticing white lines on the bottom and right sides on many of the static sprites I'm using (animated sprites and tile layers as well). The lines are most noticeable when the object is moving (I'm using LinearVelocity, moveTo, and Pathing motion). These lines carried on to iTGB 1.2 builds for the iPhone.
Do image sizes now have to be powers of 2 in order to display properly? It didn't seem to be an issue (except with Scrollers) in iTGB 1.2. What does the beta add to the image map datablocks that make the images not display appropriately in iTGB 1.2?
For the new beta, I'm noticing white lines on the bottom and right sides on many of the static sprites I'm using (animated sprites and tile layers as well). The lines are most noticeable when the object is moving (I'm using LinearVelocity, moveTo, and Pathing motion). These lines carried on to iTGB 1.2 builds for the iPhone.
Do image sizes now have to be powers of 2 in order to display properly? It didn't seem to be an issue (except with Scrollers) in iTGB 1.2. What does the beta add to the image map datablocks that make the images not display appropriately in iTGB 1.2?
About the author
Joe Virgin is a programmer for Plainvue Software, Inc., a company producing iPhone games that teach math skills to the youth. Check out Fraction's Kitchen Lite, Fortune's Prime, and Chainshooter powered by iTGB and now available on the App Store.
#2
09/24/2009 (7:23 pm)
You need to enable filterpad or make your image a power of 2. 
#3
Although I've to say that I find it desturbing that the sample, which already was bad enough in 1.2 due to 99% optimizations missing, now is even more borked, rendering it useless.
iTGB is an addon that cost $5 less than the T3D Pro upgrade, yet the quality of the beta releases is dimensions appart ...
At least its just the first beta (by its quality of at least 6+ betas till the 1st release candidate), so the more we test and report things now, the larger the chance for a fullpower stable and pretty bugfree 1.0 release :)
09/24/2009 (10:04 pm)
Thats what beta is for, finding such things :)Although I've to say that I find it desturbing that the sample, which already was bad enough in 1.2 due to 99% optimizations missing, now is even more borked, rendering it useless.
iTGB is an addon that cost $5 less than the T3D Pro upgrade, yet the quality of the beta releases is dimensions appart ...
At least its just the first beta (by its quality of at least 6+ betas till the 1st release candidate), so the more we test and report things now, the larger the chance for a fullpower stable and pretty bugfree 1.0 release :)
#4
See here:
www.garagegames.com/community/forums/viewthread/93489/6#comment-674443
09/25/2009 (4:46 am)
It is a side effect of the "optimised" flag in image map datablocks. FilterPad isn't allowed if you use Optimised, therefore you need to do you own manual padding built into the images.See here:
www.garagegames.com/community/forums/viewthread/93489/6#comment-674443
#5
I added the optimised flag to my image map which uses the KEY image mode. The sprite sheet is a power of 2, but each individual cell isn't a power of 2 (most are). Regardless of that, all of my sprites have a 1 pixel border surrounding it which is the unique color surrounding the cell in the sprite sheet. Is this the samething? Do I need to add the padding? Right now I just have 1 pixel of the unique color in between two cells.
09/25/2009 (11:15 am)
Luke,I added the optimised flag to my image map which uses the KEY image mode. The sprite sheet is a power of 2, but each individual cell isn't a power of 2 (most are). Regardless of that, all of my sprites have a 1 pixel border surrounding it which is the unique color surrounding the cell in the sprite sheet. Is this the samething? Do I need to add the padding? Right now I just have 1 pixel of the unique color in between two cells.
#6
You will need include your own "filter padding" into each individual image cell.
09/25/2009 (11:30 am)
yes you won't be able to use the optimized flag unless each individual cell is a power of two.You will need include your own "filter padding" into each individual image cell.
#7
See here:
www.garagegames.com/community/forums/viewthread/81234
09/25/2009 (5:05 pm)
I know it's really not a fix, but it's a nice work around if you want to use the optimized flag. By changing the white to transparent...See here:
www.garagegames.com/community/forums/viewthread/81234
#8
09/25/2009 (6:36 pm)
Nice find joe!
#9
When using transparency, make sure those pixels are tranparent/alphaed out. For solid images, it's usually good to "bleed" the edges of each cell outward so that he filtering doesn't introduce unwanted colours back into youe cell.
We've found that PVR cells generate quite a bit of unwanted compression artifacts, especially in the alpha channel, so we only use them for specific cases unfortunately and not a be-all-and-end-all solution. We've also modified the 16-bit bitmap code to work for individual imagemaps, so you can specify which ones get loaded into 565 or 4444 surfaces instead of it being a blanket case for *all* palettised PNGs/BMPs... not sure why that was done... I'll try to post that code when I have a chance. It's not as fast bandwith-wise as PVRs, but it is twice as fast as 32bit images with fewer artifact than PVRs (in most cases).
09/26/2009 (2:11 am)
Bret, you don't need each cell to be power-of-2. You just need them to have a pixel or 2 of space between each cell on all sides so that bilinear filtering will pull those "blank" pixels (well, texels) into account when calculating the final image to render.When using transparency, make sure those pixels are tranparent/alphaed out. For solid images, it's usually good to "bleed" the edges of each cell outward so that he filtering doesn't introduce unwanted colours back into youe cell.
We've found that PVR cells generate quite a bit of unwanted compression artifacts, especially in the alpha channel, so we only use them for specific cases unfortunately and not a be-all-and-end-all solution. We've also modified the 16-bit bitmap code to work for individual imagemaps, so you can specify which ones get loaded into 565 or 4444 surfaces instead of it being a blanket case for *all* palettised PNGs/BMPs... not sure why that was done... I'll try to post that code when I have a chance. It's not as fast bandwith-wise as PVRs, but it is twice as fast as 32bit images with fewer artifact than PVRs (in most cases).
Torque 3D Owner Marc 'Dreamora' Schaerer
Gayasoft