glVertexPointer: Stride?

I don´t understand why the thing with stride value and glVertexPointer doesn´t work.

//code:
typedef struct{
float Pos[3]; //x,y,z values
float T[2]; //texcoords
}vertex;

vertex *Vertices;// a lot of vertices;

glVertexPointer(3,GL_FLOAT,stride,Vertices);

stride=8bytes(one float has 4bytes and there are two in the T variable);

Why doesn´t this work?
The problem:
If I declare the vertex struct without the texcoord and thet stride=0 then all works perfectly.
But if I include the texcoord and set stride=8 like mentioned above, the drawing-procces later(with gldrawelements) produces only some weird(randomly appearing) lines!

Am I misinterpreting the stride parameter?

Thanx in advance,XBTC!

Stride is the distance from the beginning of one entity, to the begginging of the following entity. In your case the stride would be sizeof(vertex), or 5*sizeof(float).

Thanx that makes sense.
The MSVC5 help told me:“stride is the byte offset between two vertices” or something like that which isn´t too precise.

Thanx again,XBTC!

Had a look in MSVC 6 help about stride, and it said: The byte offset between consecutive vertices. When stride is zero, the vertices are tightly packed in the array.

Offset is generally something you add to a value to get to the next entity. But I agree, the text itself you posted wasn’t too informative .

Hmm…Perhaps I should upgrade to MSVC6,too.
The help on OpenGl from a 3 year old compiler might not be the most up to date…

Greets,XBTC!

Sorry I have a question again! :
I added a glTexCoordPointer now:
glTextCoordPointer(2,GL_FLOAT,sizeof(vertex),
Vertices+12) //I add 12 here,cause the first texcoord in the array is 3 floats after the beggining of the array.

The Texcoords give very false results if I throw them tightly packed in an extra array I don´t get the problem.Why?

Thanx in advance,XBTC!

Try to call glTexCoordPointer with last argument like this: (or similar): &Vertices->T[0], this will give you the exact adress to the texcoords, even if you change the structure later.
I don’t see the problem though, the texcoords should start 12 bytes later.

If you pack you tightly pack your values in an array, stride must be 0! Because there is not byte between them.

Thanx I´ll try your idea,bob!
And Gorg: Did I write somwhere that I have a problem with the tightly packed array??

Thanx anyway,XBTC!

[This message has been edited by XBCT (edited 06-08-2000).]

Gorg: I think you have missunderstood what stride is. Stride is not the about of bytes between two elements, but the mount of bytes from the beginning of one element to the beginning of the following element. If you pass a zero as stride, it means they are tightly packed. If you have an array of floats, which contains vertices like this, x1,y1,z1,x2,y2,z2… and so on, you can set stride to either zero (as tightly packed), or 12 (3 floats*4 bytes each from the beginning of vertex one to the beginning of vertex two).

That sounds strange to me,how does OpenGl know if I want to specify the offset between the beginning of the struct to the beginning of the next one ore the offset BETWEEN to structs,if I pass a stride value?

Greets,XBTC!

Esay, you CAN’T pass the amount of bytes between. As simple as that. Stride==0 is just a special case for thightly packed elements. Usefull if you know you are always going to pack them tightly, no need to mess with bytes then.

XBCT,

Adding integers to pointers works like this:

some_type *tp = …;
some_type *tp2 = tp + 1;

int byte_offset = (int)tp2 - (int)tp;

byte_offset is now sizeof(some_type)

When you say (Vertices + 12) you’re really saying ((void *)Vertices + 12 * sizeof(vertex)).

Does this make sense?

[This message has been edited by cass (edited 06-08-2000).]

Duh! Of course!

Was thinking about why XBCT couldn’t get it to work, but now whe you mention it

The kind of error you can spend days looking for. So there’s a reason not to use numbers in code like that.

Oh *°"$§%&$"§!
Yes thanx alot.
And bob is right it´s always one of these simple errors which take days to find…

Thanx again,XBTC!