Jump to content
  • Advertisement
Sign in to follow this  
extralongpants

OpenGL Wacky OpenGL wrapper feature

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

I decided to dig up an old OpenGL wrapper I made, and use it in my current project. While looking over my code, I came across an odd feature: I had made it so that my glBegin and glEnd related functions (like glVertex and glTexCoord) could be in one of two modes: direct and auto. While in "direct mode", the functions worked just as they might be expected to -they called their associated function (vertex would call glVertex3f, etc.). In "auto mode", however, a call to a vertex related function would simply add data to a global vertex array. When the user called the end() function, the array would be drawn. To initiate "auto mode" the user would call a beginArray() function, instead of a normal begin() function, and would have to pass in the array mode (GL_C4F_V3F and the like) and the number of vertices to be drawn, as well as the primitive type. Now I can't help but wonder: was this completely useless? At the time, I thought that it might be usefull, just because it was more intuitive than using traditional vertex arrays. Another thing I was counting on, was that it would be faster than using normal OpenGL per-vertex functions. Would my method be any faster? Or is that exactly what openGL does behind the scenes anyway? Would my way be slower? Anyway, I just thought I'd see what you all thought of my wacky feature, and if I should throw it out, enhance it, or ignore it.

Share this post


Link to post
Share on other sites
Advertisement
perhaps it would be faster, perhaps slower depending on the dataset.
eg there are cases where plain old immediate is fast at.
eg data that changes from frame to frame so u cant batch it up beforehand, also in immediate u can supply one normal for a polygon, and all the vertices of the polygon get it, with vertexarrays u have to supply that normal for each vertex

Share this post


Link to post
Share on other sites
I rather imagine it depends upon how well the OpenGL driver deals with rendering immediate primitives. Your method has two things going for it:

Firstly, you know that everything between beginArray/end will be drawn in the same render state -- same texture, same lighting, etc. The GL doesn't have that special knowledge, and may not be able to process things as efficiency.

Secondly, you know the size of the array before hand. The GL doesn't know how many vertices you're going to stuff into a begin/end, and therefore would either have to (1) dynamically grow the array it was using to store vertex data or (2) render a fixed size array each time it got full. With the first technique, you have memory management overhead (possibly including moving large arrays around), with the second you can't apply optimisations across several small arrays that might be possible across a single large array.

Thirdly, calling a GL function may be more expensive than calling a function in your own code, even if the functions do exactly the same thing.

In short, the primary reason your approach may be faster on some hardware and driver combinations is that you have special knowledge about the data you are processing that the GL does not, and can tailor your algorithms and structures to best suit that data.

Share this post


Link to post
Share on other sites
Thank you for the replies. Well, since my method doesn't seem too outrageous, I'll keep it, but I don't think I'll spend any time optimizing it, unless I develop a need for it. Regardless, it is good to hear that my method probably isn't too slow. Thanks again for your input.

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.

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!