View Issue Details

IDProjectCategoryView StatusLast Update
0033075FPCPackagespublic2018-01-25 21:53
ReporterMichalis Kamburelis Assigned ToMarco van de Voort  
PrioritynormalSeverityminorReproducibilityhave not tried
Status resolvedResolutionfixed 
Product Version3.0.4 
Fixed in Version3.1.1 
Summary0033075: EGLint in gles20 should be longint, even on win64
DescriptionCurrently, 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: . "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:

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.
TagsNo tags attached.
Fixed in Revision38045
Attached Files


Thaddy de Koning

2018-01-25 08:23

reporter   ~0106037

Last edited: 2018-01-25 08:35

View 2 revisions

I have prepared a complete new set for EGL, Gles20 and OpenVG headers and KHRONOS types that separates EGL from the gles units. When cleaned up I will submit it as patch. I also need to do that for GL(X). There are several more issues with the current headers that can only be cleaned up if the dependencies on X and EGL are factored out. There are also many wrong declarations (or in the wrong place) (hence my request for OpaqueData and OpaquePointer, which is now in trunk system.
They are generated from the latest Khronos tree so also more up-to-date.
I will submit ASAP, maybe this weekend on the forum for testing. Unless somebody else has it ready along the same lines.

Btw it is indeed typedef khronos_int32_t EGLint; which in turn is longint on all platforms.

Issue History

Date Modified Username Field Change
2018-01-25 06:47 Michalis Kamburelis New Issue
2018-01-25 08:23 Thaddy de Koning Note Added: 0106037
2018-01-25 08:35 Thaddy de Koning Note Edited: 0106037 View Revisions
2018-01-25 21:53 Marco van de Voort Fixed in Revision => 38045
2018-01-25 21:53 Marco van de Voort Status new => resolved
2018-01-25 21:53 Marco van de Voort Fixed in Version => 3.1.1
2018-01-25 21:53 Marco van de Voort Resolution open => fixed
2018-01-25 21:53 Marco van de Voort Assigned To => Marco van de Voort