I’m applying a 3x3 texture to a TbtQuadBackgroundComponent.
I’m using it like this:
[java] TbtQuadBackgroundComponent.create(
“background-panel-texture.png”, // texture
1f, // imageScale
1, // x1
1, // y1
2, // x2
2, // y2
1f, // z
false) // z[/java]
I.e. the outer rim pixels are to be applied to a 1-pixel border, the center pixel is to be stretched.
This all works as it should geometrically, however, the center area gets a color gradient.
I understand that this is normal texture behaviour when stretching; however, in this case, I want the center pixel to be simply replicated.
What’s the best approach:
Somehow access and reconfigure the texture so that it replicates pixels instead of blending them?
Use four 1-pixel-wide background panels for the border, and a large center background panel?
Use a 5x5 texture and use a border of 2 pixels so that the blending results in a constant color. I’m playing with that, but somehow the x1,y1,x2,y2 values do unexpected things.
Approach 3 works, sort-of. I’m getting nice black borders to the left and right, but at the top and bottom, the 1-pixel border is diluted into two.
Code: [java] TbtQuadBackgroundComponent.create(
// texture
getClass().getPackage().getName().replace(’.’, ‘/’) +
“/background-panel-texture.png”,
1f, // imageScale
2, 2, // x1, y1
3, 3, // x2, y2
1f, // zOffset
false) // lit[/java]
Texture (5x5, enlarged):
Bottom-left and top-right corners, enlarged:
Ah, so it’s actually left/top/right/bottom, not x1/y1/x2/y2.
Interstingly enough, the effect on left and right border is different from the effect on top and bottom border. Left/right are sharp, top/bottom are fuzzy. Looks like a fencepost error somewhere.
@toolforger said:
Ah, so it's actually left/top/right/bottom, not x1/y1/x2/y2.
Interstingly enough, the effect on left and right border is different from the effect on top and bottom border. Left/right are sharp, top/bottom are fuzzy. Looks like a fencepost error somewhere.
A better picture, maybe:
You are defining the pixel coordinates of the “center” in image space, ie: pixels. Since you set the x2,y2 to 3,3 that pixel borders a black pixel. So when you stretch it then you will get bleed. If you set it to the same x1,y1 then you will be stretching only the very center pixel but you will also not get bleed because your bordering pixels will all be transparent also.
@toolforger said:
Ah, so it's actually left/top/right/bottom, not x1/y1/x2/y2.
Interstingly enough, the effect on left and right border is different from the effect on top and bottom border. Left/right are sharp, top/bottom are fuzzy. Looks like a fencepost error somewhere.
I missed this the first time through: It’s a horizontal versus vertical problem now or was before, too?
I added a border test to the BasicDemo. The border test panel is draggable so you can drag it around. Because the dragging leaves it on even pixel coordinates then you do not get the bleed even with your 2,2,3,3 settings.
However, if you start it out on a non-even pixel coordinate (change the demo to start it at 400.5, 400.5 for example) then your borders will be aliased.
Aaahh… the panel has a float position and is centered (i.e. there are divisions by 2.0f involved), and of course the y coordinate ended up on a 0.5f position.
Sneaky, sneaky… I’ve been doing too much integer-based GUI coordinate stuff, so this would never have occurred to me.
Is that a multiplication with whatever color comes out of the texture after scaling?
(I haven’t checked how the setColor color is processed at all, that’s why I’m asking.)
@toolforger said:
Is that a multiplication with whatever color comes out of the texture after scaling?
(I haven't checked how the setColor color is processed at all, that's why I'm asking.)
Yeah, I just use Unshaded.j3md and it just multiplies the colors together.
@pspeed To help you move forward with documenting, here’s a very rough sketch of a class javadoc.
I’m pretty sure that the docs should probably be moved around (e.g. the coordinate stuff should probably go to TbTQuad and just referenced from TbtQuadBackgroundComponent), but I’m not sure enough about the details to do it right so this is what I have.
(The change in GuiControl is just a slightly more tightened-up type bound; it’s inconsequential in that this it being downcast anyway, but anyway.)
@toolforger said:
@pspeed To help you move forward with documenting, here's a very rough sketch of a class javadoc.
I'm pretty sure that the docs should probably be moved around (e.g. the coordinate stuff should probably go to TbTQuad and just referenced from TbtQuadBackgroundComponent), but I'm not sure enough about the details to do it right so this is what I have.
(The change in GuiControl is just a slightly more tightened-up type bound; it's inconsequential in that this it being downcast anyway, but anyway.)
@toolforger said:
Heh. Reminding is going to be hard since I won't know when the time is right.
This next week it is likely that my wife is going in again for brain surgery which will suck me away for the better part of a week with travel, etc… If I have not done these docs by early May then I’ve probably forgotten.
