New Open GL API Released

This forum is for the posting of new newsposts, and it stores the site's news and comments archives. Only newsposters have access to post new news in here; if you wish to submit news, please post it in the discussion section for your particular topic. We may choose to move it here as a newspost if we find that it's worthy for the front page.
User avatar
SiZiOUS
DC Developer
DC Developer
Posts: 404
https://www.artistsworkshop.eu/meble-kuchenne-na-wymiar-warszawa-gdzie-zamowic/
Joined: Fri Mar 05, 2004 2:22 pm
Location: France
Has thanked: 27 times
Been thanked: 19 times
Contact:

Re: New Open GL API Released

Post by SiZiOUS »

THIS RELEASE IS PH3NOMENAL ! :grin:

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 :mrgreen:
User avatar
PH3NOM
DC Developer
DC Developer
Posts: 576
Joined: Fri Jun 18, 2010 9:29 pm
Has thanked: 0
Been thanked: 5 times

Re: New Open GL API Released

Post by 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
User avatar
bogglez
Moderator
Moderator
Posts: 578
Joined: Sun Apr 20, 2014 9:45 am
Has thanked: 0
Been thanked: 0

Re: New Open GL API Released

Post by 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?
Wiki & tutorials: http://dcemulation.org/?title=Development
Wiki feedback: viewtopic.php?f=29&t=103940
My libgl playground (not for production): https://bitbucket.org/bogglez/libgl15
My lxdream fork (with small fixes): https://bitbucket.org/bogglez/lxdream
User avatar
mankrip
DCEmu Ex-Mod
DCEmu Ex-Mod
Posts: 3712
Joined: Sun Nov 04, 2001 5:12 pm
Has thanked: 0
Been thanked: 0
Contact:

Re: New Open GL API Released

Post by mankrip »

I will definitely try this sometime. Thanks.
Ph'nglui mglw'nafh mankrip Hell's end wgah'nagl fhtagn.
==-=-=-=-=-=-=-=-=-=-==
Dev blog / Twitter / YouTube
Image
User avatar
PH3NOM
DC Developer
DC Developer
Posts: 576
Joined: Fri Jun 18, 2010 9:29 pm
Has thanked: 0
Been thanked: 5 times

Re: New Open GL API Released

Post by PH3NOM »

bogglez wrote:I like that you replaced custom functions with standard ones.
Nice. That was done thanks to our conversations prompting me to do so 8-)
bogglez wrote: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!
User avatar
bogglez
Moderator
Moderator
Posts: 578
Joined: Sun Apr 20, 2014 9:45 am
Has thanked: 0
Been thanked: 0

Re: New Open GL API Released

Post by bogglez »

PH3NOM wrote:
bogglez wrote: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..
Wiki & tutorials: http://dcemulation.org/?title=Development
Wiki feedback: viewtopic.php?f=29&t=103940
My libgl playground (not for production): https://bitbucket.org/bogglez/libgl15
My lxdream fork (with small fixes): https://bitbucket.org/bogglez/lxdream
User avatar
PH3NOM
DC Developer
DC Developer
Posts: 576
Joined: Fri Jun 18, 2010 9:29 pm
Has thanked: 0
Been thanked: 5 times

Re: New Open GL API Released

Post by PH3NOM »

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

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
Insane DCEmu
Insane DCEmu
Posts: 112
Joined: Sat Sep 22, 2007 9:43 pm
Location: Braga - Portugal
Has thanked: 0
Been thanked: 0

Re: New Open GL API Released

Post by 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?
User avatar
bogglez
Moderator
Moderator
Posts: 578
Joined: Sun Apr 20, 2014 9:45 am
Has thanked: 0
Been thanked: 0

Re: New Open GL API Released

Post by bogglez »

Jae686 wrote: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.
Wiki & tutorials: http://dcemulation.org/?title=Development
Wiki feedback: viewtopic.php?f=29&t=103940
My libgl playground (not for production): https://bitbucket.org/bogglez/libgl15
My lxdream fork (with small fixes): https://bitbucket.org/bogglez/lxdream
Jae686
Insane DCEmu
Insane DCEmu
Posts: 112
Joined: Sat Sep 22, 2007 9:43 pm
Location: Braga - Portugal
Has thanked: 0
Been thanked: 0

Re: New Open GL API Released

Post by Jae686 »

Well, doing so it broke my code. I should have probably read the changelog before upgrading.
User avatar
GyroVorbis
Elysian Shadows Developer
Elysian Shadows Developer
Posts: 1873
Joined: Mon Mar 22, 2004 4:55 pm
Location: #%^&*!!!11one Super Sonic
Has thanked: 79 times
Been thanked: 61 times
Contact:

Re: New Open GL API Released

Post by 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!
User avatar
PH3NOM
DC Developer
DC Developer
Posts: 576
Joined: Fri Jun 18, 2010 9:29 pm
Has thanked: 0
Been thanked: 5 times

Re: New Open GL API Released

Post by PH3NOM »

GyroVorbis wrote: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.

Image
User avatar
PH3NOM
DC Developer
DC Developer
Posts: 576
Joined: Fri Jun 18, 2010 9:29 pm
Has thanked: 0
Been thanked: 5 times

Re: New Open GL API Released

Post by 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/
User avatar
PH3NOM
DC Developer
DC Developer
Posts: 576
Joined: Fri Jun 18, 2010 9:29 pm
Has thanked: 0
Been thanked: 5 times

Re: New Open GL API Released

Post by 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.
User avatar
bogglez
Moderator
Moderator
Posts: 578
Joined: Sun Apr 20, 2014 9:45 am
Has thanked: 0
Been thanked: 0

Re: New Open GL API Released

Post by 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
Wiki & tutorials: http://dcemulation.org/?title=Development
Wiki feedback: viewtopic.php?f=29&t=103940
My libgl playground (not for production): https://bitbucket.org/bogglez/libgl15
My lxdream fork (with small fixes): https://bitbucket.org/bogglez/lxdream
User avatar
PH3NOM
DC Developer
DC Developer
Posts: 576
Joined: Fri Jun 18, 2010 9:29 pm
Has thanked: 0
Been thanked: 5 times

Re: New Open GL API Released

Post by PH3NOM »

1. Sorry mate that's just how I roll :lol:

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...
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5652
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Has thanked: 9 times
Been thanked: 69 times
Contact:

Re: New Open GL API Released

Post by BlueCrab »

PH3NOM wrote: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).
User avatar
bogglez
Moderator
Moderator
Posts: 578
Joined: Sun Apr 20, 2014 9:45 am
Has thanked: 0
Been thanked: 0

Re: New Open GL API Released

Post by bogglez »

PH3NOM wrote: 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 :)
PH3NOM wrote: 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?
Wiki & tutorials: http://dcemulation.org/?title=Development
Wiki feedback: viewtopic.php?f=29&t=103940
My libgl playground (not for production): https://bitbucket.org/bogglez/libgl15
My lxdream fork (with small fixes): https://bitbucket.org/bogglez/lxdream
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5652
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Has thanked: 9 times
Been thanked: 69 times
Contact:

Re: New Open GL API Released

Post by BlueCrab »

Since it was only a couple of lines to fix, I went ahead and fixed the allocation issue in commit 46ed1d.
ozzyyzzo
DCEmu Newbie
DCEmu Newbie
Posts: 7
Joined: Wed Mar 11, 2020 6:09 am
Has thanked: 0
Been thanked: 0

Re: New Open GL API Released

Post by 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
Post Reply