Drawing triangle doesn't work: I just see a black screen and my mouse
up vote
1
down vote
favorite
I'm using GLEW for modern OpenGL functions and GLFW for the window. I'm trying to draw a triangle but something is wrong it compile and runs but doesn't draw the triangle, I just see a black screen and my mouse.
Here is my code:
#include <iostream>
#include <stdio.h>
#include <stdlib.h>
#include <glew.h>
#include <GLFWglfw3.h>
#include <glmglm.hpp>
const GLchar* vertexSource =
"#version 150 coren"
"in ver2 position;"
"void main(){"
" gl_Position = vec4(position, 0.0, 1.0);"
"}";
const GLchar* fragmentSource =
"#version 150 coren"
"out vec4 outColor;"
"void main(){"
" outColor = vec4(1.0, 1.0, 1.0, 1.0);"
"}";
int main(){
//GLFW init:
if (!glfwInit()){
fprintf(stderr, "Failed to init GLFW");
glfwTerminate();
}
//Hints:
glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3);
glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 2);
glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
glfwWindowHint(GLFW_OPENGL_FORWARD_COMPAT, GL_TRUE);
glfwWindowHint(GLFW_RESIZABLE, GL_FALSE);
//Creating window:
GLFWwindow* window = glfwCreateWindow(800, 600, "Engine", glfwGetPrimaryMonitor(), nullptr);
glfwMakeContextCurrent(window);
//Glew initialize:
glewExperimental = GL_TRUE;
glewInit();
//Create vertex array object:
GLuint vao;
glGenVertexArrays(1, &vao);
glBindVertexArray(vao);
//Create vertex buffer object:
GLuint vbo;
glGenBuffers(1, &vbo);
//Our triangle data:
GLfloat vertices = {
0.0f, 0.5f, //Vertex 1 (X, Y)
0.5f, -0.5f, //Vertex 2 (X, Y)
-0.5f, -0.5f //Vertex 3 (X, Y)
};
glBindBuffer(GL_ARRAY_BUFFER, vbo);
glBufferData(GL_ARRAY_BUFFER, sizeof(vertices), vertices, GL_STATIC_DRAW);
//Create and compile the vertex shader:
GLuint vertexShader = glCreateShader(GL_VERTEX_SHADER);
glShaderSource(vertexShader, 1, &vertexSource, NULL);
glCompileShader(vertexShader);
//Create and compile the fragment shader:
GLuint fragmentShader = glCreateShader(GL_FRAGMENT_SHADER);
glShaderSource(fragmentShader, 1, &fragmentSource, NULL);
glCompileShader(fragmentShader);
//Creating shaders program:
GLuint shaderProgram = glCreateProgram();
glAttachShader(shaderProgram, vertexShader);
glAttachShader(shaderProgram, fragmentShader);
glBindFragDataLocation(shaderProgram, 0, "outColor");
glLinkProgram(shaderProgram);
glUseProgram(shaderProgram);
GLint posAttrib = glGetAttribLocation(shaderProgram, "position");
glEnableVertexAttribArray(posAttrib);
glVertexAttribPointer(posAttrib, 2, GL_FLOAT, GL_FALSE, 0, 0);
//The loop:
while (!glfwWindowShouldClose(window)){
//Escape key:
if (glfwGetKey(window, GLFW_KEY_ESCAPE) == GLFW_PRESS){
glfwSetWindowShouldClose(window, GL_TRUE);
}
glClearColor(0.0f, 0.0f, 0.0f, 1.0f);
glClear(GL_COLOR_BUFFER_BIT);
glDrawArrays(GL_TRIANGLES, 0, 3);
glfwSwapBuffers(window);
glfwPollEvents();
}
return 0;
}
c++ opengl glfw
add a comment |
up vote
1
down vote
favorite
I'm using GLEW for modern OpenGL functions and GLFW for the window. I'm trying to draw a triangle but something is wrong it compile and runs but doesn't draw the triangle, I just see a black screen and my mouse.
Here is my code:
#include <iostream>
#include <stdio.h>
#include <stdlib.h>
#include <glew.h>
#include <GLFWglfw3.h>
#include <glmglm.hpp>
const GLchar* vertexSource =
"#version 150 coren"
"in ver2 position;"
"void main(){"
" gl_Position = vec4(position, 0.0, 1.0);"
"}";
const GLchar* fragmentSource =
"#version 150 coren"
"out vec4 outColor;"
"void main(){"
" outColor = vec4(1.0, 1.0, 1.0, 1.0);"
"}";
int main(){
//GLFW init:
if (!glfwInit()){
fprintf(stderr, "Failed to init GLFW");
glfwTerminate();
}
//Hints:
glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3);
glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 2);
glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
glfwWindowHint(GLFW_OPENGL_FORWARD_COMPAT, GL_TRUE);
glfwWindowHint(GLFW_RESIZABLE, GL_FALSE);
//Creating window:
GLFWwindow* window = glfwCreateWindow(800, 600, "Engine", glfwGetPrimaryMonitor(), nullptr);
glfwMakeContextCurrent(window);
//Glew initialize:
glewExperimental = GL_TRUE;
glewInit();
//Create vertex array object:
GLuint vao;
glGenVertexArrays(1, &vao);
glBindVertexArray(vao);
//Create vertex buffer object:
GLuint vbo;
glGenBuffers(1, &vbo);
//Our triangle data:
GLfloat vertices = {
0.0f, 0.5f, //Vertex 1 (X, Y)
0.5f, -0.5f, //Vertex 2 (X, Y)
-0.5f, -0.5f //Vertex 3 (X, Y)
};
glBindBuffer(GL_ARRAY_BUFFER, vbo);
glBufferData(GL_ARRAY_BUFFER, sizeof(vertices), vertices, GL_STATIC_DRAW);
//Create and compile the vertex shader:
GLuint vertexShader = glCreateShader(GL_VERTEX_SHADER);
glShaderSource(vertexShader, 1, &vertexSource, NULL);
glCompileShader(vertexShader);
//Create and compile the fragment shader:
GLuint fragmentShader = glCreateShader(GL_FRAGMENT_SHADER);
glShaderSource(fragmentShader, 1, &fragmentSource, NULL);
glCompileShader(fragmentShader);
//Creating shaders program:
GLuint shaderProgram = glCreateProgram();
glAttachShader(shaderProgram, vertexShader);
glAttachShader(shaderProgram, fragmentShader);
glBindFragDataLocation(shaderProgram, 0, "outColor");
glLinkProgram(shaderProgram);
glUseProgram(shaderProgram);
GLint posAttrib = glGetAttribLocation(shaderProgram, "position");
glEnableVertexAttribArray(posAttrib);
glVertexAttribPointer(posAttrib, 2, GL_FLOAT, GL_FALSE, 0, 0);
//The loop:
while (!glfwWindowShouldClose(window)){
//Escape key:
if (glfwGetKey(window, GLFW_KEY_ESCAPE) == GLFW_PRESS){
glfwSetWindowShouldClose(window, GL_TRUE);
}
glClearColor(0.0f, 0.0f, 0.0f, 1.0f);
glClear(GL_COLOR_BUFFER_BIT);
glDrawArrays(GL_TRIANGLES, 0, 3);
glfwSwapBuffers(window);
glfwPollEvents();
}
return 0;
}
c++ opengl glfw
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I'm using GLEW for modern OpenGL functions and GLFW for the window. I'm trying to draw a triangle but something is wrong it compile and runs but doesn't draw the triangle, I just see a black screen and my mouse.
Here is my code:
#include <iostream>
#include <stdio.h>
#include <stdlib.h>
#include <glew.h>
#include <GLFWglfw3.h>
#include <glmglm.hpp>
const GLchar* vertexSource =
"#version 150 coren"
"in ver2 position;"
"void main(){"
" gl_Position = vec4(position, 0.0, 1.0);"
"}";
const GLchar* fragmentSource =
"#version 150 coren"
"out vec4 outColor;"
"void main(){"
" outColor = vec4(1.0, 1.0, 1.0, 1.0);"
"}";
int main(){
//GLFW init:
if (!glfwInit()){
fprintf(stderr, "Failed to init GLFW");
glfwTerminate();
}
//Hints:
glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3);
glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 2);
glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
glfwWindowHint(GLFW_OPENGL_FORWARD_COMPAT, GL_TRUE);
glfwWindowHint(GLFW_RESIZABLE, GL_FALSE);
//Creating window:
GLFWwindow* window = glfwCreateWindow(800, 600, "Engine", glfwGetPrimaryMonitor(), nullptr);
glfwMakeContextCurrent(window);
//Glew initialize:
glewExperimental = GL_TRUE;
glewInit();
//Create vertex array object:
GLuint vao;
glGenVertexArrays(1, &vao);
glBindVertexArray(vao);
//Create vertex buffer object:
GLuint vbo;
glGenBuffers(1, &vbo);
//Our triangle data:
GLfloat vertices = {
0.0f, 0.5f, //Vertex 1 (X, Y)
0.5f, -0.5f, //Vertex 2 (X, Y)
-0.5f, -0.5f //Vertex 3 (X, Y)
};
glBindBuffer(GL_ARRAY_BUFFER, vbo);
glBufferData(GL_ARRAY_BUFFER, sizeof(vertices), vertices, GL_STATIC_DRAW);
//Create and compile the vertex shader:
GLuint vertexShader = glCreateShader(GL_VERTEX_SHADER);
glShaderSource(vertexShader, 1, &vertexSource, NULL);
glCompileShader(vertexShader);
//Create and compile the fragment shader:
GLuint fragmentShader = glCreateShader(GL_FRAGMENT_SHADER);
glShaderSource(fragmentShader, 1, &fragmentSource, NULL);
glCompileShader(fragmentShader);
//Creating shaders program:
GLuint shaderProgram = glCreateProgram();
glAttachShader(shaderProgram, vertexShader);
glAttachShader(shaderProgram, fragmentShader);
glBindFragDataLocation(shaderProgram, 0, "outColor");
glLinkProgram(shaderProgram);
glUseProgram(shaderProgram);
GLint posAttrib = glGetAttribLocation(shaderProgram, "position");
glEnableVertexAttribArray(posAttrib);
glVertexAttribPointer(posAttrib, 2, GL_FLOAT, GL_FALSE, 0, 0);
//The loop:
while (!glfwWindowShouldClose(window)){
//Escape key:
if (glfwGetKey(window, GLFW_KEY_ESCAPE) == GLFW_PRESS){
glfwSetWindowShouldClose(window, GL_TRUE);
}
glClearColor(0.0f, 0.0f, 0.0f, 1.0f);
glClear(GL_COLOR_BUFFER_BIT);
glDrawArrays(GL_TRIANGLES, 0, 3);
glfwSwapBuffers(window);
glfwPollEvents();
}
return 0;
}
c++ opengl glfw
I'm using GLEW for modern OpenGL functions and GLFW for the window. I'm trying to draw a triangle but something is wrong it compile and runs but doesn't draw the triangle, I just see a black screen and my mouse.
Here is my code:
#include <iostream>
#include <stdio.h>
#include <stdlib.h>
#include <glew.h>
#include <GLFWglfw3.h>
#include <glmglm.hpp>
const GLchar* vertexSource =
"#version 150 coren"
"in ver2 position;"
"void main(){"
" gl_Position = vec4(position, 0.0, 1.0);"
"}";
const GLchar* fragmentSource =
"#version 150 coren"
"out vec4 outColor;"
"void main(){"
" outColor = vec4(1.0, 1.0, 1.0, 1.0);"
"}";
int main(){
//GLFW init:
if (!glfwInit()){
fprintf(stderr, "Failed to init GLFW");
glfwTerminate();
}
//Hints:
glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3);
glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 2);
glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
glfwWindowHint(GLFW_OPENGL_FORWARD_COMPAT, GL_TRUE);
glfwWindowHint(GLFW_RESIZABLE, GL_FALSE);
//Creating window:
GLFWwindow* window = glfwCreateWindow(800, 600, "Engine", glfwGetPrimaryMonitor(), nullptr);
glfwMakeContextCurrent(window);
//Glew initialize:
glewExperimental = GL_TRUE;
glewInit();
//Create vertex array object:
GLuint vao;
glGenVertexArrays(1, &vao);
glBindVertexArray(vao);
//Create vertex buffer object:
GLuint vbo;
glGenBuffers(1, &vbo);
//Our triangle data:
GLfloat vertices = {
0.0f, 0.5f, //Vertex 1 (X, Y)
0.5f, -0.5f, //Vertex 2 (X, Y)
-0.5f, -0.5f //Vertex 3 (X, Y)
};
glBindBuffer(GL_ARRAY_BUFFER, vbo);
glBufferData(GL_ARRAY_BUFFER, sizeof(vertices), vertices, GL_STATIC_DRAW);
//Create and compile the vertex shader:
GLuint vertexShader = glCreateShader(GL_VERTEX_SHADER);
glShaderSource(vertexShader, 1, &vertexSource, NULL);
glCompileShader(vertexShader);
//Create and compile the fragment shader:
GLuint fragmentShader = glCreateShader(GL_FRAGMENT_SHADER);
glShaderSource(fragmentShader, 1, &fragmentSource, NULL);
glCompileShader(fragmentShader);
//Creating shaders program:
GLuint shaderProgram = glCreateProgram();
glAttachShader(shaderProgram, vertexShader);
glAttachShader(shaderProgram, fragmentShader);
glBindFragDataLocation(shaderProgram, 0, "outColor");
glLinkProgram(shaderProgram);
glUseProgram(shaderProgram);
GLint posAttrib = glGetAttribLocation(shaderProgram, "position");
glEnableVertexAttribArray(posAttrib);
glVertexAttribPointer(posAttrib, 2, GL_FLOAT, GL_FALSE, 0, 0);
//The loop:
while (!glfwWindowShouldClose(window)){
//Escape key:
if (glfwGetKey(window, GLFW_KEY_ESCAPE) == GLFW_PRESS){
glfwSetWindowShouldClose(window, GL_TRUE);
}
glClearColor(0.0f, 0.0f, 0.0f, 1.0f);
glClear(GL_COLOR_BUFFER_BIT);
glDrawArrays(GL_TRIANGLES, 0, 3);
glfwSwapBuffers(window);
glfwPollEvents();
}
return 0;
}
c++ opengl glfw
c++ opengl glfw
edited Nov 8 at 15:12
genpfault
41.3k95097
41.3k95097
asked May 23 '14 at 15:26
Casper
204
204
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
up vote
3
down vote
accepted
"in ver2 position;"
^^^^
What's a ver2
? I doubt your GLSL compiler knows either.
Try vec2
and checking your shader compilation/link status/logs:
struct Program
{
static GLuint Load( const char* vert, const char* geom, const char* frag )
{
GLuint prog = glCreateProgram();
if( vert ) AttachShader( prog, GL_VERTEX_SHADER, vert );
if( geom ) AttachShader( prog, GL_GEOMETRY_SHADER, geom );
if( frag ) AttachShader( prog, GL_FRAGMENT_SHADER, frag );
glLinkProgram( prog );
CheckStatus( prog );
return prog;
}
private:
static void CheckStatus( GLuint obj )
{
GLint status = GL_FALSE;
if( glIsShader(obj) ) glGetShaderiv( obj, GL_COMPILE_STATUS, &status );
if( glIsProgram(obj) ) glGetProgramiv( obj, GL_LINK_STATUS, &status );
if( status == GL_TRUE ) return;
GLchar log[ 1 << 15 ] = { 0 };
if( glIsShader(obj) ) glGetShaderInfoLog( obj, sizeof(log), NULL, log );
if( glIsProgram(obj) ) glGetProgramInfoLog( obj, sizeof(log), NULL, log );
std::cerr << log << std::endl;
exit( -1 );
}
static void AttachShader( GLuint program, GLenum type, const char* src )
{
GLuint shader = glCreateShader( type );
glShaderSource( shader, 1, &src, NULL );
glCompileShader( shader );
CheckStatus( shader );
glAttachShader( program, shader );
glDeleteShader( shader );
}
};
Wow I can't belive this was the problem.. ty.
– Casper
May 23 '14 at 15:40
add a comment |
up vote
0
down vote
you don't need to use glBindFragDataLocation
, instead write to gl_FragColor
in the fragment shader:
const GLchar* fragmentSource =
"#version 150 coren"
"void main(){"
" gl_FragColor = vec4(1.0, 1.0, 1.0, 1.0);"
"}";
otherwise you need to specify which buffer it is written to with glDrawBuffers
The poster is using the core profile, wheregl_FragColor
is deprecated. But theglBindFragDataLocation
call isn't needed anyway. If a fragment shader has only oneout
, it's automatically written to the first draw buffer (which by default isGL_BACK
for the default framebuffer, andGL_COLOR_ATTACHMENT0
for FBOs).
– Reto Koradi
May 24 '14 at 4:52
@RetoKoradi: Actually, I never could find such a guarantee in the spec. All the spec says is that the GL will automatically assign any outputs where the location is not manuyally assigned to some unused color number. Every real-world implementation starts assignment with 0, for obvious reasons, but relying on that is still undefined behavior as far as the spec goes.
– derhass
May 24 '14 at 16:00
@derhass: It's specified. GLSL 4.4 spec: "If an output variable with no location or index assigned in the shader text has a location specified through the OpenGL API, the API-assigned location will be used. Otherwise, such variables will be assigned a location by the linker. All such assignments will have a color index of zero." ES 3.0 GLSLS spec: "If there is only a single output, the location does not need to be specified, in which case it defaults to zero."
– Reto Koradi
May 24 '14 at 16:32
@RetoKoradi: actually, it is not. I made the same mistake by myself earlier: there is a difference between the color number, and the color index. The color number is the relevant part here. The index is just for multi-input blending. Note that it would also be weird if the spec would require that all of the outputs (if more than one is used) would be bound to the same number 0... The ES 3.0 spec is a different thing, though.
– derhass
May 24 '14 at 16:40
@derhass: Ok, yes, I see what you're saying. It's indeed not explicitly specified that the linker would assign the locations starting at 0. There's a lot of software that would break if a driver didn't handle it that way, but you're theoretically right. The ES reference matters because they try very hard to keep the ES specs to be a subset of full OpenGL. So if behavior is guaranteed in ES, but not in OpenGL, that would be very undesirable.
– Reto Koradi
May 24 '14 at 19:47
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
accepted
"in ver2 position;"
^^^^
What's a ver2
? I doubt your GLSL compiler knows either.
Try vec2
and checking your shader compilation/link status/logs:
struct Program
{
static GLuint Load( const char* vert, const char* geom, const char* frag )
{
GLuint prog = glCreateProgram();
if( vert ) AttachShader( prog, GL_VERTEX_SHADER, vert );
if( geom ) AttachShader( prog, GL_GEOMETRY_SHADER, geom );
if( frag ) AttachShader( prog, GL_FRAGMENT_SHADER, frag );
glLinkProgram( prog );
CheckStatus( prog );
return prog;
}
private:
static void CheckStatus( GLuint obj )
{
GLint status = GL_FALSE;
if( glIsShader(obj) ) glGetShaderiv( obj, GL_COMPILE_STATUS, &status );
if( glIsProgram(obj) ) glGetProgramiv( obj, GL_LINK_STATUS, &status );
if( status == GL_TRUE ) return;
GLchar log[ 1 << 15 ] = { 0 };
if( glIsShader(obj) ) glGetShaderInfoLog( obj, sizeof(log), NULL, log );
if( glIsProgram(obj) ) glGetProgramInfoLog( obj, sizeof(log), NULL, log );
std::cerr << log << std::endl;
exit( -1 );
}
static void AttachShader( GLuint program, GLenum type, const char* src )
{
GLuint shader = glCreateShader( type );
glShaderSource( shader, 1, &src, NULL );
glCompileShader( shader );
CheckStatus( shader );
glAttachShader( program, shader );
glDeleteShader( shader );
}
};
Wow I can't belive this was the problem.. ty.
– Casper
May 23 '14 at 15:40
add a comment |
up vote
3
down vote
accepted
"in ver2 position;"
^^^^
What's a ver2
? I doubt your GLSL compiler knows either.
Try vec2
and checking your shader compilation/link status/logs:
struct Program
{
static GLuint Load( const char* vert, const char* geom, const char* frag )
{
GLuint prog = glCreateProgram();
if( vert ) AttachShader( prog, GL_VERTEX_SHADER, vert );
if( geom ) AttachShader( prog, GL_GEOMETRY_SHADER, geom );
if( frag ) AttachShader( prog, GL_FRAGMENT_SHADER, frag );
glLinkProgram( prog );
CheckStatus( prog );
return prog;
}
private:
static void CheckStatus( GLuint obj )
{
GLint status = GL_FALSE;
if( glIsShader(obj) ) glGetShaderiv( obj, GL_COMPILE_STATUS, &status );
if( glIsProgram(obj) ) glGetProgramiv( obj, GL_LINK_STATUS, &status );
if( status == GL_TRUE ) return;
GLchar log[ 1 << 15 ] = { 0 };
if( glIsShader(obj) ) glGetShaderInfoLog( obj, sizeof(log), NULL, log );
if( glIsProgram(obj) ) glGetProgramInfoLog( obj, sizeof(log), NULL, log );
std::cerr << log << std::endl;
exit( -1 );
}
static void AttachShader( GLuint program, GLenum type, const char* src )
{
GLuint shader = glCreateShader( type );
glShaderSource( shader, 1, &src, NULL );
glCompileShader( shader );
CheckStatus( shader );
glAttachShader( program, shader );
glDeleteShader( shader );
}
};
Wow I can't belive this was the problem.. ty.
– Casper
May 23 '14 at 15:40
add a comment |
up vote
3
down vote
accepted
up vote
3
down vote
accepted
"in ver2 position;"
^^^^
What's a ver2
? I doubt your GLSL compiler knows either.
Try vec2
and checking your shader compilation/link status/logs:
struct Program
{
static GLuint Load( const char* vert, const char* geom, const char* frag )
{
GLuint prog = glCreateProgram();
if( vert ) AttachShader( prog, GL_VERTEX_SHADER, vert );
if( geom ) AttachShader( prog, GL_GEOMETRY_SHADER, geom );
if( frag ) AttachShader( prog, GL_FRAGMENT_SHADER, frag );
glLinkProgram( prog );
CheckStatus( prog );
return prog;
}
private:
static void CheckStatus( GLuint obj )
{
GLint status = GL_FALSE;
if( glIsShader(obj) ) glGetShaderiv( obj, GL_COMPILE_STATUS, &status );
if( glIsProgram(obj) ) glGetProgramiv( obj, GL_LINK_STATUS, &status );
if( status == GL_TRUE ) return;
GLchar log[ 1 << 15 ] = { 0 };
if( glIsShader(obj) ) glGetShaderInfoLog( obj, sizeof(log), NULL, log );
if( glIsProgram(obj) ) glGetProgramInfoLog( obj, sizeof(log), NULL, log );
std::cerr << log << std::endl;
exit( -1 );
}
static void AttachShader( GLuint program, GLenum type, const char* src )
{
GLuint shader = glCreateShader( type );
glShaderSource( shader, 1, &src, NULL );
glCompileShader( shader );
CheckStatus( shader );
glAttachShader( program, shader );
glDeleteShader( shader );
}
};
"in ver2 position;"
^^^^
What's a ver2
? I doubt your GLSL compiler knows either.
Try vec2
and checking your shader compilation/link status/logs:
struct Program
{
static GLuint Load( const char* vert, const char* geom, const char* frag )
{
GLuint prog = glCreateProgram();
if( vert ) AttachShader( prog, GL_VERTEX_SHADER, vert );
if( geom ) AttachShader( prog, GL_GEOMETRY_SHADER, geom );
if( frag ) AttachShader( prog, GL_FRAGMENT_SHADER, frag );
glLinkProgram( prog );
CheckStatus( prog );
return prog;
}
private:
static void CheckStatus( GLuint obj )
{
GLint status = GL_FALSE;
if( glIsShader(obj) ) glGetShaderiv( obj, GL_COMPILE_STATUS, &status );
if( glIsProgram(obj) ) glGetProgramiv( obj, GL_LINK_STATUS, &status );
if( status == GL_TRUE ) return;
GLchar log[ 1 << 15 ] = { 0 };
if( glIsShader(obj) ) glGetShaderInfoLog( obj, sizeof(log), NULL, log );
if( glIsProgram(obj) ) glGetProgramInfoLog( obj, sizeof(log), NULL, log );
std::cerr << log << std::endl;
exit( -1 );
}
static void AttachShader( GLuint program, GLenum type, const char* src )
{
GLuint shader = glCreateShader( type );
glShaderSource( shader, 1, &src, NULL );
glCompileShader( shader );
CheckStatus( shader );
glAttachShader( program, shader );
glDeleteShader( shader );
}
};
edited May 23 '14 at 15:44
answered May 23 '14 at 15:39
genpfault
41.3k95097
41.3k95097
Wow I can't belive this was the problem.. ty.
– Casper
May 23 '14 at 15:40
add a comment |
Wow I can't belive this was the problem.. ty.
– Casper
May 23 '14 at 15:40
Wow I can't belive this was the problem.. ty.
– Casper
May 23 '14 at 15:40
Wow I can't belive this was the problem.. ty.
– Casper
May 23 '14 at 15:40
add a comment |
up vote
0
down vote
you don't need to use glBindFragDataLocation
, instead write to gl_FragColor
in the fragment shader:
const GLchar* fragmentSource =
"#version 150 coren"
"void main(){"
" gl_FragColor = vec4(1.0, 1.0, 1.0, 1.0);"
"}";
otherwise you need to specify which buffer it is written to with glDrawBuffers
The poster is using the core profile, wheregl_FragColor
is deprecated. But theglBindFragDataLocation
call isn't needed anyway. If a fragment shader has only oneout
, it's automatically written to the first draw buffer (which by default isGL_BACK
for the default framebuffer, andGL_COLOR_ATTACHMENT0
for FBOs).
– Reto Koradi
May 24 '14 at 4:52
@RetoKoradi: Actually, I never could find such a guarantee in the spec. All the spec says is that the GL will automatically assign any outputs where the location is not manuyally assigned to some unused color number. Every real-world implementation starts assignment with 0, for obvious reasons, but relying on that is still undefined behavior as far as the spec goes.
– derhass
May 24 '14 at 16:00
@derhass: It's specified. GLSL 4.4 spec: "If an output variable with no location or index assigned in the shader text has a location specified through the OpenGL API, the API-assigned location will be used. Otherwise, such variables will be assigned a location by the linker. All such assignments will have a color index of zero." ES 3.0 GLSLS spec: "If there is only a single output, the location does not need to be specified, in which case it defaults to zero."
– Reto Koradi
May 24 '14 at 16:32
@RetoKoradi: actually, it is not. I made the same mistake by myself earlier: there is a difference between the color number, and the color index. The color number is the relevant part here. The index is just for multi-input blending. Note that it would also be weird if the spec would require that all of the outputs (if more than one is used) would be bound to the same number 0... The ES 3.0 spec is a different thing, though.
– derhass
May 24 '14 at 16:40
@derhass: Ok, yes, I see what you're saying. It's indeed not explicitly specified that the linker would assign the locations starting at 0. There's a lot of software that would break if a driver didn't handle it that way, but you're theoretically right. The ES reference matters because they try very hard to keep the ES specs to be a subset of full OpenGL. So if behavior is guaranteed in ES, but not in OpenGL, that would be very undesirable.
– Reto Koradi
May 24 '14 at 19:47
add a comment |
up vote
0
down vote
you don't need to use glBindFragDataLocation
, instead write to gl_FragColor
in the fragment shader:
const GLchar* fragmentSource =
"#version 150 coren"
"void main(){"
" gl_FragColor = vec4(1.0, 1.0, 1.0, 1.0);"
"}";
otherwise you need to specify which buffer it is written to with glDrawBuffers
The poster is using the core profile, wheregl_FragColor
is deprecated. But theglBindFragDataLocation
call isn't needed anyway. If a fragment shader has only oneout
, it's automatically written to the first draw buffer (which by default isGL_BACK
for the default framebuffer, andGL_COLOR_ATTACHMENT0
for FBOs).
– Reto Koradi
May 24 '14 at 4:52
@RetoKoradi: Actually, I never could find such a guarantee in the spec. All the spec says is that the GL will automatically assign any outputs where the location is not manuyally assigned to some unused color number. Every real-world implementation starts assignment with 0, for obvious reasons, but relying on that is still undefined behavior as far as the spec goes.
– derhass
May 24 '14 at 16:00
@derhass: It's specified. GLSL 4.4 spec: "If an output variable with no location or index assigned in the shader text has a location specified through the OpenGL API, the API-assigned location will be used. Otherwise, such variables will be assigned a location by the linker. All such assignments will have a color index of zero." ES 3.0 GLSLS spec: "If there is only a single output, the location does not need to be specified, in which case it defaults to zero."
– Reto Koradi
May 24 '14 at 16:32
@RetoKoradi: actually, it is not. I made the same mistake by myself earlier: there is a difference between the color number, and the color index. The color number is the relevant part here. The index is just for multi-input blending. Note that it would also be weird if the spec would require that all of the outputs (if more than one is used) would be bound to the same number 0... The ES 3.0 spec is a different thing, though.
– derhass
May 24 '14 at 16:40
@derhass: Ok, yes, I see what you're saying. It's indeed not explicitly specified that the linker would assign the locations starting at 0. There's a lot of software that would break if a driver didn't handle it that way, but you're theoretically right. The ES reference matters because they try very hard to keep the ES specs to be a subset of full OpenGL. So if behavior is guaranteed in ES, but not in OpenGL, that would be very undesirable.
– Reto Koradi
May 24 '14 at 19:47
add a comment |
up vote
0
down vote
up vote
0
down vote
you don't need to use glBindFragDataLocation
, instead write to gl_FragColor
in the fragment shader:
const GLchar* fragmentSource =
"#version 150 coren"
"void main(){"
" gl_FragColor = vec4(1.0, 1.0, 1.0, 1.0);"
"}";
otherwise you need to specify which buffer it is written to with glDrawBuffers
you don't need to use glBindFragDataLocation
, instead write to gl_FragColor
in the fragment shader:
const GLchar* fragmentSource =
"#version 150 coren"
"void main(){"
" gl_FragColor = vec4(1.0, 1.0, 1.0, 1.0);"
"}";
otherwise you need to specify which buffer it is written to with glDrawBuffers
answered May 23 '14 at 15:37
ratchet freak
39.8k44293
39.8k44293
The poster is using the core profile, wheregl_FragColor
is deprecated. But theglBindFragDataLocation
call isn't needed anyway. If a fragment shader has only oneout
, it's automatically written to the first draw buffer (which by default isGL_BACK
for the default framebuffer, andGL_COLOR_ATTACHMENT0
for FBOs).
– Reto Koradi
May 24 '14 at 4:52
@RetoKoradi: Actually, I never could find such a guarantee in the spec. All the spec says is that the GL will automatically assign any outputs where the location is not manuyally assigned to some unused color number. Every real-world implementation starts assignment with 0, for obvious reasons, but relying on that is still undefined behavior as far as the spec goes.
– derhass
May 24 '14 at 16:00
@derhass: It's specified. GLSL 4.4 spec: "If an output variable with no location or index assigned in the shader text has a location specified through the OpenGL API, the API-assigned location will be used. Otherwise, such variables will be assigned a location by the linker. All such assignments will have a color index of zero." ES 3.0 GLSLS spec: "If there is only a single output, the location does not need to be specified, in which case it defaults to zero."
– Reto Koradi
May 24 '14 at 16:32
@RetoKoradi: actually, it is not. I made the same mistake by myself earlier: there is a difference between the color number, and the color index. The color number is the relevant part here. The index is just for multi-input blending. Note that it would also be weird if the spec would require that all of the outputs (if more than one is used) would be bound to the same number 0... The ES 3.0 spec is a different thing, though.
– derhass
May 24 '14 at 16:40
@derhass: Ok, yes, I see what you're saying. It's indeed not explicitly specified that the linker would assign the locations starting at 0. There's a lot of software that would break if a driver didn't handle it that way, but you're theoretically right. The ES reference matters because they try very hard to keep the ES specs to be a subset of full OpenGL. So if behavior is guaranteed in ES, but not in OpenGL, that would be very undesirable.
– Reto Koradi
May 24 '14 at 19:47
add a comment |
The poster is using the core profile, wheregl_FragColor
is deprecated. But theglBindFragDataLocation
call isn't needed anyway. If a fragment shader has only oneout
, it's automatically written to the first draw buffer (which by default isGL_BACK
for the default framebuffer, andGL_COLOR_ATTACHMENT0
for FBOs).
– Reto Koradi
May 24 '14 at 4:52
@RetoKoradi: Actually, I never could find such a guarantee in the spec. All the spec says is that the GL will automatically assign any outputs where the location is not manuyally assigned to some unused color number. Every real-world implementation starts assignment with 0, for obvious reasons, but relying on that is still undefined behavior as far as the spec goes.
– derhass
May 24 '14 at 16:00
@derhass: It's specified. GLSL 4.4 spec: "If an output variable with no location or index assigned in the shader text has a location specified through the OpenGL API, the API-assigned location will be used. Otherwise, such variables will be assigned a location by the linker. All such assignments will have a color index of zero." ES 3.0 GLSLS spec: "If there is only a single output, the location does not need to be specified, in which case it defaults to zero."
– Reto Koradi
May 24 '14 at 16:32
@RetoKoradi: actually, it is not. I made the same mistake by myself earlier: there is a difference between the color number, and the color index. The color number is the relevant part here. The index is just for multi-input blending. Note that it would also be weird if the spec would require that all of the outputs (if more than one is used) would be bound to the same number 0... The ES 3.0 spec is a different thing, though.
– derhass
May 24 '14 at 16:40
@derhass: Ok, yes, I see what you're saying. It's indeed not explicitly specified that the linker would assign the locations starting at 0. There's a lot of software that would break if a driver didn't handle it that way, but you're theoretically right. The ES reference matters because they try very hard to keep the ES specs to be a subset of full OpenGL. So if behavior is guaranteed in ES, but not in OpenGL, that would be very undesirable.
– Reto Koradi
May 24 '14 at 19:47
The poster is using the core profile, where
gl_FragColor
is deprecated. But the glBindFragDataLocation
call isn't needed anyway. If a fragment shader has only one out
, it's automatically written to the first draw buffer (which by default is GL_BACK
for the default framebuffer, and GL_COLOR_ATTACHMENT0
for FBOs).– Reto Koradi
May 24 '14 at 4:52
The poster is using the core profile, where
gl_FragColor
is deprecated. But the glBindFragDataLocation
call isn't needed anyway. If a fragment shader has only one out
, it's automatically written to the first draw buffer (which by default is GL_BACK
for the default framebuffer, and GL_COLOR_ATTACHMENT0
for FBOs).– Reto Koradi
May 24 '14 at 4:52
@RetoKoradi: Actually, I never could find such a guarantee in the spec. All the spec says is that the GL will automatically assign any outputs where the location is not manuyally assigned to some unused color number. Every real-world implementation starts assignment with 0, for obvious reasons, but relying on that is still undefined behavior as far as the spec goes.
– derhass
May 24 '14 at 16:00
@RetoKoradi: Actually, I never could find such a guarantee in the spec. All the spec says is that the GL will automatically assign any outputs where the location is not manuyally assigned to some unused color number. Every real-world implementation starts assignment with 0, for obvious reasons, but relying on that is still undefined behavior as far as the spec goes.
– derhass
May 24 '14 at 16:00
@derhass: It's specified. GLSL 4.4 spec: "If an output variable with no location or index assigned in the shader text has a location specified through the OpenGL API, the API-assigned location will be used. Otherwise, such variables will be assigned a location by the linker. All such assignments will have a color index of zero." ES 3.0 GLSLS spec: "If there is only a single output, the location does not need to be specified, in which case it defaults to zero."
– Reto Koradi
May 24 '14 at 16:32
@derhass: It's specified. GLSL 4.4 spec: "If an output variable with no location or index assigned in the shader text has a location specified through the OpenGL API, the API-assigned location will be used. Otherwise, such variables will be assigned a location by the linker. All such assignments will have a color index of zero." ES 3.0 GLSLS spec: "If there is only a single output, the location does not need to be specified, in which case it defaults to zero."
– Reto Koradi
May 24 '14 at 16:32
@RetoKoradi: actually, it is not. I made the same mistake by myself earlier: there is a difference between the color number, and the color index. The color number is the relevant part here. The index is just for multi-input blending. Note that it would also be weird if the spec would require that all of the outputs (if more than one is used) would be bound to the same number 0... The ES 3.0 spec is a different thing, though.
– derhass
May 24 '14 at 16:40
@RetoKoradi: actually, it is not. I made the same mistake by myself earlier: there is a difference between the color number, and the color index. The color number is the relevant part here. The index is just for multi-input blending. Note that it would also be weird if the spec would require that all of the outputs (if more than one is used) would be bound to the same number 0... The ES 3.0 spec is a different thing, though.
– derhass
May 24 '14 at 16:40
@derhass: Ok, yes, I see what you're saying. It's indeed not explicitly specified that the linker would assign the locations starting at 0. There's a lot of software that would break if a driver didn't handle it that way, but you're theoretically right. The ES reference matters because they try very hard to keep the ES specs to be a subset of full OpenGL. So if behavior is guaranteed in ES, but not in OpenGL, that would be very undesirable.
– Reto Koradi
May 24 '14 at 19:47
@derhass: Ok, yes, I see what you're saying. It's indeed not explicitly specified that the linker would assign the locations starting at 0. There's a lot of software that would break if a driver didn't handle it that way, but you're theoretically right. The ES reference matters because they try very hard to keep the ES specs to be a subset of full OpenGL. So if behavior is guaranteed in ES, but not in OpenGL, that would be very undesirable.
– Reto Koradi
May 24 '14 at 19:47
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f23833076%2fdrawing-triangle-doesnt-work-i-just-see-a-black-screen-and-my-mouse%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown