Results 1 to 3 of 3

Thread: How do you turn off Depth Testing in KGL?

                  
   
  1. #1
    DCEmu Newbie
    Join Date
    Feb 2006
    Posts
    10
    Rep Power
    0

    Default How do you turn off Depth Testing in KGL?

    Hi guys, I'm not only a newb to Dreamcast programming but I'm also not that smart so bear with me if this question sounds stupid.

    I'm trying to do a 2D game and am using KGL. My sprites are textured quads with identical z cordinates. Here's my init routine:
    glKosInit();
    glMatrixMode(GL_MODELVIEW);
    //glShadeModel(GL_SMOOTH);
    glClearColor(0.0f, 0.0f, 0.5f, 1.0f);
    glDisable(GL_CULL_FACE);
    glFrontFace(GL_CCW);
    glEnable(GL_TEXTURE_2D);
    glColor4f(1.0f,1.0f,1.0f, 1.0f);
    glBlendFunc(GL_SRC_ALPHA,GL_ONE_MINUS_SRC_ALPHA);
    glOrtho(0, 640, 0, -480, 0, -1);

    In my render routine, I push this matrix:
    glTranslatef(0.0f, -480.f, 0.0f);

    Then I render the quads in this fashion:
    f32 x1, y1, x2, y2;
    ...
    glBegin(GL_QUADS);
    glVertex3f(x1, y1, 0.0f);
    glVertex3f( x1, y2, 0.0f);
    glVertex3f( x2, y2, 0.0f);
    glVertex3f( x2, y1, 0.0f);
    glEnd();

    Then I pop the matrix.

    In OpenGL (as far as I know) the order these quads are given to OpenGL tells it the order to render, ie a
    My current problem is that the DC seems to always do a depth buffer. So for instance, say I cover the screen with a single, white quad (the texture is filled with all white pixels) and then draw a series of quads after that. Some of those triangles will show up but others won't, as they'll be seemingly hidden behind the big two triangles making up the white background quad. Thus my theory that the DC is doing it's own depth test.

    glDisable(GL_DEPTH_TEST) seems to have no effect. Does anyone know what may be causing this?

    I'm trying to make something 2D, so I need a method for drawing sprites onto the screen. At first glance it would seem like there are two possibilities:
    1) Simply use textured quads in KallistiGL.
    2) Write directly to texture or video memory to create 2D graphics.

    I haven't put much thought into number 2 (I'm not sure if that's even a feasible idea), but it would seem that you'd lose the ability to do easy scaling / rotating of the sprites. If you used textured memory, you'd still have to give the PVR vertice info, right?

    Here's my problem. On the PC, using OpenGL with glDisable(GL_DEPTH_TEST) and an glOrtho(0, 640, 0, -480, 0, -1), what appears on the screen is whatever you put there last, ie you draw a quad from a green texture first, that appears, then you draw a quad for a orange texture, the orange one will appear over the green one.

    Unfortunetly in KGL that doesn't seem to be the case as it appears that parts of the quads (triangles) are showing through the other quads randomly. Each of the quads has their z specified to be 0. Is there any way to turn off depth testing or otherwise prevent this behavior?

  2. #2
    DCEmu Newbie
    Join Date
    Feb 2006
    Posts
    10
    Rep Power
    0

    Default New question

    Ok, I've been looking at the PvrMark.c code included in the DevIso and think (hopefully) if I use these methods I shouldn't get the problems I was getting before.

    (If anyone for any reason ever googles this, pvrmark.c in the examples/pvr is where all the juicy 2D stuff is).

    So, new question:
    Assuming this is the correct code to display a quad (and I just did this this morning, I'm sort of in a rush to post this before I go to work because I'd love an answer):

    vert.flags = PVR_CMD_VERTEX;
    vert.x = x - width;
    vert.y = y + height;
    vert.z = z;
    vert.u = vert.v = 0.0f;
    //vert.argb = col | (col << 8) | (col << 16) | 0xff000000;
    vert.argb = argb;
    vert.oargb = 0;
    pvr_prim(&vert, sizeof(vert));


    vert.y = y - height;
    pvr_prim(&vert, sizeof(vert));

    vert.y = y + height;
    vert.x = x + width;
    pvr_prim(&vert, sizeof(vert));

    vert.flags = PVR_CMD_VERTEX_EOL;
    // vert.x = x + width;
    vert.y = y - height;
    pvr_prim(&vert, sizeof(vert));

    What is the code to give pvr_prim the texel information? Any links to some source of documentation would be great, although in general my question is now less pressing.

  3. #3
    DCEmu Newbie
    Join Date
    Feb 2006
    Posts
    10
    Rep Power
    0

    Default

    Okay, I figured it out.

    pvr_vertex_t vert has a variable for "v" and "u". I'm sure I can figure this out now.

    Sorry to bother everyone.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •