CGE doesn't compile with Delphi XE7

[peardox]

Missing some issues from XE4 so OpenGLext must exist by the time XE7 came out. Also has System.NetEncoding.

These also pop up... 1) [dcc32 Error] jsonscanner.pas(362): E2003 Undeclared identifier: 'CP_UTF8' 2) {$warn COMBINING_SIGNED_UNSIGNED64 off} (not found)

It appears XE7 didn't have a TOwnerStream yet as the compilation fails for this...

constructor TGZFileStream.Create(const Stream: TStream; const AWriteMode: boolean); begin if AWriteMode then raise EZlibError.Create('Writing gzip data on Delphi not implemented yet');

inherited Create(Stream, { Simple way to read gzip-compressed data with Delphi, see https://stackoverflow.com/questions/31221429/delphi-xe-8-how-to-decompress-a-gzip-file . 31 bit wide window means that we require GZIP header (and not just Zlib header). } 15 + 16, { OwnsStream = true, to behave just like TGZFileStream that descends from TOwnerStream. } true); end;

Next 10.0

[michaliskambi]

Thank you for all the tests with older Delphi versions! I think I'll attempt then compatibility with >= XE7 as this seems like a bunch of relatively local fixes. And we'll keep "eventually maybe >= XE4" in the backlog, depending on whether users will actually require it.

[peardox]

The XEn compilers need a throw-away valid installation key (I documented how to get them in Discord #delphi)

Your DEVREL covers XEn but the installer is ignorant of this fact while the IDE is aware of License Manager.

Download an XE then start the install and when it asks for the serial use the one from that list - you prob want the XE7 enterprise one. After install it'll use the serial from license manager.

The following (long explanation) is documented here as it may possibly help your CI strategy...

A side efect of this is that you need license manager already present which should be fine if you're installing side-by-side on a main. However (and I only worked out how to do this last week) if you want e.g. a VM with ONLY XE7 on it you're in a chicken+egg situation (no License manager that will work). The solution in this event is to create a base VM with no delphi but everything else you need then when you're happy with it stick a installer for a 10.x on the VM and start installtion. Get as far as entering and accepting your key then when it wants to start installing Delphi Cancel / quit out and remove the installer. You've now got a VM with a compatible license manager (knows about idera - looks at right servers). Backup you LM-enable but Delphi absent VM.

Once that's done you can install any earlier Delphi in the VM with an XE key and it'll be quite happy. Just restore the clean VM when you want a new Delphi install and it'll all work. Unless you use this method you'll eventually run out of installations and you'll need to get Jim (now Ian) to reset/increase your install limit.

I found out all this by experiment + happy accident - it doesn't appear to be documented anywhere... I'm acually quite close to my install limit but this method works around it + is needed if you're doing 'proper' test scenarios.

[peardox]

I'm just re-doing the XE7 tests as I had an issue with testing methodology for that one

IF anything changes I'll report...

[peardox]

Righto - VCL = easy, FMX = bad (not sure how bad though)

After making the following (extremely bad) alterations to CGE TestVCL - my extremely minimal Delphi + CGE test worked

i.e. resolving as opposed to removing the problems listed below should create VCL XE7 stable

However, XE7 has no FMX.Presentation.Win so FMX is more problematical (and not easily hackable)

############################ jsonscanner - Undefined symbol - needs const {$EXTERNALSYM CP_UTF8} CP_UTF8 = 65001; { UTF-8 translation }

############################ function StackTipCalc(const Angle: Single): TVector3; [dcc32 Error] castleinternalbackgroundrenderer.pas(379): E2089 Invalid typecast

removed Assert(Angle = Single(Pi));

############################ function SpecularFactor(const M: TMaterialInfo): TCastleColorRGB; [dcc32 Error] x3dnodes_lightinstance.inc(220): E2089 Invalid typecast [dcc32 Error] x3dnodes_x3d3dbackgroundnode.inc(150): E2036 Variable required

Hacked out issue

############################ procedure TAbstract3DBackgroundNode.CreateNode;

Hacked out issue

############################ function TCastleAbstractRootTransform.WorldMoveAllowed( [dcc32 Error] castletransform_abstractroottransform.inc(592): E2250 There is no overloaded version of 'MoveCollision' that can be called with these arguments

Hacked out issue (twice)

[peardox]

Hmm - does FMX.Presentation.Win refer to generic windows or M$WINDOWS I wonder?

FMX is platform neutral so if an OS this seems bad requirement for non-Windows OSes (Eventually)

[michaliskambi]

Thanks for the information about XE7. I'll get back to this when I'll get to testing XE7.

About this:

Hmm - does FMX.Presentation.Win refer to generic windows or M$WINDOWS I wonder?

FMX is platform neutral so if an OS this seems bad requirement for non-Windows OSes (Eventually)

FMX.Presentation.Win refers to Windows.

Basically, FMX is not "magically" cross-platform :) You can make components with cross-platform API, but underneath (some) components require platform-specific code.

In case of CGE, this is also necessary: we need to initialize OpenGL context in platform-specific way, FMX doesn't provide it as of itself (on some platforms FMX has already OpenGL context, but not on others; on Windows you're on your own). So our Fmx.CastleControl unit with TCastleControl underneath has Windows-specific bits. It needs to use FMX TWinPresentation that exposes Windows handle for given control, and use CGE TGLContextWGL that can create OpenGL context for this Windows handle. There's just no other way of doing it -- FMX doesn't provide a ready "cross-platform component to get OpenGL".

And yes, it means CGE Fmx.CastleControl code is only for Windows right now. As part of porting CGE to other platforms in case of Delphi, we will have to also abstract this -- so on Linux etc. the FMX TWinPresentation and CGE TGLContextWGL will be something else. We may of course reorganize the code a bit when doing this (e.g. TWinPresentation could be moved to different unit once we abstract some stuff), to avoid littering Fmx.CastleControl code with $ifdefs . But, one way or another, there will be platform-specific code necessary to integrate CGE with FMX.

[peardox]

The FMX situation only really affects rather old compilers - Tokyo (10.1.x is prob the cut-off as it included 'Windows 10 styles for VCL and FMX') which sorta sounds presentation-like to me.

I can check which specific compiler added it as I've got all latest versions from XE7 skipping XE8 onwards now (would also need point checking ideally)

Personally I'm not bothered as I use newer compilers and 10.2.3 (Released March 2018) works fine - simply providing as much useful info as poss so you can pick a lower limit - also that 10.2 started packaging FMXLinux in Enterprise.

XE7 (September 2, 2014) seems to be a popular cut-off for older compilers Some stuff still goes back as far as XE2 (September 1, 2011) A very few packages pre-date XE2 and we don't have access to the compilers anyway (may be possible if vital but wouldn't bother - pretty non-existant marhet)

[michaliskambi]

Note that if you think about older Delphis and platforms other than Windows -- this will be more complicated. Basically, we will for sure not support Delphi XE7 with all our planned platforms.

See https://castle-engine.io/supported_compilers.php#section_platforms , my statement "We will not support Delphi versions older than 10.4 for mobile (Android and iOS)" and the explanation of it.

So my plan is, to be clear:

• Explore Delphi >= XE7 targeting Windows (32-bit and 64-bit).
• But for mobile platforms (Android, iOS) we will for sure require at least Delphi 10.4.
• (I do not know where other platforms, like Linux, place here.)

From what I can tell (see references from https://castle-engine.io/supported_compilers.php#section_platforms ) the way older Delphis decided to deal with strings on mobile is crazy-incompatible. Supporting it would be a big pain. Luckily they fixed their approach at Delphi 10.4.

[peardox]

Sounds good to me

What about Linux + Mac? Mac ARM required 11.x anyway (does 11.3CE do it - I'll have to check but probably) and of couse Linux is Enterprise required.

I remember that SKSL (https://github.com/skia4delphi/skia4delphi) didn't support Mac at all < 11.x - a choice owing to issues wiith earlier Delphis if I recall correctly.

[michaliskambi]

Thank you for testing -- for now I say to officially cut these older Delphi versions. The effort isn't really trivial, as any special hacks would need to be maintained / tested, and the usefullness for users is anyway not big -- since non-Windows platforms would not be supported with these older Delphis anyway, so the big CGE feature "cross platform" would not in practice be relevant for people with these old Delphis.