Page 2 of 2 FirstFirst 12
Results 11 to 15 of 15

Thread: Compatibility questions

  1. #11
    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.

  2. #12
    PGD Community Manager AthenaOfDelphi's Avatar
    Join Date
    Dec 2004
    Location
    South Wales, UK
    Posts
    1,245
    Blog Entries
    2
    Would a better thread be... what language features should we avoid?
    :: AthenaOfDelphi :: My Blog :: My Software ::

  3. #13
    PGDCE Developer Carver413's Avatar
    Join Date
    Jun 2010
    Location
    Spokane,WA,Usa
    Posts
    206
    Quote Originally Posted by pitfiend View Post
    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.

  4. #14
    PGD Staff code_glitch's Avatar
    Join Date
    Oct 2009
    Location
    UK (England, the bigger bit)
    Posts
    933
    Blog Entries
    45
    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

    Code:
    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
    I once tried to change the world. But they wouldn't give me the source code. Damned evil cunning.

  5. #15
    So few language features to leave out from coding insides are generics and operator overloading. But for the game programmer that uses the engine, we can make more features available via IFDEF's. This is 1 example
    Code:
    {$IFDEF fpc}
      operator +(const a, b: TVector2f): TVector2f;
      operator -(const a, b: TVector2f): TVector2f;
      operator *(const a, b: TVector2f): TVector2f;
      operator *(const a: TVector2f; n: single): TVector2f;
      operator /(const a: TVector2f; n: single): TVector2f;
    {$ENDIF}
    But we'd have to define it a little better than just 'fpc', because if we do support older than 2.7.1 it wouldn't compile on them. So it can be changed to something like {$IFDEF OpOverload}

    (But these are things we don't necessarily need to focus at all, except at much later time when things are already working. They're just a bonus, nothing to do with how engine works.)
    Last edited by User137; 28-04-2014 at 12:33 AM.

Page 2 of 2 FirstFirst 12

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •