src/video_core/renderer_opengl/texture_filters/bicubic/bicubic.cpp:51:86: error: cannot initialize a parameter of type 'GLuint' (aka 'unsigned int') with an rvalue of type 'nullptr_t'
glFramebufferTexture2D(GL_DRAW_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, NULL, 0);
^~~~
src/video_core/renderer_opengl/texture_filters/xbrz/xbrz_freescale.cpp:95:86: error: cannot initialize a parameter of type 'GLuint' (aka 'unsigned int') with an rvalue of type 'nullptr_t'
glFramebufferTexture2D(GL_DRAW_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, NULL, 0);
^~~~
/usr/include/sys/_null.h:37:14: note: expanded from macro 'NULL'
#define NULL nullptr
^~~~~~~
The default is discrete_interval which has dynamic open-ness.
We only use right_open intervals anyway. In theory this could allow some compile-time optimizations.
* videocore/renderer_opengl/gl_rasterizer_cache: Move bits per pixel table out of function
GCC and MSVC copy the table at runtime with the old implementation, which is wasteful and prevents inlining. Unfortunately, static constexpr variables are not legal in constexpr functions, so the table has to be external.
Also replaced non-standard assert with DEBUG_ASSERT_MSG.
* fix case of table name in assert
* set table to private
This is based on what was done using additional layouts, but modified
to have a variable to control rotation and making it so Single Screen
Layout behaves like Upright Single would, and Default Layout behaves
like Upright Double would, when the new variable is used.
Large Layout and Side Layout currently ignore the new variable.
New variable still currently doesn't have a hotkey.
Previously we would first attempt to use any buffer that was free,
meaning whichever buffer has already been displayed. This has poor
interactions when the operating system throttles the update rate of the
window, so if there isn't any free buffers available, just reuse the
oldest frame instead.
While QOpenGLWidget sounds like a good idea, it has issues which are
harder to debug due to how Qt manages the context behind the scenes. We
could probably work around any of these issues over time, but its
probably easier to do it ourselves with a QWindow directly.
Plus using QWindow + createWindowContainer is the easiest to use
configuration for Qt + Vulkan so this is probably much better in the
long run.
