Homebrew [Release] Caelina - OpenGL Driver

[shinyquagsire23]

Are textures actually working? I've found that doing a glEnable(GL_TEXTURE_2D) causes rendering to freeze when vertexes are drawn and glGenTextures crashes to home.

 

[machinamentum]

Are textures actually working? I've found that doing a glEnable(GL_TEXTURE_2D) causes rendering to freeze when vertexes are drawn and glGenTextures crashes to home.

They should be. My OGG music player uses this lib with working textures. They have to be RGBA with 8 bits per color. I use GL_UNSIGNED_BYTE as the type. Also note that width and height need to be powers of two on the PICA, I think. I also recommend changing the unpack alignment using glPixelStorei to 1.

It's also possible that I broke textures recently. Ill have to test when I find the time.

EDIT: if you could narrow down your issue to what functions are crashing and post that code, that'd help me help you.

 

[shinyquagsire23]

They should be. My OGG music player uses this lib with working textures. They have to be RGBA with 8 bits per color. I use GL_UNSIGNED_BYTE as the type. Also note that width and height need to be powers of two on the PICA, I think. I also recommend changing the unpack alignment using glPixelStorei to 1.

It's also possible that I broke textures recently. Ill have to test when I find the time.

EDIT: if you could narrow down your issue to what functions are crashing and post that code, that'd help me help you.

glGenTextures itself seems to crash hard (into the home menu) if the number of textures to generate is over 0x7F. glGenTextures(0x1001, texture) is what I had originally, probably should have lowered it, but is 0x80 a hard limit or a bug?

glEnable( GL_TEXTURE_2D) will cause the first glBegin (I was using GL_TRIANGLES) to hang, but not crash (some sort of loop it's stuck in?). Removing glEnable( GL_TEXTURE_2D) lets it render just a plain triangle (no actual texturing, just colors). As a test you can try adding glEnable( GL_TEXTURE_2D) to the fourth NeHe example and it will hang before drawing. It doesn't seem to be a kernel hang only because I can eject the cart and it responds.

 

[machinamentum]

glGenTextures itself seems to crash hard (into the home menu) if the number of textures to generate is over 0x7F. glGenTextures(0x1001, texture) is what I had originally, probably should have lowered it, but is 0x80 a hard limit or a bug?

glEnable( GL_TEXTURE_2D) will cause the first glBegin (I was using GL_TRIANGLES) to hang, but not crash (some sort of loop it's stuck in?). Removing glEnable( GL_TEXTURE_2D) lets it render just a plain triangle (no actual texturing, just colors). As a test you can try adding glEnable( GL_TEXTURE_2D) to the fourth NeHe example and it will hang before drawing. It doesn't seem to be a kernel hang only because I can eject the cart and it responds.

It seems to be an allocation bug. I use a custom buffer that resizes itself when data exceeds its current size, which is by default 128 units (0x80) so it seems to crash on allocation, which is odd because in my Suzanne example, Suzanne is ~1500 vertices, and vertex data is stored in the same way. I'll look into fixing it ASAP.

glEnable(GL_TEXTURE_2D) causing glBegin to hang is a bug thats on my list. It's due to the backend not having enough safety checks and then it attempts to use texture data without having a bound texture to use.

 

[shinyquagsire23]

It seems to be an allocation bug. I use a custom buffer that resizes itself when data exceeds its current size, which is by default 128 units (0x80) so it seems to crash on allocation, which is odd because in my Suzanne example, Suzanne is ~1500 vertices, and vertex data is stored in the same way. I'll look into fixing it ASAP.

glEnable(GL_TEXTURE_2D) causing glBegin to hang is a bug thats on my list. It's due to the backend not having enough safety checks and then it attempts to use texture data without having a bound texture to use.

Ah, I see. If I glBindTexture(GL_TEXTURE_2D, 0) it'll not hang, but it won't display non-textured stuff normally. In any case, I might be able to work with this I suppose, I'll have to try loading textures as I need them rather than the whole array at once.

EDIT: Seems like even when I allocate them individually, 0x7F is still a limit. Boo. If this could get fixed that would be fantastic.

EDIT 2: Seems a new commit has appeared, time to test.

 

[machinamentum]

Ah, I see. If I glBindTexture(GL_TEXTURE_2D, 0) it'll not hang, but it won't display non-textured stuff normally. In any case, I might be able to work with this I suppose, I'll have to try loading textures as I need them rather than the whole array at once.

EDIT: Seems like even when I allocate them individually, 0x7F is still a limit. Boo. If this could get fixed that would be fantastic.

I believe I've fixed the glGenTextures issue. It seems I've overlooked a delete operator on an array when it should've been delete[]. It's still odd that vertices still worked this way but not textures. Anyways, pull the latest release from GitHub and try it again.

EDIT: noticed delete[] calls destructors; commit 007c4f3 will save you a lot of headaches

 

[shinyquagsire23]

I believe I've fixed the glGenTextures issue. It seems I've overlooked a delete operator on an array when it should've been delete[]. It's still odd that vertices still worked this way but not textures. Anyways, pull the latest release from GitHub and try it again.

EDIT: noticed delete[] calls destructors; commit 007c4f3 will save you a lot of headaches

Seems to have done the trick, still working on getting the textures to actually display though.

EDIT: Can't seem to get neither a simple triangle nor a quad (drawn with GL_QUADS) to texture properly. They just draw as black, or with alpha blending enabled, transparent.

EDIT 2: Seems I missed a commit, might try that real quick.

 

[Deleted User]

Nice job. I have my own OpenGL-ish GPU functions, but actual OpenGL would be even better. Hope you manage to get any issues worked out.

 

[shinyquagsire23]

OK, so I finally got textures to display somewhat. My first issue was that I was using BGRA (the particular program I'm porting has it's colors in that format, however it was an easy fix to move it to RGBA), apparently it just kinda goes nowhere if the source format is anything but RGBA. My second issue I found is that it's not exactly friendly with textured quads at all:

Spoiler

Although quads are bad practice anyhow so now I have an excuse to fix that. Just a note though to get that implementation better.

Also, vertex color information seems to be ignored on textures as well:

Spoiler

vs

Spoiler

EDIT: Actually it seems the main issue is that it doesn't like negative/flipped texture coordinates with quads or triangles, so not a quad issue.

 

[machinamentum]

OK, so I finally got textures to display somewhat. My first issue was that I was using BGRA (the particular program I'm porting has it's colors in that format, however it was an easy fix to move it to RGBA), apparently it just kinda goes nowhere if the source format is anything but RGBA. My second issue I found is that it's not exactly friendly with textured quads at all:
Although quads are bad practice anyhow so now I have an excuse to fix that. Just a note though to get that implementation better.

Also, vertex color information seems to be ignored on textures as well:
vs

Spoiler

The reason for this is I've used a somewhat lazy approach I've learned form sf2dlib for sending just two buffer attributes to the shader instead of 3 or 4. I'll try to work out a fix with a new shader.

As for the quads, I'm not sure why thats happening as I've successfully used textured quads.

 

[shinyquagsire23]

The reason for this is I've used a somewhat lazy approach I've learned form sf2dlib for sending just two buffer attributes to the shader instead of 3 or 4. I'll try to work out a fix with a new shader.

As for the quads, I'm not sure why thats happening as I've successfully used textured quads.

Check my edit, it's an issue with negative texture mappings (commonly used to flip textures in some games). I flipped them the right way around and my textured quads work fine.

EDIT: Ported my mini project I made a while back! It was originally written in SDL for PC, but it doesn't do much more than render maps so porting was mostly just working out quirks and ifdefs

Spoiler

 

[machinamentum]

Check my edit, it's an issue with negative texture mappings (commonly used to flip textures in some games). I flipped them the right way around and my textured quads work fine.

EDIT: Ported my mini project I made a while back! It was originally written in SDL for PC, but it doesn't do much more than render maps so porting was mostly just working out quirks and ifdefs

Spoiler

I'm not sure if this is related but the driver wasn't setting texture wrapping. I've changed it to submit wrapping data and I've added glTexParameteri. Note that it won't support the mipmap operations for GL_TEXTURE_MIN_FILTER.

Also, neat!
EDIT: I've ported an old test project with working TTF rendering (stb_truetype). Ignore the white blob, lighting is really a priority at this point.

Spoiler

EDIT: it seems with very large textures (i.e. 1024x1024) the PICA slows down as the number of pixels to be drawn with that texture increases. It also seems that the overall brightness of the screen changes as the camera moves closer to the stone henge in my attached pic. Odd..
EDIT 2: Since the PICA200 has a lot of interesting extensions, I'm implementing some of them as the GL matures enough to easily incorporate them. All supported extensions can be found in GL/glext.h and i've linked to my own documentation for them in the OP.
EDIT 3: Display lists should now be working.
EDIT 4: Both color and texture coordinates are now submitted to the shader with their respective vertices. Should fix some issues for apps that utilize both (i.e. for alpha textures). GL_ALPHA textures should be fully working and inherit their RGB values from glColor commands as they should. I've also studied a bit on 3DBrew and I've learned to be able to fully utilize the buffer attributes from shaders, so lighting will be in the works soon.

 

[gudenau]

Great, for my current 3D projecr this appears to have everything I need. Does this have VBOs?

 

[machinamentum]

Great, for my current 3D projecr this appears to have everything I need. Does this have VBOs?

At the moment, no. However, you can wrap glBegin/glEnd calls into a display list then use glCallList for drawing. The implementation uses a VBO approach internally, so it should be pretty efficient for now.

 

[gudenau]

How do I install this?

 

[machinamentum]

How do I install this?

Option 1:

Copy the headers from caelina/include to <DEVKITPRO>/libctru/include
Copy libcaelina.a from caelina/lib/libcaelina.a to <DEVKITPRO>/libctru/lib
Add -lcaelina to your LIBS in Makefile.

Option 2:

Keep the caelina folder somewhere relative to your project directory.
Add -I<caelina include dir path> to your CFLAGS
Add <relative path to libcaelina.a> to your LIBS
(See Makefile in the example folder)

I'll add a Makefile in the next upload that just installs to devkitPro.
Makefile added. use make install to install it into the libctru folder.
Add -lcaelina to your LIBS.

 

[ghjfdtg]

Why is this closed source? There is no reason to keep it to yourself.

 

[machinamentum]

Why is this closed source? There is no reason to keep it to yourself.

Because it is usable as a compiled library, it isn't yet complete and thus not ready for a full release, and some important features are broken or missing. There's also not enough developers currently working on 3D homebrew to warrant a need to open source. If a lot of people start developing 3D homebrews and this project reaches a certain level of maturity, then I'll consider releasing the source.

If some developers feel they can't trust a pre-compiled library for what ever reason, there are several other GL-like implementations with source code available.

 

[neobrain]

Because it is usable as a compiled library, it isn't yet complete and thus not ready for a full release, and some important features are broken or missing. There's also not enough developers currently working on 3D homebrew to warrant a need to open source. If a lot of people start developing 3D homebrews and this project reaches a certain level of maturity, then I'll consider releasing the source.

There's a bit of a chicken-and-egg problem here. I'm sure some people would eventually be willing to contribute to this project even without having done any prior 3DS-related work before. There's no way people can prove their willingness towards contributing when everybody keeps the basis for themselves. Also note that lots of people are more interested in working on base libraries like this without actually developing applications themselves, so waiting for people to do something with your library might not be the best approach.

Providing source code gives people the ability to jump in and help you out (if not by developing new features, then maybe by spotting and fixing bugs which you otherwise might not have noticed), and there's no reason not to do it. And even if people don't end up helping you, looking at the source code might give them a few clues on how to develop other interesting stuff. For instance, imagine that the ctrulib or nihstro examples had only shipped as precompiled binaries without source code - judging by how similar the shader in the Caelina library is, wouldn't that have made your job quite a bit harder?

If some developers feel they can't trust a pre-compiled library for what ever reason, there are several other GL-like implementations with source code available.

You have to understand that many developers stay away from closed-source library on principle, for good reasons. Having a reference implementation has nothing to do with that. Fear of malicious code (which lots of closed-source libraries are contaminated with one way or the other) is just one of the reasons, another one would be lack of customizability and lack of insight into implementation details (which is important when documentation is vague or the implementation turns out to be buggy).

 

[shinyquagsire23]

To add onto neobrain's remarks, I probably would have been able to find the texture allocation bug on my own had I been able to view the source. But without it, I really have nothing to go off of. Believe me, there's plenty of people willing to improve this, and honestly having the source out really doesn't hurt.