Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


glBufferData failing


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 Ender1618   Members   -  Reputation: 243

Like
0Likes
Like

Posted 09 July 2012 - 01:22 PM

Im using OGL 4.0 core profile on Win7, with about 2gb of video card memory.

So my software is receiving an arbitrary amount of points over time that need to be visualized. The thing is i do not know in advance how many points there will be. My solution is to allocate empty VBOs of a fixed size, and copy the incoming points into the current VBO with calls to glBufferData. When a VBO fills up I allocate a new VBO and start filling it, and so on.

The problem I am having is when allocating an empty VBO, with a call like this:
glGenBuffers(1, &(entry.handle));
  glBindBuffer(GL_ARRAY_BUFFER, entry.handle);
  glBufferData(GL_ARRAY_BUFFER, entry.size, NULL, usage);
GLenum err = glCheckError();
  if(err != GL_NO_ERROR)
	return false;

I am using interleaved arrays with a vertex of size 28 bytes, I tried letting my max VBO size to be 50k vertices, which is 1.4 mb each. After about the 5th VBO allocated like this, glBufferData fails with an invalid parameter message (from glGetError). The odd thing is if I allow the VBO max size to be 500k vertices, everything is fine, glBufferData never fails and everything renders fine.

Has anyone ever come across anything like this?

I would have thought glBufferData would have failed with a out of memory message if anything.

Sponsor:

#2 Ender1618   Members   -  Reputation: 243

Like
0Likes
Like

Posted 09 July 2012 - 01:41 PM

Ugh the problem was that the error was happening before all that code, it was just being picked up when i called glGetError later.

So now my question becomes how does one use glGetError effectively? Do I actually need to call it after every gl call (that seems excessive), do I set it up to only get called in a debug build after every gl call? Is there a way to monitor any error that might be happening through piping them to the debug window (this is what DX does).

#3 Brother Bob   Moderators   -  Reputation: 8431

Like
0Likes
Like

Posted 09 July 2012 - 01:54 PM

You shouldn't have to call it at all unless you're trying to find an actual error in parameters or usage. Once the code base is working, you should not have to check for errors due to user input. The amount of code you need to check for actual errors in should be fairly limited, or you have speard your code out in too many places.

I believe the common OpenGL debuggers can monitor error states. However, I have never used them. The OpenGL code I use is typically very limited (only a very few selected places are actually responsible for communicating with OpenGL) and simply manually placing glGetError's in strategic places and narrowing it down in a binary search manner is quite fast.

#4 wolfscaptain   Members   -  Reputation: 200

Like
0Likes
Like

Posted 10 July 2012 - 08:40 AM

I wrap all my GL calls with a macro that, if debugging is wanted, adds a call to a function that prints a GL error.
It's not automated, but it's as close to it without going and making bindings that do it.
I would have liked having a debug version of GLEW.

On another note - do not use glBufferData to edit buffers, use glBufferSubData.
The former forces the driver to reallocate the whole buffer.

#5 mhagain   Crossbones+   -  Reputation: 8139

Like
0Likes
Like

Posted 10 July 2012 - 09:14 AM

You can also use GLIntercept and configure it to log errors - that may be a better option for this kind of use case.

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS