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
Re: GLdc - Call for testers!
You got a sample texture file for me to test with? I'll see what I can do
-
- 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!
Gosh now I really DO feel like a doofus! That was a lot easier than I thought it was! Thank you!lerabot wrote: ↑Mon Aug 06, 2018 9:33 am If you cloned the lib in kos/addons/, all you have to do is addand link usingCode: Select all
#include <GL/gl.h>
Or at least, that's what I didCode: Select all
-lGLdc
-
- 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!
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?
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?
-
- 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!
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
glCompressedTexImage2D now works great. It supports compressed, twiddled and mipmapped formats. Sample here: https://github.com/Kazade/GLdc/blob/mas ... _vq/main.c
-
- 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!
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?
-
- 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!
OK so mipmapping is now implemented:
The only big feature now "missing" from GLdc that was in libGL is the framebuffer extension.
- 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 only big feature now "missing" from GLdc that was in libGL is the framebuffer extension.
- lerabot
- Insane DCEmu
- Posts: 134
- Joined: Sun Nov 01, 2015 8:25 pm
- Has thanked: 2 times
- Been thanked: 19 times
- Christuserloeser
- Moderator
- Posts: 5948
- Joined: Thu Aug 28, 2003 12:16 am
- Location: DCEvolution.net
- Has thanked: 10 times
- Been thanked: 0
- Contact:
Re: GLdc - Call for testers!
This is quite exciting! Excellent job, kazade
Insane homebrew collector.
-
- 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!
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?
Or am I just not supposed to be using that to begin with?
-
- 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!
No problem! Happy to help! Thanks so much for all the hard work on this library! ^^
-
- 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!
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?
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?
-
- 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!
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
There's a video of it in action here:https://twitter.com/kazade/status/10410 ... 21408?s=19
-
- DC Developer
- Posts: 142
- Joined: Thu Apr 03, 2008 7:01 am
- Has thanked: 0
- Been thanked: 4 times
- Contact:
Re: GLdc - Call for testers!
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: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.
#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.
-
- DC Developer
- Posts: 142
- Joined: Thu Apr 03, 2008 7:01 am
- Has thanked: 0
- Been thanked: 4 times
- Contact:
Re: GLdc - Call for testers!
@kazade: I wonder if you saw this post?
viewtopic.php?f=29&t=102181&start=20#p1034105
(Actually the whole thread is super-interesting)
viewtopic.php?f=29&t=102181&start=20#p1034105
(Actually the whole thread is super-interesting)
-
- 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 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!
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!