2D ring - should I use gluDisk, or glVertex2f?
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?
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?
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.
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?
I figured out how to get anti-aliasing working without using FSAA:
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?
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?
If you're careful with how you draw your polygons, it shouldn't have any problems. You can always do glEnable(GL_MULTISAMPLE); though.
... 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.
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.
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.
Forgive me Keith... I'm a total newbie when it comes to OpenGL. After reading this, I think I'll tackle VBOs first.Thanks!
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.
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.
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
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.
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.
You were right about display lists being incredibly easy to use.
This is a non-dynamic 2D ring? Why not just a single quad with a texture?
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.
The thickness of the ring will change, though. It will also get blurry if it gets too large.

