Fix glow backend on mac
Without this change, the screen was blank when using the glow backend on macos.
Some debugging traced it down to the shader attribute configuration.
@dabreegster suggested trying to declare a newer version of the shader
language which supports the syntax for explicit attribute layout, which
fixed it.
Specifically, before this commit, this diff was interesting on macos:
diff --git a/ezgui/src/backend_glow.rs b/ezgui/src/backend_glow.rs
index 2046bccd..f834a4fa 100644
--- a/ezgui/src/backend_glow.rs
+++ b/ezgui/src/backend_glow.rs
@@ -244,31 +244,7 @@ impl PrerenderInnards {
glow::FLOAT,
false,
stride,
- // WTF: this offset seems correct, but on macos (OpenGL 4.1)
- // a blank screen is rendered.
- //
- // To debug, I've hardcoded a color assignment in the fragment shader.
- //
- // What's fascinating is that, even if we don't use this second "style"
- // input for anything, the mere act of passing it in with the expected
- // offset causes all the geometries to not be visible.
- //
- // That is:
- // - with a hardcoded color in the fragment shader
- // - set offset `0` here (which is surely wrong?)
- // - I can see the correct shapes with my hardcoded color
- //
- // - with a hardcoded color in the fragment shader
- // - set offset `2*size_of(f32)` here (which should be right)
- // - I'd expect to see the correct shapes with my hardcoded color
- // - But instead I can no longer see any shapes on the screen
- //
- // So it seems like something about setting the offset on this second attribute
- // configuration is corrupting our vertex data, even if we never read from that
- // attribute data.
- //
- // 2 * std::mem::size_of::<f32>() as i32,
- 0
+ 2 * std::mem::size_of::<f32>() as i32,
);
2020-08-19 18:30:20 +03:00
|
|
|
#version 410
|
2019-01-23 01:34:11 +03:00
|
|
|
|
2019-01-23 04:17:14 +03:00
|
|
|
// (x offset, y offset, zoom)
|
|
|
|
uniform vec3 transform;
|
2020-02-07 22:20:11 +03:00
|
|
|
// (window width, window height, z value)
|
2019-05-13 02:40:52 +03:00
|
|
|
uniform vec3 window;
|
2020-09-18 04:38:55 +03:00
|
|
|
// textures grid
|
|
|
|
uniform sampler2DArray textures;
|
2019-01-23 01:34:11 +03:00
|
|
|
|
2020-09-21 21:54:39 +03:00
|
|
|
layout (location = 0) in vec3 position;
|
2020-09-18 04:38:55 +03:00
|
|
|
layout (location = 1) in vec4 color;
|
|
|
|
layout (location = 2) in float texture_index;
|
2019-01-23 01:34:11 +03:00
|
|
|
|
2020-09-18 04:38:55 +03:00
|
|
|
out vec4 fs_color;
|
|
|
|
out vec3 fs_texture_coord;
|
2019-01-23 01:34:11 +03:00
|
|
|
void main() {
|
2020-09-18 04:38:55 +03:00
|
|
|
fs_color = color;
|
|
|
|
|
|
|
|
float zoom = transform[2];
|
2019-01-23 01:34:11 +03:00
|
|
|
|
2019-01-23 04:17:14 +03:00
|
|
|
// This is map_to_screen
|
2020-09-18 04:38:55 +03:00
|
|
|
float screen_x = (position[0] * zoom) - transform[0];
|
|
|
|
float screen_y = (position[1] * zoom) - transform[1];
|
|
|
|
|
Fix glow backend on mac
Without this change, the screen was blank when using the glow backend on macos.
Some debugging traced it down to the shader attribute configuration.
@dabreegster suggested trying to declare a newer version of the shader
language which supports the syntax for explicit attribute layout, which
fixed it.
Specifically, before this commit, this diff was interesting on macos:
diff --git a/ezgui/src/backend_glow.rs b/ezgui/src/backend_glow.rs
index 2046bccd..f834a4fa 100644
--- a/ezgui/src/backend_glow.rs
+++ b/ezgui/src/backend_glow.rs
@@ -244,31 +244,7 @@ impl PrerenderInnards {
glow::FLOAT,
false,
stride,
- // WTF: this offset seems correct, but on macos (OpenGL 4.1)
- // a blank screen is rendered.
- //
- // To debug, I've hardcoded a color assignment in the fragment shader.
- //
- // What's fascinating is that, even if we don't use this second "style"
- // input for anything, the mere act of passing it in with the expected
- // offset causes all the geometries to not be visible.
- //
- // That is:
- // - with a hardcoded color in the fragment shader
- // - set offset `0` here (which is surely wrong?)
- // - I can see the correct shapes with my hardcoded color
- //
- // - with a hardcoded color in the fragment shader
- // - set offset `2*size_of(f32)` here (which should be right)
- // - I'd expect to see the correct shapes with my hardcoded color
- // - But instead I can no longer see any shapes on the screen
- //
- // So it seems like something about setting the offset on this second attribute
- // configuration is corrupting our vertex data, even if we never read from that
- // attribute data.
- //
- // 2 * std::mem::size_of::<f32>() as i32,
- 0
+ 2 * std::mem::size_of::<f32>() as i32,
);
2020-08-19 18:30:20 +03:00
|
|
|
// Translate that to normalized device coordinates (NDC)
|
2019-03-18 22:20:40 +03:00
|
|
|
float x = (screen_x / window[0] * 2.0) - 1.0;
|
|
|
|
float y = (screen_y / window[1] * 2.0) - 1.0;
|
2020-09-21 21:54:39 +03:00
|
|
|
float z = position[2] + window[2];
|
2019-08-15 02:19:54 +03:00
|
|
|
|
2019-01-23 04:48:49 +03:00
|
|
|
// Note the y inversion
|
2020-09-21 21:54:39 +03:00
|
|
|
gl_Position = vec4(x, -y, z, 1.0);
|
2020-09-18 04:38:55 +03:00
|
|
|
|
|
|
|
// An arbitrary factor to scale the textures we're using.
|
|
|
|
//
|
|
|
|
// The proper value depends on the design of the particular sprite sheet.
|
|
|
|
// If we want to support multiple sprite sheets, this could become a
|
|
|
|
// uniform, or a vertex attribute depending on how we expect it to change.
|
|
|
|
float texture_scale = 16.0;
|
|
|
|
|
|
|
|
float t_x = ((position[0] * zoom)) / texture_scale / zoom;
|
|
|
|
float t_y = ((position[1] * zoom)) / texture_scale / zoom;
|
|
|
|
fs_texture_coord = vec3(vec2(t_x, t_y), texture_index);
|
2019-01-23 01:34:11 +03:00
|
|
|
}
|