I have started diving a bit into the code. I like to rearrange, document and slightly refactor code while doing this, and here’s what I arrived at for the color buffer:
[java] /**
* Color buffer, used for gradient colors. /
private FloatBuffer colors;
public void setColorBuffer(FloatBuffer colors) {
this.colors = colors;
setBuffers(true);
}
/*
* Add a run of {@code length} entries for {@code color} to the
* {@link#colors} buffer. /
private void putColorRun(ColorRGBA color, int length) {
for (int i = 0; i < length; i++) {
colors.put(color.r);
colors.put(color.g);
colors.put(color.b);
colors.put(color.a);
}
}
public void setGradientFillVertical(ColorRGBA start, ColorRGBA end) {
colors = BufferUtils.createFloatBuffer(164);
for (int i = 0; i < 4; i++) {
putColorRun(start, 2);
putColorRun(end, 2);
}
setBuffers(true);
}
public void setGradientFillHorizontal(ColorRGBA start, ColorRGBA end) {
colors = BufferUtils.createFloatBuffer(16*4);
putColorRun(start, 8 );
putColorRun(end, 8 );
setBuffers(true);
}[/java]
Are you interested in merging this (and stuff to come) into your code base?
If yes, I can prepare patches for you to apply, or commit given access, whichever you prefer.
Ah, right. My thinking was that you’ll want to see just the end result to see whether it fits the project, but seeing what the actual changes are would be helpful, too.
Here’s the patch:
[java]Index: src/tonegod/gui/core/ElementQuadGrid.java
}
public void updateTexCoords(float atlasX, float atlasY, float atlasW, float atlasH) {
float fX = pixelWidthatlasX;
float fW = pixelWidth(atlasX+atlasW);
[/java] I don't think this patch will apply cleanly, I removed some unrelated changes. Also, I put a blank in between 8 and ) to prevent the forum from replacing it with 8)
Hm. Another thing. Either I’m overlooking something really stupid, or this code could be drastically simplified (see patch below):
Buffer#put(index, o); index++ can be simplified to Buffer#put(o) if index starts a 0 and we do a Buffer#rewind() before the loop.
x and indexX are always the same value. Likewise, y and indexY.
Again, please give feedback if I’m overlooking something exceedingly stupid (my excuse: I’m overdue for horizonal inactivity ).
[java]Index: src/tonegod/gui/core/ElementQuadGrid.java
===================================================================
— src/tonegod/gui/core/ElementQuadGrid.java (Revision 332)
+++ src/tonegod/gui/core/ElementQuadGrid.java (Arbeitskopie)
@@ -235,19 +235,13 @@
}
private void updateMesh() {
int index = 0, indexX = 0, indexY = 0;
verts.rewind();
for (int y = 0; y < 4; y++) {
for (int x = 0; x < 4; x++) {
@toolforger said:
Hm. Another thing. Either I'm overlooking something really stupid, or this code could be drastically simplified (see patch below):
1) Buffer#put(index, o); index++ can be simplified to Buffer#put(o) if index starts a 0 and we do a Buffer#rewind() before the loop.
2) x and indexX are always the same value. Likewise, y and indexY.
I’ve not looked at the code itself but in theory you are right - and in fact the performance of put, put, put is much better as it doesn’t have to seek between each write.
Actually… I’m really excited to get a fresh pair of eyes reviewing, cleaning things up and finding better ways of doing things. I banged the entire library out in like weeks and new that this would have to happen to all the way around eventually. Better sooner than later! This is such a huge help.
Glad to be of service
My help may be coming to an end, I’ve banging my head on the background panel issues for far too long now and have started playing with Lemur. Ironically, the background color is a non-issue but there I’m having trouble specifying panel sizes.
Tonegodgui’s mesh handling is a bit difficult to follow, mostly because it’s hard to find out what vertex has what index. I found a really easy to follow variant of that in Lemur’s TbtQuad#refreshGeometry; maybe that’s the kind of doc that’s missing in Tonegodgui. (Paul’s commenting style is terse but provides just enough hints to see what’s not instantly visible in the code; it’s generally a good example to follow.)
@toolforger said:
Glad to be of service :-)
My help may be coming to an end, I've banging my head on the background panel issues for far too long now and have started playing with Lemur. Ironically, the background color is a non-issue but there I'm having trouble specifying panel sizes.
Tonegodgui's mesh handling is a bit difficult to follow, mostly because it's hard to find out what vertex has what index. I found a really easy to follow variant of that in Lemur's TbtQuad#refreshGeometry; maybe that's the kind of doc that's missing in Tonegodgui. (Paul's commenting style is terse but provides just enough hints to see what's not instantly visible in the code; it's generally a good example to follow.)
Very cool! I’m glad to hear you found something that works for you! Do post to say how things are going as you progress.
@toolforger
Updating this post so you don’t have to peice together what I was trying to say
The solution to what you were trying to do is simple:
Use a 5x5 pixel image with a single pixel black border.
The inner pixels should be white at whatever transparency you want.
Set the resize border to Vector4f(2,2,2,2)… this will make sure the static and stretched pixels are the same color… causing no weird color smearing.
Then just use setColor on the material… your border will remain black and the inner panel will tint to the color you want, remaining partially transparent.
The gradient you saw was not a library issue, it is the nature of the beast with texture sampling in shaders. You can verify this yourself, as you will find the same issue in Nifty… and more than likely Lemur as well.
Here are the results to doing this:
[java]
Panel p = new Panel(screen, new Vector2f(100,100), new Vector2f(300,200), new Vector4f(2,2,2,2), “Textures/bg_test4.png”);
p.getElementMaterial().setColor(“Color”, ColorRGBA.Blue);
screen.addElement§;
[/java]
Well, what can I say… it doesn’t happen with Lemur.
My current best guess is that it’s happening withe Tonegodgui because it’s always insisting on using that background color, which then mixes with the texture.
I still don’t know what caused that color ramp.
@toolforger said:
Well, what can I say... it doesn't happen with Lemur.
My current best guess is that it’s happening withe Tonegodgui because it’s always insisting on using that background color, which then mixes with the texture.
I still don’t know what caused that color ramp.
Awesome news! Definitely keep everyone posted on how this works for you!
).
