Hi Tiago,
Yes, it's not normal, but in current SVN version there are some features that make conversion to 64-bit not so easy. Some problems with asm that should not mixed with delphi codes now have been fixed, but other range checking, access violations and float point overflowing, still remain as in applied demo for beer_64 project.
Hi Tiago,
Try to include Winapi.OpenGL unit in your uses clause to compile and run your app in 64 windows target platform without this error. As in attachment test. Some demos like DCEDemo, BumpShader, ShaderComponent, projection, dyncubemap,mirror, pong, tobitmap, motionblur2, ProjTextures, shadowplane, shadowvolume, imposter and few others work without Floating point overflow error now. But the many other have a conflict somewhere in OpenGLTokens unit and division by zero in GLVectorGeometry for win64 types. It should be localized.
Hi!
Is it normal that cant run GLScene on an 64b compiled app without having this error?
Hi Tiago,
Yes, it's not normal, but in current SVN version there are some features that make conversion to 64-bit not so easy. Some problems with asm that should not mixed with delphi codes now have been fixed, but other range checking, access violations and float point overflowing, still remain as in applied demo for beer_64 project.
Hi Tiago,
Try to include Winapi.OpenGL unit in your uses clause to compile and run your app in 64 windows target platform without this error. As in attachment test. Some demos like DCEDemo, BumpShader, ShaderComponent, projection, dyncubemap,mirror, pong, tobitmap, motionblur2, ProjTextures, shadowplane, shadowvolume, imposter and few others work without Floating point overflow error now. But the many other have a conflict somewhere in OpenGLTokens unit and division by zero in GLVectorGeometry for win64 types. It should be localized.
PW