Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

CRACK123

OpenGL vectors and opengl

This topic is 5533 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

Hey, I define a vector as float and put data into it, but when I render it, the rendering does not happen. But if I render the same data using glBegin and glEnd giving exact values it renders. Here is the code I am using
  
vector <float> m_particleArray;   // my vector


m_particleArray.push_back(0);
m_particleArray.push_back(0);
m_particleArray.push_back(-10);

//and I am using interleaved arrays to render it


glInterleavedArrays(GL_V3F, 0, &m_particleArray);
glDrawArrays(GL_POINTS, 0, 1);

  
Nothing gets rendered with that code. But with the following code it renders fine
  
glBegin(GL_POINTS);
    glVertex3f(0, 0, -10);
glEnd();
  
Is it vectors that is causing this or is it my code ?? Can I use vectors with OpenGL. From what I understand I should be able to. Or is it that my understanding of vectors is slightly flawed ? Hope someone can answer my question. Thank you.

Share this post


Link to post
Share on other sites
Advertisement
During your init are you making a call to glEnableClientStae(GL_VERTEX_ARRAY)? I think this may be where your problem lies.

Share this post


Link to post
Share on other sites
std::vector isn''t compatible with a traditional array, as I am explaining to you on irc now

Share this post


Link to post
Share on other sites
I am pretty sure glInterleavedArrays does the enabling and disabling of clientstates. So that is definitely not the problem.

It probably must be that my understanding of c++ vectors is flawed .

Share this post


Link to post
Share on other sites
are you seriously passing the adress of the vector itself which is just a container with the actual data stored who knows where? at least do something like &vector[0] and hope the best.
and why draw only one sprite, which should be 0,0,0 and not 0,0,-10 like in the second version.

Share this post


Link to post
Share on other sites
quote:
Original post by Trienco
are you seriously passing the adress of the vector itself which is just a container with the actual data stored who knows where? at least do something like &vector[0] and hope the best.
and why draw only one sprite, which should be 0,0,0 and not 0,0,-10 like in the second version.


Q1. Why should it be 0,0,0 ??
With a push_back &vector[0] didn''t work, with a reserve it did.

Yes, seriously I was doing it. I really don''t see anything wrong in making mistakes. I made a mistake, I will probably make a lot more, the only way I will learn is from my mistakes. They may be dumb, they may not

Share this post


Link to post
Share on other sites
does the function really take a void* ? i guess it has to to be flexible. but it seems the downside is that it virtually takes everything *g*

it was the part about your understanding of vectors. i thought you have a rough idea of what all those stl containers are. im sure you do by now, but just in case:

class stl_whatever {
_ couple of members _
_ lots of functions _
_ pointer to actual data _
};

"Q1. Why should it be 0,0,0 ??
With a push_back &vector[0] didn't work, with a reserve it did."

because i didnt have a close enough look and thought you were adding three vertices when you were adding coordinates.

i didnt mean to use push_back and &vector[0] but to use &m_particleArray[0] when you set the interleaved array. of course hoping the data really is stored in the right way (one block and the correct order). you could still happen to use an stl implementation that for whatever reason stores the vector in reversed order, but that should be extremely unlikely.

the idea is that array[0] returns a reference to the beginning of the actual data and & should give its address.

[edited by - Trienco on May 30, 2003 4:55:53 AM]

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!