[FIXED] Texture Loading on the New GL API

[Jae686]

Good afternoon.

On the old version of KGL, I used the following code to load a given texture :

Code: Select all

#include <kos.h>
#include <GL/gl.h>
#include <GL/glu.h>
#include <pcx/pcx.h>

void loadtxr(const char *fn, GLuint *txr, int *w, int *h  ) {
    kos_img_t img;
    pvr_ptr_t txaddr;

    if(pcx_to_img(fn, &img) < 0) {
        printf("can't load %s\n", fn);
        return;
    }

    txaddr = pvr_mem_malloc(img.w * img.h * 2);
    *w = img.w ;
    *h = img.h ;
    pvr_txr_load_kimg(&img, txaddr, PVR_TXRLOAD_INVERT_Y);
    kos_img_free(&img, 0);

    glGenTextures(1, txr);
    glBindTexture(GL_TEXTURE_2D, *txr);
    glKosTex2D(GL_RGB565_TWID, img.w, img.h, txaddr);
}

But since glKosTex2D appears to have been removed, (because i get this on compile )

Code: Select all

jaerder@jaerder-G50V ~/development/Projectos Software/vidfdc/dreamcast $ make
rm -f bin/main.elf romdisk.*
/home/jaerder/development/Tools/dreamcast/kallistios/utils/genromfs/genromfs -f romdisk.img -d romdisk -v -x .svn
0    rom 53f23e19         [0xffffffff, 0xffffffff] 37777777777, sz     0, at 0x0     
1    .                    [0x817     , 0xde0013  ] 0040755, sz     0, at 0x20    
1    ..                   [0x817     , 0xde0002  ] 0040755, sz     0, at 0x40     [link to 0x20    ]
1    exporter_t.xml       [0x817     , 0xde011d  ] 0100644, sz  2464, at 0x60    
1    piramid.mtl          [0x817     , 0xde0147  ] 0100644, sz   279, at 0xa20   
1    bw.pcx               [0x817     , 0xde0135  ] 0100644, sz 78181, at 0xb60   
1    checkerboard.pcx     [0x817     , 0xde003f  ] 0100644, sz  4993, at 0x13cf0 
1    teste.obj            [0x817     , 0xde0037  ] 0100644, sz   887, at 0x150b0 
1    piramid.obj          [0x817     , 0xde012e  ] 0100644, sz   859, at 0x15450 
1    font_2.fnt           [0x817     , 0xde0104  ] 0100644, sz 15848, at 0x157d0 
1    plane.obj            [0x817     , 0xde0038  ] 0100644, sz   555, at 0x195e0 
1    teste.xml_x          [0x817     , 0xde004e  ] 0100644, sz  1802, at 0x19830 
1    hex.obj              [0x817     , 0xde0123  ] 0100644, sz  3374, at 0x19f60 
1    monkey.obj           [0x817     , 0xde003d  ] 0100644, sz 99318, at 0x1acb0 
1    font.png             [0x817     , 0xde001c  ] 0100644, sz 17671, at 0x330d0 
1    crate.pcx            [0x817     , 0xde002c  ] 0100644, sz 66451, at 0x37600 
1    font_2.png           [0x817     , 0xde0103  ] 0100644, sz 61359, at 0x479c0 
1    font.fnt             [0x817     , 0xde001b  ] 0100644, sz 15907, at 0x56990 
/home/jaerder/development/Tools/dreamcast/kallistios/utils/bin2o/bin2o romdisk.img romdisk romdisk.o
kos-cc -o bin/main.elf src/main.o src/data_estructures.o src/dc_render.o src/obj_loader.o src/asset_loader.o src/pcx_loader.o src/xml_parser.o src/fnt_parser.o src/png_loader.o src/procedural.o romdisk.o  -L/home/jaerder/development/Tools/dreamcast/kallistios/lib  -lgl -lpcx -lkosutils -lexpat -lpng -lz -lm -Wl,--start-group -lkallisti -lc -lgcc -Wl,--end-group 
src/pcx_loader.o: In function `loadtxr':
/home/jaerder/development/Projectos Software/vidfdc/dreamcast/src/pcx_loader.c:24: undefined reference to `_glKosTex2D'
src/png_loader.o: In function `loadpng':
/home/jaerder/development/Projectos Software/vidfdc/dreamcast/src/png_loader.c:24: undefined reference to `_glKosTex2D'
collect2: error: ld returned 1 exit status
make: *** [bin/main.elf] Error 1
jaerder@jaerder-G50V ~/development/Projectos Software/vidfdc/dreamcast $ 

Therefore, and looking at the new examples, one would believe that glTexImage2D() should be used.

But my confusion is on the fmt member of the kos_img_t struct.

As specified on http://gamedev.allusion.net/docs/kos-cu ... ource.html do seem not match the specs defined on http://sourceforge.net/p/cadcdev/libgl/ ... clude/gl.h or http://gamedev.allusion.net/docs/kos-cu ... vr_8h.html.

Therefore if I wish to make a texture available via glTexImage2D() i would be inclided to do

Code: Select all

#include <kos.h>
#include <GL/gl.h>
#include <GL/glu.h>
#include <pcx/pcx.h>

void loadtxr(const char *fn, GLuint *txr, int *w, int *h  ) {
    kos_img_t img;
    pvr_ptr_t txaddr;

    if(pcx_to_img(fn, &img) < 0) {
        printf("can't load %s\n", fn);
        return;
    }

    txaddr = pvr_mem_malloc(img.w * img.h * 2);
    *w = img.w ;
    *h = img.h ;
    pvr_txr_load_kimg(&img, txaddr, PVR_TXRLOAD_INVERT_Y);
    

    glGenTextures(1, txr);
    glBindTexture(GL_TEXTURE_2D, *txr);
    

    glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB,
                img.w,img.h, 0,
                img.fmt, GL_RGB, img.data);

    
    kos_img_free(&img, 0);
}

But since fmt definitions seems to differ from ogl....
Any recommendations on what may be the best method for texture loading ?

[EDIT]
The code mentioned above does , indeed, NOT work.

PH3N0N,

Code: Select all

glClearColor(1.0f, 1.0f, 1.0f, 1.0f);

, appears to have no effect.
Also, did the coords on Othographic projection change compared to the old KGL / KGL-X ?

[Jae686]

My issue is now fixed.

This the the following code to bind a png texture as a OGL texture :
(Based on the new examples provided, although I dunno where on earth the .pvr file format came from, I'm only assuming, from the examples, that it is raw texture data plus a header)

Code: Select all

#include <kos.h>
#include <GL/gl.h>
#include <GL/glu.h>
#include <png/png.h>
#include "img_loader_aux.h"

void loadpng(const char *fn, GLuint *txr, int *w, int *h) {
    pvr_ptr_t txaddr;
    int iw , ih = 0 ;

    if(png_load_texture(fn, &txaddr,PNG_FULL_ALPHA, &iw, &ih) < 0) {
         printf("can't load %s\n", fn);
        return;
    }

    *w = iw ;
    *h = ih ;
    printf("WIDTH : %d, HEIGHT : %d\n", iw, ih);


 

    glGenTextures(1, txr);
    glBindTexture(GL_TEXTURE_2D, *txr);
   
    glKosTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA,
                 iw, ih, 0,
                 PVR_TXRFMT_TWIDDLED, PVR_TXRFMT_ARGB4444, txaddr);

  
}

It would be perfect if I could determine the apropriate glKosTexImage2D() parameters at runtime though.




The render time is quite odd though.

Best Regards.

P.S. The ortho coordinates are totally different..!

[PH3NOM]

PH3N0N,

Code: Select all

glClearColor(1.0f, 1.0f, 1.0f, 1.0f);

, appears to have no effect.

I should have mentioned that I did not plan to be fully backwards compatible with old KGL API.
The old KGL was not exactly doing things by the standard, so in some areas I attempted to be a bit closer to the standard.

If you look at the standard definition of glClearColor
https://www.khronos.org/opengles/sdk/do ... rColor.xml

glClearColor(...) will set the values of the color to be set, but will have no effect until you call
glClear(GL_COLOR_BUFFER_BIT);

My issue is now fixed.

This the the following code to bind a png texture as a OGL texture :
(Based on the new examples provided, although I dunno where on earth the .pvr file format came from, I'm only assuming, from the examples, that it is raw texture data plus a header)

Code: Select all

void loadpng(const char *fn, GLuint *txr, int *w, int *h) {
...
    glKosTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA,
                 iw, ih, 0,
                 PVR_TXRFMT_TWIDDLED, PVR_TXRFMT_ARGB4444, txaddr);
...
}

It would be perfect if I could determine the apropriate glKosTexImage2D() parameters at runtime though.

Yes, in the new Open GL API, I removed the old glKos texture loading function, and replaced that with one that is slightly closer to the way the standard GL API works.

If you look at the comments above the function protocols in gl.h, you will see that
"glTexImage2D(...)" is for use when you are loading a texture that is stored in main RAM.
With this function, Open GL will take care of the dirty work for you: allocating PVR memory and data transfer from cpu to gpu, etc.

"glKostexImage2D(...)" is for use when your texture data is already loaded into PVR memory.
Open GL will assume that you are passing the data as a pointer to a location in PVR memory.

The best demo for looking at texture submission would be the radial blur example, kgl/demos/blur.
That demo uses glTexImage2D for binding the .pvr texture, and it uses glKosTexImage2D for binding the render-to-texture result.

The .pvr texture is the "official" texture format used by DC hardware. Most retail games use the .pvr texture extension.

The .pvr texture loader I wrote should be able to handle either VQ compressed, or Raw texture data.

If you notice in my texture loader, we use the file header to determine what size and color format the texture is.
Therefore, I see no reason why you cant determine the "apropriate glKosTexImage2D() parameters at runtime."

The render time is quite odd though.

Best Regards.

The render time you are seeing is most likely the CPU time spent building the vertex data needed to feed the GPU.
Without looking at your code, I would have to guess you are measuring time submitting vertex data to the API, but you are not measuring how much time "glutSwapBuffers()" takes.

In my API, all of the client submission occurs on the CPU. When the client is finished submitting vertex data for the scene, the client will call "glutSwapBuffers".

When "glutSwapBuffers()" is called, the API will then proceed to interact with the GPU, waiting for the PVR to get a vblank, and then feed the PVR all of the vertex data for the scene.

Therefore, we can effectively isolate the time spent in the render process as time spent by the CPU, or time spent by the GPU, as seen in some of the recent screens I have posted in the other thread.

P.S. The ortho coordinates are totally different..!

glOrtho() should behave as expected, there is an example using it kgl/basic/scissor.
However, I should ask, are you submitting vertices in ortho mode as glVertex2f, or glVertex3f?

[Jae686]

PH3N0N,

Code: Select all

glClearColor(1.0f, 1.0f, 1.0f, 1.0f);

, appears to have no effect.

I should have mentioned that I did not plan to be fully backwards compatible with old KGL API.
The old KGL was not exactly doing things by the standard, so in some areas I attempted to be a bit closer to the standard.

If you look at the standard definition of glClearColor
https://www.khronos.org/opengles/sdk/do ... rColor.xml

glClearColor(...) will set the values of the color to be set, but will have no effect until you call
glClear(GL_COLOR_BUFFER_BIT);

Thank you, and in fact on IRC they brought that detail to my attention.

My issue is now fixed.

This the the following code to bind a png texture as a OGL texture :
(Based on the new examples provided, although I dunno where on earth the .pvr file format came from, I'm only assuming, from the examples, that it is raw texture data plus a header)

Code: Select all

void loadpng(const char *fn, GLuint *txr, int *w, int *h) {
...
    glKosTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA,
                 iw, ih, 0,
                 PVR_TXRFMT_TWIDDLED, PVR_TXRFMT_ARGB4444, txaddr);
...
}

It would be perfect if I could determine the apropriate glKosTexImage2D() parameters at runtime though.

Yes, in the new Open GL API, I removed the old glKos texture loading function, and replaced that with one that is slightly closer to the way the standard GL API works.

If you look at the comments above the function protocols in gl.h, you will see that
"glTexImage2D(...)" is for use when you are loading a texture that is stored in main RAM.
With this function, Open GL will take care of the dirty work for you: allocating PVR memory and data transfer from cpu to gpu, etc.

"glKostexImage2D(...)" is for use when your texture data is already loaded into PVR memory.
Open GL will assume that you are passing the data as a pointer to a location in PVR memory.

The best demo for looking at texture submission would be the radial blur example, kgl/demos/blur.
That demo uses glTexImage2D for binding the .pvr texture, and it uses glKosTexImage2D for binding the render-to-texture result.

The .pvr texture is the "official" texture format used by DC hardware. Most retail games use the .pvr texture extension.

The .pvr texture loader I wrote should be able to handle either VQ compressed, or Raw texture data.

If you notice in my texture loader, we use the file header to determine what size and color format the texture is.
Therefore, I see no reason why you cant determine the "apropriate glKosTexImage2D() parameters at runtime."

(emphasis mine)

In your texture loader you have those parameters on the header of the .pvr file...... If you look into my code you will notice that I am loading from a png file instead. I can't determine the "apropriate glKosTexImage2D() parameters at runtime. " because I don't know, at the moment, how to retrieve the texture format from a texture loaded through png_load_texture(), since a pvr_ptr_t only has, as far as I know, headless texture data. (I infer this from the pvr_ptr_t declaration at http://gamedev.allusion.net/docs/kos-cu ... 55426d0fa4 ).

One option would be get the texture loaded into a .kmg and get the data from the kos_img struct's fmt field.....

The render time is quite odd though.

Best Regards.

The render time you are seeing is most likely the CPU time spent building the vertex data needed to feed the GPU.
Without looking at your code, I would have to guess you are measuring time submitting vertex data to the API, but you are not measuring how much time "glutSwapBuffers()" takes.

In my API, all of the client submission occurs on the CPU. When the client is finished submitting vertex data for the scene, the client will call "glutSwapBuffers".

When "glutSwapBuffers()" is called, the API will then proceed to interact with the GPU, waiting for the PVR to get a vblank, and then feed the PVR all of the vertex data for the scene.

Therefore, we can effectively isolate the time spent in the render process as time spent by the CPU, or time spent by the GPU, as seen in some of the recent screens I have posted in the other thread.

P.S. The ortho coordinates are totally different..!

glOrtho() should behave as expected, there is an example using it kgl/basic/scissor.
However, I should ask, are you submitting vertices in ortho mode as glVertex2f, or glVertex3f?

Regarding the ortho coordinates.....
(Notice the text location)
Old KOS API :


New API (after fixing some issues also related with coord's) :


To render the text I use the following function :

Code: Select all

void print_text(pDemoAssetList d, char* font_name,  char* txt, int xpos, int ypos, const float scale)
{
    int curr_texture_pos = getTexturePos(d->t, font_name);
    int curr_texture = retrieveTextureHandle(d->t, curr_texture_pos);

    int tex_w = retrieveTextureWidth(d->t, curr_texture_pos);
    int tex_h = retrieveTextureHeight(d->t, curr_texture_pos);

    glBindTexture(GL_TEXTURE_2D, curr_texture);
    
    glDisable(GL_DEPTH_TEST);
    glEnable(GL_BLEND);
    glBlendFunc( GL_ONE, GL_ONE_MINUS_SRC_ALPHA );

    glMatrixMode(GL_PROJECTION);
    glPushMatrix();
    glLoadIdentity();
    glOrtho(0,640,0,480, -1,1);
    glMatrixMode(GL_MODELVIEW);
    glPushMatrix();
    glLoadIdentity();

    

    int txt_len = strlen(txt);
    int i = 0 ;

    unsigned int c ;

    float cursor = 0;

    float n_width = 0 ;
    float n_height = 0.5 ;
    float spacing = 5 ;

    float uv_x, uv_y, uv_wx, uv_wy;
    vec2 uv_up_l, uv_up_r;
    vec2 uv_bottom_r, uv_bottom_l;

    vec2 quad_up_l, quad_up_r;
    vec2 quad_down_l, quad_down_r;

    pTexFontList f = getTexFont(d->f, font_name);
    
     

    for(i = 0; i < txt_len ; i++)
    {
        
        
        c = txt[i];

        n_width = new_width(f->charCoord[c].width, f->charCoord[c].height, scale) ;

        uv_x =  (f->charCoord[c].x / (float) tex_w);
        uv_y = (f->charCoord[c].y / (float)tex_h);

        uv_wx =  ((f->charCoord[c].x + f->charCoord[c].width) / (float) tex_w) ; 
        uv_wy = ((f->charCoord[c].y + f->charCoord[c].height) / (float) tex_h) ;


        uv_bottom_l.u = uv_x ;
        uv_bottom_l.v = uv_y ;

        uv_bottom_r.u = uv_wx ; 
        uv_bottom_r.v = uv_y ;
        
        uv_up_r.u = uv_wx ;
        uv_up_r.v = uv_wy ;

        uv_up_l.u = uv_x ;
        uv_up_l.v = uv_wy ;

        //old uv coords
        /*
        uv_bottom_l.u = uv_x ;
        uv_bottom_l.v = uv_wy ;

        uv_bottom_r.u = uv_wx ;
        uv_bottom_r.v = uv_wy ;
        
        uv_up_r.u = uv_wx ;
        uv_up_r.v = uv_y ;

        uv_up_l.u = uv_x ;
        uv_up_l.v = uv_y ;
        */

        // quad old coords
        /*
        quad_up_l.u = xpos + cursor;
        quad_up_l.v = ypos + (f->charCoord[c].height * scale) ;
        
        quad_up_r.u = xpos + cursor + (f->charCoord[c].width * scale) ;
        quad_up_r.v = ypos + (f->charCoord[c].height * scale);

        quad_down_r.u = xpos + cursor + (f->charCoord[c].width * scale);
        quad_down_r.v = ypos ;

        quad_down_l.u = xpos + cursor;
        quad_down_l.v = ypos;
        */
        //quad new coords


        quad_up_l.u = xpos + cursor;
        quad_up_l.v = ypos  ;
        
        quad_up_r.u = xpos + cursor + (f->charCoord[c].width * scale) ;
        quad_up_r.v = ypos  ;

        quad_down_r.u = xpos + cursor + (f->charCoord[c].width * scale);
        quad_down_r.v = ypos - (f->charCoord[c].height * scale) ;

        quad_down_l.u = xpos + cursor;
        quad_down_l.v = ypos - (f->charCoord[c].height * scale) ;





    glBegin(GL_QUADS);                      // Draw A Quad
       
        glTexCoord2f(uv_up_l.u , uv_up_l.v);
        glVertex2f(quad_up_l.u , quad_up_l.v);              // Top Left
        glTexCoord2f(uv_up_r.u , uv_up_r.v); 
        glVertex2f( quad_up_r.u , quad_up_r.v);
        glTexCoord2f(uv_bottom_r.u , uv_bottom_r.v);             // Top Right
        glVertex2f( quad_down_r.u , quad_down_r.v );
        glTexCoord2f(uv_bottom_l.u , uv_bottom_l.v);              // Bottom Right
        glVertex2f(quad_down_l.u , quad_down_l.v ); 
                     // Bottom Left
    glEnd();                            // Done Drawing The Quad

   

    cursor = cursor + (f->charCoord[c].width * scale) + spacing;


    }

  


    glMatrixMode(GL_PROJECTION);                        // Select The Projection Matrix
    glPopMatrix();                              // Restore The Old Projection Matrix


    glMatrixMode(GL_MODELVIEW);                     // Select The Modelview Matrix
    glPopMatrix();                              // Restore The Old Projection Matrix

    glDisable(GL_BLEND);

    glEnable(GL_DEPTH_TEST);   

}

To have a better perspective you can see the whole code here : https://bitbucket.org/jae686/vidfdc/src ... ter#cl-221

Best Regards!

[Quzar]

"glKostexImage2D(...)" is for use when your texture data is already loaded into PVR memory.
Open GL will assume that you are passing the data as a pointer to a location in PVR memory.

Why not just determine where the texture is located based off the pointer at runtime? That would eliminate one more nonstandard function from the mix.

[BlueCrab]

"glKostexImage2D(...)" is for use when your texture data is already loaded into PVR memory.
Open GL will assume that you are passing the data as a pointer to a location in PVR memory.

Why not just determine where the texture is located based off the pointer at runtime? That would eliminate one more nonstandard function from the mix.

As long as people aren't using the MMU, that's pretty easy to do.

If you use the MMU in your code (which KOS can do, of course), then you might run into trouble if you map some strange place to VRAM.

That said, I think it is actually a bit more clear the way that things are anyway (to have a separate function for using something already in VRAM). OpenGL isn't necessarily designed for you to have such low-level control over the video memory pool, so it's actually better, in my opinion, to leave things as they are with a separate extension function.

[PH3NOM]

(emphasis mine)

In your texture loader you have those parameters on the header of the .pvr file...... If you look into my code you will notice that I am loading from a png file instead. I can't determine the "apropriate glKosTexImage2D() parameters at runtime. " because I don't know, at the moment, how to retrieve the texture format from a texture loaded through png_load_texture(), since a pvr_ptr_t only has, as far as I know, headless texture data. (I infer this from the pvr_ptr_t declaration at http://gamedev.allusion.net/docs/kos-cu ... 55426d0fa4 ).

One option would be get the texture loaded into a .kmg and get the data from the kos_img struct's fmt field.....

Using a PNG texture, you only have 3 options of what the texture color will be.
Alpha 0 = PVR_TXRFMT_RGB565
Alpha 1 = PVR_TXRFMT_ARGB1555
Alpha 2 = PVR_TXRFMT_ARGB4444

From there, it is up to your engine to determine what level of alpha channel to use.
For example, Quake 3 BSP's use a structure that stores not only the name of the texture, but also flags for the texture.
Then by examining the flags of the texture, you can decide what level of alpha to use, and therefore, the correct parameters to pass to glTexImage2D(...).

Regarding the ortho coordinates.....
(Notice the text location)
Old KOS API :
...
New API (after fixing some issues also related with coord's) :
...

To render the text I use the following function :
...

To have a better perspective you can see the whole code here : https://bitbucket.org/jae686/vidfdc/src ... ter#cl-221

Best Regards!

Thanks for pointing that out. Too bad this was not noticed by any of the beta testers using my API.
As I thought, hence why I asked, this problem only applies to glVertex2f, not glVertex3f.

I will admit currently glVertex2f represents an area where I did not ensure things are as the standard defines.
I will probably end up re-naming the current glVertex2f to glKosVertex2f, because I am not transforming the 2D vertices, instead submitting them directly to the PVR.

Using the PVR, 0,0 is the top left corner of the screen, and 640,480 is the bottom right corner of the screen.

It appears that your code expects the vertical plane to be inverted from what the PVR expects, that means 0,0 is the bottom left corner, and 640,480 is the top right corner.

I will take a look and see if I can come up with a patch to get things working closer to what the standard expects.

EDIT:

One last note, one obvious thing I noticed in your font render code is that you are calling glBegin(...)/glEnd(...) for every quad submitted (i.e. every character) in your font render routine.
This can be easily optimized by putting glBegin(...) before your loop

Code: Select all

for(i = 0; i < txt_len ; i++)

and glEnd(...) after your loop.

There are a few good reasons why you should minimize calls to glBegin(...)/glEnd(...).
1.) Every call to glBegin(...) will basically consume 1 pvr_vertex_t in size of the gl vertex buffer.
-> This means for every 4 vertices you are submitting, you are actually submitting 5 in terms of how much data is being transferred to the PVR.
2.) glBegin(...) will compile a global parameter for the PVR. See my post here to see why that slows things down:
viewtopic.php?f=29&t=102181&start=40#p1034350

[Quzar]

"glKostexImage2D(...)" is for use when your texture data is already loaded into PVR memory.
Open GL will assume that you are passing the data as a pointer to a location in PVR memory.

Why not just determine where the texture is located based off the pointer at runtime? That would eliminate one more nonstandard function from the mix.

As long as people aren't using the MMU, that's pretty easy to do.

If you use the MMU in your code (which KOS can do, of course), then you might run into trouble if you map some strange place to VRAM.

That said, I think it is actually a bit more clear the way that things are anyway (to have a separate function for using something already in VRAM). OpenGL isn't necessarily designed for you to have such low-level control over the video memory pool, so it's actually better, in my opinion, to leave things as they are with a separate extension function.

I just figure that if the MMU is being used then things are going to be wonky all over the place anyways (that is, if someone is remapping the normal memory space used for vram, not using the MMU in general).

OpenGL not being designed for you to have low level control is exactly the reason I would not have an extension function and just have it detect wherever the texture is and take the appropriate steps to deal with it internally. It would also tap it closer and closer to being standard.

Was just suggesting in case it was something that had slipped by or hadn't been considered.

[PH3NOM]

Regarding the ortho coordinates.....
(Notice the text location)
Old KOS API :
...
New API (after fixing some issues also related with coord's) :
...

To render the text I use the following function :
...

To have a better perspective you can see the whole code here : https://bitbucket.org/jae686/vidfdc/src ... ter#cl-221

Best Regards!

Thanks for pointing that out. Too bad this was not noticed by any of the beta testers using my API.
As I thought, hence why I asked, this problem only applies to glVertex2f, not glVertex3f.

I will admit currently glVertex2f represents an area where I did not ensure things are as the standard defines.
I will probably end up re-naming the current glVertex2f to glKosVertex2f, because I am not transforming the 2D vertices, instead submitting them directly to the PVR.

...

I will take a look and see if I can come up with a patch to get things working closer to what the standard expects.

Tonight I have done just that.

Submitting 2D vertices should behave as you would expect in the standard Open GL, using glVertex2f(...).

However, I have included the function glKosVertex2f(...) for submitting 2D vertices to the PVR without transformation.
This is faster than the standard glVertex2f.

Pull the latest commit to get up to date and let me know if that fixes the problems you mentioned previously.