Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!

Mercury Filter

Member Since 24 Oct 2013
Offline Last Active Mar 26 2015 11:11 AM

Topics I've Started

How Languages Compare?

14 November 2013 - 10:46 AM

I have been wondering about how the practice of coding in C and C++ compare, in terms of a high-level view since I doubt at this point I would really benefit from a lot of the technical detail. I am not asking this for the purpose of "choosing a language", or anything like that. I just felt curious about opinions on benefits and drawbacks if comparing the two.

Most of what I have done to this point has been in either C, C++, or Java, with dabbling in various other areas. (Haskell and Prolog were pretty fun I thought, but I never got very far with them...no reason really, they were a sidetrack themselves, or just for fun)

I became familiar with C mostly from a course in computational physics that I took. I had used it prior, but most of my (occasional) effort had been directed at C++ up to that point. The thing that that use of C highlighted to me was that it seemed like C was a great deal more...hmm, not sure how to put this. Direct, maybe? When comparing the two, it feels quicker to write stuff in C. I would add that I have yet to write anything sizable. Even the final project for the course was not very big in terms of code. I am aware of statements regarding C++ code being organized in ways that makes it convienient for large projects, but I am not really familiar with the specifics of why that is. (Okay, maybe I could come up with an acceptable answer to that, but I would not be very confident in it, having not seen such things for myself.)


In writing some C++ code today, I saw that there were member functions of classes that could, due to the nature of classes, be written in a way that no arguments were needed to the function. I realized that if I were to write the same thing in C, there would be arguments required. I admit that I wrote some code in the above mentioned course that had some painfully large amounts of arguments. The flip side to the nice (at least I felt) no arguments benefit was that I had to write the class were in C I would have written two funtions alone. Perhaps this is a concept with importance of either greater, or lesser magnitude than I realize. I don't know how this type of thing (included as an example to hopefully clarify the nature of my question) would scale when you are talking about major projects, as opposed to something small, which is pretty much what I have written to date.


Or maybe I am horribly misunderstanding all kinds of things, lol. ["lol" is included in my typing language as a provisional inclusion, and I am not sure if it will make the cut for the standard]

Globals usage in tutorials and elsewhere.

25 October 2013 - 02:49 PM

I have been reading the OpenGL Programming Guide, and in it they justify usage of global variables in tutorials on the grounds that they are just small programs in the examples. The question I have is if there is some piece of information about global variables that I don't understand that would justify that? I am familiar with scope, but I am trying to understand why you would risk the possibility of teaching something that is considered to be bad practice (as far as I have ever heard; also, I realize that the book I am referring to is not to teach programming, but OpenGL), when you could just avoid using the globals?

So in essence, is there a difference that I simply am not understanding that makes their use appealing for such tutorials?


When I took a course in computational physics, the professor seemed to love global variables, and it took me a bit to get past that, as I had read often that one should avoid them. Every C program that we looked at in class had almost every piece of information related to the values of the elements of the simulation placed in variables that were at the top of the source file, right below the includes and defines. I believe that I read that C variables are not actually strictly globals in that context, so my usage of the term may be incorrect.

OpenGL, Blank Screen

24 October 2013 - 12:12 PM

I am attempting to learn some OpenGL, and I have become a bit stuck. I have been playing with the tutorials at open.gl, and while working on the drawing polygons section, I got stumped while making a few changes. I have gotten everything into the section to work when compiling under C via MinGW, but after moving over to Eclipse (still using MinGW), and rewriting some of the code using C++, I cannot get anything to display to the screen. Before, I had a multi-colored triangle, as the tutorial intended, but now I just get a black window. I have been compiling with -std=c++0x, so I thought I might have done something unforgivable in C++11, but when I set another Eclipse project up with the same settings, and then cut and pasted the code from the C version in, it worked fine (it did throw some compiler warnings). I have been over the code several times, comparing it to the strictly C code that I used at first, and I cannot find where I went wrong. I did rewrite a few things based off tutorials and posts from other places, such as the code for loading the shaders.

The current version of the code is as follows:


 * main.cpp


 *  Created on: Oct 23, 2013



#include <GL/glew.h>

#include <GLFW/glfw3.h>

#include <stdio.h>

#include <stdlib.h>

#include <math.h>

#include <time.h>

#include <iostream>

#include <fstream>

#include <string>

#include <sstream>

/* Shader Load


bool getShader(std::string filename, GLchar ** contents) {

    std::ifstream file;

    file.open(filename.c_str(), std::ifstream::in);

    if (!file) {

        return (false);


    std::stringstream stream;

    stream << file.rdbuf();


    std::string tStr;

    tStr = stream.str();

    *contents = (GLchar*)tStr.c_str();

    return (true);


int main(void) {

    /* Initialization */

    if (!glfwInit()) {

        std::cout << "GLFW initialization error.\n";

        // TODO Add error message output.


    else {

        std::cout << "GLFW Initialized. Using version:" << glfwGetVersionString() << "\n";


    glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 4);

    glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3);


    glfwWindowHint(GLFW_RESIZABLE, GL_FALSE);

    /* Create Window */

    GLFWwindow * window = glfwCreateWindow(800, 600, "Basic OpenGL", nullptr, nullptr);


    glewExperimental = GL_TRUE;

    GLenum err = glewInit();

    if (GLEW_OK != err) {

        std::cout << "GLEW initialization failed. Error: " << glewGetErrorString(err) << "\n";


    else {

        std::cout << "Using GLEW " << glewGetString(GLEW_VERSION) << "\n";


    GLuint vao;

    glGenVertexArrays(1, &vao);


    std::cout << "Vertex Array: " << vao << "\n";

    // REVIEW Find out exactly what I am outputting here.

    GLfloat verticies[] = {

            0.0f, 0.5f, 1.0f, 0.0f, 0.0f,

            0.5f, -0.5f, 0.0f, 1.0f, 0.0f,

            -0.5f, -0.5f, 0.0f, 0.0f, 1.0f


    GLuint vbo;

    glGenBuffers(1, &vbo);

    std::cout << "Vertex Buffer: " << vbo << "\n";

    glBindBuffer(GL_ARRAY_BUFFER, vbo);

    glBufferData(GL_ARRAY_BUFFER, sizeof(verticies), verticies, GL_STATIC_DRAW);

    GLuint elements[] = {

            0, 1, 2


    GLuint ebo;

    glGenBuffers(1, &ebo);

    glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, ebo);

    glBufferData(GL_ELEMENT_ARRAY_BUFFER, sizeof(elements), elements, GL_STATIC_DRAW);

    std::cout << "Element Buffer: " << ebo << "\n";

    /* Load shader files */

    GLchar * vC;

    GLchar * fC;

    if (!getShader("vShad.vert", &vC)) {

        std::cout << "Vertex shader load source failed.\n";


    else {

        std::cout << "Vertex shader source loaded.\n";


    if (!getShader("fShad.frag", &fC)) {

        std::cout << "Fragment shader source load failed.\n";


    else {

        std::cout << "Fragment shader source loaded.\n";


    const GLchar * vert = vC;

    const GLchar * frag = fC;

    /* Compile Shaders */

    GLuint vertexShader = glCreateShader(GL_VERTEX_SHADER);

    glShaderSource(vertexShader, 1, &vert, nullptr);


    GLuint fragmentShader = glCreateShader(GL_FRAGMENT_SHADER);

    glShaderSource(fragmentShader, 1, &frag, nullptr);


    //std::cout << "Vertex Shader Source:\n" << vert;

    //std::cout << "Fragment Shader Source:\n" << frag;

    /* Shader compilation status */

    GLint status;

    char errBuffer[512];

    glGetShaderiv(vertexShader, GL_COMPILE_STATUS, &status);

    if (status == GL_FALSE) {

        std::cout << "Vertex shader compilation failed.\n";

        glGetShaderInfoLog(vertexShader, 512, nullptr, errBuffer);

        std::cout << errBuffer << "\n";


    else {

        std::cout << "Vertex shader compiled.\n";


    glGetShaderiv(fragmentShader, GL_COMPILE_STATUS, &status);

    if (status == GL_FALSE) {

        std::cout << "Fragment shader compilation failed.\n";

        glGetShaderInfoLog(fragmentShader, 512, nullptr, errBuffer);

        std::cout << errBuffer << "\n";


    else {

        std::cout << "Fragment shader compiled.\n";


    GLuint shaderProgram = glCreateProgram();

    glAttachShader(shaderProgram, vertexShader);

    glAttachShader(shaderProgram, fragmentShader);

    glBindFragDataLocation(shaderProgram, 0, "outColor");



    GLint posAttrib = glGetAttribLocation(shaderProgram, "position");


    glVertexAttribPointer(posAttrib, 2, GL_FLOAT, GL_FALSE, 5 * sizeof(GLfloat), 0);

    GLint colAttrib = glGetAttribLocation(shaderProgram, "color");


    glVertexAttribPointer(colAttrib, 3, GL_FLOAT, GL_FALSE,

            5 * sizeof(GLfloat), (void*)(2 * sizeof(GLfloat)));

    glClearColor(0.0f, 0.0f, 0.0f, 1.0f);


    while (!glfwWindowShouldClose(window)) {


        glDrawElements(GL_TRIANGLES, 3, GL_UNSIGNED_INT, 0);



        if (glfwGetKey(window, GLFW_KEY_ESCAPE) == GLFW_PRESS) {

            glfwSetWindowShouldClose(window, GL_TRUE);






    glDeleteBuffers(1, &ebo);

    glDeleteBuffers(1, &vbo);

    glDeleteVertexArrays(1, &vao);



    return (0);


The shader files that I am using are:

Vertex Shader:

#version 150

in vec2 position;

in vec3 color;

out vec3 Color;

void main() {

    Color = color;

    gl_Position = vec4(position, 0.0f, 1.0f);


Fragment Shader:

#version 150

in vec3 Color;

out vec4 outColor;

void main() {

    outColor = vec4(Color, 1.0f);



In case it is relevant, I am linking:

-lmingw32 -lglew32s -lglfw3 -lopengl32 -lgdi32

and compiler options are:

-fmessage-length=0 -std=c++0x (I am not really sure about message length, it was the default, and I have left it alone so far).

Compiler is MinGW 4.7.2

The program builds in Eclipse, and runs with a black screen. It may be worth noting that I have a warning:

Warning: .drectve `/DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES" ' unrecognized

I have not tracked the cause of that down yet, and have been trying on and off to determine the exact cause, since I would prefer no warnings at all, even if the program runs with them. One post I read somewhere I cannot recall mentioned that those errors are related to the Microsoft compilers, but I don't yet really know more than libcmt being part of the multithread c library for them (please correct me if I am wrong).

I was worried if the shaders were loading correctly, as a friend had issues with the program where I did not (I still have not been able to figure that one out, it was with the C code I used originally), but after adding the code to print the loaded shader code in the console, I was able to determine that they are loading properly.

The terminal output when running the program is:

GLFW Initialized. Using version:3.0.3 Win32 WGL MinGW LoadLibrary(winmm)
Using GLEW 1.10.0
Vertex Array: 1
Vertex Buffer: 1
Element Buffer: 2
Vertex shader source loaded.
Fragment shader source loaded.
Vertex shader compiled.
Fragment shader compiled.


I am still getting a blank screen though. I cannot figure out what I am overlooking.

Additionally, I am not what you would call well-versed with programming. I have been playing with various languages for years, but never very seriously. That being said, I am always happy to hear about any...unconventional practices...that may cause me problems in the future as well.