New Open GL API Released

[SiZiOUS]

THIS RELEASE IS PH3NOMENAL !

Thank you a lot for releasing this library, and I'm really happy to see that it has been included in KOS repository!
Dreamcast isn't dead, my friends

[PH3NOM]

Just a note, today the API has received its first major update.

Frame Buffer Objects have been added to use for render-to-texture, so things work as the GL standard defines.
-Look at demos/blur for an example.

Texture parameters now apply to textures as GL would expect.
Texture clamping should now work as expected.
Error checking in the API has been added in some areas, so look at the console output to see errors thrown.
Blending for non-textured polys should now work as expected.

Git the latest build to get up to date
https://sourceforge.net/p/cadcdev/libgl/ci/master/tree

[bogglez]

Nice release! I will also get back to GL dev soon. I'm just really busy at work now.
I like that you replaced custom functions with standard ones.
Why does get active texture always return 0?

[mankrip]

I will definitely try this sometime. Thanks.

[PH3NOM]

I like that you replaced custom functions with standard ones.

Nice. That was done thanks to our conversations prompting me to do so

Why does get active texture always return 0?

Code: Select all

GL_ACTIVE_TEXTURE
params returns a single value indicating the active multitexture unit. The initial value is GL_TEXTURE0. See glActiveTexture. 

Problem is, the PVR does not support multi-texture in hardware.
Basically, that means we need to transform/submit every vertex multiple times, i.e. once per enabled texture unit.
I had minimized the burden on the CPU by only transforming each vertex once, but then submitting multiple times to the PVR ( each with their own u/v set ).
However, I realized some problems with my old multi-texture code, specifically when NearZ Clipping is enabled.
Because of that, in this build, the old multi-texture code has been removed, and so have the examples using it.
When I get some time, one of my top priorities for the API is working out a proper multi texture unit implementation.

If you have any ideas on the implementation, as always, let me know!

[bogglez]

Why does get active texture always return 0?

Code: Select all

GL_ACTIVE_TEXTURE
params returns a single value indicating the active multitexture unit. The initial value is GL_TEXTURE0. See glActiveTexture. 

Problem is, the PVR does not support multi-texture in hardware.
Basically, that means we need to transform/submit every vertex multiple times, i.e. once per enabled texture unit.
I had minimized the burden on the CPU by only transforming each vertex once, but then submitting multiple times to the PVR ( each with their own u/v set ).
However, I realized some problems with my old multi-texture code, specifically when NearZ Clipping is enabled.
Because of that, in this build, the old multi-texture code has been removed, and so have the examples using it.
When I get some time, one of my top priorities for the API is working out a proper multi texture unit implementation.

If you have any ideas on the implementation, as always, let me know!

I think you're confused about what this function does?

glActiveTexture selects which texture unit subsequent texture state calls will affect.

So all you have to do in glGet is to return the argument of the last glActiveTexture call. This is a bug. Not that glGet for the active texture is useful or anything..

[PH3NOM]

Texture Units are not implemented currently in the API, I would not consider that a bug

Code: Select all

Multitexture

Modern OpenGL hardware implementations support the capability to apply two or more textures to geometry simultaneously. If an implementation supports more than one texture unit, you can query with GL_MAX_TEXTURE_UNITS to see how many texture units are available:

So, if you query GL_MAX_TEXTURE_UNITS in my API, it will return -1. The -1 is there to indicate an invalid parameter, thus indicating that multi texture units are not supported.

But as I said, I do plan to have another go at it when I get some time...

[Jae686]

Good Afternoon.
I've checked out the latest version of the API, but now I get the following error :

Code: Select all

 
/home/jaerder/development/Tools/dreamcast/kallistios/utils/bin2o/bin2o romdisk.img romdisk romdisk.o
kos-cc -o bin/main.elf bin/asset_loader.o bin/data_estructures.o bin/dc_render.o bin/fnt_parser.o bin/loading_screen.o bin/main.o bin/matrix.o bin/obj_loader.o bin/pcx_loader.o bin/png_loader.o bin/procedural.o bin/xml_parser.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 
bin/dc_render.o: In function `InitRenderTexture':
/home/jaerder/development/Projectos Software/vidfdc/dreamcast/src/dc_render.c:128: undefined reference to `_glKosTexImage2D'
bin/pcx_loader.o: In function `loadtxr':
/home/jaerder/development/Projectos Software/vidfdc/dreamcast/src/pcx_loader.c:32: undefined reference to `_glKosTexImage2D'
bin/png_loader.o: In function `loadpng':
/home/jaerder/development/Projectos Software/vidfdc/dreamcast/src/png_loader.c:29: undefined reference to `_glKosTexImage2D'
collect2: error: ld returned 1 exit status
make: *** [bin/main.elf] Error 1

What happened to the glKosTexImage2D function?

[bogglez]

Good Afternoon.
I've checked out the latest version of the API, but now I get the following error :

Code: Select all

 
/home/jaerder/development/Tools/dreamcast/kallistios/utils/bin2o/bin2o romdisk.img romdisk romdisk.o
kos-cc -o bin/main.elf bin/asset_loader.o bin/data_estructures.o bin/dc_render.o bin/fnt_parser.o bin/loading_screen.o bin/main.o bin/matrix.o bin/obj_loader.o bin/pcx_loader.o bin/png_loader.o bin/procedural.o bin/xml_parser.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 
bin/dc_render.o: In function `InitRenderTexture':
/home/jaerder/development/Projectos Software/vidfdc/dreamcast/src/dc_render.c:128: undefined reference to `_glKosTexImage2D'
bin/pcx_loader.o: In function `loadtxr':
/home/jaerder/development/Projectos Software/vidfdc/dreamcast/src/pcx_loader.c:32: undefined reference to `_glKosTexImage2D'
bin/png_loader.o: In function `loadpng':
/home/jaerder/development/Projectos Software/vidfdc/dreamcast/src/png_loader.c:29: undefined reference to `_glKosTexImage2D'
collect2: error: ld returned 1 exit status
make: *** [bin/main.elf] Error 1

What happened to the glKosTexImage2D function?

It has been removed. There's no need for it, since you can do the same thing with standard OpenGL's framebuffer objects which have been added with this release.

[Jae686]

Well, doing so it broke my code. I should have probably read the changelog before upgrading.

[GyroVorbis]

We just got back from SIEGECon promoting Elysian Shadows, and I want you to know that we pushed the SHIT out of this GL API for Dreamcast. Got QUITE A FEW developers very interested in developing for DC, and this is pretty much a dream come true for them... Carry on the good fight!

[PH3NOM]

We just got back from SIEGECon promoting Elysian Shadows, and I want you to know that we pushed the SHIT out of this GL API for Dreamcast. Got QUITE A FEW developers very interested in developing for DC, and this is pretty much a dream come true for them... Carry on the good fight!

Hey Gyro hope things are on track for u guys.

Anyhow today I have added a basic multi-texture support to the API as well as glCompressedTexImage2D for use with vq compressed textures.
For now, multi-texture does not work in immediate mode; it only works with glDrawArrays and glDrawElements.
Examples updated.

[PH3NOM]

Just letting you guys know that I have made a decent update to the API today, as usual, get it here:
http://sourceforge.net/p/cadcdev/libgl/ci/master/tree/

[PH3NOM]

Just letting you guys know that I have made a decent update to the API today, as usual, get it here:
http://sourceforge.net/p/cadcdev/libgl/ci/master/tree/

A quick list of what is new:
+Added Texture Format Conversion for glTexImage2D, allowing many more texture types to be uploaded
-Before, the API would only accept texture formats directly supported by the PVR hardware; i.e. 16bpp textures.
-Now you can upload 16bpp as before, 24bpp(8bit RGB), 32bpp(8bit RGBA), 48bpp(16bit RGB), 64bpp(16bit RGBA), 96bpp(32bit Float RGB), or even 128bpp(32bit Float ARGB)

+Added GL_TEXTURE Matrix for transforming U/V Components. This is a somewhat custom implementation; you must enable the transformations by glEnable(GL_KOS_TEXTURE_MATRIX). By default, this is disabled.

+Added glFrustum(...) definition to gl.h, was a bug reported on the forums here

+Added function glGetString(...)

+Fixed a bug in the rotation direction of glRotatef, reported by MisterDave here.

+Fixed a bug using GL_QUADS with glDrawArrays.

[bogglez]

Great work as usual! Some comments:

1. It would be nice if you could make smaller commits
2. I see you used a different glRotate fix than posted here. Did you check the rotation of the other axes? I'd compare rotating a cube on PC and DC
3. You're toying with DMA again, any good results or what's the reason?
4. For the 2D Texture coordinate case which is arguably the more common one you can transform 2 with one matrix multiplication at the same time. Put the matrix in the top left and bottom right and put the coordinate in the 4d vector argument twice.
5. In your texture conversion code you allocate 2 * w*h bytes on the stack. I think that could corrupt the memory? 1024x1024 textures would result in 2MB on the stack

[PH3NOM]

1. Sorry mate that's just how I roll

2. I need to re-configure my PC chain ATM, I will try to get into it today.

3. The DMA Vertex Transfer is still experimental, and thus disabled by default.
The current implementation is using blocking DMA and shows faster throughput on emulator, but is not working on real hardware.
I would like to enable non-blocking DMA transfers for the Multi-Texture Pass, as it should be possible to be setting the next texture units multi u/v cords on the CPU while the DMA simultaneously transfers current texture unit's vertex buffer.

4. Texture coordinates, even 2D, are still transformed as a 4D vector, from the redbook:

When the four texture coordinates (s, t, r, q) are multiplied by the texture matrix, the resulting vector (s' t' r' q') is interpreted as homogeneous texture coordinates. In other words, the texture map is indexed by s'/q' and t'/q' . (Remember that r'/q' is ignored in standard OpenGL, but may be used by implementations that support a 3D texture extension.)

Are you sure your idea would work? I don't see how you compute the q component in your proposed approach?

5. Didn't think that would be a problem, but it would be easy enough to malloc() instead...

[BlueCrab]

5. Didn't think that would be a problem, but it would be easy enough to malloc() instead...

Please make it use malloc instead, as soon as possible. That will certainly overflow the stack on any relatively large texture on anything but the main thread. That will not only cause stack related problems, but will also cause heap problems (since thread stacks are allocated with malloc, so they're on the heap too).

By default, threads are only allocated 32KiB of stack space, meaning even a 128x128 texture will cause problems (that size would be exactly 32KiB, filling the entire allocated stack).

[bogglez]

3. The DMA Vertex Transfer is still experimental, and thus disabled by default.
The current implementation is using blocking DMA and shows faster throughput on emulator, but is not working on real hardware.
I would like to enable non-blocking DMA transfers for the Multi-Texture Pass, as it should be possible to be setting the next texture units multi u/v cords on the CPU while the DMA simultaneously transfers current texture unit's vertex buffer.

Keep me posted

4. Texture coordinates, even 2D, are still transformed as a 4D vector, from the redbook:

When the four texture coordinates (s, t, r, q) are multiplied by the texture matrix, the resulting vector (s' t' r' q') is interpreted as homogeneous texture coordinates. In other words, the texture map is indexed by s'/q' and t'/q' . (Remember that r'/q' is ignored in standard OpenGL, but may be used by implementations that support a 3D texture extension.)

Are you sure your idea would work? I don't see how you compute the q component in your proposed approach?

Hm, you're right, it would only work with particular matrices without translation and projection.. sorry about that.
BTW I noticed that texture matrices are per texture unit instead of just one global texture matrix. Did you keep that in mind?

[BlueCrab]

Since it was only a couple of lines to fix, I went ahead and fixed the allocation issue in commit 46ed1d.

[ozzyyzzo]

hello in 2020 ^^,

i'm using immediate mode atm and got issues with transparency when using PVR_TXRFMT_ARGB1555 non twiddled.

Alpha information seems ignored , blending is enabled and blendFunc GL_ONE_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA

the problem may come from glTexEnvi(GL_TEXTURE_2D, GL_TEXTURE_ENV_MODE, GL_MODULATE); which seems to generate an error : saying INVALID ENUM


also

Is there any way to load and use paletted textures with libGL ?

thx