Homebrew [Release] Caelina - OpenGL Driver

[machinamentum]

Hello,
Around the time ninjhax was first released, I wrote a software renderer with an OpenGL-based front-end. Recently as I've worked on more homebrew projects, I've began writing a GPU-enabled backend and over the course of several days and many headaches, I've got a working API with texture mapping, generic 2D/3D rendering, and many of the bread and butter functionalities you'd expect from an OpenGL driver. The goal of this project is to eventually implement a viable GL for homebrew projects that may be ported to other devices in the future, as well as support the extensions that the PICA200 provides.

What's working:

• Textures
• Matrix stacks (Projection & Modelview full support, Texture partial)
• Matrix operations (glLoadIdentity, glRotate, glTranslate, glOrtho, glFrustumf)
• Alpha blending
• Enable/Disable depth test
• glClearColor
• GL_TRIANGLES, GL_QUADS
• glViewport
• glScissor
• Display lists (glNewList, glEndList, glCallList, glGenLists)
• glGetError
• Per-vertex lighting***
• Alpha testing
• Stencil testing and stencil buffer operations
• glTexSubImage2D

Extensions:

• glScissorMode

Not yet feasible (see below):

• GL_POINTS,GL_LINES and related

TODO:

• Nothing is left on my original TODO

*Some aspects of the specification call for operations not available on the PICA200 based on what information is currently available (like GL_POINTS and GL_LINES). The specification requires only that the GL perform an operation that viably produces expected results. Because of this, these features will not be implemented until a fast software rasterizer that is compatible with the PICA's output is implemented (the current software rasterizer is effectively too slow to be of use on a large scale).

**Every function has safety checks and conforms to their specified error handling with very few exceptions. General rule of thumb: if something isn't drawn to expectation, check glGetError; if device soft locks or crashes to home menu, it's likely a bug in the driver.

***Currently, only GL_LIGHT0 can be used

Using immediate mode is not only slow, but I've also noticed it causes the GPU to hang after running awhile (maybe ~10 mins?). I've yet to notice this while using cached vertex data, so I recommend to cache all your vertex data into display lists and use immediate mode sparsely. Hacky fix.

If you use this library, attribution in your readme/documentation is appreciated.

Currently, this project is closed source but the library itself and the necessary headers are provided as well as an example app rendering a well-known monkey
NeHe tutorials 01 - 05 now available.
Source repo: here
Extension documentation: here

 

[hippy dave]

Cool, always good to see new libraries, and opengl should be useful!

 

[rewrewrew123]

So later we can play any pc titles that requires openGL?

 

[cebolleto]

Is this OpenGL or OpenGL ES?

 

[Lectem]

So later we can play any pc titles that requires openGL?

obviously not

--------------------- MERGED ---------------------------

Is this OpenGL or OpenGL ES?

OpenGL by looking at the headers

 

[machinamentum]

So later we can play any pc titles that requires openGL?

No, however, this enables a developer to port an OpenGL application to 3DS with just a bit more ease.

Is this OpenGL or OpenGL ES?

I try to conform the code to the desktop OpenGL 1.1. The included GL header is just an unmodified copy of Mesa3D's gl.h.

 

[Lectem]

May I ask why you left a software rasterizer in the lib ?

 

[machinamentum]

May I ask why you left a software rasterizer in the lib ?

Historically, this lib worked on both 3DS and PC when it was just the rasterizer. I'll disable it in future builds.

 

[Normmatt]

source code?

 

[Lectem]

source code?

+1
At least we would know exactly what is working and what isn't

 

[cebolleto]

I think OpenGL ES is a better option since it is what the 3ds supports officially

 

[machinamentum]

I think OpenGL ES is a better option since it is what the 3ds supports officially

Right now, my focus is on implementing the core features of GL. After that, writing the GL ES functions should be straightforward, so I'll definitely add them if there is the demand for them.

 

[MeisterFenster]

Cool, great work

 

[Lectem]

Right now, my focus is on implementing the core features of GL. After that, writing the GL ES functions should be straightforward, so I'll definitely add them if there is the demand for them.

Most OpenGL 1.1(and the subset of gles2 supported) have 1:1 bindings with GPU commands though.

 

[Jim_e]

I think your going to run into a number of problems. The biggest being that the gpu isn't fully RE'd yet. I'm not sure if specular lighting was ever fully resolved. On top of that OpenGL Es would be better to implement due to the nature hardware(ie slow as molasses).

Good luck to you though.

 

[neobrain]

The biggest being that the gpu isn't fully RE'd yet. I'm not sure if specular lighting was ever fully resolved.

You're referring to fragment lighting. Specular lighting (as a part of OpenGL) is defined as vertex lighting, which can be implemented easily in a vertex shader. In fact, I'm pretty sure the GPU has been REed far enough to provide a working GLES 1.x implementation.

On top of that OpenGL Es would be better to implement due to the nature hardware(ie slow as molasses).

What does the performance of PICA200 even have to do with OGL vs OGL ES?

 

[Jim_e]

You're referring to fragment lighting. Specular lighting (as a part of OpenGL) is defined as vertex lighting, which can be implemented easily in a vertex shader. In fact, I'm pretty sure the GPU has been REed far enough to provide a working GLES 1.x implementation.

The last I read, the hardware supports phong shading via quaternion interpolation. I know little of the method, but I noticed the output registers for the shaders have a quaterion sitting there doing jack. With vertex shading specular is gonna look pretty bad for low poly objects. But I doubt any one is actually aiming for photo realism on the 3ds.

What does the performance of PICA200 even have to do with OGL vs OGL ES?

I was referring to the cpu. Loading vertices and attributes one call at a time is long and annoying process. The hardware would do better using VBOs as to not bog down the cpu as much.

 

[purpasmart96]

Hmm well I guess I wasn't the only one I have been working on getting an almost perfect OpenGl API for the 3ds, the only difference of mine, is that's it's inside of ctrulib and not a separate library.
Oh yeah and also please make it open source I would love to take a look at the source myself.

 

[TheCruel]

Hmm well I guess I wasn't the only one I have been working on getting an almost perfect OpenGl API for the 3ds, the only difference of mine, is that's it's inside of ctrulib and not a separate library.
Oh yeah and also please make it open source I would love to take a look at the source myself.

Haha. I'm working on an OpenGL implementation too. I'll get the source pushed online this week, no need for everyone to keep recreating the same functionality, waste of time.

 

[machinamentum]

So, I've implemented viewports and ~12,000 vertices causes a noticeable slowdown, I think (my eyes could be deceiving me...) (animation still seems smooth though), but still not bad considering how slow immediate mode rendering generally is
I've also noticed that the closer to 1/3 - 1/4 the screen height an object is drawn, it seems to become more pleasant to look at in stereoscopic 3D.
EDIT: ~18,000 vertices across 12 draw calls and still smooth!
EDIT: NeHe tutorial ports added to repo.

Spoiler

EDIT: I've been brainstorming some theories to pushing performance. Attempting to implement display lists within the next few days