[Release] Caelina - OpenGL Driver

Discussion in '3DS - Homebrew Development and Emulators' started by machinamentum, Jul 11, 2015.

  1. machinamentum
    OP

    machinamentum GBAtemp Regular

    Member
    163
    450
    Jul 5, 2015
    United States
    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
     
    Last edited by machinamentum, Aug 8, 2015


  2. hippy dave

    hippy dave Butts Butts Megabutts

    Member
    2,569
    1,791
    Apr 30, 2012
    Cool, always good to see new libraries, and opengl should be useful!
     
  3. rewrewrew123

    rewrewrew123 GBAtemp Regular

    Member
    263
    26
    Aug 20, 2014
    Italy
    So later we can play any pc titles that requires openGL?
     
    frogboy and Zidapi like this.
  4. cebolleto

    cebolleto GBAtemp Regular

    Member
    148
    206
    Mar 5, 2010
    Is this OpenGL or OpenGL ES?
     
  5. Lectem

    Lectem Member

    Newcomer
    43
    60
    Nov 21, 2014
    France
    obviously not

    — Posts automatically merged - Please don't double post! —

    OpenGL by looking at the headers
     
  6. machinamentum
    OP

    machinamentum GBAtemp Regular

    Member
    163
    450
    Jul 5, 2015
    United States
    No, however, this enables a developer to port an OpenGL application to 3DS with just a bit more ease.

    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.
     
  7. Lectem

    Lectem Member

    Newcomer
    43
    60
    Nov 21, 2014
    France
    May I ask why you left a software rasterizer in the lib ?
     
  8. machinamentum
    OP

    machinamentum GBAtemp Regular

    Member
    163
    450
    Jul 5, 2015
    United States
    Historically, this lib worked on both 3DS and PC when it was just the rasterizer. I'll disable it in future builds.
     
  9. Normmatt

    Normmatt Former AKAIO Programmer

    Member
    2,142
    544
    Dec 14, 2004
    New Zealand
    source code?
     
    Purple_Smart96 likes this.
  10. Lectem

    Lectem Member

    Newcomer
    43
    60
    Nov 21, 2014
    France
    +1
    At least we would know exactly what is working and what isn't
     
    Purple_Smart96 likes this.
  11. cebolleto

    cebolleto GBAtemp Regular

    Member
    148
    206
    Mar 5, 2010
    I think OpenGL ES is a better option since it is what the 3ds supports officially
     
  12. machinamentum
    OP

    machinamentum GBAtemp Regular

    Member
    163
    450
    Jul 5, 2015
    United States
    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.
     
    Idaho likes this.
  13. MeisterFenster

    MeisterFenster GBAtemp Regular

    Member
    161
    31
    Nov 18, 2014
    Gambia, The
    Cool, great work :)
     
  14. Lectem

    Lectem Member

    Newcomer
    43
    60
    Nov 21, 2014
    France
    Most OpenGL 1.1(and the subset of gles2 supported) have 1:1 bindings with GPU commands though.
     
  15. Jim_e

    Jim_e Advanced Member

    Newcomer
    79
    41
    Nov 13, 2007
    United States
    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.
     
  16. neobrain

    neobrain -

    Member
    306
    472
    Apr 25, 2014
    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.

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

    Jim_e Advanced Member

    Newcomer
    79
    41
    Nov 13, 2007
    United States
    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.

    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.
     
  18. Purple_Smart96

    Purple_Smart96 Advanced Member

    Newcomer
    73
    31
    Dec 26, 2013
    United States
    NSA headquarters
    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.
     
    Last edited by Purple_Smart96, Jul 12, 2015
  19. TheCruel

    TheCruel Developer

    Banned
    1,351
    2,882
    Dec 6, 2013
    United States
    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.
     
  20. machinamentum
    OP

    machinamentum GBAtemp Regular

    Member
    163
    450
    Jul 5, 2015
    United States
    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 :P
    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.
    Warning: Spoilers inside!
    EDIT: I've been brainstorming some theories to pushing performance. Attempting to implement display lists within the next few days
     
    Last edited by machinamentum, Jul 13, 2015
    marc00077 likes this.