Windows 95 / OPENGL Run Time Crash with Delphi

Windows 95 / OPENGL Run Time Crash with Delphi

Post by Walt Smi » Fri, 18 Oct 1996 04:00:00



I have written several test programs with the OpenGL Delphi Header
files that were ported by Richard hansen at Artemis Alliance.  He did
a wonderful job and the .pas units work flawlessly at design time.  At
run time, however, I am getting intermittent Floating point errors,
usually immediately following glRotate(x) or glTranslate(x).  I feel
that the overflow is probably in the Microsoft gl library.

Has anyone else experienced this problem either in C++ or Delphi?  Are
there any suggestions for work arounds or bug fixes?  I am currently
running Version 1.1 of the libraries, Version 2.0 of Delphi and am
using the OpenGL SuperBible as my programming guide (A great book).

Thanks for your help,
Walt Smith
Maidens Software Systems
Maidens, VA

 
 
 

Windows 95 / OPENGL Run Time Crash with Delphi

Post by Richard S. Wright Jr » Fri, 18 Oct 1996 04:00:00


Walt,

I'm glad you liked my book<g>! Your report of floating point errors sounds
very familiar. In fact, these same errors are frequently reported by users
of Borland C++. I believe that there is something fishy going on with
Borland's floating point support. Delphi and C++ are supposed to share the
same backend, so this would make sense. I've sent a demonstration to some
people at Microsoft who were interested in tracking down this problem, but
I haven't heard from them in a while.

It doesn't matter if your running 1.0 or 1.1 of the OpenGL binaries, or NT
3.51 or NT 4.0. It is a real and easily produced bug. I wish someone from
Borland would visit this forum from time to time. I tried in vain to bring
this to their attention during the 5.0 beta, but they seem to have more
than enough other problems to worry about right now...

Richard



Quote:> I have written several test programs with the OpenGL Delphi Header
> files that were ported by Richard hansen at Artemis Alliance.  He did
> a wonderful job and the .pas units work flawlessly at design time.  At
> run time, however, I am getting intermittent Floating point errors,
> usually immediately following glRotate(x) or glTranslate(x).  I feel
> that the overflow is probably in the Microsoft gl library.

> Has anyone else experienced this problem either in C++ or Delphi?  Are
> there any suggestions for work arounds or bug fixes?  I am currently
> running Version 1.1 of the libraries, Version 2.0 of Delphi and am
> using the OpenGL SuperBible as my programming guide (A great book).

> Thanks for your help,
> Walt Smith
> Maidens Software Systems
> Maidens, VA


 
 
 

Windows 95 / OPENGL Run Time Crash with Delphi

Post by Hock San L » Fri, 18 Oct 1996 04:00:00


Thanks for posting this!  Apparently, our MSDN beta users all use MSVC
compiler.

Hock San Lee
Microsoft Corporation


>I received this response via e-mail from Hock San Lee.  I assume from
>Hock San Lee and wished to post it for others to see.  I apologize if
>it was already posted, I did not see it.
>Best Regards.

>Walt,

>I believe this is the same problem others have been seeing.  We will
>fix
>this in a NT service pack.  For now, you can work around it in your
>application.  Here is the workaround that we have been telling others
>to
>do:

>The problem is due to an assumption on our part that floating-point
>exceptions will be masked on x86.  We have internal assembly which
>does
>not check for certain boundary cases because we know that later the
>results will be discarded and will have no effect on the rendering.
>These operations can, however, produce FP exceptions, which we are
>relying on being masked.

>When building with Microsoft tools FP exceptions are masked by default
>so we haven't been seeing problems.  Other tools, however, may have
>different defaults or even specifically unmask FP exceptions, so our
>code starts producing exceptions.

>We will be changing OpenGL to force masking of these exceptions in an
>upcoming service pack.

>In the meantime, it is possible for the application to force masking
>itself.  The following macros can be used to mask and restore the
>exception mask.  Bracketing OpenGL rendering with them should prevent
>the FP exceptions that they've reported.

>Note that these macros use the _X86_ define and Microsoft
>inline-assembler syntax so some modification may be necessary for
>other
>tools.

>#ifdef _X86_

>#define X86_MASK_EXCEPTIONS(dwOldMode) \
>    __asm fnstcw WORD PTR dwOldMode \
>    __asm mov eax, dwOldMode \
>    __asm or eax, 0x3f \
>    __asm mov WORD PTR dwOldMode+2, ax \
>    __asm fldcw WORD PTR dwOldMode+2

>#define X86_RESTORE_MASK(dwOldMode) \
>    __asm fnclex \
>    __asm fldcw WORD PTR dwOldMode

>#else // _X86_

>#define X86_MASK_EXCEPTIONS(dwOldMode)
>#define X86_RESTORE_MASK(dwOldMode)

>#endif // _X86_

>Regards,
>Hock


>>Walt,

>>I'm glad you liked my book<g>! Your report of floating point errors
sounds
>>very familiar. In fact, these same errors are frequently reported by
users
>>of Borland C++. I believe that there is something fishy going on with
>>Borland's floating point support. Delphi and C++ are supposed to share
the
>>same backend, so this would make sense. I've sent a demonstration to
some
>>people at Microsoft who were interested in tracking down this problem,
but
>>I haven't heard from them in a while.

>>It doesn't matter if your running 1.0 or 1.1 of the OpenGL binaries, or
NT
>>3.51 or NT 4.0. It is a real and easily produced bug. I wish someone
from
>>Borland would visit this forum from time to time. I tried in vain to
bring
>>this to their attention during the 5.0 beta, but they seem to have more
>>than enough other problems to worry about right now...

>>Richard



>>> I have written several test programs with the OpenGL Delphi Header
>>> files that were ported by Richard hansen at Artemis Alliance.  He did
>>> a wonderful job and the .pas units work flawlessly at design time.  At
>>> run time, however, I am getting intermittent Floating point errors,
>>> usually immediately following glRotate(x) or glTranslate(x).  I feel
>>> that the overflow is probably in the Microsoft gl library.

>>> Has anyone else experienced this problem either in C++ or Delphi?  Are
>>> there any suggestions for work arounds or bug fixes?  I am currently
>>> running Version 1.1 of the libraries, Version 2.0 of Delphi and am
>>> using the OpenGL SuperBible as my programming guide (A great book).

>>> Thanks for your help,
>>> Walt Smith
>>> Maidens Software Systems
>>> Maidens, VA

 
 
 

Windows 95 / OPENGL Run Time Crash with Delphi

Post by Walt Smi » Sat, 19 Oct 1996 04:00:00


I received this response via e-mail from Hock San Lee.  I assume from
Hock San Lee and wished to post it for others to see.  I apologize if
it was already posted, I did not see it.
Best Regards.

Walt,

I believe this is the same problem others have been seeing.  We will
fix
this in a NT service pack.  For now, you can work around it in your
application.  Here is the workaround that we have been telling others
to
do:

The problem is due to an assumption on our part that floating-point
exceptions will be masked on x86.  We have internal assembly which
does
not check for certain boundary cases because we know that later the
results will be discarded and will have no effect on the rendering.
These operations can, however, produce FP exceptions, which we are
relying on being masked.

When building with Microsoft tools FP exceptions are masked by default
so we haven't been seeing problems.  Other tools, however, may have
different defaults or even specifically unmask FP exceptions, so our
code starts producing exceptions.

We will be changing OpenGL to force masking of these exceptions in an
upcoming service pack.

In the meantime, it is possible for the application to force masking
itself.  The following macros can be used to mask and restore the
exception mask.  Bracketing OpenGL rendering with them should prevent
the FP exceptions that they've reported.

Note that these macros use the _X86_ define and Microsoft
inline-assembler syntax so some modification may be necessary for
other
tools.

#ifdef _X86_

#define X86_MASK_EXCEPTIONS(dwOldMode) \
    __asm fnstcw WORD PTR dwOldMode \
    __asm mov eax, dwOldMode \
    __asm or eax, 0x3f \
    __asm mov WORD PTR dwOldMode+2, ax \
    __asm fldcw WORD PTR dwOldMode+2

#define X86_RESTORE_MASK(dwOldMode) \
    __asm fnclex \
    __asm fldcw WORD PTR dwOldMode

#else // _X86_

#define X86_MASK_EXCEPTIONS(dwOldMode)
#define X86_RESTORE_MASK(dwOldMode)

#endif // _X86_

Regards,
Hock


>Walt,
>I'm glad you liked my book<g>! Your report of floating point errors sounds
>very familiar. In fact, these same errors are frequently reported by users
>of Borland C++. I believe that there is something fishy going on with
>Borland's floating point support. Delphi and C++ are supposed to share the
>same backend, so this would make sense. I've sent a demonstration to some
>people at Microsoft who were interested in tracking down this problem, but
>I haven't heard from them in a while.
>It doesn't matter if your running 1.0 or 1.1 of the OpenGL binaries, or NT
>3.51 or NT 4.0. It is a real and easily produced bug. I wish someone from
>Borland would visit this forum from time to time. I tried in vain to bring
>this to their attention during the 5.0 beta, but they seem to have more
>than enough other problems to worry about right now...
>Richard


>> I have written several test programs with the OpenGL Delphi Header
>> files that were ported by Richard hansen at Artemis Alliance.  He did
>> a wonderful job and the .pas units work flawlessly at design time.  At
>> run time, however, I am getting intermittent Floating point errors,
>> usually immediately following glRotate(x) or glTranslate(x).  I feel
>> that the overflow is probably in the Microsoft gl library.

>> Has anyone else experienced this problem either in C++ or Delphi?  Are
>> there any suggestions for work arounds or bug fixes?  I am currently
>> running Version 1.1 of the libraries, Version 2.0 of Delphi and am
>> using the OpenGL SuperBible as my programming guide (A great book).

>> Thanks for your help,
>> Walt Smith
>> Maidens Software Systems
>> Maidens, VA

 
 
 

Windows 95 / OPENGL Run Time Crash with Delphi

Post by Richard S. Wright Jr » Sat, 19 Oct 1996 04:00:00


Hock and Walt,

Thanks! I've been wondering about this for a long time. I'm glad someone finally got to the
bottom of it!

Richard

 
 
 

Windows 95 / OPENGL Run Time Crash with Delphi

Post by Michael Brook » Tue, 29 Oct 1996 04:00:00


Hello Walt:

I'm sure this isn't the response you were expecting.  In fact it is a plea
from me for help from a fellow Delphi programmer.

I've been working on using textured OpenGL objects in Delphi 2.0 without
much success.  My first attempt left me with a formerly identifiable
untextured cube looking like a silhouette when textured.  My second
attempt, which increasing the complexity of my texture loading function,
left me fighting with CreateDIBSection. CreateDIBSection is returning a
NULL handle and zero errors via GetLastError.

Have you had any experience with texturing.  If so, could you share an
example?

Thank You, for your time!

Michael.



Quote:> I have written several test programs with the OpenGL Delphi Header
> files that were ported by Richard hansen at Artemis Alliance.  He did
> a wonderful job and the .pas units work flawlessly at design time.  At
> run time, however, I am getting intermittent Floating point errors,
> usually immediately following glRotate(x) or glTranslate(x).  I feel
> that the overflow is probably in the Microsoft gl library.

> Has anyone else experienced this problem either in C++ or Delphi?  Are
> there any suggestions for work arounds or bug fixes?  I am currently
> running Version 1.1 of the libraries, Version 2.0 of Delphi and am
> using the OpenGL SuperBible as my programming guide (A great book).

> Thanks for your help,
> Walt Smith
> Maidens Software Systems
> Maidens, VA

 
 
 

Windows 95 / OPENGL Run Time Crash with Delphi

Post by Marc Burn » Thu, 31 Oct 1996 04:00:00




Quote:>Hello Walt:

>I'm sure this isn't the response you were expecting.  In fact it is a plea
>from me for help from a fellow Delphi programmer.

<snip>

Quote:>Have you had any experience with texturing.  If so, could you share an
>example?

>Thank You, for your time!

>Michael.

hi,

I've had a little experience of using textures with opengl and delphi
2.0 so I hope I can be of some help.

Firstly, I don't think textures work in 256 colour mode.
The following code assumes you are using 16bit high colour.

I begin by setting up the texture state variables;

glpixelstorei(gl_Unpack_Alignment,1);
gltexparameteri(GL_TEXTURE_2D,GL_TEXTURE_WRAP_S,gl_repeat{GL_clamp});
gltexparameteri(GL_TEXTURE_2D,GL_TEXTURE_WRAP_T,gl_repeat{GL_clamp});
gltexparameteri(GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER,GL_NEAREST);
gltexparameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER,GL_NEAREST);
{ GL_Modulate-- colour of underlying object modulates the Bitmaps
intensity }
{ GL_Decal-- Walllpapers over original colour of object }
glTexEnvf(GL_TEXTURE_ENV,GL_TEXTURE_ENV_MODE,GL_MODULATE{GL_DECAL});

Then I bitblt the image I want as the texture to a dib(I think there is
a restriction set on the dimensions of the bitmap used as a texture,the
minimum dimensions being 64x64)

{ creating the dib to store texture bitmap }

TexDc:=createCompatibleDc(mainwindow.canvas.handle);
{ create the bitmap to store the image to use as texture }
{ PtexBits is a pointer to the dibs actual bits }

Texbitmap := CreateDIBSection(mainwindow.canvas.handle, pbmi^,
                          DIB_RGB_COLORS, PTexBits, nil, 0);
{ select DIB into the texture device context }
selectobject(TexDc,Texbitmap);
{ then bitblt texture image to texdc }

The colour information stored in a dib is a different format to that
used in opengl so the bits of the dib with the texture on it need to be
converted before we use them.

{we need a store for the new opengl colour info}
type
   TTextureRGBArrayType=array[0..NoOfTextureBytes-1] of glubyte;
var
   TextureRGBArray:TTextureRGBArrayType;

procedure ConvertFromDib16BitFormatToOpenGl(PTexBits: Pointer);
var pdest: PrgbTriple;
    Pscr: Pword;
    i: integer;
begin
   {PTexbits points to the first element of a bmpwidth by bmpheight
array of word values }
   { because the dc has 16 bpp. 1bit unused and 5 each for r,g,b( need
to check for  different settings of bitsperpixel, this is just catering
for 16bpp )}

   Pscr:=Pword(PTexBits);

   { opengl only works on arrays of RGB values, each colour being
represented by a byte }
   { we create an array to contain these values and convert the 16bpp
dib colours to the opengl format }


   for i:=0 to NoTexturePixels-1 do
   begin
      { masking the word value stored in each element of ptexbits to }
      { get rgb values }
      pdest^.rgbtred:=((Pscr^)and($1f))*8;
      { for green and blue we also need to shift the bits }
      pdest^.rgbtgreen:=(((Pscr^)and($3e0))shr 5)*8;
      pdest^.rgbtblue:=((Pscr^)and($7c00)shr 10)*8;
      inc(Pscr);
      inc(pdest);
   end;
end;

TextureRGBArray should now contain the correct colour information to
pass to opengl to specify a texture;


GlTexImage2d(GL_TEXTURE_2D,0,3,Texturebitmapwidth,Texturebitmapheight,0,
                         GL_RGB,GL_UNSIGNED_BYTE,
                         ptexturebits);

glEnable(GL_TEXTURE_2D)

then specify texture coordinates for each vertice of the object you want
texture to appear on

GLTexCoord2f(texX,texY);
glVertex3f(x,y,z);

( mapping the texture coordinates to each vertice can get a little
complicated  but there will be more information on this subject floating
around in a newsgroup somewhere }

These are just a few snippets of the code that I used to implement
texture mapping,
I can't guarantee that it is the best way or that I haven't made a
mistake writing this reply but I hope it gives you a better idea on the
subject.

Paul melia.

*****************************************************************************
Robot Simulations Ltd - Developers of the Workspace robot simulation software
                 Visit our VR home page at www.rosl.com

     Phone Line +44 (0)191 272 3673       Fax Line +44 (0)191 272 0121
*****************************************************************************

 
 
 

1. Windows 95 crash after terminating a Delphi 4-program

Please help us,

we use a network with several WINDOWS95 and WINDOWS98 and WINDOWS-NT
pc's.
We wrote a program under Delphi 4 professional, which has an EXE-size of
about 3 MB.
All 3 operating systems allow us to start the program and use it, but
only WINDOWS95
crashes after leaving out program. The error is:

out of memory in S3_4.DRV

All the WINDOWS95-computers have different graphic cards (e.g. Hercules
Terminator 128,
ATI RAGE PRO, ..), but all have the file S3_4.DRV with a size of 84336
Bytes. We tried to
obtain a driver update, but didn't get another S3_4.DRV
We can work around the problem if we use the standard-VGA-option for the
screen.
But this it not a good solution...

Are there perhaps any known conflicts with WINDOWS95 and e.g. the
INTERNET-palette of Delphi 4?

Thanks for your help.
T. Schr?der

2. Contour

3. OpenGL - Crashes in IDE - Runs OK in Windows

4. Ray Tracing for Reflector Design

5. OpenGL for the Matrox millenium under Windows 3.11 or Windows 95

6. how do i get this matrix poster effect in ps7?

7. HELP: Running Quark Xpress under Windows 95

8. Component that plays quicktime .mov files??

9. Running Data Explorer under Windows 95

10. Macromodel won't run in Windows 95 Build 347

11. HOW TO RUN 3D STUDIO R4 UNDER WINDOWS 95

12. Running 3d Syudio under Windows 95