AmigaOS4 : is testGLSL() is correct one ?

[kas1e]

Hi ptitSeb !

Do not know if it again issue on our side or something inside of gl4es, but lately found that problem: we do have such small test case:

#include <iostream>
#include <cstring>
#include <SDL2/SDL.h>
#include <GL/GL.h>

SDL_Window *    gSDLWindow = NULL; 
SDL_GLContext    gAGLContext = NULL;

#define GAME_ASSERT(condition) do { if (!(condition)) DoFatalAlert("%s:%d: %s", __func__, __LINE__, #condition); } while(0)
#define GAME_ASSERT_MESSAGE(condition, message) do { if (!(condition)) DoFatalAlert("%s:%d: %s", __func__, __LINE__, message); } while(0) 

#define PROJECT_VERSION "3.0.0"

void DoFatalAlert(const char* format, ...)
{

    char message[1024];
    va_list args;
    va_start(args, format);
    vsnprintf(message, sizeof(message), format, args);
    va_end(args);

    printf("CMR Fatal Alert: %s\n", message);
    SDL_ShowSimpleMessageBox(SDL_MESSAGEBOX_ERROR, "Cro-Mag Rally", message, NULL);

    if(gAGLContext)
        SDL_GL_DeleteContext(gAGLContext);
    gAGLContext = NULL;
    if(gSDLWindow)
        SDL_DestroyWindow(gSDLWindow);
    gSDLWindow = NULL;

    SDL_Quit();    
} 

int main()
{

    // Initialize SDL video subsystem
    if (0 != SDL_Init(SDL_INIT_VIDEO))
    {
        throw std::runtime_error("Couldn't initialize SDL video subsystem.");
    }

    gSDLWindow = SDL_CreateWindow(
            "Cro-Mag Rally " PROJECT_VERSION,
            SDL_WINDOWPOS_CENTERED,
            SDL_WINDOWPOS_CENTERED,
            640,
            480,
            SDL_WINDOW_OPENGL | SDL_WINDOW_RESIZABLE | SDL_WINDOW_SHOWN);

    GAME_ASSERT_MESSAGE(gSDLWindow, "Window must be created before the DC!");

            /* CREATE AGL CONTEXT & ATTACH TO WINDOW */

    gAGLContext = SDL_GL_CreateContext(gSDLWindow);

    if (!gAGLContext)
        DoFatalAlert(SDL_GetError());

    GAME_ASSERT(glGetError() == GL_NO_ERROR);

            /* ACTIVATE CONTEXT */

    int mkc = SDL_GL_MakeCurrent(gSDLWindow, gAGLContext);
    GAME_ASSERT_MESSAGE(mkc == 0, SDL_GetError());

    printf("all fine! Quit!\n");

    if(gAGLContext)
        SDL_GL_DeleteContext(gAGLContext);
    gAGLContext = NULL;
    if(gSDLWindow)
        SDL_DestroyWindow(gSDLWindow);
    gSDLWindow = NULL;

    SDL_Quit();    

}

Now, when i compile it with minigl all fine, no errors, but when i do compile it with gl4es and it tries to create some test shaders, it do return GL Error.

I checked with glsnoop, and we find that gl4es create 3 test shaders, for 120, 300es and 310es. And first one fail:

#version 120'
layout(location = 0) in vec4 vecPos;
layout(location = 0) uniform mat4 matMVP;

void main() {
gl_Position = matMVP * vecPos;
}

And fail because #version should be 300 or 310 es due to uniform location. And because of that we do have GL_ERROR, and test case fail with error.

Now question is : should't be shader for 120 be one which works on 120, or not ?

Thanks!

[kas1e]

Also, if shader should be of this kind (while imho, it need to be a bit rewriten, as 120 do not support uniform location of this kind), we maybe should in gl4es after those 3 test shaders clear the GL_ERROR, so it will be point to the APP that we do have GL_ERROR.

[ptitSeb]

The tests shaders are just test shaders, it should not impact anything running. If the tests gives you some issue, you can disable them with LIBGL_NOTEST=1 env. var. Maybe glError should be reset after the init?

[ptitSeb]

(the shader with location on version 120 is because there is 1 unofficial PowerVR extension that seems to allow that, but I haven't really used it, but the test is in place)

[kas1e]

LIBGL_NOTEST 1 didn't help, it still the same run tests (i can see words "GLSL 300 es supported" and "GLSL 310 es supported", but your changes in gl4es itself with reseting GL_ERROR after test shader check - that did help for sure, thanks ! :)

[ptitSeb]

Ah, NOTEST was not working? strange. Glad the reset of gl error worked.

Anyway, how are you? it's been a long time!

[kas1e]

Ah, NOTEST was not working? strange.

Yeah, NOTEST definately not working.

Anyway, how are you? it's been a long time!

Still updating our components bit by bit, and for now we tried to port this good game: https://github.com/jorio/CroMagRally, that from where i got this GL_ERROR firstly

[ptitSeb]

Oh, that seems like a lovely game! I'll try to get it running on Pandora and Pyra :D

[kas1e]

I don't remember if Pandora and Pyra little endian or big-endian, but for make this game to work there surely need some big-endian fixes (even if it was born on big-endian macs, it seems a little bit rewritten and not works as it on big-endian). I.e. game loads up, menu works, etc, but once you choose a level (at least on big endian), you do have :

CMR Fatal Alert: Skeleton file has wrong version #

And also:

ParseBG3DFile: FSRead failed

We think that first one happens because of that:

https://github.com/jorio/Pomme/blob/master/src/Utilities/structpack.h#L52 https://github.com/jorio/Pomme/blob/master/src/Utilities/structpack.h#L33

But not sure.. But looks like for real endian issues

[kas1e]

@ptitSeb Author add big-endian fixes as well, check this out how it looks like on my hardware:

https://www.youtube.com/watch?v=2TGcASKjyoo

Through we do have one small issue: all the powerups/bonuses in the levels do not visibly, but only their shadow (you can see it on video as well). Currently do not know if it issues with our drivers , or gl4es, or endian-issues-left.

[ptitSeb]

Looks very nice! I haven't built it for Pandora yet, it should be done today (I needed to update cmake first). Pandora is little endian, so if I don't see the bonus, I'll debug gl4es there.

[kas1e]

Yeah, looks quite good :) Btw we checked game on morphos (other ppc os, with their own drivers), and they do have bonuses/powerup visibly, so my bet it can be something on our side (our drivers or gl4es) and not in big-endian stuff in the game

[ptitSeb]

Ah ok. Still not ready to check on the Pandora, I need to rebuild cmake (I forgot ccmake, and cmake is such a beast to build!)

[ptitSeb]

I tested, and I see the upgrades on the track, so not a direct gl4es issue it seems.

[kas1e]

Damn.. They visibly together with shadow, etc ? If so .. what it can be ? I think about 2 possible moments: shaders which gl4es compile didn't works correctly on our side, or, some endian issues left (but then, developer from morphos (other os, ppc one too) says that on his drivers he see it too ..

[ptitSeb]

yep...

[kas1e]

Right, they visibly, but didn't they looks like some texture x2 or something ? (so to find out the difference between other textures/objects)

[ptitSeb]

The Pandora have a very limited hardware. Texture size is limited to 2048x2048 and the games needs bigger (I supposed all the bonus are in a 1 big atlas), so I used LIBGL_SHRINK=11 to shrink larger textures. I don't expect youto have any problem like that, as the radeon usualy have 16384x16384 texture size or something like that.

[kas1e]

What i mean maybe npot differences may act there somehow ? I will try to trace all the stuff firstly to see how it, maybe there some errors somewhere.

[ptitSeb]

So, I reproduce the issue with the missing bonus on the Pyra (I don't need LIBGL_SHRINK there). I'll check how to fix it.

[kas1e]

Oh cool ! Mean not endian issues ! Interesting what the differences between Pandora and Pyra there ..

[ptitSeb]

Ok, I think I have found the issue. Some buggy RGBA->5551 conversion (the alpha chanel was wrong)

[kas1e]

Yeah ! It works ! Wohoo !

Btw, you may also want to port OttoMattic from the same author:

https://github.com/jorio/OttoMatic/

See how good is it:

https://youtu.be/ZvhwfaYtiNE

(through currently too much blue in the settings and help menu, not sure if it gl4es issue or not fully done endian fixes)

[kas1e]

Btw, if you will port OttoMattic, author says that looks like multitextured animated models are shaded incorrectly. The main character, the brian alien, and the mantis are too bright in the main menu. They're supposed to look like this:

For me (if you see on video), there no solid coloring. I assume it can be because we do miss "shadows" support in GL4ES ? That how it looks like for me:

[ptitSeb]

Yeah, I'll port Otto Matic once I'm done with Cro-Mag Rally. And I'll check the self shadow issue then.

[kas1e]

By the way, did on Pandora / Pyra used the same pathes as on linux ? Or they also have something weird like we have work:games/aaa ?

We just found there issues with saving/loading preferences/scroreboard not from directory of the game, but instead in the volume's root directory.. I do trying to fix it with change in Pomme/src/Files/Files.cpp :

....
#ifdef _WIN32
        path = Pomme::Platform::Windows::GetPreferencesFolder();
#elif defined(__amigaos4__)
        const char *home = "PROGDIR:";
        path = fs::path(home);
#elif defined(__APPLE__)
....

But then it still use root volume, and not currentdir (which is PROGDIR:) for us.

Do you have any problems with on Pandora/Pyra ?

[ptitSeb]

Pandora and Pyra use linux regular path, I haven't noticed issue, but I have done very limited tests on my side.

[kas1e]

About shading issues we have in OttoMatic that what author says:

The three multitextured models in the main menu (robot, alien, mantis) have standard texture mapping with standard Gouraud shading + a sphere mapping effect with an extra texture to achieve a "shiny" look.

The sphere mapping looks fine (the alien looks shiny). However, the Gouraud shading is missing, so those models aren't affected by lighting.

Objects that are not multitextured are correctly Gouraud-shaded in your video: the humans, the clown, the planet's central sphere, etc.

This problem affects all multitextured objects in your video.

[ptitSeb]

Ok, that helps. probably a shader is not built correctly. And it renders fine with GLES1.1 backend. I'll do a capture and check what is going on tomorow or sunday.

[kas1e]

But it the same reproducable on ogles2 on your hardware too ? (just to be sure it's not shaders issues on our drivers)

[ptitSeb]

Yes, I don't see the gourau shading with GLESv2 backend on the Pandora.

[ptitSeb]

It should be fixed now. Now, if you have new issue, please open new ticets so this one can be closed.

[kas1e]

Yeah ! Fixed ! Thanks a bunch !:)