GLdc - Call for testers!

If you have any questions on programming, this is the place to ask them, whether you're a newbie or an experienced programmer. Discussion on programming in general is also welcome. We will help you with programming homework, but we will not do your work for you! Any porting requests must be made in Developmental Ideas.
kazade
Insane DCEmu
Insane DCEmu
Posts: 128
Joined: Tue May 02, 2017 3:11 pm
Has liked: 1 time
Been liked: 8 times

GLdc - Call for testers!

Post by kazade » Sun May 20, 2018 10:29 am

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 :grin:

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.
User avatar
lerabot
Insane DCEmu
Insane DCEmu
Posts: 118
Joined: Sun Nov 01, 2015 8:25 pm
Has liked: 0
Been liked: 1 time

Re: GLdc - Call for testers!

Post by lerabot » Mon Jun 11, 2018 11:48 am

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.
User avatar
MetaFox
Adventure Gamer
Adventure Gamer
Posts: 2801
Joined: Wed Oct 17, 2001 7:44 pm
Has liked: 0
Been liked: 5 times
Contact:

Re: GLdc - Call for testers!

Post by MetaFox » Fri Jun 22, 2018 5:14 pm

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. :D
User avatar
Corbin
DC Developer
DC Developer
Posts: 121
Joined: Fri Dec 14, 2007 1:56 am
Location: California
Has liked: 0
Been liked: 0

Re: GLdc - Call for testers!

Post by Corbin » Sat Jul 28, 2018 12:26 pm

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!
kazade
Insane DCEmu
Insane DCEmu
Posts: 128
Joined: Tue May 02, 2017 3:11 pm
Has liked: 1 time
Been liked: 8 times

Re: GLdc - Call for testers!

Post by kazade » Sun Jul 29, 2018 10:48 am

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 :)
User avatar
lerabot
Insane DCEmu
Insane DCEmu
Posts: 118
Joined: Sun Nov 01, 2015 8:25 pm
Has liked: 0
Been liked: 1 time

Re: GLdc - Call for testers!

Post by lerabot » Tue Jul 31, 2018 10:55 am

+1 for everyone willing to use GLdc. Kazade has been very active in making this work and pushing new updates.
Rizzoislandgame
DCEmu Junior
DCEmu Junior
Posts: 44
Joined: Sat Dec 30, 2017 4:03 pm
Has liked: 0
Been liked: 0

Re: GLdc - Call for testers!

Post by Rizzoislandgame » 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.
make defaultall
3.
make create_kos_link
4. put headers into you programs include folder
"Smile for me, You're in loving hands
Don't be sad today, You can make other plans"

-Smile, Tom Rizzo
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5387
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Has liked: 1 time
Been liked: 12 times
Contact:

Re: GLdc - Call for testers!

Post by BlueCrab » Thu Aug 02, 2018 2:03 pm

@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?
kazade
Insane DCEmu
Insane DCEmu
Posts: 128
Joined: Tue May 02, 2017 3:11 pm
Has liked: 1 time
Been liked: 8 times

Re: GLdc - Call for testers!

Post by kazade » Thu Aug 02, 2018 2:18 pm

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. :)
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5387
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Has liked: 1 time
Been liked: 12 times
Contact:

Re: GLdc - Call for testers!

Post by BlueCrab » Thu Aug 02, 2018 10:44 pm

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. ;-)
User avatar
lerabot
Insane DCEmu
Insane DCEmu
Posts: 118
Joined: Sun Nov 01, 2015 8:25 pm
Has liked: 0
Been liked: 1 time

Re: GLdc - Call for testers!

Post by lerabot » Fri Aug 03, 2018 2:02 am

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.
make defaultall
3.
make create_kos_link
4. put headers into you programs include folder
This also works for people on linux.

Don't forget to go

Code: Select all

cd GLdc
between step 1 and 2
kazade
Insane DCEmu
Insane DCEmu
Posts: 128
Joined: Tue May 02, 2017 3:11 pm
Has liked: 1 time
Been liked: 8 times

Re: GLdc - Call for testers!

Post by kazade » Fri Aug 03, 2018 6:20 am

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

Re: GLdc - Call for testers!

Post by BlueCrab » Fri Aug 03, 2018 11:49 am

kazade wrote:
Fri Aug 03, 2018 6:20 am
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.
Cool. Keep me posted. :grin:
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
Reasonable.
- I perform each step (e.g. transform, clip, perspective divide etc.) in a separate loop to avoid using up floating point registers
Not sure on this one, especially considering how many iterations it might need to be run over...
- I try not to switch loaded matrix unless necessary
Definitely a good idea.
- I'm trying to minimise hand coded ASM and trust the compiler
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 only ever send triangle strips, I dunno if there's some flag or something when sending plain triangles that might speed things up?
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.
Is DMA faster than using store queues? I'm currently using store queues for submission.
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.
kazade
Insane DCEmu
Insane DCEmu
Posts: 128
Joined: Tue May 02, 2017 3:11 pm
Has liked: 1 time
Been liked: 8 times

Re: GLdc - Call for testers!

Post by kazade » Fri Aug 03, 2018 4:17 pm

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

Re: GLdc - Call for testers!

Post by BlueCrab » Fri Aug 03, 2018 8:50 pm

Run kos-cc -E on your files, like this:

Code: Select all

kos-cc -E filename.c -o filename.s
User avatar
Corbin
DC Developer
DC Developer
Posts: 121
Joined: Fri Dec 14, 2007 1:56 am
Location: California
Has liked: 0
Been liked: 0

Re: GLdc - Call for testers!

Post by Corbin » Sat Aug 04, 2018 12:08 pm

@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.
kazade
Insane DCEmu
Insane DCEmu
Posts: 128
Joined: Tue May 02, 2017 3:11 pm
Has liked: 1 time
Been liked: 8 times

Re: GLdc - Call for testers!

Post by kazade » Sat Aug 04, 2018 2:13 pm

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
KingCrazy
DCEmu Crazy Poster
DCEmu Crazy Poster
Posts: 33
Joined: Sat Aug 04, 2018 11:36 am
Has liked: 2 times
Been liked: 6 times

Re: GLdc - Call for testers!

Post by KingCrazy » Sat Aug 04, 2018 6:46 pm

Okay I'm going to sound like a real doofus right now, but...
Rizzoislandgame wrote:
Thu Aug 02, 2018 1:04 pm
4. put headers into you programs include folder
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!
User avatar
lerabot
Insane DCEmu
Insane DCEmu
Posts: 118
Joined: Sun Nov 01, 2015 8:25 pm
Has liked: 0
Been liked: 1 time

Re: GLdc - Call for testers!

Post by lerabot » Mon Aug 06, 2018 9:33 am

KingCrazy wrote:
Sat Aug 04, 2018 6:46 pm
Okay I'm going to sound like a real doofus right now, but...
Rizzoislandgame wrote:
Thu Aug 02, 2018 1:04 pm
4. put headers into you programs include folder
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?
If you cloned the lib in kos/addons/, all you have to do is add

Code: Select all

#include <GL/gl.h>
and link using

Code: Select all

-lGLdc
Or at least, that's what I did :)
User avatar
Corbin
DC Developer
DC Developer
Posts: 121
Joined: Fri Dec 14, 2007 1:56 am
Location: California
Has liked: 0
Been liked: 0

Re: GLdc - Call for testers!

Post by Corbin » Mon Aug 06, 2018 12:52 pm

@kazade: Any chance we could get support to handle paletted textures?

For our games and the engine, it would really help us save VRAM.
Post Reply