Screen Corruption When Using OpenGL

Hi Everyone,

Emphatic thanks for any help received regarding this plea.

I have been using OpenGL to render some scenes using Visual C++ 6.0. I am developing on Windows 2000 using an 32Mb ATI Rage 128 Ultra graphics card.

Recently, I have noticed that while I have my OpenGL application running, some screen corruption can be seen under certain conditions, specifically where I know the R2_NOT raster operation to be used. Closing my OpenGL application resolves this ‘problem’ instantly.

I have only noticed this problem on my machine/setup. I have the latest drivers supplied by Dell for my graphics card and have also tried ATI’s reference drivers, but the problem remains.

However, I have also noticed that I can use other people’s OpenGL applications free of this corruption. Hence, I wonder if I am doing something wrong.

I have stripped out most of my code and have reproduced the problem with skeleton code, which I shall include here and would be appreciative if anybody can point out anything (evrything?) I am doing wrong.

Originally, it seemed that the problem occurred once I had set up my OpenGL surface and subsequently called glFlush() (or any function that indirectly invoked glFlush()). But, because this code can call these before the dialog is displayed, I am less sure.

OK, this code creates a small dialog box with two buttons…one quits, one calls glFlush(), though the corruption tends to occur even before the button is clicked, but when the dialog is displayed.

The dialog has three private members also:
HDC m_DAHdc;
HGLRC m_glRContext;
PIXELFORMATDESCRIPTOR m_pfd;

COpenGLTestDlg::COpenGLTestDlg(CWnd* pParent /=NULL/)
: CDialog(COpenGLTestDlg::IDD, pParent)
{
//{{AFX_DATA_INIT(COpenGLTestDlg)
// NOTE: the ClassWizard will add member initialization here
//}}AFX_DATA_INIT
// Note that LoadIcon does not require a subsequent DestroyIcon in Win32
m_hIcon = AfxGetApp()->LoadIcon(IDR_MAINFRAME);

m_DAHdc = NULL;
m_glRContext = NULL;

}

void COpenGLTestDlg::OnButton()
{
glFlush();
}

int COpenGLTestDlg::OnCreate(LPCREATESTRUCT lpCreateStruct)
{
if (CDialog::OnCreate(lpCreateStruct) == -1)
return -1;

CDC *dc = GetDC();
m_DAHdc = dc->GetSafeHdc();

int pfindex;
BOOL result;

memset(&m_pfd, 0, sizeof(PIXELFORMATDESCRIPTOR));

m_pfd.nSize		= sizeof(PIXELFORMATDESCRIPTOR);
m_pfd.nVersion	= 1;

m_pfd.dwFlags	=	PFD_DOUBLEBUFFER	|
					PFD_SUPPORT_OPENGL	|
					PFD_DRAW_TO_WINDOW;

m_pfd.iPixelType	= PFD_TYPE_RGBA;
m_pfd.cColorBits	= 24;

m_pfd.cDepthBits	= 16;
m_pfd.cRedBits		= 0;
m_pfd.cRedShift		= 0;
m_pfd.cGreenBits	= 0;
m_pfd.cGreenShift	= 0;
m_pfd.cBlueBits		= 0;
m_pfd.cBlueShift	= 0;
m_pfd.cAlphaBits	= 0;
m_pfd.cAlphaShift	= 0;

m_pfd.iLayerType	= PFD_MAIN_PLANE;

pfindex = ChoosePixelFormat(m_DAHdc, &m_pfd);

if(pfindex == 0)
{
	TRACE("ChoosePixelFormat Failed %d

", GetLastError());
}

result = SetPixelFormat(m_DAHdc, pfindex, &m_pfd);

if(!result)
{
	TRACE("SetPixelFormat Failed %d

", GetLastError());
}

m_glRContext = wglCreateContext(m_DAHdc);

if(!m_glRContext)
{
	TRACE("wglCreateContext Failed %d

", GetLastError());
}

if(wglMakeCurrent(m_DAHdc, m_glRContext) == FALSE) 
{
	TRACE("Chosen Pixel Format = %d

", pfindex);
}
return 0;
}

void COpenGLTestDlg::OnDestroy()
{
CDialog::OnDestroy();

::ReleaseDC((HWND)this, m_DAHdc);

}

Many many thanks,
Lucyxx

When do you delete the opengl context? You may be lossing some video memory because of that and probably your drivers arent doing a good job in that case (typical)

wglMakeCurrent(NULL, NULL);
wglDeleteContext(GLContext);

V-man

I have the same setup (W2K/ATI128) and I have found out that the ATI drivers are not truly W2K compatiable. I have some trouble with both directx and opengl on my computer, whereas it works perfectly on other computers with different graphics cards.

Have you tried your code on another computer?

Hi,

Thanks for your help everyone.

Sorry, I was a bit misleading by not deleting my rendering context in the example code…this is something I usually do, but overlooked in my ‘stripped down’ example. So, although a valid and acute suggestion, it mustn’t be the problem.

Regarding the drivers, I have now tried my code on 3 other computers. Two have different setups and one the same. Oddly enough, there is corruption on the one but none on the other two. So, although not conclusive, it may look like a driver issue.

Thanks and Kind Regards,
Lucyxx