Correct me if I’m wrong, but people who use to program in Borland C++ would experience divide by zero messages, right? I think it is because in opengl32.dll, it does some calculations that can cause a divide by zero. There was a solution to get rid of the messages I think. Anyone remember?
In Borland Delphi you had to change the FPU control word during program initialisation with the command:
Set8087CW($133F);
With any luck their C++ compiler uses the same command, with 0x133F for the hexadecimal value
Thanks for the reply.
In reality, the program is in VB6, GL 1.1. It has been working fine on various hardware (nvidia, AMD, intel). Recently, I discovered that on AMD HD 5450 and another one (6xxx), with Catalyst 13.1 (the current one), it flags division by 0 on functions like glScalef.
WTF? I had disabled FPU error reported in VB6. I wonder if the AMD driver is enabling it.
Here is the actual assembler code it uses if thats any help.
procedure Set8087CW(NewCW: Word);
begin
Default8087CW := NewCW;
asm
FNCLEX // don't raise pending exceptions enabled by the new flags
{$IFDEF PIC}
MOV EAX,[EBX].OFFSET Default8087CW
FLDCW [EAX]
{$ELSE}
FLDCW Default8087CW
{$ENDIF}
end;
end;
I had similar issues with odd releases of AMD drivers too!
Using the Set8087CW($133F); trick worked for me when I initialied the OpenGL context.
Yes, it is good when you can do it with your programming language.
A SOLUTION IS FOUND.
In VB6, go to project properties, click on compile tab.
Press the Advanced Optimizations button.
Click on Remove floating point exceptions check.
I had already done this in my project but for some reason, my partner’s VB6 did not have that checked.