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
DCEmu Freak
DCEmu Freak
Posts: 98
Joined: Tue May 02, 2017 3:11 pm

Re: GLdc - Call for testers!

Post by kazade » Mon Aug 06, 2018 1:13 pm

You got a sample texture file for me to test with? I'll see what I can do :)
KingCrazy
DCEmu Fast Newbie
DCEmu Fast Newbie
Posts: 22
Joined: Sat Aug 04, 2018 11:36 am

Re: GLdc - Call for testers!

Post by KingCrazy » Mon Aug 06, 2018 5:58 pm

lerabot wrote:
Mon Aug 06, 2018 9:33 am
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 :)
Gosh now I really DO feel like a doofus! That was a lot easier than I thought it was! Thank you!
kazade
DCEmu Freak
DCEmu Freak
Posts: 98
Joined: Tue May 02, 2017 3:11 pm

Re: GLdc - Call for testers!

Post by kazade » Tue Aug 07, 2018 3:09 pm

OK so here's an interesting conundrum...

I've been working on glCompressedTexImage2D and use a "DTEX" compressed image for testing. I have it working for non-mipmapped tex files, but if the texture has mipmap data I have two options:

1. Throw an error. The user should upload each level individually with multiple calls to glCompressedTexImage2D
2. Upload all the data and mark the texture as "mipmap complete"

The problems I have are:

1. How can I know that the compressed data contains multiple mipmap levels?
2. How can you find out where one level's data ends, and the next begins? Presumably the size of each level isn't predictable if it's compressed?
kazade
DCEmu Freak
DCEmu Freak
Posts: 98
Joined: Tue May 02, 2017 3:11 pm

Re: GLdc - Call for testers!

Post by kazade » Wed Aug 08, 2018 3:52 am

OK for now I've gone with comparing the calculated uncompressed size with the actual data size and making a guess based on the ratio: https://github.com/Kazade/GLdc/blob/mas ... ure.c#L227

glCompressedTexImage2D now works great. It supports compressed, twiddled and mipmapped formats. Sample here: https://github.com/Kazade/GLdc/blob/mas ... _vq/main.c
kazade
DCEmu Freak
DCEmu Freak
Posts: 98
Joined: Tue May 02, 2017 3:11 pm

Re: GLdc - Call for testers!

Post by kazade » Wed Aug 08, 2018 5:38 am

What's the layout for mipmap data that the PVR expects? Is it base level, followed by the smaller levels (e.g. 256x256, then 128x128, 64x64 etc.) or is it some other ordering?
kazade
DCEmu Freak
DCEmu Freak
Posts: 98
Joined: Tue May 02, 2017 3:11 pm

Re: GLdc - Call for testers!

Post by kazade » Thu Aug 09, 2018 3:48 am

OK so mipmapping is now implemented:
  • Loading VQ compressed data with mipmaps is supported by using specific constants when calling glCompressedTexImage2D (e.g. GL_COMPRESSED_ARGB_4444_VQ_MIPMAP_KOS)
  • glGenerateMipmapEXT() is implemented to generate a full set of mipmaps from a base texture uploaded via glTexImage2D
  • OpenGL mipmap filters (e.g. GL_NEAREST_MIPMAP_NEAREST) enable mipmapping, and perform my best guess at mapping filtering values
The next texturing feature I plan to implement is support for paletted textures via glColorTableEXT.

The only big feature now "missing" from GLdc that was in libGL is the framebuffer extension.
User avatar
lerabot
Insane DCEmu
Insane DCEmu
Posts: 109
Joined: Sun Nov 01, 2015 8:25 pm

Re: GLdc - Call for testers!

Post by lerabot » Thu Aug 09, 2018 11:48 am

Don't forget spotlight ;)

Good job as always!
User avatar
Christuserloeser
Moderator
Moderator
Posts: 5936
Joined: Thu Aug 28, 2003 12:16 am
Location: DCEvolution.net
Contact:

Re: GLdc - Call for testers!

Post by Christuserloeser » Fri Aug 10, 2018 5:22 am

This is quite exciting! :) Excellent job, kazade
Insane homebrew collector.
KingCrazy
DCEmu Fast Newbie
DCEmu Fast Newbie
Posts: 22
Joined: Sat Aug 04, 2018 11:36 am

Re: GLdc - Call for testers!

Post by KingCrazy » Mon Aug 13, 2018 12:18 am

Is GL_UNSIGNED_SHORT_5_6_5 supposed to be absent from the _determineStride function's switch statement in texture.c? I was trying to use glTexImage2D (Still trying to figure out how to load textures, haha), and when passing in GL_UNSIGNED_SHORT_5_6_5 I was receiving an "invalid GL_ENUM" error.

Or am I just not supposed to be using that to begin with?
kazade
DCEmu Freak
DCEmu Freak
Posts: 98
Joined: Tue May 02, 2017 3:11 pm

Re: GLdc - Call for testers!

Post by kazade » Mon Aug 13, 2018 1:25 am

Ah this looks like a mistake on my part. Leave it with me.
kazade
DCEmu Freak
DCEmu Freak
Posts: 98
Joined: Tue May 02, 2017 3:11 pm

Re: GLdc - Call for testers!

Post by kazade » Mon Aug 13, 2018 3:20 am

@KingCrazy Fixed! Thanks for letting me know!
KingCrazy
DCEmu Fast Newbie
DCEmu Fast Newbie
Posts: 22
Joined: Sat Aug 04, 2018 11:36 am

Re: GLdc - Call for testers!

Post by KingCrazy » Wed Aug 15, 2018 12:16 am

No problem! Happy to help! Thanks so much for all the hard work on this library! ^^
kazade
DCEmu Freak
DCEmu Freak
Posts: 98
Joined: Tue May 02, 2017 3:11 pm

Re: GLdc - Call for testers!

Post by kazade » Fri Aug 17, 2018 1:30 am

Ok so I have a question about compressed textures and mipmaps...

If I manually generate mipmaps for an uncompressed texture, and then disable mipmapping in the list header, then everything displays fine.

However, if i load a compressed texture with mipmaps, then switch off mipmapping, then the image is all corrupted.

Anyone know why that is?
kazade
DCEmu Freak
DCEmu Freak
Posts: 98
Joined: Tue May 02, 2017 3:11 pm

Re: GLdc - Call for testers!

Post by kazade » Tue Sep 18, 2018 1:04 am

Just an update. The new clipping algorithm has landed, and it's super fast. If no clipping is necessary then the performance hit is negligible. There are no copies to temporary buffers, everything happens in the same array, only newly generated triangles are appended.

There's a video of it in action here:https://twitter.com/kazade/status/10410 ... 21408?s=19
BB Hood
Insane DCEmu
Insane DCEmu
Posts: 166
Joined: Fri Mar 30, 2007 12:09 am

Re: GLdc - Call for testers!

Post by BB Hood » Tue Sep 18, 2018 9:14 pm

Awesome! So excited.
Ayla
Insane DCEmu
Insane DCEmu
Posts: 135
Joined: Thu Apr 03, 2008 7:01 am
Contact:

Re: GLdc - Call for testers!

Post by Ayla » Fri Sep 21, 2018 4:31 am

BlueCrab wrote:
Thu Aug 02, 2018 10:44 pm
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.
Instead of renaming functions, just define clearly what functions should be visible from outside the library, and what functions are for internal use only. Then mark the former ones as externally visible using the __api tag on their prototype in the public header, defined like this:

#define __api __attribute__((visibility ("default")))

Then add -fvisibility=hidden to your CFLAGS.

Example here: https://github.com/analogdevicesinc/lib ... ster/iio.h

The big benefit over just renaming functions, is that the private functions stay private, and the apps linking to your library can't use them even if they try to define them as extern.
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5335
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Contact:

Re: GLdc - Call for testers!

Post by BlueCrab » Fri Sep 21, 2018 11:18 am

That will work just fine then. :)
kazade
DCEmu Freak
DCEmu Freak
Posts: 98
Joined: Tue May 02, 2017 3:11 pm

Re: GLdc - Call for testers!

Post by kazade » Fri Sep 21, 2018 3:38 pm

I'll get on it as soon as I can! Thanks Ayla!
Ayla
Insane DCEmu
Insane DCEmu
Posts: 135
Joined: Thu Apr 03, 2008 7:01 am
Contact:

Re: GLdc - Call for testers!

Post by Ayla » Wed Sep 26, 2018 1:13 am

@kazade: I wonder if you saw this post?
viewtopic.php?f=29&t=102181&start=20#p1034105

(Actually the whole thread is super-interesting)
kazade
DCEmu Freak
DCEmu Freak
Posts: 98
Joined: Tue May 02, 2017 3:11 pm

Re: GLdc - Call for testers!

Post by kazade » Wed Sep 26, 2018 2:50 am

I hadn't but that's a really interesting read!

I don't think I'll be doing anything like that in GLdc. My aim there is to hit 100000 quads per second and then hope someone with more low-level knowledge than me submits improvements :)

I'm at around 85k in the quadmark bench, but I know where the bottleneck is; there's a fat loop that builds the vertex list from user submitted data and that's eating the time. I'll fix that soon and then see where we are.

Or if someone is feeling adventurous, pull requests welcome!
Post Reply