New Open GL API Released
- SiZiOUS
- 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
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
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
- 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
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
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
Re: New Open GL API Released
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?
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
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
- mankrip
- DCEmu Ex-Mod
- Posts: 3712
- Joined: Sun Nov 04, 2001 5:12 pm
- Has thanked: 0
- Been thanked: 0
- Contact:
- PH3NOM
- 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
Nice. That was done thanks to our conversations prompting me to do sobogglez wrote:I like that you replaced custom functions with standard ones.
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.
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!
Re: New Open GL API Released
I think you're confused about what this function does?PH3NOM wrote:bogglez wrote:Why does get active texture always return 0?Problem is, the PVR does not support multi-texture in hardware.Code: Select all
GL_ACTIVE_TEXTURE params returns a single value indicating the active multitexture unit. The initial value is GL_TEXTURE0. See glActiveTexture.
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!
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..glActiveTexture selects which texture unit subsequent texture state calls will affect.
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
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
- PH3NOM
- 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
Texture Units are not implemented currently in the API, I would not consider that a bug
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...
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:
But as I said, I do plan to have another go at it when I get some time...
-
- 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
Good Afternoon.
I've checked out the latest version of the API, but now I get the following error :
What happened to the glKosTexImage2D function?
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
Re: New Open GL API Released
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 wrote:Good Afternoon.
I've checked out the latest version of the API, but now I get the following error :What happened to the glKosTexImage2D function?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
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
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
-
- 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
Well, doing so it broke my code. I should have probably read the changelog before upgrading.
- GyroVorbis
- Elysian Shadows Developer
- Posts: 1874
- Joined: Mon Mar 22, 2004 4:55 pm
- Location: #%^&*!!!11one Super Sonic
- Has thanked: 81 times
- Been thanked: 64 times
- Contact:
Re: New Open GL API Released
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
- 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
Hey Gyro hope things are on track for u guys.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!
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
- 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
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/
http://sourceforge.net/p/cadcdev/libgl/ci/master/tree/
- PH3NOM
- 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
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.
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.
Re: New Open GL API Released
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
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
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
- PH3NOM
- 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
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:
5. Didn't think that would be a problem, but it would be easy enough to malloc() instead...
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:
Are you sure your idea would work? I don't see how you compute the q component in your proposed approach?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.)
5. Didn't think that would be a problem, but it would be easy enough to malloc() instead...
- BlueCrab
- The Crabby Overlord
- Posts: 5666
- 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
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).PH3NOM wrote:5. Didn't think that would be a problem, but it would be easy enough to malloc() instead...
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).
Re: New Open GL API Released
Keep me postedPH3NOM 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.
Hm, you're right, it would only work with particular matrices without translation and projection.. sorry about that.PH3NOM wrote: 4. Texture coordinates, even 2D, are still transformed as a 4D vector, from the redbook:Are you sure your idea would work? I don't see how you compute the q component in your proposed approach?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.)
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
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
- BlueCrab
- The Crabby Overlord
- Posts: 5666
- 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
Since it was only a couple of lines to fix, I went ahead and fixed the allocation issue in commit 46ed1d.
Re: New Open GL API Released
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
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