Would it be faster if...
Author
I put everything with the same texture under the same glBegin(GL_QUADS)... glEnd();, but to compensate for different rotations used cos and sin in all the vertices? or is cos and sin too slow? am i better off just starting a new glBegin etc. for each quad, translating and rotating appropriately before hand?
-plasmicsoup
it would be faster if everything used the same texture, I don''t think you need to use sin and cos the move the vertices. I''m not sure it really matters that much if it''s all in the same glBegin()-glEnd block for speed''s sake.
My Homepage
My Homepage
Author
I read that putting things under the same glBegin and end block is much faster than starting and stopping 200 times a frame, which is basically what i do right now.
I should clarify though: not all objects are the same texture, just those that are i want to put under the same glBegin as you can change a texture/translate/rotate with those blocks. to compensate for that, im going to put the vertices of each new quad relative to the center for being unable to translate which is simple. for rotation, im going to use cos and sin to figure out the values for each vertices based on the angle rotation, eliminating the need to use glRotatef which i cant use between glBegin and glEnd, which wouldnt allow me to combine everything within one black of glBegin and glEnd, per object of the same texture.
My question is, is it worth doing this, as I don''t know how slow/fast cos and sin are. So I guess essential my question is, are the sin and cos functions fast enough to use 4 times per object (250+ objects on screen at once) per frame?
-plasmicsoup
Gilgamesh Games
I should clarify though: not all objects are the same texture, just those that are i want to put under the same glBegin as you can change a texture/translate/rotate with those blocks. to compensate for that, im going to put the vertices of each new quad relative to the center for being unable to translate which is simple. for rotation, im going to use cos and sin to figure out the values for each vertices based on the angle rotation, eliminating the need to use glRotatef which i cant use between glBegin and glEnd, which wouldnt allow me to combine everything within one black of glBegin and glEnd, per object of the same texture.
My question is, is it worth doing this, as I don''t know how slow/fast cos and sin are. So I guess essential my question is, are the sin and cos functions fast enough to use 4 times per object (250+ objects on screen at once) per frame?
-plasmicsoup
Gilgamesh Games
Don''t waste a lot of time worrying about this.
#1 - Sounds like you haven''t profiled yet.
#2 - GlBegin/GlEnd is slow no matter what you do. You''ll be switching to glDrawElements soon enough.
#1 - Sounds like you haven''t profiled yet.
#2 - GlBegin/GlEnd is slow no matter what you do. You''ll be switching to glDrawElements soon enough.
Author
Alright, I give up trying to figure this out... how do i use glDrawElements? I have no experience with vertex arrays and whatnot.
-plasmicsoup
Gilgamesh Games
-plasmicsoup
Gilgamesh Games
to use glDrawElements:
let''s say you have a bunch of indexed triangles.
And using DrawElements:
Check your docs if you want to tweak these settings.
If you want to pass normals or texture coords, check out glTexCoordPointer, or glNormalPointer
Don''t forget to glEnableClientState on anything you need.
let''s say you have a bunch of indexed triangles.
float verts[NUM_VERTS][3];unsigned int indices[NUM_TRIANGLES*3];//to draw in immediate modeglBegin(GL_TRIANGLES);for(int i=0;i<NUM_TRIANGLES;i++){ glVertex3fv(verts[indices[3*i+0]]); glVertex3fv(verts[indices[3*i+1]]); glVertex3fv(verts[indices[3*i+2]]);}glEnd(); And using DrawElements:
float verts[NUM_VERTS][3];unsigned int indices[NUM_TRIANGLES*3];//do this in your setup codeglEnableClientState(GL_VERTEX_ARRAY);//render codeglVertexPointer(3,GL_FLOAT,0,verts);glDrawElements(GL_TRIANGLES,NUM_TRIANGLES*3,GL_UNSIGNED_INT,indices); Check your docs if you want to tweak these settings.
If you want to pass normals or texture coords, check out glTexCoordPointer, or glNormalPointer
Don''t forget to glEnableClientState on anything you need.
Author
Is it faster to call DrawElements 20 times with 20 triangles rendered each, or is it faster to call DrawElements once with 400 triangles? I''m guessing the first?
-plasmicsoup
Gilgamesh Games
-plasmicsoup
Gilgamesh Games
Author
Yet another "which is faster", should i draw my sprites (originally 4 pointed tristrips) each with its own DrawElements as tristrips? or do it all as quads in one? or triangles in one?
>>Is it faster to call DrawElements 20 times with 20 triangles rendered each, or is it faster to call DrawElements once with 400 triangles? I''m guessing the first? <<
on all cards i know the 2nd will be techinacally quicker (though u will most likely see no difference in the framerate between the two)
>>I put everything with the same texture under the same glBegin(GL_QUADS)... glEnd();, but to compensate for different rotations used cos and sin in all the vertices? or is cos and sin too slow? am i better off just starting a new glBegin etc. for each quad, translating and rotating appropriately before hand? <<
sin + cos are very fast to do on any processor since 1995.
eg say my game runs at 102.34 fps + i added 10000 cos calls it would still run at 102.34 fps
A/ calculate the vertices (with sin or cos or whatever) and then pass the vertices to opengl.
as the AP saiz most importanta
GET THE THING WORKING AND THEN WORRY ABOUT PERFORMANCE LATER
http://uk.geocities.com/sloppyturds/kea/kea.html
http://uk.geocities.com/sloppyturds/gotterdammerung.html
on all cards i know the 2nd will be techinacally quicker (though u will most likely see no difference in the framerate between the two)
>>I put everything with the same texture under the same glBegin(GL_QUADS)... glEnd();, but to compensate for different rotations used cos and sin in all the vertices? or is cos and sin too slow? am i better off just starting a new glBegin etc. for each quad, translating and rotating appropriately before hand? <<
sin + cos are very fast to do on any processor since 1995.
eg say my game runs at 102.34 fps + i added 10000 cos calls it would still run at 102.34 fps
A/ calculate the vertices (with sin or cos or whatever) and then pass the vertices to opengl.
as the AP saiz most importanta
GET THE THING WORKING AND THEN WORRY ABOUT PERFORMANCE LATER
http://uk.geocities.com/sloppyturds/kea/kea.html
http://uk.geocities.com/sloppyturds/gotterdammerung.html
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
