2D ring - should I use gluDisk, or glVertex2f?

Member
Posts: 208
Joined: 2005.04
Post: #1
To draw a ring in 2D space, which would be more efficient - using gluDisk, or constructing it by hand using a bunch of glVertex2f calls? The ring is going to be about 400px in diameter and 4px thick. If I were to do it by hand, would it be best to use thick lines, triangles, or quads?

Also, I want the ring to look nice without impacting the frame rate of my game. For 2D (I.E. no depth or lighting), is it best to use GL_SMOOTH, or is FSAA the better choice? Or how about arekkusu's Texture AA?
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #2
I'd use a disk with 1 loop. As for making it look better, GL_SMOOTH and FSAA are totally different. GL_SMOOTH is for smooth shading, as in whether the colors are interpolated between vertices or not. Using FSAA is for anti-aliasing, which I'm guessing is what you want.
Quote this message in a reply
Member
Posts: 208
Joined: 2005.04
Post: #3
akb825 Wrote:I'd use a disk with 1 loop. As for making it look better, GL_SMOOTH and FSAA are totally different. GL_SMOOTH is for smooth shading, as in whether the colors are interpolated between vertices or not. Using FSAA is for anti-aliasing, which I'm guessing is what you want.

Oh.. what about GL_LINE_SMOOTH, GL_POLYGON_SMOOTH, or GL_BLEND?
Quote this message in a reply
Member
Posts: 208
Joined: 2005.04
Post: #4
I figured out how to get anti-aliasing working without using FSAA:

Code:
glBlendFunc(GL_SRC_ALPHA_SATURATE, GL_ONE);
glEnable(GL_BLEND);
glEnable(GL_POLYGON_SMOOTH);

Other than ditching the depth buffer, and making sure I pass the right constants into glBlendFunc, are there any "gotchas" when anti-aliasing this way?
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #5
If you're careful with how you draw your polygons, it shouldn't have any problems. You can always do glEnable(GL_MULTISAMPLE); though.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #6
... if you've requested a multisample pixel format, that is.

The original question is a bit odd though, "should I use a really horribly slow and poorly-suited to my purpose method, or just a really horribly slow one?"

If you care about speed, use a vertex buffer object or a display list.
Quote this message in a reply
Member
Posts: 208
Joined: 2005.04
Post: #7
OneSadCookie Wrote:The original question is a bit odd though, "should I use a really horribly slow and poorly-suited to my purpose method, or just a really horribly slow one?"

If you care about speed, use a vertex buffer object or a display list.

LOL Forgive me Keith... I'm a total newbie when it comes to OpenGL. After reading this, I think I'll tackle VBOs first.

Thanks!
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #8
Note that using VBOs require relatively new versions of OpenGL, and it may put the system requirements of your game much higher than it would using display lists. That example was done using 1 test, more or less, and depending on the situation your milage may vary. One example of VBOs going horribly wrong is Dantooine in Knights of the Old Republic: it absolutely dies unless you turn VBOs off. However, for the rest of the game, it's usually beneficial to have them on.

Edit: and using display lists is incredibly easy: just create a list, begin it, do your draw commands, end it, than call it. WIth VBOs, you have to make sure everything is in a vertex array, put it in a bufer, etc. It can get much more complicated depending on your scene. For this project, I'd recommend display lists.
Quote this message in a reply
Member
Posts: 208
Joined: 2005.04
Post: #9
akb825 Wrote:For this project, I'd recommend display lists.

Display list it is. What about graphics card issues? Do display lists work on all Mac OS X capable hardware?

Also, my game already requires Mac OS X v10.3 or later. In what version of Mac OS X were VBOs introduced into OpenGL? Are there hardware incompatibly issues with VBOs, or is it just the version of OpenGL I'd have to worry about if I went the VBO route?

Oh ya... can I stick gluDisk and gluPartialDisk calls inside a display list?

Thanks
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #10
Display lists have been available for a very long time (either from the beginning or 1.1 AFAIK) I know display lists used to work on the ATI Rage 128 on my old computer, so you should be fine with hardware. I believe VBOs were supported in Panther and higher on hardware that can support it. The biggest hardware limit, AFAIK, would be the fact that you're using the VRAM to store the VBOs, so if you have too many it could cause some performance issues on lower-end cards. (such as ones with 32 MB or less) Furthermore, VBOs are best with static objects. I'm not sure which cards started supporting them.

It is fine to use gluDisk or gluPartialDisk in a display list. That's the beauty of it: you can use any drawing commands you want. You can't with VBOs, though... You need to do everything in a vertex array.
Quote this message in a reply
Member
Posts: 208
Joined: 2005.04
Post: #11
You were right about display lists being incredibly easy to use. Smile
Quote this message in a reply
Member
Posts: 269
Joined: 2005.04
Post: #12
This is a non-dynamic 2D ring? Why not just a single quad with a texture?
Quote this message in a reply
Member
Posts: 208
Joined: 2005.04
Post: #13
Bachus Wrote:This is a non-dynamic 2D ring? Why not just a single quad with a texture?

Well, it needs to be scalable too.
Quote this message in a reply
mnajera
Unregistered
 
Post: #14
Andrew Wrote:Well, it needs to be scalable too.
You can scale a single quad.
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #15
The thickness of the ring will change, though. It will also get blurry if it gets too large.
Quote this message in a reply
Post Reply