• Ever thought it'd be cool to have your art, writing, or challenge runs featured on PokéCommunity? Click here for info - we'd love to spotlight your work!
  • It's time to vote for your favorite Pokémon Battle Revolution protagonist in our new weekly protagonist poll! Click here to cast your vote and let us know which PBR protagonist you like most.
  • Welcome to PokéCommunity! Register now and join one of the best fan communities on the 'net to talk Pokémon and more! We are not affiliated with The Pokémon Company or Nintendo.
    Register

Your current Ctrl + V

Status
Not open for further replies.
(5:49 PM) Arylett Dawnsborough: ;;Nervously, Arylett removes her jacket, revealing a red short sleeved-collar shirt and not a sexy bathingsuit;;

...Erm. I was showing my boyfriend an RP from long ago I did over IM.
 
Code: 
  def 
    return Get.call(@nodeID, @materialID)
  end
  
  def =(val)
    return Set.call(@nodeID, @materialID, val)
  end

Basically it's a small ruby template I made for a DLL that I've got a lot of calls similar to what you see above. xD
 
glGenBuffers(1, &VBO);
OpenGL defines several glGen* functions for generating objects of various types. They often take two parameters - the first one specifies the number of objects you want to create and the second is the address of an array of GLuints to store the handles that the driver allocates for you (make sure the array is large enough to handle your request!). Future calls to this function will not generate the same object handles unless you delete them first with glDeleteBuffers. Note that at this point you don't specify what you intend to do with the buffers so they can be regarded as "generic". This is the job of the next function.

glBindBuffer(GL_ARRAY_BUFFER, VBO);
OpenGL has a rather unique way of using handles. In many APIs the handle is simply passed to any relevant function and the action is taken on that handle. In OpenGL we bind the handle to a target name and then execute commands on that target. These commmands effect the bounded handle until another one is bound in its stead or the call above takes zero as the handle. The target GL_ARRAY_BUFFER means that the buffer will contain an array of vertices. Another useful target is GL_ELEMENT_ARRAY_BUFFER which means that the buffer contains the indices of the vertices in another buffer. Other targets are also available and we will see them in future tutorials.

glBufferData(GL_ARRAY_BUFFER, sizeof(Vertices), Vertices, GL_STATIC_DRAW);
After binding our object we fill it with data. The call above takes the target name (same as what we used for binding), the size of the data in bytes, address of the array of vertices and a flag that indicates the usage pattern for this data. Since we are not going to change the buffer contents we specify GL_STATIC_DRAW. The opposite will be GL_DYNAMIC_DRAW. While this is only a hint to OpenGL it is a good thing to give some thought as to the proper flag to use. The driver can rely on it for optimization heuristics (such as what is the best place in memory to store the buffer).

glEnableVertexAttribArray(0);
In the shaders tutorial you will see that vertex attributes used in the shader (position, normal, etc) have an index mapped to them that enable you to create the binding between the data in the C/C++ program and the attribute name inside the shader. In addition you must also enable each vertex attribute index. In this tutorial we are not yet using any shader but the vertex position we have loaded into the buffer is treated as vertex attribute index 0 in the fixed function pipeline (which becomes active when there is no shader bound). You must enable each vertex attribute or else the data will not be accessible by the pipeline.

glBindBuffer(GL_ARRAY_BUFFER, VBO);
Here we bind our buffer again as we prepare for making the draw call. In this small program we only have one vertex buffer so making this call every frame is redundent but in more complex programs there are multiple buffers to store your various models and you must update the pipeline state with the buffer you intend to use.

glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 0, 0);
This call tells the pipeline how to interpret the data inside the buffer. The first parameter specifies the index of the attribute. In our case we know that it is zero by default but when we start using shaders we will either need to explicitly set the index in the shader or query it. The second parameter is the number of components in the attribute (3 for X, Y and Z). The third parameter is the data type of each component. The next parameter indicates whether we want our attribute to be normalized before it is used in the pipeline. It our case we want the data to pass un-changed. The fifth parameter (called the 'stride') is the number of bytes between two instances of that attribute in the buffer. When there is only one attribute (e.g. the buffer contains only vertex positions) and the data is tightly packed we pass the value zero. If we have an array of structures that contain a position and normal (each one is a vector of 3 floats) we will pass the size of the structure in bytes (6 * 4 = 24). The last parameter is useful in the case of the previous example. We need to specify the offset inside the structure where the pipeline will find our attribute. In the case of the structure with the position and normal the offset of the position is zero while the offset of the normal is 12.

glDrawArrays(GL_POINTS, 0, 1);
Finally, we make the call to draw the geometry. All the commands that we've seen so far are important but they only set the stage for the draw command. This is where the GPU really starts to work. It will now combine the parameters of the draw call with the state that was built up to this point and render the results to the screen.

OpenGL provides several types of draw calls and each one is appropriate for a different case.
Click to expand...

Oh... Yeah.
 
Don't worry sir who pats my head awkwardly, I know exactly how you feel about having clipboards like that.

Code: 
#include <vector>

using namespace std;

#include <irrlicht.h>

using namespace irr;
using namespace core;
using namespace gui;
using namespace scene;
using namespace video;

I don't even know why I still use irrlicht other than it's cross platform and I'm too lazy to write a graphics engine from scratch for my projects... Okay, never mind, that explains itself..
 
Status
Not open for further replies.
Back
Top