OPENGL and Intel 8.1, f90gl

[don-philp]

To those that might know,

Wondered if there was a pre-compiled version for use.

the NIST site implies there might be
("Intel Visual Fortran: https://premier.intel.com/ (Registered users log in, select File Downloads and search for f90gl.)")
but it is beyond me to find it.

Thanks

Don

Message Edited by Don-Philp on 05-27-2005 09:55 PM

[edmund_dunlop]

Hello Don,

This file does seem to have disappeared from the premier support site.Please email me at edunlopremovespam@removespamutvinternet.ie(please remove the two "removespam" strings from the given address) and I shall send you a copy of the file f90gl-1[1].2.8-Win32.ZIP, which I downloaded just over a year ago..

Kind regards,

Edmund Dunlop.

[Steven_L_Intel1]

Yeah, I noticed recently that it disappeared. I'll put it back. Sorry about that.

[don-philp]

Steve,

Was wondering if this was on the web site now??

Any clues as to how to find it??

Also, does anybody have an Intel Fortran version of Wright and Lipchak's Opengl Superbible examples, particularly the Text 3D example (Chapt 13).

I do have the book and CD but the conversion to Fortran escapes me at this point. Also I am struggling with a full conversion to Intel Fortran of Lawrences' HelloGL2 using
gl.... routines rather than fgl.... (Chapter 16).

The book example converts to an Intel project but changing across to the gl routines has posed a number of challenges, it seems around the glCallLists vs fglCallLists. Something is different in the routines.


Any and all clues would be appreciated.

Much appreciated.

Don

[Steven_L_Intel1]

I guess the file "falls off" Premier Support after a while. When I get back to the office on Wednesday I'll post it as an attachment here.

The Lawrence book is using the Win32 API version of OpenGL, not f90GL. The code there should work in IVF without changes. The f in front of routine names was a Microsoft PowerStation convention that we preserved.

[sumitm1]

Hi,

I just upgraded to IVF 9.0 from CVF and am having myraid problems rebuiliding, Mostly with Array Visualizer (AvDef and AVShareName are common errors, nobody said anything about use AVFRT in project conversion manual(pdf)). Anyways, now I need the f90gl library compiled by NIST but it is nowehere to be seen in premier download.

Can someone help, please.

I will have many more questions I think before I can rebuild my project succesfully.

Thanks in advance.

Sumit

[Steven_L_Intel1]

Let's see if I can attach it here.

[sumitm]

Thanks Steve for the prompt response.

Can you help me why I geta warningfor the following statement with int or int2 when it was working fine in CVF

itemp=RGB(

int2(255*ContourColours(vertex1,3)),int2(255*ContourColours(vertex1,4)),int2(255*ContourColours(vertex1,5)))

c: ead_pref_dxf.f90(1011): Warning: The data type of the actual argument does not match the definition. [INT]

and contour colors has been defined as

real(8)

ContourColours(ContourNumber,8)

and

integer(4)

, parameter, public :: ContourNumber = 60

I also got a warning in the line

CALL

SETLINESTYLE(#FFFF) ! Solid Line

c: ead_pref_dxf.f90(366): Warning: The data type of the actual argument does not match the definition. [#FFFF]

and

retv=POLYGON_W($GFILLINTERIOR,points,3)

c:PTIGRAPHICS.F90(1106): Warning: The data type of the actual argument does not match the definition. [3]

Thanks for your help

Sumit

[Steven_L_Intel1]

This is explained in the compiler release notes in 9.0. It also applies to late 8.1 updates. Here's what it says:

Mismatch of Argument KIND Now Diagnosed

In previous versions, the compiler would silently allow a mismatch of KIND
for an argument when calling a routine that had an explicit interface. For
example, consider the following:

interface

subroutine sub (x)

real(8) :: x


end subroutine sub

end interface

...

call sub(3.0)

The 3.0 in the call is of type "default real", or real(4).
Previously, the compiler would accept this and convert the value on the call
and return. Now, the compiler will give an error such as:

Error: The type of the actual argument differs from the type of the
dummy argument. [3.0]

call sub(3.0)

---------^

This issue also arises for mismatches of integer and logical kinds. If your
application took advantage of the earlier compiler's failure to diagnose
this error, you can correct the problem by making sure that the argument
is the correct kind. For constants, you can add the kind specifier
suffix, such as 3.0_8 or 50_2. For constants or
expressions, use the COMPLEX, INT, LOGICAL or COMPLEX intrinsics
with the second KIND argument to convert the argument to the
proper kind. For variables, you will need to correct the declaration
of the variable to make sure that it matches the expected kind. The
TRANSFER intrinsic can also be used to convert integer values,
for example, TRANSFER(200,0_1) converts the value 200 as if it were
an unsigned integer into an INTEGER(1) value.