It is easy to get x,y in regular graphics window, but how to do similar thing in openGL?
How to get cursor position in openGL screen ?
I've used something like this
In definitions:
common/mouse_stuff/mouse_button_state,mx,my,mxp,myp
integer :: passivemotion, mouse_press
external :: passivemotion, mouse_press
mouse_button_state = 0
After setting up window + %lw
call glutMouseFunc(mouse_press)
call glutMotionFunc(motion)
call glutPassiveMotionFunc(passivemotion)
Typical routines:
integer function motion(x, y)
include <opengl.ins>
integer :: x, y
common/mouse_stuff/mouse_button_state,mx,my,mxp,myp
mx = x
my = y
if(mouse_button_state .eq. 2)then
.
.
.
endif
motion = 2
end function motion
integer function passivemotion(x, y)
include <opengl.ins>
integer :: x, y
common/mouse_stuff/mouse_button_state,mx,my,mxp,myp
mxp = x
myp = y
passivemotion = 2
end function passivemotion
integer function mouse_press()
include <opengl.ins>
include <clearwin.ins>
character*32 reason
common/mouse_stuff/mouse_button_state,mx,my,mxp,myp
reason=clearwin_string@('CALL_BACK_REASON')
select case(reason)
case('MOUSE_LEFT_CLICK')
mouse_button_state = 1
case('MOUSE_MIDDLE_CLICK')
mouse_button_state = 3
case('MOUSE_RIGHT_CLICK')
mouse_button_state = 2
case default
mouse_button_state = 0
end select
mouse_press = 2
end function mouse_press
I have a series of 'nvert' 3D vertices splattered around the window, previously stored in array 'xyz', and by the following routines they can be located say while moving the mouse around the screen and calling within function 'passivemotion':
as:
call get_graphic_matrices
inode = ifind_node(mxp,myp)
integer*4 function ifind_node(ix,iy)
implicit real*8 (a-h,o-z)
include <clearwin.ins>, nolist
include <opengl.ins>, nolist
common/vertices/nvert,xyz(3,5000)
dimension screen(3)
common/matrices/iviewport(4),amvmatrix(4,4),projmatrix(4,4)
realx = ix
realy = iviewport(4)-iy-1
c
c set proximity to detect node
distance = iviewport(3)*0.015d0
c
c scan each stored vertex for a match
test = sqrt((screen(1) - realx)**2 + (screen(2) - realy)**2)
if(test .lt. distance)then
ifind_node = i
distance = test
endif
enddo
end
subroutine get_graphic_matrices()
implicit real*8 (a-h,o-z)
include <clearwin.ins>, nolist
include <opengl.ins>, nolist
common/matrices/iviewport(4),amvmatrix(4,4),projmatrix(4,4)
call glGetIntegerv(GL_VIEWPORT,iviewport)
call glGetDoublev(GL_MODELVIEW_MATRIX,amvmatrix)
call glGetDoublev(GL_PROJECTION_MATRIX,projmatrix)
end
Although these are cut down code fragments, and not tested at this level, I hope they help.
Ian
I use:-
CALL GET_OPENGL_MOUSE_STATE@(mx,my,mflag)
where mx and my is cursor position (obviously!)
and:-
mflag=1 for left mouse button pressed mflag=2 for right mouse button mflag=3 for middle mouse button mflag=16 for both left and right buttons pressed
John,
Where is that documented? It does not show up in the FTN95 help or have you been rumaging through the opengl.ins & clearwin.ins files?
Thanks, that will make things easier, but the code I posted, helps to find positions in real space, from the integer values returned from the mouse location. It will obviously replace the code in mouse_press and can be used elsewhere.
Are there any more useful OpenGL items that are undocumented? Or for that matter, for other things.
Regards
Ian
Thanx Ian and John!
Ian,
Its some years since I first used that routine, so I can't remember how I stumbled across it, I guess I must have scanned the clearwin.ins file for anything OpenGL related at the time.
Having first started writing graphics routines in fortran for tektronix machines which were subsequently migrated to HPUX starbase, then to PC's using FTN77 with graphics in a DOS environment, followed by MS windows GDI graphics (using %gr), I finally arrived at OpenGL. I now maintain dual graphics drivers in my software using %gr and %og from clearwin. For that reason I don't use the glut libraries in OpenGL or any third party graphics libraries at all. Therefore I had to replicate in OpenGL the same cursor enquiry techniques I had always used, dating back to the tektronix, as I wasn't going to throw away the best part of 30 years worth of code!
When it came to implementing OpenGL, I quickly found out that there were some hurdles to jump through:-
1). cursor interrogation of the image. 2). writing text to the graphics screen (as OpenGL can't do this!) 3). copying the image to clipboard or bmp/jpg files
And finally I never figured out how to get the specific OpenGL printer statements to work correctly, so I managed to implement DIB_PRINT instead!
The resolution to 1). is as above, 3). I covered in another thread about a month ago, and 2). was resolved by converting a C++ routine (of which I have a near zero understanding!) and modifying the windf95.ins file (which I first reported as being incorrect some years ago - and is still not fixed!), so putting text into OpenGL graphics is a quite involved procedure (well at least for me it was - but I daresay some other whizz will wonder why I struggled).
OpenGL can be problematic on some machines, especially laptops, which is usually resolved by turning graphics acceleration off (anyone know how to do this automatically via fortran?), which is why I still maintain the very stable GDI graphics drivers as well.
But I now see that MS (typically!) are pushing their own DirectX/DirectDraw stuff to the fore with vista and relegating OpenGL to a secondary emulation level ! (MS policy to kill off anything not MS?)
Anyway I hope that helps!
John,
Thanks very much for the info, and it seems that we must all go through the difficulties of OpenGL and interrogating locations on the screen. Writing text has also confused me, because due to the helpful nature of the beautiful '3D hidden line/surface/etc' removal of OpenGL, putting a text overlay never seems to be described in terms simple enough for my brain to comprehend. As such, I really haven't got to grips with OpenGL. More examples are needed!
Is FTN95 going to have support for DirectX/DirectDraw, I wonder?
It is nice to see that you have been though the development route which started with Tektronix. Does 4006, 4014, 4662 & 4663 ring a bell? I've got the latter two items lying around my house if you know of anybody who might like them.
Regards
Ian
John, what do you mean by
2). writing text to the graphics screen (as OpenGL can't do this!)
'Animate.for' example writes the text on og screen.
I also have one problem. I can not make specular reflection from the surface a la reflection from the water. I can send couple simple OpenGL examples for anyone to try. Will very appreciate.
Dan,
Are you using OpenGL to do the reflection business or are you programming it yourself? If the latter, can I recommend Angell & Griffith 'High resolution computer graphics using Fortran 77' (Macmillan, 1987) ISBN 0-333-40398-3 or 0-333-430399-1 (paperback) - Chapter 15. Not light reading, but good for reflection (pun intended)!
Eddie
Ian,
My tektronix experience started with the monochrome storage scope displays of the 4010 and 4014 and finished with the 4111 colour displays. I do miss the ability to write a complete fully interactive graphical application using 100% standard fortran that was possible with the tektronix. I don't miss the time it took to render a colour filled stress contour plot! (plot times of 30 minutes were not uncommon - compare that to the fraction of a second to rotate an OpenGL image!) If still you have source code from this era then it is possible after installing linux (ubuntu can now be installed very easily under MS windows), to compile with g95 and display it in a tektronix simulation window (using 'xterm -t').
As for OpenGL examples, there are enough provided with FTN95 to get you going, then there are masses to be found on the web, the fortran examples you find are never for FTN95, but all the OpenGL calls (which is what you are after) are the same in any dialect of fortran (and very little different in C++). So just keep pluging away, it's well worth it in the end! BTW OpenGL can be very unforgiving when you get it wrong (re-boots were common with me when first starting) and the debugger only debugs fortran not OpenGL calls.
DanRRight,
Yes you're correct, this example does show text in OpenGL :!: But it is not how I do it! With the routines I use, I can select font type and all the normal attributes (bold, italic and so on...), not sure how this could be done in this example. As Ian hinted, text can either be made to move with geometry or placed statically, unobscured somewhere on the image whilst geometry can be rotated, zoomed and panned behind the static text.
Can't you just plug the old Tektronix terminal in a serial port and write to it from FTN95?
What is wrong with windf95.ins ?
Eddie
Hi Eddie,
I didn't seriously expect anyone to be still using tektronix hardware!! My point was that it is still possible to compile and run tektronix dependent fortran source code (but only for 4010/4014 not any later models) without any great difficulty (infact very easily using ubuntu).
What is wrong with windf95.ins ?
Well, using an undoctored version you get so many errors like the following that the compiler aborts with a too many errors message:-
1/1102) C_EXTERNAL GETDRIVERINFO 'GetDriverInfo' (VAL,WINREF):LOGICAL2 *** Bad argument descriptor in C_EXTERNAL (In include file C:\Program Files (x86)\Silverfrost\FTN95\include\WINDF95.INS) *** Return type is expected. Found (VAL,WINREF):LOGICAL2 1/1111) C_EXTERNAL OPENDRIVER 'OpenDriver' (WINSTRING,WINSTRING & 1/1112) &,VAL):INTEGER*2 *** Bad argument descriptor in C_EXTERNAL (In include file C:\Program Files (x86)\Silverfrost\FTN95\include\WINDF95.INS) *** Return type is expected.
How do I fix it?
Answer by editing the file and making the following changes for every occurence of the variable name on the left, replace it with that on the right.
WINREF → REF WINSTRING → INSTRING WOUTSTRING → OUTSTRING WSTRING → STRING
As I said, I informed Salford Software at the time, to which I got the rather amusing replying 'it seems that not too many people are using this file'
cheers John
Hi John,
That's useful to know - but what does windf95.ins do? I haven't moved on from INCLUDE <WINDOWS.INS>.
I used ESC-code driven graphics hardware on the COM port of my 8086 Apricot PC, and found that it was about equal to being one of several users on a VAX. The great thing about external graphics hardware is that it can be programmed in anybody's Fortran - but you need to reinvent the GUI for yourself.
Eddie
Hi Eddie,
I use windf95.ins to provide definitions used by STDCALL CREATEFONTA which I use to create a text font for use in OpenGL graphics.
So it looks I've been a unique user of this include file! :roll:
cheers John
Eddie,
Where I will find that old book? And not being specifically easy reading makes me grieving because most probably it will stop me on the first not working example. This is exactly what happening with 99 or of 100 people who looked at OpenGL. My usual point here is : who now RTFM ? 😄 I saw a lot of courses on OpenGL on the net but even Digital/Compaq Fortran examples do not work without serious sometimes intimate editing unfortunately... Adding refection like most of things in programming is 3 min work for those who did that and know that or if we have an example.
[color=olive:cca4b521ac]This is why I encourage everyone to send your small nice loooking code snippets to delelopers, so they will include them for everyones benefits. I believe if FTN77 and then FTN95, Clearwin+ and OpenGL and recently .NET had 100 (will repeat, A HUNDRED) times more very nice looking and useful in science, technology and education examples of all sort, it would make Salford #1 or #2 Fortran compiler 10 years ago.
[/color:cca4b521ac]
John,
I still use my own pixel depth colour routine for hidden line removal, rather than OpenGL. I've adapted it to a virtual screen, 4000x3000 resolution for improved clarity of dumps to .pcx files and it runs at about 10 frames per second. My input are flat(ish) well behaved polygons, where every node of the polygon has (x,y,z,c) C represents a colour range value for a pre-defined spectrum. To draw the pixel result to the screen, I scan each line of the colour array, drawing lines where the colour is the same. While OpenGL is be far better for displaying curved surfaces, my crude approach works well for flat faces. I've overcome the walk-thru problem by using a small porthole, with much faster refresh rates.
I still retain a lot of the plot-10 functionality, and it's hard to let go of code that gives a lot of flexibility. I find a lot of the superier OpenGL style graphical displays often comprimise good looks for accuracy, especially where result 'smoothing' takes place.
John
Dan,
I made the assumption that you were university based like me, and thus had access to a huge library with 'inter-library loans' on demand - which is why I posted the ISBN.
Send me a private message with your postal address - I'm in the UK, so it may take a week or two to arrive in the US. You can let me have it back when you are finished with it.
Eddie
Thanks, Eddie, for offered help, I will try to find advice on the net first, then if the book is available here, and if fail, then may be will ask you to send the book...
Most of the functions in windf95.ins have been transcribed for you in win32api.ins and similar include files containing STDCALL declarations.
There appear to be some omissions and I do not know if they are deliberate or accidental.
I take the point about the lack of examples. All we need is some benefactor to send us a pile of money so we can pay people to do the work.
How about outsorcing this job, Paul ? If this still is not financially possible then
Ask users of compiler to make a 2-3 most interesting additions to the library of 'Users Examples and Snippets', which could be published as is, with no warranties in all next releases expanding it with time. Future users of these examples of course can email to the authors their questions, bug reports and suggestions