• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

Mercury Filter

Members
  • Content count

    15
  • Joined

  • Last visited

Community Reputation

354 Neutral

About Mercury Filter

  • Rank
    Member
  1. Sorry, I realize that they are not the same, I was just asking if there was some roundabout, not necessarily sensible way that you could massage similar behaviour (the part about accepting different types), and create something similar. I realize that it may make no sense to actually do that, just wondered if it would be possible.   It may also be that I am misunderstanding more than one thing (history suggests this is indeed a worthwhile consideration). It was just intended as a question of idle curiousity.
  2. I did not really mean to say that was what you meant so much as I was questioning the wording because I felt that it could make it a little confusing as to the origin of such techniques. I did indeed misread generic as genetic. I did a little reading, and have a bit of a question on that. From what I have seen, with generic algorithms, it seem that we are talking in terms of templates, essentially. While I am guessing that there would be good reason not to do this, would it be possible to implement something similar to templates via unions in C? Perhaps I am thinking along the wrong lines, and it may be something that would be ridiculous amounts of work to build something that is handily available elsewhere, or some other technique can take the place of. Primarily, I just wonder as to the possibility as a matter of curiousity.
  3. What I am really taking out of this is that it is a "toolbox" type issue. Everything has strengths, everything has weaknesses. I certainly did not ask the question with the goal of trying to crown the king of languages. I wanted to know what are some positive points of the two, unfortunately I used some questionable wording. I have found a lot of these posts to be quite informative. I am guessing that no matter who you ask, they are always going to have a personal preference (a very strong one in some sometimes, probably), and I can see a bit more why I was warned by Winfield that such a question can incite a holy war. Thanks everyone, for maintaining civility on such a topic, since there was some pretty good information to be had. The current view I am going to go forward with is that based on responses, and on other threads that I have read as well, my best bet is probably just choosing and sticking to a language for the time being (that one seems to have been reiterated in numerous places). Not that I was really questioning that it was the best thing to do, nor trying to get help choosing. Just wanted to try and learn a bit more about the two, and I would say that goal was achieved.   Although everything that I stated above is meant sincerely, I feel a bit too much "after-school special" seeping into it.....the cynic in me feels quite ill, but thanks for the information, again.
  4. I hate to nit-pick (ok, I actually love to, it seems very effective in terms of learning), but isn't it a bit misleading to refer to genetic algorithms and lambdas as being C++ techniques? Correct me if I misunderstood what you were saying but the statement seems to associate those techniques with C++, while I am pretty sure the two I mentioned existed before it did. I could not say about the others, as I am less familiar with them, and I am not very familiar with those two in the first place.
  5. I understand what you are saying there (not really, as I lack the experience of writing large programs to claim understanding). I imagine managing any large programming project is not trivial, but I am curious about what it is that makes managing the larger programs in C++ easier? I have heard the quick answer of "classes", and perhaps this is another question that I need to experience as opposed to hear an answer to, as the quick answer does not really feel like it enhances my understanding (I often take this as a sign that I am missing some fundamental understanding that would make the quick answer more complete, if I had the knowledge). I assume that what Winfield said above is a  Edit::workable good::Edit option, so I guess I am wondering if there is something else that I am not familiar with in C++ that makes it easier to manage code for bigger projects, or if perhaps I need to write more C++ before I will really see the benefits? Sorry if some of these questions are kind of silly (perhaps). I presume the wonderous shield of 'newb', which should be obvious from said questions, should afford me some pity, assuming that I manage to improve....eventually.   Edit::I felt like "workable" may have been communicating a negative or perhaps diminished appraisal of the option that I did not intend.
  6. This is interesting for me to see. I am sure that there are people developing in all kinds of languages that I would not expect, but I usually see people insisting that you cannot use C, and you need to use C++. I would assume that it is a "toolbox" issue, and nothing is actually quantifiably superior in all ways, with the selection being a matter of choosing which benefits are most important. I am currently kind of a fan of C, but that is probably due to familiarity, since I have spent the most time using it at this point. Thank you, by the way, for warning me about asking this kind of question. I will either be a lot more careful with how I approach such matters, or I will avoid asking potentially inflamatory questions in the future.
  7. I am sorry if I did not make it more clear what I was saying. I am aware that C allows functions without arguments, I was trying to say that I was doing something with C++ where I would have needed arguments in C, or (if I understand correctly) I would have needed to be using global variables in C.
  8. I apologize if I have asked something that can be the cause of a legendary holy war. That was certainly not my intent. Perhaps I was not clear. I was not asking for whether one or the other is better. I wanted to know (if such a response is even possible with reasonable effort) if anyone had any high-level explanations regarding benefits in writing code in one or the other. Not really a better thing, but more specifically if there are certain things that are a bit easier in one language versus the other. My question was meant to try and obtain objective responses, but I did use the dirty word "opinions" in my original post. Probably bad form when seeking an objective response. Perhaps the nature of my question can not easily be answered objectively. I mainly just want to try and determine if there are things here and there that may be easier in one language versus the other. I play with both of them (which occasionally leads to me trying to do riduculous things in one because I forget I am not using the other), and just wanted to know a bit more about usage of the languages in general.
  9. 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]
  10. I may have asked the question in a bit unclear fashion, but one of the things that I was interested in was things such as the stated speed difference between local and global variables. The impression that I have gotten from responses is that a lot of the matter lies with what you are writing the program for. If I were to attempt to delve into the details of why these differences occur, would some of this be the memory system? I feel like it is a rough way to ask the question; would it be more specifically the way that the specific language deals with handling memory? I am more than happy to use google myself, but if anyone is familiar with any good resources off the top of their heads (I don't consider it anyone's responsibility to find it for me, but if you are already familiar with something it would certainly make it easier, lol), that would be a good starting point, it would be appreciated.
  11. 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.
  12. Okay, apparently it actually is the code that I have been using to bring in the shaders. I need to play around a bit more, but replacing the function to load the shader source with const GLchar* definitions of the shader source has resolved the issue. I guess that it was too soon to assume that my program being able to print the source of my shaders correctly corresponded to them working right.   I am rather new here, and just as a point for future reference, can anyone tell me if this thread was correctly placed? I would consider myself a beginner, but after looking at the content of my post, I decided I was not sure if it was appropriate for the beginner forum.   I am not sure of the social protocols here (I am often a bit slow in regards to learning social protocols), but if I want to ask more questions about this matter, specifically what was wrong with my loading of shaders, would it be acceptable to do so in this thread, or would it be better suited to a different one? I am not sure if it is an issue with the C++ specifically, or with my understanding of something OpenGL related. I guess I feel that I am not really sure where the boundary between a beginner question, and something that should be directed towards the more focused areas is.   Finally, I apologize ahead of time if the placement of this was incorrect.   EDIT: Additionally, if anyone would be kind enough to critique the methods I used (at least the ones that are visible here) in the process of trying to root out the issue, or if there are suggestions that would allow me to expedite the process of resolving unknown issues, I am always looking to expand my proverbial toolbox.
  13. I am afraid that is my incompetence showing, I will be reading more in that area for sure. Thank you for pointing it out.   In regards to the viewport, I have not set it. I believe the tutorial covers the matter later on, but the initial stuff seems to all be sans-viewport setting. This is a link to code associated with the tutorial, but not identical as it uses SFML for the window and context. Additionally, I used some elements of code from a small amount further in the tutorial. I had a version of this working in C. I can compile the C code using g++, and it will run fine and create the triangle as intended. In the course of trying to hunt down my problem, I pasted the C code into a project with the same settings as the one the code I posted initially is from, to confirm that I was not fouling up the settings in Eclipse. Pretty much the only thing that I changed in the version above is using std::cout for printing, and adding some more stuff to be printed out, with the major change being rewriting the function to load the shader code (I was working rather late on that one, and cannot honestly recall exactly why I changed it at the time; I may have been dealing with warnings or errors, or it may have been more whimsical, i.e. "let's see if we can write this in C++ now"). If it would help, I can post the C code that I attempted to adapt the above code from. Pretty much all the GLFW and GL code is identical(or was until I spent a bunch of time tinkering with it), with the exception of loading the shaders and the console printing.   ** I should state that I am now not 100% sure that Eclipse was actually compiling the C code with g++ and not gcc. Regardless, I can use g++ to compile the C code via the command line and it works as intended, I just figured that I may actually be wrong about my test in Eclipse. There are some details on Eclipse I will need to read more on I see.
  14. I attempted both of the changes, but I am still getting the black screen. The new code reads: [source lang="cpp"] GLfloat verts[] = {             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     };     std::vector<GLfloat> vertex_vect;     vertex_vect.resize(15);     for (int i = 0; i < 15; i++) {         vertex_vect.at(i) = verts[i];     }     GLuint vbo;     glGenBuffers(1, &vbo);     std::cout << "Vertex Buffer: " << vbo << "\n";     glBindBuffer(GL_ARRAY_BUFFER, vbo);     glBufferData(GL_ARRAY_BUFFER, sizeof(vertex_vect.at(0)) * vertex_vect.size(), &vertex_vect.at(0), 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(GLuint)*3, elements, GL_STATIC_DRAW); [/source]   I was curious about what kind of problem the original was causing, so I threw together this: [source lang="cpp"] #include <iostream> #include <vector> int main(void) {     /* Define a set of values. */     float myvals[] = {         0.1f, 0.3f, 0.0f,         1.5f, 0.2f, 0.0f     };          /* Printing info*/     std::cout << "sizeof(myvals) : " << sizeof(myvals) << "\n";     std::cout << "sizeof(myvals[0]) : " << sizeof(myvals[0]) << "\n";          /* Try a vector */     std::vector<float> vect_vals;     vect_vals.resize(6);     for (int i = 0; i < 6; i++) {         vect_vals.at(i) = myvals[i];     }          /* Print vector info */     std::cout << "sizeof(vect_vals) : " << sizeof(vect_vals) << "\n";     std::cout << "sizeof(vect_vals.at(0)) : " << sizeof(vect_vals.at(0)) << "\n";     std::cout << "sizeof(vect_vals.at(0)) * vect_vals.size() : " <<                     sizeof(vect_vals.at(0)) * vect_vals.size() << "\n";          return 0; } [/source] but the results seem to indicate that the values being returned when using sizeof were the same for sizeof(vertices) (I corrected the spelling), and for sizeof(vertex_vect.at(0)) * vertex_vect.size(). My results: C:\Dev\Projects\Utility>g++ -std=c++0x sizeTest.cpp -o st.exe C:\Dev\Projects\Utility>st.exe sizeof(myvals) : 24 sizeof(myvals[0]) : 4 sizeof(vect_vals) : 12 sizeof(vect_vals.at(0)) : 4 sizeof(vect_vals.at(0)) * vect_vals.size() : 24   I don't think I misunderstood what I was doing here, so I am wondering if it is actually something else that was the issue, rather than the size values that I was passing in.
  15. 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: [source lang="cpp"] /*  * main.cpp  *  *  Created on: Oct 23, 2013  */ #define GLEW_STATIC #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();     file.close();     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_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);     glfwWindowHint(GLFW_RESIZABLE, GL_FALSE);     /* Create Window */     GLFWwindow * window = glfwCreateWindow(800, 600, "Basic OpenGL", nullptr, nullptr);     glfwMakeContextCurrent(window);     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);     glBindVertexArray(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);     glCompileShader(vertexShader);     GLuint fragmentShader = glCreateShader(GL_FRAGMENT_SHADER);     glShaderSource(fragmentShader, 1, &frag, nullptr);     glCompileShader(fragmentShader);     //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");     glLinkProgram(shaderProgram);     glUseProgram(shaderProgram);     GLint posAttrib = glGetAttribLocation(shaderProgram, "position");     glEnableVertexAttribArray(posAttrib);     glVertexAttribPointer(posAttrib, 2, GL_FLOAT, GL_FALSE, 5 * sizeof(GLfloat), 0);     GLint colAttrib = glGetAttribLocation(shaderProgram, "color");     glEnableVertexAttribArray(colAttrib);     glVertexAttribPointer(colAttrib, 3, GL_FLOAT, GL_FALSE,             5 * sizeof(GLfloat), (void*)(2 * sizeof(GLfloat)));     glClearColor(0.0f, 0.0f, 0.0f, 1.0f);     glClearDepth(1.0f);     while (!glfwWindowShouldClose(window)) {         glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);         glDrawElements(GL_TRIANGLES, 3, GL_UNSIGNED_INT, 0);         glfwSwapBuffers(window);         glfwPollEvents();         if (glfwGetKey(window, GLFW_KEY_ESCAPE) == GLFW_PRESS) {             glfwSetWindowShouldClose(window, GL_TRUE);         }     }     glDeleteProgram(shaderProgram);     glDeleteShader(fragmentShader);     glDeleteShader(vertexShader);     glDeleteBuffers(1, &ebo);     glDeleteBuffers(1, &vbo);     glDeleteVertexArrays(1, &vao);     glfwDestroyWindow(window);     glfwTerminate();     return (0); } [/source] The shader files that I am using are: Vertex Shader: [source] #version 150 in vec2 position; in vec3 color; out vec3 Color; void main() {     Color = color;     gl_Position = vec4(position, 0.0f, 1.0f); } [/source] Fragment Shader: [source] #version 150 in vec3 Color; out vec4 outColor; void main() {     outColor = vec4(Color, 1.0f); }   [/source] 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. Thanks