Legacy OpenGL code (glBegin/glEnd) on Switch

[dmitry.grigoryev]

Hello,

I'm trying to build an old game which is written using SDL and procedural OpenGL. I understand that switch-glad only supports OpenGL 4.3, without legacy APIs such as glBegin() / glEnd().

What options do I have, besides rewriting the game engine with VAOs/VBOs? Is there a reason why procedural OpenGL is not supported on Switch? Or is there a package I have missed which provides such support?

[fincs]

switch-mesa does support legacy OpenGL. The version of glad we package as switch-glad is only offered as courtesy so that most people don't need to do it on their own; but it is perfectly possible to generate a version of glad that loads an older version of OpenGL (select e.g. GL version 2.1 in Compatibility profile, and uncheck "Generate a loader" since that only works on Windows/Linux/macOS), and change the EGL initialization code likewise.

[dmitry.grigoryev]

Thank you, generating a custom GLAD solved the compilation problems. However, I'm still stuck with unsupported functions at runtime. I ran a few lines of OpenGL code with GL_DEBUG_OUTPUT enabled, and this is what I get:

Code: Select all

	glEnable(GL_TEXTURE_2D); //GL CALLBACK: type = GL_ERROR, severity = 37190, message = GL_INVALID_ENUM in glEnable(GL_TEXTURE_2D)
	glClearColor(0.0, 0.0, 0.0, 0.0);
	glClearDepth(1.0);	 //GL CALLBACK: type = GL_ERROR, severity = 37190, message = GL_INVALID_OPERATION in unsupported function called (unsupported extension or deprecated function?)
	glDisable(GL_CULL_FACE);
	glLoadIdentity();	 //GL CALLBACK: type = GL_ERROR, severity = 37190, message = GL_INVALID_OPERATION in unsupported function called (unsupported extension or deprecated function?)
	glFinish();

Now I'm left wondering whether GL_TEXTURE_2D, glClearDepth, glLoadIdentity etc. are unsupported, or perhaps I screwed up somewhere in my build. Is there a way to verify a function / feature is supported on Switch, preferably in bulk at compile time?

PS. I'm pretty sure I screwed up, because I overlooked your advice on EGL initialization settings. I'm still figuring out how to do it in my case. Currently I have:

Code: Select all

scr = SDL_CreateWindow(..., SDL_WINDOW_OPENGL | SDL_WINDOW_SHOWN | SDL_WINDOW_FULLSCREEN)
glc = SDL_GL_CreateContext(scr);

As such, I don't call eglCreateContext() so I have to find out where the call is made and how to modify the parameters.

[fincs]

Since you're using SDL and not EGL directly, that means you're locked out of using legacy GL APIs (SDL2 does not support creating legacy GL contexts as far as I can tell). You'll have to switch over to using EGL directly, unfortunately.

[dmitry.grigoryev]

Thanks, your suggestion worked just fine!
I'm still fighting some minor bugs, one of them seems to come from glRasterPos. I'm using GLAD for OpenGL 2.1 compatibility profile with all extensions, and have modified initEgl accordingly. Then I changed the EGL example to have only this GL code, which crashes.

Code: Select all

                initEgl(nwindowGetDefault());
                gladLoadGL();
		glClearColor(1,0,0,1);
		glClear(GL_COLOR_BUFFER_BIT);
		glRasterPos2i(0, 0);
                eglSwapBuffers(s_display, s_surface);
                // Wait for user input
                deinitEgl();

Removing glRasterPos2i(0, 0); heals the crash. Is glRasterPos problematic on the Switch, or am I doing something wrong?

[fincs]

glRasterPos2i is indeed a problematic function in legacy GL, since there is no hardware accelerated support for it in certain modern GPUs such as the one the Switch uses. Under normal circumstances a GL implementation has to fall back on software rendering, which is what upstream mesa implements. However, this software renderer is fairly costly in terms of code size and also defeats the purpose of providing a GPU driver library (not to mention it is very rarely used and since mesa is not optimized for static linking, *every* single homebrew application would need to pay the price), so it was disabled/removed in switch-mesa. Unfortunately we aren't able to offer an alternative that doesn't involve advising you to rewrite/adapt the code you're working with as to not rely on this feature.