OpenGL graphics with hardware acceleration

Hi,

I have successfully used %og to create OpenGL graphics windows, which provide excellent graphics for shading, dynamic rotation, animation and so on and is far superior to GDI graphics using %gr for these functions.

Using average video cards with 64MB or 128MB of ram all has worked well. However I have found on a couple of machines (one a laptop and one a desktop) that have the nVidia GeForce Go 6800 with 256MB of ram that the program crashes at the point it tries to create the OpenGL window using %og. It's possible to get the program to run on these machines by turning the graphics hardware acceleration completely off. Once the program is running it doesn't seem to mind the acceleration being turned back on.

With machines improving all the time, this could become a big issue for me.

I have tried different options (as you can see below) but nothing seems to work:-

c i=winio@('%^og[double,depth32,USER_RESIZE,stencil]&' i=winio@('%^og[double,depth16,USER_RESIZE]&' * ,IX_PC,IY_PC,IHNDL,opengl_proc)

Does anyone have any ideas ? Is there a windows API command I can use as an alternative to %og?

Thanks, John 😦(

No doubt you have already seen the information given in FTN95.chm under OpenGL then References and 'Online information'.

ClearWin+ does a lot of the work for you so you may find it hard work to use the OpenGL API directly. If it where possible to switch the graphics hardware acceleration off and on programatically then I guess that this could be built into the ClearWin+ code.

I believe that the Geforce Go series of cards are not quite standard. I have had problems in the past with certain applications running on a Geforce 4 Go, but which ran fine on a 'real' Geforce 4 and subsequently a 6800. Do you still have the problem with a non Go card?

Since I first started this thread I have had more instances of this problem occuring and asked a more experienced friend to investigate for me. Here is his findings:-

*I have done some faffing around, and the only thing I can think of trying is ignoring your floating point error.

My latest OGL app runs fine, however the OGL interface for my old dynamics program crashes unless you turn off hardware acceleration (it used to work fine on my laptop). The only difference between the two programs? The compiler - the one that works is Microsoft, the one that crashes is Borland. Apparently the MS compiler ignores this particular FP error by default, whereas you have to manually set the Borland compiler to ignore it. So my latest app is generating this error, ignoring it and still running OK. I don't think the problem is buried in your wrapper function - it must be at a lower level than that and it is hardware specific obviously, so someone somewhere isn't implementing their OGL correctly.

Find out where the error is, exception-catch it, and ignore it!

If this doesn't work I'm stumped.*

I'm not sure if this is possible with Salford FTN95 and even if the exception is successfully caught will %OG still complete it's task? 😕

John

In principle it is possible to trap exceptions with FTN95.

See the help topic on 'Trapping Win32 exceptions' and TRAP_EXCEPTION@.

Only trial and error will determine the outcome.

Regards

Paul

I have now included TRAP_EXCEPTION@ and after trying the program on a couple of machines with hardware acceleration, the program simply hangs on both machines producing no error messages when accelaeration is on.

I'm at a lose on what to try next !

regards John 😦(