Elysian Shadows

I'm glad that fixed it. You'll pick up the terminology as you go.

The user pointer doesn't operate terribly much different from the immediate mode processing, instead it attempts to make better use of vertex cache coherency and reduce DMA overhead to the card by batching multiple vertices at a time. They're still very very slow. Matrices are not "pushed onto vertices" or anything like that. When you make a draw call, whether it's via an immediate mode begin/end pair, or via a hardware buffered draw arrays call, all the vertices are simply passed through the top-most (current) modelview and projection matrices at all times...no matter what..and all this is part of the vertex processing pipeline.

So glVertexPointer in his case is just another method of sending the information through the pipes. They get transformed just the same.

I dont know enough about OpenGL to know what most of the functions do... Im just following tutorials at thus point. Soon, hopefully, Ill understand.

I have a question about glRotatef.

I have been just trying trying to get a 2d box to spin around. I finally got this piece of code to work.
Since I have a 1.0 in my z coordinate, I am imagining my rectangle on the end of a pole, and I am simply turning the pole.

I have the Redbook here with me, and it's not helping me much either.

Anyone care to elaborate on exactly how this is working? I'm still learning opengl, I'm super new to it still.

Thanks

edit: What does the 1.0f in the z parameter do?

Yeah, that's exactly how you should imagine it. I'm guessing your rectangle is in 2D?

The two perpendicular edges of your rectangle are your x and y axes. Then the pole is perpendicular to the two, being the z coordinate. Since you're rotating about the z coordinate, it is analogous to the pole rotating through it.

The 1.0f in the z parameter is how much of the rotation transform you want to affect each axis. 0.0-1.0f. 0.0 is nothing (because you aren't rotating through x or y), and z is 1.0 (because the entire rotation is through the z).

Another question: I have pretty much everything working so far that I need, but when I tried to import a .png file with alpha/transparency, it just showed up as a my image with a black background... how do I fix this?

Are you using sdl_image?

I'm doing iPhone development, with OpenGL ES. No SDL involved. Though I wish it was, SDL was my best friend back with my old Windows computer!

I'm not sure if GyroVorbis fixed your mistake or not, but with what I have done so far in OpenGL ES, I always use a -1.0 for my Z value in all my vertices, because going negative makes it go away from the camera in a forward motion. When you set up your orthogonal/frustum view you might have set the near parameter to 0.001, which is greater than 0, thus making the rectangle not display. Just guessing, I could(most likely) be wrong.

ibly31 wrote:Another question: I have pretty much everything working so far that I need, but when I tried to import a .png file with alpha/transparency, it just showed up as a my image with a black background... how do I fix this?

[Edit] Oops, thought you said blank. Read what qpHalcy0n wrote

If the image is showing but not blending, then most likely you have not enabled alpha blending. If you want to smoothly blend with the rest of the scene you'll need to turn z-testing off (if you're doing depth tests) and render back to front blending the source alpha to the inverted source's alpha value.
The following enables alpha blending:

Ah, yes. Thanks. I have that in my setupView: function, and I only call it once, it seems to work. Is it better practice to glEnable and glDisable EVERY time the scene is drawn?

ibly31 wrote:Ah, yes. Thanks. I have that in my setupView: function, and I only call it once, it seems to work. Is it better practice to glEnable and glDisable EVERY time the scene is drawn?

The chances are that eventually you will have things blended and not blended in the scene, in which case you don't have a choice. So there's nothing wrong with doing it.

Oh, okay. Can you give me an example of when you'd need to do blended and non-blended work in a game/ simulation?

Well, any time you have alpha blended faces you'll need to do a proper sort. Generally you'd do a pass w/ the opaque geometry front to back w/ blending disabled. By rendering front to back you can make use of early z-rejection and on some video cards double speed or quadruple speed depth writes (normally when color writes are disabled). Then you would disable depth testing, enable alpha blending, sort the transparent faces back to front, and then render them. Always reset the original render state when you're done. Just be cautious to not redundantly (normally redundant calls are buffered out) and excessively enable blending. Alpha blending is one of the more expensive post pixel processing routines.