forums.silverfrost.com

[DanRRight]

Anyone knows how make plotted linewidth glLineWidth(wid) to work in OpenGL ?

What i do is the following

[DanRRight]

Thanks John,
You can see or guess by commented line in the example above that i tried these things but did not succeed. The problem is that there is no documentation for all OpenGL features in Fortran and you are permanently guessing using docs or examples in other 20 different other languages. DJIP made some examples when we communicated 15 years back and that's it. He used Compaq/Intel and that not always worked with FTN95

Why Fortraneers do not use OIpenGL is beyond me as this is the most needed graphics tool in science and engineering. Here in the Forum must be the whole separate topic devoted to OpenGL

But if not will help i will look again myself so thanks for this found link which save me some time

[IanLambley]

Dan,
Looking at the documentation you were directed to, the parameter for width is in GLfloat which I assume is real*4. You seem to have used 4.d0 which is real*8, try 4.e0.
Ian

[DanRRight]

Ian, Well, yes, I tried and polished with my bad butt all these confusing OpenGL options when you often do not know what precision is actually used

This one if you substitute real*8 to real*4 gives Error 29, Call to missing routine, _glLineWidth@4 at 0x00447d53

In FTN95 INCLUDE dir the opengl.ins is defined as

STDCALL GLLINEWIDTH 'glLineWidth' (VAL)

as you can see this the root of old confusion story. Intel/Compaq rewrote all their numerous INS files to Fortran style long long ago

So we work based on intuition and tries and after few punches back into our face things usually work. For example i decided to change the point size and got it almost from the first attempt

[IanLambley]

Dan,
Have a look at:
https://msdn.microsoft.com/en-us/library/windows/desktop/dd373931%28v=vs.85%29.aspx
This shows the parameter is float not double.
However, if you follow the glget link at the bottom of that page to glgetfloatv and you will see that the gl_line_width parameter is returned as a float. But calling glgetdoublev with the same parameter returns it as a double.

You might like to try this after initialising opengl:

[DanRRight]

Thanks Ian, then the question has to be addressed to Silverfrost: why such strange error report from using glLineWidth with right VAL ??

[DanRRight]

What game, John? Time of simple XY graphs is gone. Without top notch graphics you will not get attention, sales, funding, you are basically dead nowadays. Look at the games kids play on 4K monitors, that's not an ascii Tetris on monochrome CGA monitors of our glorious past, no one accepts from scientists and engineers anything less than that kind of visualization quality. Reviewers and program managers demand in plain English text super still and video graphics.

You can briefly scan and review all the graphics in this for example presentation and see what is used https://www.youtube.com/watch?v=fVKD9u_TZMg

or here https://www.google.com/search?q=nanophotonic&source=lnms&tbm=isch&sa=X&ved=0CAgQ_AUoAmoVChMI0ayRjsyXxwIVTTuICh3VNwMG&biw=946&bih=613
Yes, real*8 does not give error, but does not do anything, real*4 produces error by the compiler. I think Paul has to look at that

[IanLambley]

Dan,
Sorry about my earlier post, the code was incomplete and has now been edited.

I thought I would investigate further and so modified a copy of the "Animate.for" demonstration program supplied with FTN95. I added a function which queries the current line width and range giving the results of :
1.0
1.0 63.0
for these respectively.

Then I set the line width to 4. which by default is real*4 and re-queried the line with setting which then gave a value of 4.000

I used this function as a start-up call back and all the lines in the animation drew thicker than the original program. Have you set the default real type to *8 in the compiler set up? You could try passing the thickness in a real*4 variable instead of as a direct numeric.

Updated demo code attached:

[IanLambley]

Continued...

[IanLambley]

Continued ...

[LitusSaxonicum]

[IanLambley]

Eddie,
Yes that was why. The point of my post was that Dan had been having problems getting the routine to work at all. This showed that it can work and I think the main problem was the position of the call, i.e. it cannot be between a glbegin and glend. But it could also be caused by the implementation on Dan's computer, version of Opengl32.dll etc.
Regards
Ian

[IanLambley]

Eddie,
Yes that was why. The point of my post was that Dan had been having problems getting the routine to work at all. This showed that it can work and I think the main problem was the position of the call, i.e. it cannot be between a glbegin and glend. But it could also be caused by the implementation on Dan's computer, version of Opengl32.dll or hardware or graphic acceleration etc. Your test on a Lenovo machine shows that there are differences in hardware/software.
Regards
Ian

[DanRRight]

Wow, Ian, that was good catch, thanks, this program does compile with no problems and changes line width.

Though it changes line width globally, while i need linewidth change for each individual line, surprisingly it goes with no errors or complaints about this damn absent real*4 program. *How on earth this could be* ?

Currently my workaround with not working linewidth is by plotting many slightly shifted lines around the one in the center

[IanLambley]

It's a miracle!
Just call the routine before the glbegin perhaps?

Now maybe more people will use OpenGL.

I would love to but stopped because I could not get the screen picking of entities to work. Also I wanted to put a 2D overlay on a 3D picture but haven't a clue. If you have some examples I would be pleased to see them as no doubt would many others and perhaps an OpenGL index entry on this site would be useful.

You are up very early this morning, or just haven't gone to bed yet. Take a break and have a good sleep without nightmares of OpenGL.


Ian