Compatibility questions

[AthenaOfDelphi]

In theory yes, but it all depends on the language features. The big string compatibility problem came in with D2009, but since then they've been adding a lot of new language features.

The biggest problem is access to compilers. I have access to D5, D2009, XE2 and XE6 (MVP licence) so they'll be the platforms I can support.

[SilverWarior]

In theory yes, but it all depends on the language features. The big string compatibility problem came in with D2009, but since then they've been adding a lot of new language features.

There was is quite big difference between Delphi XE and Delphi XE2. Main difference is introduction of Namespaces in Delphi XE2 and moving some function into different units.
Now I haven't encountered those problems myself since I used Delphi XE trial version just for quick testing to see what is new since Delphi 7 which I was using before. I then waited a bit for Delphi XE2 to come out and bought that. So I never had to do Delphi XE to Delphi XE2 code porting.
But I read quite many complaints of other pepole about this.

I'm afraid that biggest problem will be LVVM compiler with ARC support that was introduced in Delphi XE5 for MacOS, iOS and Android platform. This introduces several big changes like "weak referencing", calling SomeObject.Free is equal to SomeObject := nil, DisposeOf method to force object destruction, etc.
I'm actually afrad that becouse of these changes we might even need seperate souce codes or heavy use of ifdefs.

The biggest problem is access to compilers. I have access to D5, D2009, XE2 and XE6 (MVP licence) so they'll be the platforms I can support.

Wait doesen't owning of newest version of Delphi grants you acces to all older versions all the way back to Delphi 7?

[de_jean_7777]

1. 2.7.x (later 2.8.x)
2. Problem, I don't own Delphi, and I don't think I could afford it right now. Also, considering the price and how often new versions come, I don't think I'd want to.
3. The same code base could support 3 and 4, as well as GLES. There are differences, but with a bit of abstraction it should be possible to support everything.
4. Supporting GLES 2 would be benefitial due to the many devices that support it.

[Mirage]

We need our code to be compiled with Delphi and FPC.
So we can use some subset of language features. We should decide which.
FPC in Delphi mode doesn't support all the features of latest versions (and probably never will).
Personally I'm satisfied with Delphi 7 language features, plus:
1. unicode (D2009, FPC 2.6.2)
2. generics (D2009, FPC 2.6.2)
3. unit namespaces (D2007, FPC 2.7.1)
As I know generics are usable starting from Delphi XE.
We'll need to test various code with generics to check if FPC and Delphi are consistent on that.

And I'd to avoid usage of ifdefs or separate units where possible.

Stable FPC 2.6.2 is very old.
FPC 2.7.1 is pretty stable.

[Cybermonkey]

Sorry to call in, but stable FPC is 2.6.4 ... since it wasn't mentioned before I thought to make a notice about that.

[pitfiend]

I think we could make it language neutral, leaving all that stuff about big strings and unicode in a separated group of units, with helpers to display the correct strings based on error codes or something like if needed.
As generics are not well supported on fpc I think we should avoid them too, specially if we plan to cover all the delphi family as well as the fpc one.

[AthenaOfDelphi]

Would a better thread be... what language features should we avoid?

[Carver413]

I think we could make it language neutral, leaving all that stuff about big strings and unicode in a separated group of units, with helpers to display the correct strings based on error codes or something like if needed.
As generics are not well supported on fpc I think we should avoid them too, specially if we plan to cover all the delphi family as well as the fpc one.

I agree with this, and would add that if the true intention of this project is to rebuilt the comunity then the best chance is threw new members wanting to learn and they will be using fpc not delphi.

[code_glitch]

If we plan the architecture well, or are clever with compiler switches I think we could emulate a system similar to the gallium developers. In other words have multiple backends which target different systems which can be worked on by people with expertise in that field. I have a system like that for the Prometheus library that when compiled for linux uses my X11_Window unit, for win32 uses my WINAPI_Window unit and for anything else uses my SDL_Window unit for event/window handling. Each unit basically translates a Prometheus call into the relevent OS level calls. That way, as a user I can do

CreateWindow(640, 480, 32);

And the compiler will automatically compile the appropriate code for the target system. If I recall this is similar to the gallium project as they have an implementation for each standard and that plugs into their actual driver code. So they implement OpenGL once, OpenCL once and even D3D once and to add enw hardware they just write the hardware specific stuff in the layer under.

Also, I dont have delphi so any code I would work on would be FPC. I also agree with the decision for using 2.6.4 as the current stable version. As for graphics, OpenGL3 and 4 seem like a good choice. As most of my work has been with OpenGL 2.1 I'd be happy to convert some of my implementation from the Prometheus library to supply a 'compatibility mode' for the engine

Edit: Forgot to mention this, but the prometheus code has texture handling, FBOs, context creation, extension loading, basic 3d support and I'm working on an HLSL implementation . It uses Benjamin Rousseaux's rather excellent TGA and PNG loaders for image loading