I have been experimenting with mapping the dialog surface as a texture to a polygon but it was dead slow. I need some speed here since I have scrollbars and users expect them to be fast.
Now, I began to use glDrawPixels() instead but I don’t know how fast it is yet. Does anyone know it it is slow?
Another thing is that glDrawPixels() expects the image’s pixel data to begin with the lower left corner of the image. I really want this to be the upper left corner instead to avoid rewriting the dialog system. I can’t seem to do that. Is it possible?
Is there any other (faster) way of getting 2d-images to the OpenGL window?
Are you using glTexImage2D or gluBuild2DMipmaps to update the new texture?
A faster way to do it would be to use glTexImage2D the first time you use the texture object and then use glTexSubImage2D to update the texture every frame.
If you are creating mipmapped textures using gluBuild2DMipmaps then I would suggest looking into the GL_SGIS_generate_mipmap extension (supported by GeForce hardware) to significantly speed up this process.
Originally posted by Zeno:
[b]If drawing one texturemapped polygon is “dead slow”, then either:
You are not doing it right
Your hardware is REALLY old
Rendering is going to software for some reason
That is the fastest way to draw 2d scenes.
[/b]
Is it really faster than glDrawPixels?
You have a point there (rather three). I have to add that I want a game to run at the same time, which makes the speed more important than if I just have the dialog in itself.
> It is “dead slow” because I need to update
> the texture that can be 400x500 pixels for
> example often. It is not enough fast for a
> dialog system.
So? Uploading a 400x500 pixel texture shouldn’t take a substantial part of your frame render time (though it’s slower than not uploading, of course
If you’re drawing the 2D UI in a pixel-for-pixel mapping to the screen, you should NOT spend time building MIP maps. You should also draw in GL_NEAREST interpolation mode, as filtering will make the 2D UI less crisp.
your button is:
a quad, with 2 possible stages… not clicking, clicking => 2 textures ( or one, and changing texcoors
your scrollbar is:
three buttons, two with arrows on, one not
a background quad
your textbox is:
a rect where you can print text in
your text is:
quads with part of a font-texture ( nehe texture-font tutorial )
and your window is:
a quad for title bar, with a textline in, some buttons for closing, minimizeing,maximizeing, and the left menubutton ( suppose you want a windows-windows system… )
and a quad with all those objects in…
=> drawing bout 10 - 20 quads for the whole window, text not countet…
Originally posted by jra101: Are you using glTexImage2D or gluBuild2DMipmaps to update the new texture?
I’m using glTexImage2D.
A faster way to do it would be to use glTexImage2D the first time you use the texture object and then use glTexSubImage2D to update the texture every frame.
A good idea. The image objects I’m using supports dirty rectangles so that would be easy to add.
Ok, the existing dialog system generates an image with the entire layout, it has been used for pure 2d rendering also. That’s why I want to stick to one polygon and not to split it into several.
I think I get the point, however. Uploading a new texture per update shouldn’t take so much time compared to the rest of a game. I thought that texture uploading was a bottleneck. I will measure it of course.
