Welcome to our forums
Good evening,
I've run into a problem when implementing OpenGL through Clearwin. Every time I minimize the window, the application crashes on a floating point exception. If not, it renders garbage when maximised again. It also happens with the OpenGL-Example Files. Is there any way to work this out?
Never had that. Check graphics driver.
Graphic driver is up to date. Also writing SDL/OpenGL Applications in C works like a charm. It appears to me that the window size during minimization (0x0) is passed to OpenGL when I minimize the application to the taskbar, which causes a division through zero error somewhere. There is no event created on minimizing, nor are any of my rendering routines called.
There is no easy way that I know.
Temporarily remove major blocks of code to localise the problem
Use a %mv callback to see if the callback is called before the crash. You might be able to look at your variables from this callback via the debugger.
Make sure that all active variables are in scope - use STATIC, COMMON or MODULE variables where necessary (e.g. a control variable for %lw).
I seem to remember something like this happening during RESIZE with a %gr region, so I checked in my code and found this (with extraneous stuff removed) in my graphics callback function near the start:
CBR = CLEARWIN_STRING@ ('CALLBACK_REASON')
IF (CBR .EQ. 'RESIZE') THEN
IXRES0 = CLEARWIN_INFO@ ('GRAPHICS_WIDTH')
IYRES0 = CLEARWIN_INFO@ ('GRAPHICS_DEPTH')
IXRES = MAX (1, IXRES0)
IYRES = MAX (1, IYRES0)
IF (MGR(2) .EQ. 0) THEN
CALL ScrnPLOT ! this replots everything including recalc scaling
ENDIF
GR_callback_FN = 1
RETURN
ENDIF
MGR(2) is the grey code for Menu File|Open, so there is no point in redrawing if there isn't anything to redraw (this is a single document application). IXRES and IYRES are used to calculate scaling, and clearly I had got into a situation where I had a divide by zero when using the size returned by Clearwin+.
On the basis of my experience, I suggest that it is likely therefore that the problem lies somewhere in your own code rather than in Clearwin+, and it is somewhere where you scale stuff for the screen. Perhaps I shouldn't replot if IXRES or IYRES is smaller than a certain limit - one learns from other users' experience.
CLEARWIN_INFO@ also returns important info on OpenGL.
Eddie
Since Ftn95 own Opngl example crash it does not look like the code problem. It more hints at system conflict. Like this forums.silverfrost.com/viewtopic.php?t=2434
Dan, you may be right, but the floating point exception is most probably a divide by zero error, and the original poster has half diagnosed what is causing it, but has not decided where to look for it. He may not allow part resizing of his master window, but minimising to the taskbar is a resize event if the %og is resizable.
Eddie
Thank you for your comments on this so far.
Dan, you may be right, but the floating point exception is most probably a divide by zero error, and the original poster has half diagnosed what is causing it, but has not decided where to look for it. He may not allow part resizing of his master window, but minimising to the taskbar is a resize event if the %og is resizable.
As far as I can tell, the OpenGL event is not called on minimizing. It is called when it's actually being resized, I check the size and don't set anything if the height or width is 0. I need to try if setting the glViewport to 0 works for resizing, but that still wouldn't solve the minimization problem. I'll try to get closer to where it crashes using Paul's instructions.
I'd try another computer with different graphics card first
Did as you said, and different computer/different graphic card works like a charm. Not really satisfying, but at least it's not an issue in the code. Thanks too all for the ideas.
Curious what processor/graphics/driver which crashes OpenGL? Mine is mostly Intel 4770K/NVIDIA 770 (which delivers mind blowing speed 6 to 9 thousand fps or so in OpenGL) but some other PCs and laptops have Intel switcheable graphics with ATI and all work fine too.
I have an Intel HD 4000, no other graphics card i could switch to. Processor is an i5. I've never run into problems with OpenGL before (did some SDL-Projects in C++, wxWidgets works like a charm too, played OpenGL Games). Only Problem i seem to have is when Minimizing/Resizing a window to zero height or zero width through Clearwin OpenGL, which gives me the floating point exception.
I thought my driver was up to date, but i downloaded the newest version of the driver from lenovo (dates back to 2013, but works). I don't encounter the problem again now.
Intel graphics and drivers are not that advanced and polished.
By the way, were it your own games written in OpenGL? I have written one game in FTN95+Clearwin+OpenGL (my kids were shocked in disbelief LOL Me too, BTW, that's how good all look in OpenGL) but need more advanced way to control it via mouse.
The problem is simple: imagine the 3D surface with, say, green trees on it.
I need to select these trees when i click on them. If it were 2D %gr
i'd do that easily just by giving each tree slightly not noticeably different color and get that color associated with specific tree when click on it.
With 3D OpenGL unfortunately there is no such facility in FTN95 graphics library. And there are not so many OpenGL examples written in Fortran (DJIP wrote some for Digital/Intel Fortran almost decade ago but we lost contact since then). Paul promised to look at that but things so far not there yet. For someone familiar with OpenGL in different languages then Fortran that would be not a problem
If an application depends on having a compatible OpenGL system (and apart from trial and error, one does not know what works and what doesn't), then distributing it commercially seems problematical to me. Perhaps the answer is to distribute it complete with a compatible graphics card or even a wholly compatible computer included in the price!
It also seems to me to be yet another source of the darn thing not working if the user switches to a different version of windows ....
I'd still be interested to know what software trapped the overflow case, and reported it, as I find it difficult to believe that it occurred in a driver and was reported from there.
Eddie
I had a very similar problem on my high-end workstation with AMD graphic card.
To identify the reason it has been very helpful to remove the graphic card driver and use only the windows driver for the OpenGL graphics. The resolution is lower, but the software was running ok.
In my case it was clear, that there was an incompatibility between (newest) AMD driver and my Fortran / OpenGL software.
I changed the graphic card.
Erwin
By the way, were it your own games written in OpenGL? I have written one game in FTN95+Clearwin+OpenGL (my kids were shocked in disbelief LOL Me too, BTW, that's how good all look in OpenGL) but need more advanced way to control it via mouse.
The problem is simple: imagine the 3D surface with, say, green trees on it. I need to select these trees when i click on them. If it were 2D %gr i'd do that easily just by giving each tree slightly not noticeably different color and get that color associated with specific tree when click on it.
If the green trees are drawn using vertices, one can use the opengl implemented selection. but if the trees on the 3D surface are on the texture, i think it would be close to impossible to doing this in fortran, since you'd probably need shaders to do this.