GLdc - Call for testers!
-
- Insane DCEmu
- Posts: 145
- https://www.artistsworkshop.eu/meble-kuchenne-na-wymiar-warszawa-gdzie-zamowic/
- Joined: Tue May 02, 2017 3:11 pm
- Has thanked: 3 times
- Been thanked: 34 times
GLdc - Call for testers!
Hi everyone!
Over the last few months I've been maintaining a custom fork of libGL, but a few weeks ago I hit a corruption bug that I couldn't solve and decided to essentially tear the whole thing apart and put it back together again
So, now it's *mostly* back together and it lives here: https://github.com/Kazade/GLdc
There are still outstanding features to implement, so I'm not recommending people just blindly switch over, but I would really appreciate if people could try it, and report bugs on GitHub (or even better, send me patches!)
There are a lot of bug fixes in this version compared to libGL, and it adheres more to the spec. The one thing you will need to do is swap glutSwapBuffers with glKosSwapBuffers.
Over the last few months I've been maintaining a custom fork of libGL, but a few weeks ago I hit a corruption bug that I couldn't solve and decided to essentially tear the whole thing apart and put it back together again
So, now it's *mostly* back together and it lives here: https://github.com/Kazade/GLdc
There are still outstanding features to implement, so I'm not recommending people just blindly switch over, but I would really appreciate if people could try it, and report bugs on GitHub (or even better, send me patches!)
There are a lot of bug fixes in this version compared to libGL, and it adheres more to the spec. The one thing you will need to do is swap glutSwapBuffers with glKosSwapBuffers.
- lerabot
- Insane DCEmu
- Posts: 134
- Joined: Sun Nov 01, 2015 8:25 pm
- Has thanked: 2 times
- Been thanked: 19 times
Re: GLdc - Call for testers!
Shoutouts to Kazade for working on this.
We've been chatting quite a bit about this project and I've been using it for Reaperi Cycle.
It's been working quite well so far. We've both been testing different stuff with, my project being in 2D and using glOrtho and kazade's test being 3D.
We've been chatting quite a bit about this project and I've been using it for Reaperi Cycle.
It's been working quite well so far. We've both been testing different stuff with, my project being in 2D and using glOrtho and kazade's test being 3D.
- MetaFox
- Adventure Gamer
- Posts: 2818
- Joined: Wed Oct 17, 2001 7:44 pm
- Has thanked: 0
- Been thanked: 12 times
- Contact:
Re: GLdc - Call for testers!
Sorry for the lateness in seeing this. I've been toying with some GL stuff, and I've recently gotten into Dreamcast again, so I'm excited to see improved libGL support on the Dreamcast.
I'll try to it with a few of my different prototypes once I get a DC toolchain up on my MacBook, as this is my main computer now.
Thanks for this library, Kazade, and thanks for DreamPi too - I just recently ordered a premade DreamPi kit from dreamcastlive.com, so I'll be playing with that too once I get it.
I'll try to it with a few of my different prototypes once I get a DC toolchain up on my MacBook, as this is my main computer now.
Thanks for this library, Kazade, and thanks for DreamPi too - I just recently ordered a premade DreamPi kit from dreamcastlive.com, so I'll be playing with that too once I get it.
- Corbin
- DC Developer
- Posts: 121
- Joined: Fri Dec 14, 2007 1:56 am
- Location: California
- Has thanked: 0
- Been thanked: 0
Re: GLdc - Call for testers!
Late to the party, as usual :S
I am _definitely_ interested in helping test and shape GLdc kazade! Right now we are using libGL (for Slave, Hypertension, and EDGE/DOOM/etc in general) and, well, while it definitely is a great GL library, it has room for improvements. It is nicer and closer to real GL, but it doesn't seem quite as stable as something older, like KGLX (also, we have to modify the internal vert counts in gl_pvr.h [from 1024*64 -> 1024*16][ everytime we rebuild the toolchain for libGL, otherwise we run out of RAM really quick. I don't remember having to do that for other GL libraries..
Let me know what I can do, my engine is pure OpenGL so I would be very happy to test and report results for you @kazade! Please get in touch with me via PM or email!
I am _definitely_ interested in helping test and shape GLdc kazade! Right now we are using libGL (for Slave, Hypertension, and EDGE/DOOM/etc in general) and, well, while it definitely is a great GL library, it has room for improvements. It is nicer and closer to real GL, but it doesn't seem quite as stable as something older, like KGLX (also, we have to modify the internal vert counts in gl_pvr.h [from 1024*64 -> 1024*16][ everytime we rebuild the toolchain for libGL, otherwise we run out of RAM really quick. I don't remember having to do that for other GL libraries..
Let me know what I can do, my engine is pure OpenGL so I would be very happy to test and report results for you @kazade! Please get in touch with me via PM or email!
-
- Insane DCEmu
- Posts: 145
- Joined: Tue May 02, 2017 3:11 pm
- Has thanked: 3 times
- Been thanked: 34 times
Re: GLdc - Call for testers!
Well GLdc is ready for use aside from the caveats listed in the README and the issues here: https://github.com/Kazade/GLdc/issues
I've basically done the hard-slog 80% but need help to get the final 20% done. The key missing feature you'll probably find is multitexturing isn't there yet, neither is mipmapping (but then I'm fairly sure libGL mipmapping would trash memory anyway...)
Feel free to try compiling it and using it and let me know if anything doesn't work - the GLdc code is easy to follow so you should be able to figure out any bugs fairly quickly
For what it's worth, I don't have masses of time for this and coded GLdc out of necessity (for another project) so I'd really appreciate some help with it - filing issues or submitting patches is the best way to do that
I've basically done the hard-slog 80% but need help to get the final 20% done. The key missing feature you'll probably find is multitexturing isn't there yet, neither is mipmapping (but then I'm fairly sure libGL mipmapping would trash memory anyway...)
Feel free to try compiling it and using it and let me know if anything doesn't work - the GLdc code is easy to follow so you should be able to figure out any bugs fairly quickly
For what it's worth, I don't have masses of time for this and coded GLdc out of necessity (for another project) so I'd really appreciate some help with it - filing issues or submitting patches is the best way to do that
- lerabot
- Insane DCEmu
- Posts: 134
- Joined: Sun Nov 01, 2015 8:25 pm
- Has thanked: 2 times
- Been thanked: 19 times
Re: GLdc - Call for testers!
+1 for everyone willing to use GLdc. Kazade has been very active in making this work and pushing new updates.
-
- DCEmu Junior
- Posts: 44
- Joined: Sat Dec 30, 2017 4:03 pm
- Has thanked: 0
- Been thanked: 0
Re: GLdc - Call for testers!
For those using windows subsystem for linux, these are the installation instructions:
1. go into your kos/addons folder and git clone GLdc into it
2.
3.
4. put headers into you programs include folder
1. go into your kos/addons folder and git clone GLdc into it
2.
make defaultall
make create_kos_link
"Smile for me, You're in loving hands
Don't be sad today, You can make other plans"
-Smile, Tom Rizzo
Don't be sad today, You can make other plans"
-Smile, Tom Rizzo
- BlueCrab
- The Crabby Overlord
- Posts: 5663
- Joined: Mon May 27, 2002 11:31 am
- Location: Sailing the Skies of Arcadia
- Has thanked: 9 times
- Been thanked: 69 times
- Contact:
Re: GLdc - Call for testers!
@kazade:
As GLdc gets more and more feature-complete, how would you feel about us including it officially as the GL library going forward in kos-ports? Do you think it is mature enough now, and if not, any estimates as to when it will be?
As GLdc gets more and more feature-complete, how would you feel about us including it officially as the GL library going forward in kos-ports? Do you think it is mature enough now, and if not, any estimates as to when it will be?
-
- Insane DCEmu
- Posts: 145
- Joined: Tue May 02, 2017 3:11 pm
- Has thanked: 3 times
- Been thanked: 34 times
Re: GLdc - Call for testers!
I think it might be an idea to ship it in kos-ports alongside libGL (e.g. libGLdc + /usr/include/GLdc/gl.h). Simply because it will avoid ambiguity of which version someone is using, and also, GLdc won't be exactly compatible (it has different header constants and glKosSwapBuffers() instead of glut etc.)
But yes, I'd be very happy if GLdc became part of kos-ports - the only real blocker to that is multitexture support. It won't take me long to add multitexturing, I just haven't gotten around to it. I'll try to get to that next!
I'd also like to know how performant it is compared to libGL so if someone has a relatively intensive GL scene they could try it on and compare I'd appreciate it.
But yes, I'd be very happy if GLdc became part of kos-ports - the only real blocker to that is multitexture support. It won't take me long to add multitexturing, I just haven't gotten around to it. I'll try to get to that next!
I'd also like to know how performant it is compared to libGL so if someone has a relatively intensive GL scene they could try it on and compare I'd appreciate it.
- BlueCrab
- The Crabby Overlord
- Posts: 5663
- Joined: Mon May 27, 2002 11:31 am
- Location: Sailing the Skies of Arcadia
- Has thanked: 9 times
- Been thanked: 69 times
- Contact:
Re: GLdc - Call for testers!
It could certainly be the case that both are shipped as part of kos-ports, although, I'd probably avoid calling the resulting .a file (or the include directories for that matter) different things. The idea is that your library would probably be "the" library going forward, once any further kinks are worked out. If I were to rename one, it'd probably be PH3NOM's library, since it would essentially be deprecated by yours.
Also, I wouldn't necessarily call multitexture support a blocker, as no version of GL that was available in kos-ports or the addons tree up until PH3NOM's supported it.
There are other things that could potentially be blockers, but that all is probably better served to be discussed after I take a look at the code first. Probably highest amongst the many things that could potentially be considered blockers is pollution of the global namespace with functions that aren't prefixed in any way... By that, I mean internal functions that you can't make static for whatever reason. I recall there being quite a few of them before PH3NOM's libgl went in, so I'm expecting your library probably has a bunch of stuff like that too (just based on how all of it has to fit together in the end). When PH3NOM did his libgl, I asked him to prefix any internal functions that couldn't be made static with "_glKos" or similar, to make sure to not potentially trample on names someone else might want to use for a function in their own code. The underscore prefix makes it obvious that they're meant to be internal, and the glKos part makes sure it doesn't trample so much on the global namespace.
Another potential blocker would be porting over example programs and whatnot, but that's not as much of an issue until we get closer to a KOS release.
Also, I wouldn't necessarily call multitexture support a blocker, as no version of GL that was available in kos-ports or the addons tree up until PH3NOM's supported it.
There are other things that could potentially be blockers, but that all is probably better served to be discussed after I take a look at the code first. Probably highest amongst the many things that could potentially be considered blockers is pollution of the global namespace with functions that aren't prefixed in any way... By that, I mean internal functions that you can't make static for whatever reason. I recall there being quite a few of them before PH3NOM's libgl went in, so I'm expecting your library probably has a bunch of stuff like that too (just based on how all of it has to fit together in the end). When PH3NOM did his libgl, I asked him to prefix any internal functions that couldn't be made static with "_glKos" or similar, to make sure to not potentially trample on names someone else might want to use for a function in their own code. The underscore prefix makes it obvious that they're meant to be internal, and the glKos part makes sure it doesn't trample so much on the global namespace.
Another potential blocker would be porting over example programs and whatnot, but that's not as much of an issue until we get closer to a KOS release.
- lerabot
- Insane DCEmu
- Posts: 134
- Joined: Sun Nov 01, 2015 8:25 pm
- Has thanked: 2 times
- Been thanked: 19 times
Re: GLdc - Call for testers!
This also works for people on linux.Rizzoislandgame wrote: ↑Thu Aug 02, 2018 1:04 pm For those using windows subsystem for linux, these are the installation instructions:
1. go into your kos/addons folder and git clone GLdc into it
2.3.make defaultall
4. put headers into you programs include foldermake create_kos_link
Don't forget to go
Code: Select all
cd GLdc
-
- Insane DCEmu
- Posts: 145
- Joined: Tue May 02, 2017 3:11 pm
- Has thanked: 3 times
- Been thanked: 34 times
Re: GLdc - Call for testers!
Cool, OK I'll make sure I prefix non static functions with _gl. I've got a bug to fix in lighting, and then I'll shove in multitexture support.
I could really use someone who understands the SH4/PVR to look over my code and suggest performance improvements. At the moment:
- I only send polygon headers if necessary
- I perform each step (e.g. transform, clip, perspective divide etc.) in a separate loop to avoid using up floating point registers
- I try not to switch loaded matrix unless necessary
- I'm trying to minimise hand coded ASM and trust the compiler
- I only ever send triangle strips, I dunno if there's some flag or something when sending plain triangles that might speed things up?
Is DMA faster than using store queues? I'm currently using store queues for submission.
I could really use someone who understands the SH4/PVR to look over my code and suggest performance improvements. At the moment:
- I only send polygon headers if necessary
- I perform each step (e.g. transform, clip, perspective divide etc.) in a separate loop to avoid using up floating point registers
- I try not to switch loaded matrix unless necessary
- I'm trying to minimise hand coded ASM and trust the compiler
- I only ever send triangle strips, I dunno if there's some flag or something when sending plain triangles that might speed things up?
Is DMA faster than using store queues? I'm currently using store queues for submission.
- BlueCrab
- The Crabby Overlord
- Posts: 5663
- Joined: Mon May 27, 2002 11:31 am
- Location: Sailing the Skies of Arcadia
- Has thanked: 9 times
- Been thanked: 69 times
- Contact:
Re: GLdc - Call for testers!
Cool. Keep me posted.
Reasonable.I could really use someone who understands the SH4/PVR to look over my code and suggest performance improvements. At the moment:
- I only send polygon headers if necessary
Not sure on this one, especially considering how many iterations it might need to be run over...- I perform each step (e.g. transform, clip, perspective divide etc.) in a separate loop to avoid using up floating point registers
Definitely a good idea.- I try not to switch loaded matrix unless necessary
Often trying to optimize things and be more clever than the compiler blows up in people's faces, so this is probably a good idea, especially before doing any sort of hard analysis of things to determine where the compiler might need more help.- I'm trying to minimise hand coded ASM and trust the compiler
Nope. The PVR doesn't really do just plain triangles. There's specialized quads that cut down on the amount of data being sent, but no specialized "general" triangles.- I only ever send triangle strips, I dunno if there's some flag or something when sending plain triangles that might speed things up?
That largely depends on how your handling things. DMA isn't necessarily "faster", but you can do it in the background while you're doing other things, whereas with the store queues, the transfer can't be done completely in the background in a large batch (the actual transfers can/do happen in the background, but you still need to load up the SQ for each 32 byte transfer, unlike with DMA where it does all the work for you). One benefit of the SQs are that you don't have to go through the extra step of flushing the operand cache to memory before doing things, and you can potentially write the results of your final transformations directly into the SQ (rather than to memory) to speed things along a slight bit.Is DMA faster than using store queues? I'm currently using store queues for submission.
-
- Insane DCEmu
- Posts: 145
- Joined: Tue May 02, 2017 3:11 pm
- Has thanked: 3 times
- Been thanked: 34 times
Re: GLdc - Call for testers!
Interesting, thanks!
I don't suppose you know how I can view the compiled ASM for a function? I could really do with being able to see what functions are being compiled down to.
I don't suppose you know how I can view the compiled ASM for a function? I could really do with being able to see what functions are being compiled down to.
- BlueCrab
- The Crabby Overlord
- Posts: 5663
- Joined: Mon May 27, 2002 11:31 am
- Location: Sailing the Skies of Arcadia
- Has thanked: 9 times
- Been thanked: 69 times
- Contact:
Re: GLdc - Call for testers!
Run kos-cc -E on your files, like this:
Code: Select all
kos-cc -E filename.c -o filename.s
- Corbin
- DC Developer
- Posts: 121
- Joined: Fri Dec 14, 2007 1:56 am
- Location: California
- Has thanked: 0
- Been thanked: 0
Re: GLdc - Call for testers!
@kazade:
Since EDGE is OpenGL heavy, and uses things like lighting and multi-texturing, I'll be sure to keep up to date and report any performance and/or other issues we might have.
I plan on switching this library out today inside KOS at work, and tomorrow I should be completely free to integrate and test with SLaVE/Hypertension/EDGE.
Since EDGE is OpenGL heavy, and uses things like lighting and multi-texturing, I'll be sure to keep up to date and report any performance and/or other issues we might have.
I plan on switching this library out today inside KOS at work, and tomorrow I should be completely free to integrate and test with SLaVE/Hypertension/EDGE.
-
- Insane DCEmu
- Posts: 145
- Joined: Tue May 02, 2017 3:11 pm
- Has thanked: 3 times
- Been thanked: 34 times
Re: GLdc - Call for testers!
Excellent! I've made good progress on multitexture, just need to write a good test sample for it and then fix up any breakage.
*Update*
Just pushed a completely untested multitexture implementation. I'll test and improve tomorrow.
https://github.com/Kazade/GLdc/commit/6 ... e2d0bfcb82
*Update*
Just pushed a completely untested multitexture implementation. I'll test and improve tomorrow.
https://github.com/Kazade/GLdc/commit/6 ... e2d0bfcb82
-
- DCEmu Crazy Poster
- Posts: 33
- Joined: Sat Aug 04, 2018 11:36 am
- Has thanked: 2 times
- Been thanked: 7 times
Re: GLdc - Call for testers!
Okay I'm going to sound like a real doofus right now, but...
I tried a couple of combinations, but when I went to go run the make files for the samples I was getting undefined references for almost every GLdc function.
Edit: Pretty sure the latter issue was because I didn't include it in the makefile. Oops. First part of the question still stands, though, considering I'm not sure how to specify if I'm using libGL or GLdc when including/compiling.
Sorry if this is a stupid question!
What folder am I supposed to put the headers into? By "program's include folder " do you mean kos/include, kos/addon/include, an include folder within my project, or some other include folder?
I tried a couple of combinations, but when I went to go run the make files for the samples I was getting undefined references for almost every GLdc function.
Edit: Pretty sure the latter issue was because I didn't include it in the makefile. Oops. First part of the question still stands, though, considering I'm not sure how to specify if I'm using libGL or GLdc when including/compiling.
Sorry if this is a stupid question!
- lerabot
- Insane DCEmu
- Posts: 134
- Joined: Sun Nov 01, 2015 8:25 pm
- Has thanked: 2 times
- Been thanked: 19 times
Re: GLdc - Call for testers!
If you cloned the lib in kos/addons/, all you have to do is add
Code: Select all
#include <GL/gl.h>
Code: Select all
-lGLdc