blitting and drawing lines

[raft]

hello,

i'm drawing lines with open gl commands. this seems to work alone, however when i blit something between the lines, blitting somehow interleaves with lines.

what i do is basicly init projection and ortho mode, disable textures, draw lines and disable projection again

this is the lines only. all seems ok


this is how it looks when a blit text. blitting is not correct, and after first blit, other lines are not drawn


i've figured that, blitting assumes textures are enabled. so after drawing a line, i re-enable textures. this corrects blitting but lines are still missing


any ideas ?

[EgonOlsen]

Can you post that code snippet that draws the boxes? (BTW: Why don't you just blit them too?)

[raft]

sure i can blit them too, but i thought lines maybe handy for some cases

here is the code:

Code Select Expand


public void drawLine(int x1, int y1, int x2, int y2) {
    GL11.glMatrixMode(GL11.GL_PROJECTION);
    GL11.glPushMatrix();
    GL11.glLoadIdentity();

    int width = Display.getDisplayMode().getWidth();
    int height = Display.getDisplayMode().getHeight();
    GLU.gluOrtho2D(0, width, height, 0); //reverse y-coordinate

    GL11.glTranslatef(dX, dY, 0f);
    GL11.glDisable(GL11.GL_TEXTURE_2D);

    GL11.glBegin(GL11.GL_LINE);
    GL11.glVertex2f(x1, y1);
    GL11.glVertex2f(x2, y2);
    GL11.glEnd();

    GL11.glMatrixMode(GL11.GL_PROJECTION);
    GL11.glPopMatrix();
}

[EgonOlsen]

I assume that your are drawing one box, blit the text and then draw the other box? Not all the boxes and then all the blits!? When encountering the first blit, jPCT switches into "blitting mode" to minimize state changes unless another, not blitting related command arrives. Blitting mode doesn't change much...maybe drawing the lines require the depth buffer to be on for some reason? I can't imagine why it should, but it's worth a try to add a GL11.glEnable(GL11.GL_DEPTH_TEST); before drawing the lines and a GL11.glDisable(GL11.GL_DEPTH_TEST); afterwards to see if that helps.

[raft]

I assume that your are drawing one box, blit the text and then draw the other box? Not all the boxes and then all the blits!?

that's right. that assumed to be a simple gui component which takes care of itself. bad for performance but good for clear code.

i've found the reason. the code i've posted isn't exact. i've omited color code:

Code Select Expand

GL11.glColor4f(color.getRed()/255f, color.getGreen()/255f,  color.getBlue()/255f, color.getAlpha()/255f);

the color here is jPCT's RGB color but seems as it ignores alpha part. it's constructed with new RGBColor(255, 255, 255, 255). i guess first blit enables something (what is it?) which makes GL use alpha value. so other lines become invisible.

[EgonOlsen]

Depending on the mode (default or additive), it one of these:

Code Select Expand


case (0):
GL11.glEnable(GL11.GL_BLEND);
GL11.glBlendFunc(GL11.GL_SRC_ALPHA, GL11.GL_ONE_MINUS_SRC_ALPHA);
break;
case (1):
GL11.glEnable(GL11.GL_BLEND);
GL11.glBlendFunc(GL11.GL_SRC_ALPHA, GL11.GL_ONE);
break;
}


So actually a call to GL11.glDisable(GL11.GL_BLEND); before drawing the lines and GL11.glEnable(GL11.GL_BLEND); afterwards should fix the problem.

[raft]

ok, thanks, now it works

what about enabling textures when blitting. will you add it to blit code or should i continue to enable it after drawing ?

[EgonOlsen]

Keep it in your code. Because i can't know if somebody has disabled them from the outside, i would have to enable them on each call, which isn't free.

[raft]

ok

[raft]

now i have a similar situation in android edition blitting and drawing lines work on their own but not together. by trial and error i've noticed gl.glVertexPointer(..) interferes with blitting.

init and clear code is the same as above.

Code Select Expand


    initDraw();
    try {
        //set the vertex buffer
        gl.glVertexPointer(2, GL10.GL_FLOAT, 0, floatBuffer);
           
        //draw
        gl.glDrawElements(GL10.GL_LINES, 2, GL10.GL_UNSIGNED_SHORT, indexBuffer);
    } finally {
        endDraw();
    }


[EgonOlsen]

I see...that's because starting the blitting mode in AE enables those VAs. It should be possible to move that to a later stage, so that it doesn't interfere with your code. I'll try that later today.

[EgonOlsen]

I've uploaded a new AE-jar. Please give it a try.

[raft]

yes, it's ok now, thanks 

[raft]

the color here is jPCT's RGB color but seems as it ignores alpha part. it's constructed with new RGBColor(255, 255, 255, 255).

btw, is this a bug or intentional ? it's a bit weird accepting alpha in constructor and omiting it

[EgonOlsen]

You mean when assigning an additional color to the blit? That's intentional. Transparency of the blit is controlled by it's own transparency setting, not by alpha of the color. The only reason why RGBColor has an alpha value is for clearing the frame buffer with alpha in AE. Desktop jPCT doesn't make use of it.