Results 1 to 10 of 48

Thread: Cheb's project will be here.

Hybrid View

Previous Post Previous Post   Next Post Next Post
  1. #1



    Yet another !surprise! from this newfangled string encoding auto-management.

    I launched my engine compiled in fpc 3.0.4 on the mammoth coprolite I call my file server:
    Code:
    Chentrah version 0.21.3847 for Win32-i386, 
      compiled at 12:21:52 on 2018/01/28 using Free Pascal 3.0.4.
      (developer mode on)
    Operating System: Wine 1.3.28 / Ubuntu 11.10
    User name: cheb
    CPU Phenom II X2 550
      x2 logical cores
      level 2 cache: 512 Kbytes, line size 64 bytes
      TSC invariancy: yes
      TSC frequency: 3.11 GHz)
    Lo and behold it crashed with "Failed to load "GL_ARB_framebuffer_object"".
    Scratching the bone between my ears, I checked the extension string. Nope, the extension was there. So why?

    Unearthed an old function naively assuming that String = AnsiString:
    Code:
    function glext_ExtensionSupported(const extension: String; const searchIn: String): Boolean;
    var
      extensions: PAnsiChar;
      start: PAnsiChar;
      where, terminator: PAnsiChar;
    begin
    
      if (Pos(' ', extension) <> 0) or (extension = '') then
      begin
        Result := FALSE;
        Exit;
      end;
    
      if searchIn = '' then extensions := PAnsiChar(glGetString(GL_EXTENSIONS))
      else extensions := PAnsiChar(searchIn);
      start := extensions;
      while TRUE do
      begin
        where := StrPos(start, PAnsiChar(extension));
        if where = nil then Break;
        terminator := Pointer(PtrUInt(where) + Length(extension));
        if (where = start) or (PAnsiChar(PtrUInt(where) - 1)^ = ' ') then
        begin
          if (terminator^ = ' ') or (terminator^ = #0) then
          begin
            Result := TRUE;
            Exit;
          end;
        end;
        start := terminator;
      end;
      Result := FALSE;
    
    end;
    Corrected it to AnsiString and my engine started up, proving there is life on GeForce 7025.

    But!
    The wrong version was working fine in real Windows.
    I can only assume that that fossilized wine did not have some mechanism the auto-recoding of the FPC RTL relies on.
    That's another thing to watch out for, I suppose.
    Last edited by Chebmaster; 20-11-2019 at 08:58 AM.

  2. #2
    Cheb's Game Engine is that eternally worked on thing that never releases its next build.

    Today, seeing the compilation process complete, I roared like a bear overcoming horrible constipation: I spent a full year refactoring my code. A full year!

    Ahhhhh...

    A debugging hell lies ahead of me but all I could feel is relief. Finally!

    The previous build was released at December 17, 2016 (please don't go looking at it: I am horribly ashamed of that mess by some mistake called my sources).

    The last year I looked at Fidel Castro's example and gave a vow to never shave or trim my beard until my engine goes past the rotating cube stage. I am now forced to resort to dirty life hacks like putting my t-shirt over my beard so that it stays stuffed down my collar to look presentable ...

    My track record of making side trips, each holding me back for a year or two:
    2007: Linux support
    2009: Migrating from OpenGL ~1.4 to OpenGL 2.1 (later GL ES 2)
    2010: Tired of never getting anywhere, almost abandoned the project
    2013: Changing architecture to multi-threaded for multi-core CPU support
    2015: x86-64 support (still not finished, dammit, requires FPC 3.2 released to continue)
    2016: Raspberry Pi support
    2018: Epic refactoring of my horribly dated ODBMS I created back in 2006

  3. #3
    Ah yes.. strings! i've done migration of my game to widestrings everywhere 2-3 years ago, i still feel some pain, but it was worth it in the end!

    Same with "epic refactoring" - after converting my project from delphi 7 to freepascal, i've done so much refactoring and consequentially simplifications - make use of operator overlading, generics and methods in records, code writes a hell lot cleaner in modern pascal

    You have interesting way of building your engine, especially that you can keep resources loaded and re-load the game logic, i assume it's done via sort of dll mechanism?
    This is my game project - Top Down City:
    http://www.pascalgamedevelopment.com...y-Topic-Reboot

    My OpenAL audio wrapper with Intelligent Source Manager to use unlimited:
    http://www.pascalgamedevelopment.com...source+manager

  4. #4
    Yes, indeed. All game logic resides in a module DLL hosted by the mother EXE. When the DLL unloads it uses the same serialization mechanism used for saving to selectively gather all asset classes (owning OpenGL handles and such) and store them into a memory stream owned by the EXE.
    The process is not as simple as it looks (because of interdependent nested assets like fbos and their textures I have the assets loaded from the save "devour" their counterparts received from the mother taking over their handles) but I had it working almost perfectly before the rehaul.

    Generics, turns out I have invented them as well, back when fpc 1.x didn't have dynamic arrays yet but already had modern classes. Worked via tricky includes and preprocessor. I plan to re-do the static remains of those classes, still used everywhere, using real generics. But that is a secondary task.

    What I was going to do before rehauling my ODBMS was replacing the old, horribly awkward module switching GUI in the EXE with the standard GUI that is available to the DLL, making them into a specialized module DLL of their own thus leaving the EXE a dumb container only able to render console. And because I interrupted that task half-way in October 2018, I forgot what I was going to do and where I stopped. Now my engine finally runs... rendering a blank screen and not responding to inputs.
    Where do I start... Boo-hoo-hoo...

  5. #5
    During debugging, encountered a grievous documentation error:
    Code:
    function TChepersyMemoryManagerChunk.Alloc: pointer;
    var 
      i, k: integer;
      j: cardinal;
      m: ptruint;
    begin
      i:= 0;
      // the mask bits of non-valid indexes are pre-set to 1, see the constructor
      for i:= 0 to High(f_AllocMask) do begin
        m:= not f_AllocMask[i];
    
        if m = 0 then continue; 
        // https://www.freepascal.org/docs-html/current/rtl/system/bsfdword.html
        // incorrectly states that BsfDWord returns 255 if no bits are set
        // while in fact it returns 0! (at least in fp 2.6.4 it does)
            j:= {$ifdef cpu64}BsfQWord( {$else}BsfDWord( {$endif} m );
    addlog(' i=%0, j=%1, k=%2, mask=%3',[i,j,k,pointer(f_AllocMask[i])])    ;
    //    if j < 255 then begin
          k:= (i * 8 * sizeof(pointer)) + j;
          Assert((k >= f_IdxLow) and (k <= f_IdxHigh)
                , 'TChepersyMemoryManagerChunk.Alloc: index ' + IntToStr(k) 
                + ' is out of bounds (' + IntToStr(f_IdxLow) + ',' 
                + IntToStr(f_IdxHigh) + ')');
          Inc(f_AllocCount);
          Dec(f_FreeCount);
          if f_FreeCount = 0 then CpsMemoryManager.OnChunkBecomingFull(Self);
          f_AllocMask[i]:= f_AllocMask[i] or (ptruint(1) shl j); 
          Exit(pointer(ptruint(Self) + ptruint(k) * f_Size));
    //    end;
      end;
      Die(MI_ERROR_PROGRAMMER_NO_BAKA, [
                               'TChepersyMemoryManagerChunk.Alloc algorithm fail']);
    end;
    ..aaand I'd say this is more than just twitching:

    YEEEE-HAW!

  6. #6
    elaborating:
    Code:
    program test;
    begin
      WriteLn(BsfDword(0));
      WriteLn(BsfQWord(0));
      WriteLn({$I %FPCVERSION%});
    end.
    d:chentrahmodulestests>c:FPC2.6.4bini386-win32fpc bsfdword.pas
    Free Pascal Compiler version 2.6.4 [2014/03/06] for i386
    Copyright (c) 1993-2014 by Florian Klaempfl and others
    Target OS: Win32 for i386
    Compiling bsfdword.pas
    Linking bsfdword.exe
    7 lines compiled, 0.1 sec , 25616 bytes code, 1628 bytes data

    d:chentrahmodulestests>bsfdword
    0
    4231860
    2.6.4

    d:chentrahmodulestests>c:FPC3.0.4bini386-win32fpc bsfdword.pas
    Free Pascal Compiler version 3.0.4 [2017/10/06] for i386
    Copyright (c) 1993-2017 by Florian Klaempfl and others
    Target OS: Win32 for i386
    Compiling bsfdword.pas
    Linking bsfdword.exe
    7 lines compiled, 0.1 sec, 25424 bytes code, 1252 bytes data

    d:chentrahmodulestests>bsfdword
    255
    255
    3.0.4

  7. #7
    This mighty Cheb finally wrangled unicode paths into submission!

    I've successfully ran my engine in GL ES 2 mode from a folder named D:\/人◕‿‿◕人\ while it contains ANGLE DLLs ripped from old Firefox, which are NOT unicode - i.e. they crash and burn if loaded from a path not representable in the system 8-bit encoding (CP1251 in my case).

    This is how:
    Code:
      function GetAnsiSafePath(s: TFileNameString): TFileNameString;
      {$ifndef windows}
      begin
        Result:= s;
      end;  
      {$else}
      // ASSUMING that the file name is safe anyway
      var
        u, b: UnicodeString;
        reqlen: dword;
        fn, pt: TFileNameString; 
        a: Array of UnicodeString;
        i: integer;
      begin
        if Length(s) = 0 then Exit(s);
        fn:= ExtractFileName(s);
        // first, optimize the path correcting slashes and collapsing all '\..\'
        pt:= OptiPath(ExtractFilePath(s));
        u:= FileNameToUnicode(pt);
        if IsPathAnsiSafe(u) then Exit(s);
        a:= Explode('\', u);
        u:= a[0] + '\'; // assuming its the drive letter, not checking
        for i:= 1 to High(a) - 1 do begin
          u+= a[i] + '\';
          if IsPathAnsiSafe(u) then continue;
    
          reqlen:= GetShortPathNameW(@u[1], nil, 0); //msdn sayd NOT INCLUDING
            // the terminating #0 but then where does that extra space
            // come from?
          if reqlen = 0 then begin
            GetLastError; // clear the error message
            Exit(s);
          end;
          SetLength(b, reqlen); // automatically creates extra space for the terminating zero
          SetLength(b, GetShortPathNameW(@u[1], @b[1], reqlen + 1));
          if Length(b) = 0 then Exit(s);
          u:= b;
        end;
        Result:= UnicodeToFileName(u) + fn;
      end;
      {$endif}
    , where OptiPath is my custom path parser that collapses relative paths containing '\..\', UnicodeToFileName and so on are from my chtonic patch for fpc where TFileNameString = Utf8String even in Windows (I don't use lazarus libraries, implemented everything on my own) and IsPathAnsiSafe is this:
    Code:
    function IsPathAnsiSafe(u: UnicodeString): boolean;
    {$ifndef windows}
    begin Result:= Yes end;
    {$else windows}
    var 
      a: UnicodeString;
      b: AnsiString;
      i: integer;
      res: longbool;
      ac: AnsiChar;
    begin
      if Length(u) < 1 then Exit(Yes);
      
      res:= false;
      i:= WideCharToMultiByte(CP_ACP, WC_COMPOSITECHECK or WC_DISCARDNS, 
                                               @u[1], length(u), nil, 0, nil, nil);
      if i < 1 then Exit(Yes); // graceful degradation
      SetLength(b, i);
      ac:= #7;
      WideCharToMultiByte(CP_ACP, WC_COMPOSITECHECK or WC_DISCARDNS,
                                            @u[1], length(u), @b[1], i, @ac, @res);
      Result:= Yes;
      for i:= 1 to Length(b) do
        if ord(b[i]) < 32 then begin
          Result:= No;
          break;
        end; 
    end;
    {$endif windows}
    Aaaand, it worked!
    Loading d:\84BC~1\3rdparty\ANGLE\win32\libGLESv2.dll...Ok, d:\84BC~1\3rdparty\ANGLE\win32\libGLESv2.dll
    Loading d:\84BC~1\3rdparty\ANGLE\win32\libEGL.dll...Ok, d:\84BC~1\3rdparty\ANGLE\win32\libEGL.dll
    Loading the procedure addresses from the GL ES DLL ...
    glActiveTexture() at 5F1742C0h in d:\84BC~1\3rdparty\ANGLE\win32\libGLESv2.dll
    glAttachShader() at 5F1742C5h in d:\84BC~1\3rdparty\ANGLE\win32\libGLESv2.dll
    glBindAttribLocation() at 5F1742CAh in d:\84BC~1\3rdparty\ANGLE\win32\libGLESv2.dll
    glBindBuffer() at 5F1742CFh in d:\84BC~1\3rdparty\ANGLE\win32\libGLESv2.dll
    P.S. I had unhealthy obsession with redefining true and false as "Yes" and "No". I still follow this in my engine as it became standard.

    P.P.S. This was a big problem in WinXP as it used user's name for that user's home directory. Use one non-unicode character and suddenly lots of software crash on you. Including anything compiled in fpc.
    I'm not sure if later windozes resolved that.
    Last edited by Chebmaster; 14-01-2020 at 03:30 PM.

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
  •