Jump to content
  • Advertisement
Sign in to follow this  
coderWalker

glGenBuffers doing nothing

This topic is 2636 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Someone please tell me why glGenBuffers is not giving an Unsigned Int.
I have been trying to figure this out the last 45 minutes.

It would be much appreciated if someone could spot what's wrong with this.
Thanks,
Walker


The first time called it does works perfectly, allocates the VBO and sets buffer to 1.
Here is the List (lst->vec) that is passed, as shown in Visual Studio C++:

+ [0] {x=-1.0000000 y=-1.0000000 z=-1.0000000 ...} vert
+ [1] {x=-1.0000000 y=-1.0000000 z=1.0000000 ...} vert
+ [2] {x=1.0000000 y=-1.0000000 z=1.0000000 ...} vert
+ [3] {x=1.0000000 y=-1.0000000 z=-1.0000000 ...} vert
+ [4] {x=-1.0000000 y=1.0000000 z=-1.0000000 ...} vert
+ [5] {x=-1.0000000 y=1.0000000 z=1.0000000 ...} vert
+ [6] {x=1.0000000 y=1.0000000 z=1.0000000 ...} vert
+ [7] {x=1.0000000 y=1.0000000 z=-1.0000000 ...} vert
+ [8] {x=-1.0000000 y=-1.0000000 z=-1.0000000 ...} vert
+ [9] {x=-1.0000000 y=1.0000000 z=-1.0000000 ...} vert
+ [10] {x=1.0000000 y=1.0000000 z=-1.0000000 ...} vert
+ [11] {x=1.0000000 y=-1.0000000 z=-1.0000000 ...} vert
+ [12] {x=-1.0000000 y=-1.0000000 z=1.0000000 ...} vert
+ [13] {x=-1.0000000 y=1.0000000 z=1.0000000 ...} vert
+ [14] {x=1.0000000 y=1.0000000 z=1.0000000 ...} vert
+ [15] {x=1.0000000 y=-1.0000000 z=1.0000000 ...} vert
+ [16] {x=-1.0000000 y=-1.0000000 z=-1.0000000 ...} vert
+ [17] {x=-1.0000000 y=-1.0000000 z=1.0000000 ...} vert
+ [18] {x=-1.0000000 y=1.0000000 z=1.0000000 ...} vert
+ [19] {x=-1.0000000 y=1.0000000 z=-1.0000000 ...} vert
+ [20] {x=1.0000000 y=-1.0000000 z=-1.0000000 ...} vert
+ [21] {x=1.0000000 y=-1.0000000 z=1.0000000 ...} vert
+ [22] {x=1.0000000 y=1.0000000 z=1.0000000 ...} vert
+ [23] {x=1.0000000 y=1.0000000 z=-1.0000000 ...} vert
[/quote]

However the second time it does not change Buffer at all even though the data is viable.
The strange thing is it doesn't even create a VBO, because when I pause the program in gDebugger it only shows one VBO
and after viewing the verticies, they are the verticies of the first VBO.
So the problem is:
It doesn't allocate the VBO nor does it set the buffer to an GLuint.
Here is the list the second call:
+ [0] {x=7.0000000 y=13.000000 z=14.000000 ...} vert
+ [1] {x=7.0000000 y=13.000000 z=15.000000 ...} vert
+ [2] {x=7.0000000 y=14.000000 z=15.000000 ...} vert
+ [3] {x=7.0000000 y=14.000000 z=14.000000 ...} vert
+ [4] {x=7.0000000 y=14.000000 z=14.000000 ...} vert
+ [5] {x=7.0000000 y=14.000000 z=15.000000 ...} vert
+ [6] {x=7.0000000 y=15.000000 z=15.000000 ...} vert
+ [7] {x=7.0000000 y=15.000000 z=14.000000 ...} vert
[/quote]

makeBuffer Functions:
model::model(list* lst)
{
int len = lst->vec.size();
buffer = gl::makeBuffer( GL_ARRAY_BUFFER, (void*)&lst->vec[0], len*32 );
}
GLuint makeBuffer( GLenum target, const void *buffer_data, GLsizei buffer_size )
{
GLuint buffer;
glGenBuffers(1, &buffer);
glBindBuffer(target, buffer);
glBufferData(target, buffer_size, buffer_data, GL_STATIC_DRAW);
return buffer;
}

Share this post


Link to post
Share on other sites
Advertisement

Do you have a GL context current?


I'm not sure, how do I know?

Threading!

Also! I just realized something I forgot to mention!
I have one thread drawing a scene using a GLSL program and VBO's
and I'm trying to create more VBO's in a second thread running in parallel.

Does this have anything to do with it not working?

I have not seen one difference between the two calls, until just now.
The first is called before the Second thread starts and the rest are called from the second thread while the first draws

Threading Structure
Thread A creation
[color="#0000FF"]A) Create Loading screen VBO, Program, etc (Perfect)
A) Create thread B
[color="#A0522D"]B) Draw Loading screen (main VBO and program) (repetitive )
[color="#0000FF"]A) Create the games VBOS (FAILS)
if (Thread A = done loading)
Kill thread B
A) run main game code

Share this post


Link to post
Share on other sites

Yhat is the worst idea to call openGL on two different threads. openGL cant be threaded anyway.


I didn't think about that! I guess that's true though, since it's a state machine that would be very bad.
Thanks man! I got the VBO's allocating with main thread now, however am having trouble drawing them.

Anyway,
I want to draw a loading screen and load the game world (allocate VBO's) what's the best way to do this?
Now that I'm using VBO's instead of Client-side Arrays, it's not possible to multi-thread it anymore, is it?

Share this post


Link to post
Share on other sites

Anyway,
I want to draw a loading screen and load the game world (allocate VBO's) what's the best way to do this?
Now that I'm using VBO's instead of Client-side Arrays, it's not possible to multi-thread it anymore, is it?


There are plenty of ways, the oldest is probably to simply do a little work each frame (unless you see reason to draw a loading screen at 500fps). For a more annoying situation (loading chunks of terrain while playing) I decided that TBBs pipelines are neat. The steps in the pipeline would be:
-Load data (only one thread, unless you happen to use an SSD)
-Uncompress data (as many threads as TBB decides to assign)
-Process data (in my case, turning MC chunk data into geometry data.. multiple threads)
-Upload data to VBO (one and only thread doing this is the main thread with an optional time limit)

The last part simply loops until no further chunks are ready to be uploaded (or all chunks are done or a time limit per frame is reached). Obviously you can do it without using TBB, but I like to automatically use as many threads as make sense on a given machine (plus, you don't need to deal with synchronizing your threads and worry about how to pass the data from one stage to another). I also expect Intels developers to do a better job than whatever I'd put together on short notice.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • 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!