Page 12 of 13 FirstFirst ... 210111213 LastLast
Results 111 to 120 of 126

Thread: So whatever happened to the whole PGDCE thing?

  1. #111

  2. #112
    I have 15 years programming experience with Pascal/Object Pascal (Delphi and FPC), and never seen nothing that cannot do with this language. I made games, multimedia apps, console apps and database apps.

    I think pascal needs more community support, new developers don't know the power of Pascal and the power of <T>, but I saw a little improvement since 2016 at tiobe chart. https://www.tiobe.com/tiobe-index/delphi-object-pascal/

  3. #113
    I will keep making my engine, not game (chances of success 5%), then will make a proof-of-concept game using assets lifted from OA, then will try making tools (another 15% success chance), then will try making a real game (chances of success 5% again). And only then I will look what could be shared / ported back to community.
    I haven't even created a thread in "your projects" yet, it's that hopeless.

    I admit I tend to create fixes for severe flaws in FPC RTL... Then not share them back because my fixes are too specialized
    Like that one that allows you reach Platinum level of Wine compatibility using fpc 2.6.4 for Win32 Without it you get random crashes on file operations because some crap algorithm seeped into the RTL in the times of Windows 95 and never got fixed in that version (does not free file handles that are less than 5). But why where there's 3.0.2 coming Or the system that solves exception handling in a DLL - but it's too too integrated into my engine and requires the DLL to have a special callback entry point for re-raising Pascal exceptions

  4. #114
    Quote Originally Posted by Chebmaster View Post
    I will keep making my engine, not game (chances of success 5%), then will make a proof-of-concept game using assets lifted from OA, then will try making tools (another 15% success chance), then will try making a real game (chances of success 5% again). And only then I will look what could be shared / ported back to community.
    I haven't even created a thread in "your projects" yet, it's that hopeless.

    I admit I tend to create fixes for severe flaws in FPC RTL... Then not share them back because my fixes are too specialized
    Like that one that allows you reach Platinum level of Wine compatibility using fpc 2.6.4 for Win32 Without it you get random crashes on file operations because some crap algorithm seeped into the RTL in the times of Windows 95 and never got fixed in that version (does not free file handles that are less than 5). But why where there's 3.0.2 coming Or the system that solves exception handling in a DLL - but it's too too integrated into my engine and requires the DLL to have a special callback entry point for re-raising Pascal exceptions
    Uh, why are you still using FPC 2.6.4? It has a large number of known bugs that have been fixed in 3.0.0 and onwards. (Personally I always just use trunk everything for both FPC and Lazarus... the developers are careful enough that the risk and overall rate of "breakage" is quite low.)

  5. #115
    PGD Staff / News Reporter phibermon's Avatar
    Join Date
    Sep 2009
    Location
    England
    Posts
    510
    I think we've made good progress so far, I'm interested in discussing how to cater for many skill levels - it'd be nice if everybody that wanted to contribute had something to work on that they are confident with.

    But there are parts that only the minority can work on immediately.

    But there's no reason why we should wait for the core engine / graphics pipeline to be workable before its dependencies as long as we have substitutes for those dependencies and an abstraction / API that will remain at least fairly constant.

    I propose that parts such as a model loading library could be created before the engine design is even finalised and via a temporary abstraction - be able to render (for the purposes of development) using some existing system.

    In this example the structure/API of the model lib would be abstracted from the host engine so that it could be dropped in to the PGD engine when functional enough.

    Just one idea but anybody have thoughts along these lines? approaches that will let the most number of people start work on something instead of waiting for a minority to develop a framework?

    I think it would be beneficial to identify lines to be drawn so that it's multiple projects, PGD_Graphics, PGD_Resources, PGD_Framework etc - just an idea but I think it has merit.
    When the moon hits your eye like a big pizza pie - that's an extinction level impact event.

  6. #116
    Quote Originally Posted by Akira13 View Post
    Uh, why are you still using FPC 2.6.4?
    Is very stable.

    Trunk and 3.0.0 compilers, on the other hand, crash with internal errors trying to build my project (I reported many a bug). It seems that that was fixed in 3.0.2 but I want to be ABSOLUTELY sure when something crashes it's a problem in my mindscrewy code, not in the compiler or RTL.
    I had very bad experience of spending several months on difficult debugging and practically had my project die due to my confidence failing -- all because of a faulty tool causing random *unrelated* crashes.
    Let's say I would be boasting the first multi-threaded first-person shooter for DOS in human history (made in 1998 ) if not for that faulty piece of excrement. It killed my motivation.
    Since then I ONLY use stable tools. So, until the managers of Debian Stable say it's okay by raising its FPC over 2.6.4... Just no.
    I carefully prepare my code to move over to 3.0.x and periodically test if it compiles, of course, but not yet.

  7. #117
    PGD Staff / News Reporter phibermon's Avatar
    Join Date
    Sep 2009
    Location
    England
    Posts
    510
    Chebmaster : having developed cross platform code using FPC for a number of years, I've encountered many bugs, usually OS specific. I'd recommend that you build on at least two operating systems - It helps to identify the source of problems, to eliminate common code etc.

    I've found FPC 3.0.x to be very stable, my code is working on all the OSes I currently support and it touches everything you'd expect from a modern engine - I had a few issues with 2.6.x.

    There may be some issues that were introduced perhaps but don't dismiss it entirely just in case you spend ages trying to get round a bug that was later fixed - which is a more likely scenario.
    When the moon hits your eye like a big pizza pie - that's an extinction level impact event.

  8. #118
    I'm not dismissing it, I'm waiting for it to mature to the point of usability.
    Which, in my estimate, will eventually happen as fpc reaches 3.0.4 or 3.0.6
    For example, classes in 3.0.0 are not unicode so I *still* had to create this hackaround:

    Code:
      TFileStream = class(classes.THandleStream)
      Private
        FFileName : UnicodeString;
      public
        constructor Create(const AFileName: UnicodeString; Mode: Word);
        constructor Create(const AFileName: UnicodeString; Mode: Word; Rights: Cardinal);
        destructor Destroy; override;
        property FileName : UnicodeString Read FFilename;
      end;
    That wasn't hard. I already have one for 2.6.4:

    Code:
    {
      This is a permanent fix for the broken RTL of FPC 2.6.4
      See http://bugs.freepascal.org/view.php?id=27221
    
      This fix is required to get Platinum level of Wine compatibility
    }
    {$ifndef windows}
      {$fatal Windows ONLY}
    {$endif}
    type
      TFileStream = class(classes.TFileStream)
      public
        destructor Destroy; override;
      end;
    
      //The rest of the classes are dragged along by the need to base them on the fixed TFileStream
      TStringList = class(classes.TStringList)
      public
        procedure LoadFromFile(const FileName: AnsiString);
        procedure SaveToFile(const FileName: AnsiString);
      end;
    
      TIniFileKey = class
    
    //..... and so on
    // where 
    
    destructor TFileStream.Destroy;
    begin
      if Handle <= 4 then CloseHandle(Handle);
      inherited;
    end;
    P.S. Truly universal code compatible with both 2.6 and 3.0 branches goes like this:
    Code:
    {$if FPC_FULLVERSION>=20700}
      {$define che_unicode}
    {$endif}  
    
    ...
    
    {$ifdef che_unicode}
      {$if FPC_FULLVERSION<30000}
        {$fatal Impossible to use this compiler version: RTL is not unicode} //The sad truth
      {$endif}
    
      { modeswitch unicodestrings} //is in the main project file
    
      {$warn IMPLICIT_STRING_CAST_LOSS Error}
      {$warn EXPLICIT_STRING_CAST_LOSS Error}
      { if FPC_FULLVERSION<=40000} //***TODO Replace with version in which it is fixed
         {$define fix_fpc3_unicode} // Use custom mods of TFileStream, TStringList and TIniFile
      { endif}
    
      AnsiString1251 = type AnsiString(1251);
      TFileNameString = UnicodeString;
      PFileNameChar = PUnicodeChar;
    
    {$else}
      //Legacy Free Pascal below 3.0 (2.6.0 to 2.6.4)
      RawByteString = AnsiString;
      AnsiString1251 = AnsiString;
      {$ifdef windows}
        //no unicode support for file names
        TFileNameString = AnsiString;
        PFileNameChar = PAnsiChar;
      {$else}
        TFileNameString = Utf8String;
        PFileNameChar = PAnsiChar;
      {$endif}
    {$endif}
    P.P.S. This is getting far off-topic. Dear mods, please feel free to snip this discussion off.
    Last edited by Chebmaster; 13-08-2017 at 10:38 AM.

  9. #119
    PGD Staff / News Reporter phibermon's Avatar
    Join Date
    Sep 2009
    Location
    England
    Posts
    510
    Yes there are still problems - you do raise a good point - code you've patched to suit your purposes is effectively more 'advanced' - better the devil you know and all that jazz
    When the moon hits your eye like a big pizza pie - that's an extinction level impact event.

  10. #120
    @Chebmaster: I still don't understand how your filenames could possibly require unicode support. Why would anyone specifically go out of their way to use unicode characters in a filename to begin with? It makes no sense. I've also never encountered a "unicode" situation with FPC that normal "AnsiStrings" couldn't handle. For example, the following code compiles fine and displays correctly:

    Code:
    procedure TForm1.FormShow(Sender: TObject);
    var
      MyString: AnsiString;
    begin
      MyString := '' + '' + '' + '' + '' + 'ȾȾȾȾȾȾȾȾ' + 'ɎɎɎɎɎɎɎɎ' + 'ΏΏΏΏΏΏΏΏΏ' + 'ϼϼϼϼϼ';
      ShowMessage(MyString);
    end;
    Also, you do realize the people who maintain Debian are entirely unrelated to the developers of FPC/Lazarus, right?....
    Last edited by Akira13; 10-09-2017 at 04:54 PM.

Page 12 of 13 FirstFirst ... 210111213 LastLast

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
  •