New to forums - 2 questions

I am new to these forums, so please be patient with me.

I have two questions to start with:

(1) I have developed a GUI engine (for use with PowerBasic) which is now in its 5th generation and I am currently writing a custom control which supports 3D drawing using OpenGL. If I read the this web page correctly : http://www.opengl.org/about/licensing/ only those who write device drivers (aka. video card manufacturers) are required to license OpenGl from SGI.

Would this mean that software developers who write GUI engines based on OpenGL don’t have to buy any license ?

I have a GUI engine (for use with Powerbasic) which is going into its 5th generation and I am currently writing a custom graphic control which uses OpenGL for 3D drawing. My software is sold to programmers who use it to build applications. Am I correct to assume I would fall into the catagory of those who do not have to license OpenGL ?

(2) This question is about actual OpenGL coding.

I currently am using glDrawPixels and it is terribly slow on the common video cards/chips found on mass market computers. Is there any way to optimize it to speed it up to maximum speed (within the hardwares limits of course) ?

The reason I need this, is the custom control I am writing is a superclass of an existing 2D (GDI based) Graphic control I also wrote. The control is a hybrid of sorts. It can draw 2D graphics and has its own sprite engine and I am using what it draws as a background for the OpenGL based control. I need to copy a DIBsection every animation cycle from its buffers to the OpenGL buffer and then draw OpenGL graphics on top of it.

I have it working, its just a bit slow. On Windows XP (2.5 ghz CPU, NVidia GeForce4 MX 4000 video card) I get about 27 frames per second with a window about 640 x 440 pixels.

When I turn off the image copy (just clear OpenGL buffer background with a solid color) I cna get about 250 fps (while animating 5 primitives rotating around their own axes, rotating around the windows center and changing perspective every cycle (appears to moving farther away and then starts coming back closer again).

Any suggestions on how to optimize glDrawPixels would be appreciated.

  1. you don’t need to get a license.
  2. do not use gldrawpixels. Upload texture data long before you need to use that data. GDI and 3D-accelerated surfaces do not mix together in Vista and Win7.

I need to use glDrawPixels !

The control will have multiple modes:

(1) Every interation of an animation, the background image will be updated (glDrawPixels drawing into back buffer). This image will change in every cycle, since it itself can do 2D animation.
(SLOW)

(2) The background image, need not be updated often but will be updated. In this instance, I plan on adding the ability to copy the image to a textures and then texture a flat plane (3D object) in the background. This will allow faster display rates and allow the background to be rotated and moved.
(FASTER)

(3) No background image required, so background will simply be cleared with a solid color every cycle. Only 3D objects will be displayed.
(FASTEST)

The OpenGL window will not always be a large window. This is a custom control for use on user interaces (lots of other controls) and there may be multiple instances of this OpenGL control on a form at a time in multiple sizes (small to large). The control is a Hybrid control which superclasses an existing 2D Graphic control which I also wrote (it does high speed 2D animation using a proprietary sprite engine).

Render to texture (FBO), disable depth buffer write, and draw textured full screen quad(background) - eliminates glDrawPixels.

You could also use glTexSubImage2D to update a single texture object from your raw background image data, then draw it as a texture. This would have the advatage that it would also work on older hardware that doesn’t support FBOs.

if (!backpic)
{
	glGenTextures (...
	glBindTexture (...
	glTexImage2D (...
}
else
{
	glBindTexture (...
	glTexSubImage2D (...
}

glBegin (GL_QUADS);
	.
	.
	.
	.
glEnd ();

If you still absolutely must use glDrawPixels, look at 22.070 here: http://www.opengl.org/resources/faq/technical/performance.htm and implement the recommendations. Then check your state during your glDrawPixels call. If texturing is enabled, OpenGL will quite happily apply the currently bound texture to each pixel, so disable texturing (http://www.mesa3d.org/brianp/sig97/gotchas.htm). Likewise disable lighting, shaders or anything else that you don’t explicitly want here but might be using elsewhere.

Will any of the following OpenGL calls effect the speed of glDrawPixels ?

glOrtho

glHint (which states ?)

glEnable or glDisable (which states ?)

glPixelStorei (which states ?)

glPixelTransferi (which states ?)

glPixelZoom

Is it best to set glOrtho to the same scale (size/width) as the actual window (meaning defining the same width and height as the window is in pixels for a one to one coorespendence) ?

Which executes faster with glDrawPixels?

GL_BGRA_EXT
GL_ABGR_EXT
GL_RGBA

I can prepare the bitmap data in any one of the three formats with ease.

Update:

I now have a working OpenGL based custom control!
It is a real windows control (unique window class) which can have multiple instances of itself.

It has a 3D engine which supports a variety of 3D primitives, has a built in GL primitive definition language (to design models using simple 3D primitives), supports 2 light sources, supports a Material list and a model list which can be shared among all the instances of the control, can store an unlimited number of Scene Objects per control and more.

Scene objects can also be STL models for models with high polygon counts. I have tested it with a model with as many as 400,000 triangles in it (polygons).

Scene Objects can be rotated on their own personal origin (X,Y,Z axis) as well as be rotated on the scenes origin (0,0,0). Objects can use any defined model (STL, 3D Primitive or enhanced STL format). Objects can also be scaled in any direction (X,Y,Z).

It also supports perspective too.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.