Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Everything posted by _Pickle_

  1. _Pickle_

    GL_UNSIGNED_BYTE indices

    Yes the offset would only change where you start in the indices, but its the only other thing I can think to check that relates to using indices. It seems like the data never transfered in the case of the first IBO. I would try and run the code on another vendor as a sanity check.
  2. _Pickle_

    GL_UNSIGNED_BYTE indices

    yeah that looks fine for populating the ibo. Do you plan to update the index data? If not you could just use glBufferData. what i mean by pointer offset is the value that is given during the call to glDrawElements: glDrawElements(GL_QUADS, 24, GL_UNSIGNED_BYTE, 0); Where 0 is the offset in the index buffer, if it wasnt 0 in your app the indices could end up being read wrong.
  3. _Pickle_

    GL_UNSIGNED_BYTE indices

    i dont know what I was thinking with my previous statement, a cube will never exceed the index range. Its monday Its seems either the index buffer was loaded with incorrect data or the pointer offsets are incorrect. The first case might be true if the array being loaded into the ibo, doesnt because initialized until after the first cube init occurs. The second doesnt seem likley as you most likely have or run the same code for both
  4. _Pickle_

    GL_UNSIGNED_BYTE indices

    How many vertices do you have for the cube? Does it render incorrectly? (with and without gdebugger?) How do you handle rendering multiple objects? single vbo/ibo bind then draw each instance or bind and draw each instance?
  5. _Pickle_

    Question about particle systems and VBOs

    VBO's gain performance by reducing the amount of time needed to transfer vertex data. The idea is that most of the information is transfered into the buffer before regular rendering begins. If data in the buffer has to be updated only the parts that change are updated. Previously with basic vertex arrays the data was transfered each loop. In your case I would do the following, load all of the vertex/index data into the vbo/ibo. Then update only the particles that need updating (can be done with glBufferSubData or glMapbuffer) Use a index array (which can be stored in an IBO) to decide which particles can be rendered with glDrawElements. In my personal project I use a vbo/ibo per model, I have not observed any bad behavior (about a dozen). I believe I have read that there may limits the amount of buffers gpu vendors can support.
  6. _Pickle_

    gluPerspective and rotation

    I think you just need to adjust your fov for each mode, since the view height changes.
  7. If all vertices are different than you can use glDrawArrays
  8. Ive been working on a Opengl-ES compatible game. Objects are defined by OBJ files, which ive added support for groups which can be by material type or texture. A group will have a start and count which refers to the vertex index array. There is one situation Im not sure the most efficient way of handling is. My current path works fine for situations where the obj data is either just textured or non-textured. I think if I have a mixture then some thing might be happening incorrectly. Say I have a cube where every other side is defined to use a texture. In my current method of rendering would be as follows: EnableClientStates (if the array doesnt support texcorrds or normals at all then they are not enable or binded later) BindVertexArrays (setting up pointers to arrays) For each group IF group has material THEN BindMaterials ENDIF IF group has texture THEN BindTexture ENDIF RenderElements UnBindTexture Next Group DisableClientStates Now do I have wasted overhead because i defined the tex pointer for non textured vertices's? (Since i only relied on the GL_TEXTURE2D state) To fix that i could move the client state handling into the loop, but binding the data should come after enabling the states. I dont need to bind the data more than once which would be wasteful i imagine. Can/Should I disable the texcoord client state along with the GL_TEXTURE2D?
  9. _Pickle_

    Managing Vertex Arrays

    Well in theory what I have right now is 2 loops one with textures enabled and another without. The difference is that the client for texcoords is enabled for both. Maybe i can enable/disable the texcoord where I handle the texture state. Either way I will keep most of what i have since it works.
  10. Check this out: http://www.opengl.org/wiki/Texture_Combiners Keep in mind though your limited to how many textures you can combine based on how many units your hardware supports.
  11. _Pickle_

    Text Glyphs Clipped

    Can you show what you do in here? Or specifically how you clip your texture to choose the letter you want. mTextGlyphs.Draw(); You can tell from your picture the clip is not wide enough and cuts off the right side of the letters, the left overs then show up in the letters that follow. Maybe the top right parts of the left overlap with the bottom left of the following letter? Could also be because the font is not monospaced font, meaning each letter takes up a different width. Is your clip always the same or does it try to adjust?
  12. Immediate Mode isnt supported by GLES. You need to use vertex arrays/VBO's. I think you could do this with fixed pipeline (programmable (shaders) would do the same thing, you would just be duplicating what fixed does with the shader) Create a vertex mesh like what is shown in the picture, and look at it as 35 quads. Draw each quad (has to be triangle fan or strip for GLES), assign the texcoords to the appropriate coordinates (texcoords go 0 to 1, so the coordinates would be something like: 1/7, 1/5 upper left 2/7, 1/5 upper right 1/7, 2/5 lower left 2/7, 2/5 lower right Now as you move your vertices it should stretch that part of the texture to fit within the quad.
  13. Vertex Arrays store vertex data on the cpu side VBO stores the data on the gpu be it vertex data or index data. VAO stores the attributes that define the data in VBO's Vertex arrays basically made the cpu transfer vertex/index data and attributes (gl*Pointer) every loop to the gpu. If the vertex data doesnt change or only parts then that data could be stored once and updated as needed. Thats where VBO's came in. VAO are actually new to me as Ive been working in the GLES versions. But it looks like a nice thing, with either GLES 1.X/2.0 the attributes have to be specified every time a vertex array or vbo is used. It also seems with 2.0/3.0 the directions have been to buffer/store as much data one time on the gpu side with minimal changes as needed.
  14. Rolli I think you only have to change the up vector if you intend to let the camera flip. For example I have setup a camera that acts like a first person shooter using lookat. I limit my pitch to +/- 89 degrees, otherwise if I let pass over the the 90 degree point the camera will flip since the up vector is still pointing up. I might be able allow 360 degrees if I inverted the up vector when i hit the 90 degree point. Edit: also the link to the cml library provides any math related operation you would ever need. Using it you can get rid of glu, not use the gl library matrix api( other than glMatrixMode and glLoadMatrix). Im glad I took this approach as it helped adding opengl 2.0 support. > 2.0 does not support matrix api like 1.X does.
  15. _Pickle_

    OpenGLES Question

    I do it by setting opengl into 2d projection mode (set projection matrix with a orthographic matrix). Now you can do text in 2 ways either with a bitmap font or draw lines. In bitmap font you basically have a texture with images of each character. So you would draw a quad with the right texture in the right position. In lines you draw all of the lines defined by points in a vertex array for the character desired. This is the method I currently use.
  16. If you dont want to make a math library yourself take a look at this: http://cmldev.net Ive been using this for all of my vector/matrix operations. I has the Lookat function you refer to and ive use it in my camera code to translate objects into the correct camera positions.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!