Compiling for switch - Githubissues

SpartanJ commented 5 years ago

Original report by Andy Adshead (Bitbucket: BaronKiko, GitHub: BaronKiko).

I am trying to compile this library for the switch under switchbrew/devkitpro so that I may load DDS files. I get lots of undefined reference errors to opengl functions such as glTexImage2D
I have tried various changes to the include logic at the top of SOIL2.c with no luck, including removing all the ifdef's and just referencing opengl directly. I am able to reference these methods from my code without issue and the linker options are defined appropriately.

To replicate you can use this project https://github.com/BaronKiko/Ryujinx-OGL-Demos/tree/master/cubemap

Main still uses stbi which I am trying to upgrade from, an updated version that uses SOIL2 can be found here: https://gist.github.com/BaronKiko/6a77f0b84802feb9b4e14ca8f40578fb

You should only need devkitpro to compile it through msys2 using make. The output nro file can be loaded with yuzu or an actual switch. Ryujinx does technically work but there are issues I'm trying to fix, hence the creation of this demo.

Thank you for your time and help

SpartanJ commented 5 years ago

Original comment by Martín Lucas Golini (Bitbucket: SpartanJ, GitHub: SpartanJ).

Hi Andy! I'm not familiar with the Switch dev sdk, but AFAIK you should have OpenGL ES 2 support since it's a Tegra device. Addding support to Switch should be trivial, but it's not supported because it just simply never even occurred me that someone could be interested ( also i don't own a Swich and didn't even know there was an open source devkit ). But if you're getting an undefined reference error is because you're not linking against libGL or libGLES2 ( -lGL or -lGLESv2 ). I'm mostly sure that you must add -lGLESv2 to the linker flags. I don't have any knowledge about the platform but an undefined reference is just that the linker can't find the symbols of that functions, so there's not to many options. Also, if you're going to use GLES2 you need to let SOIL2 know that GLES2 is being used, addding the macro definition for it, named: SOIL_GLES2 ( -DSOIL_GLES2 ).

Regards, Martín

SpartanJ commented 5 years ago

Original comment by Andy Adshead (Bitbucket: BaronKiko, GitHub: BaronKiko).

Using -lGLESv2 solved my problem. I had been using -lEGL for my main application and assumed it would just use that. Other than that it works just fine out of the box. At least the 1 function I tried.

Thank you for the help with my silly mistake

SpartanJ commented 5 years ago

Original comment by Martín Lucas Golini (Bitbucket: SpartanJ, GitHub: SpartanJ).

Nice to hear that! =)

SpartanJ commented 5 years ago

Original comment by Andy Adshead (Bitbucket: BaronKiko, GitHub: BaronKiko).

For anyone in the future that may be reading this. Turns out the switch always reports feature unsupported even though it does support most features. You can just return 1 in this method or come up with a cleaner solution: https://bitbucket.org/SpartanJ/soil2/src/1c584821379872b5556fa750c55228964a63c67f/src/SOIL2/SOIL2.c#lines-302

SpartanJ commented 5 years ago

Original comment by Martín Lucas Golini (Bitbucket: SpartanJ, GitHub: SpartanJ).

The Wwitch should be reporting the extensions supported by the GPU. I'm pretty sure this can be fixed the right way. Checking for the correct extensions names, they must be using other extension names that SOIL2 is not cheking. Can you send me what's the output of the GL extensions supported?

You should be able to output the extensions with something like:

#!c

typedef const GLubyte *( * pglGetStringiFunc) (unsigned int, unsigned int);

std::string getExtensions() {
    std::string exts;

    static pglGetStringiFunc rglGetStringiFunc = NULL;

    int num_exts = 0;
    int i;

    if ( NULL == rglGetStringiFunc ) {
        rglGetStringiFunc = (pglGetStringiFunc)SOIL_GL_GetProcAddress("glGetStringi"); // or just use eglGetProcAddress

        if ( NULL == rglGetStringiFunc ) {
            return 0;
        }
    }

    #ifndef GL_NUM_EXTENSIONS
    #define GL_NUM_EXTENSIONS 0x821D
    #endif
    glGetIntegerv(GL_NUM_EXTENSIONS, &num_exts);
    for (i = 0; i < num_exts; i++)
    {
        const char *thisext = (const char *) rglGetStringiFunc(GL_EXTENSIONS, i);

        exts += std::string( thisext ) + " ";
    }

    return exts;
}

Regards

SpartanJ commented 5 years ago

Original comment by Andy Adshead (Bitbucket: BaronKiko, GitHub: BaronKiko).

I can try run your code later, just heading out the door, but I'm assuming it's the same info as here: https://opengl.gpuinfo.org/displayreport.php?id=3154

That report was created by another dev so we didn't have to keep writing code to check these things.

If that's not what you need let me know and I can try your code when I get back.

Do remember I am:

Running through an opensource implementation of the switch API's, nothing official.
On an experimental emulator.
And it's also a console so you know ahead of time what's supported and don't really need to check anyway. I assume no actual games check.

SpartanJ commented 5 years ago

Original comment by Martín Lucas Golini (Bitbucket: SpartanJ, GitHub: SpartanJ).

Oh ok. The extensions are fine. Then if it's failing it might be a bug in the OpenGL driver. The SOIL2 implementation is just valid, if fails it must be reporting something wrong the OpenGL driver. Anyway, since this isn't nothing official, i'm not very interested in fixing it. Patchs are welcomed tho.

SpartanJ commented 5 years ago

Original comment by Andy Adshead (Bitbucket: BaronKiko, GitHub: BaronKiko).

Yeah there isn't a need for a fix. If you wanted a clean fix you could just wrap the change I mentioned earlier in a

#!c

ifdef __switch__

but it's no big deal. Just figured I should mention it for future people that may want to use SOIL2 as it confused me for a bit.

Having used it for a couple days everything else seems fine. It's a nice library, much better than STBI so thank you for your work.

SpartanJ / SOIL2

Compiling for switch #22