EGLint in gles20 should be longint, even on win64
Original Reporter info from Mantis: Michalis @michaliskambi
-
Reporter name: Michalis Kamburelis
Original Reporter info from Mantis: Michalis @michaliskambi
- Reporter name: Michalis Kamburelis
Description:
Currently, unit packages/opengles/src/gles20.pas defines EGLint like this:
"""
EGLint = {ifdef win64}int64{
else}longint{$endif}; // Why int64 only on win64 and not even on 64-bit linux???
"""
It seems that some developer already considered this definition suspicious, and (s)he was right: the "{ifdef win64}int64{
else}" is incorrect. Testing with two OpenGLES implementations on 64-bit Windows (Mali and Angle), they both expect EGLint to be 32-bit LongInt. So this line should simply be changed to trivial
"""
EGLint = longint;
"""
This was reproduced and fixed in Castle Game Engine, in this commit: https://github.com/castle-engine/castle-engine/commit/de8cd357773051a065168e1642ab7903dd2f03dd . "Castle Game Engine" maintains a fork of FPC's gles20 unit for reasons unrelated to this issue (but explained below anyway).
Information how to get Mali or Angle is here: https://github.com/castle-engine/castle-engine/wiki/Android-FAQ#testing-mobile-opengl-es-rendering-without-an-android
&LtPos;sidenote>
Why "Castle Game Engine" maintains a copy/fork of FPC's gles20 unit ?
It's because we need to load libGLESv2 later, to work on all Android devices, with FPC 3.0.x. This is already solved in FPC 3.1.x in a more general way, outside of the gles20 unit (FPC 3.1.x delays loading all dynamic libraries on Android). So, once FPC 3.2.0 will be released (and CGE will no longer need to support FPC 3.0.x), we will be able to drop our "fork" of FPC gles20 and just use the FPC one.
&LtPos;/sidenote>
Mantis conversion info:
- Mantis ID: 33075
- OS: Windows
- Platform: x86-64
- Version: 3.0.4
- Fixed in version: 3.1.1
- Fixed in revision: 38045 (#c98214c3)