Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 33

Thread: Pascal eXtended Library (aka Asphyre) released!

  1. #21
    No there is a TCustomDrawableTexture that is intended to be used as a render target.

  2. #22
    Quote Originally Posted by devchenxip View Post
    First chance exception at $00017D80. Exception class EAccessViolation with message 'Access violation at address 0058520B, accessing address 00000000'. Process client_mobile (38

    target platform:OS X - MacOSX 10.9.5

    Code:
    procedure TExtensions.DecodeVersionString;
    var
      VersionText: TExtString;
      CharPos: Integer;
    begin
      VersionText := GetGLString(GL_VERSION);  //VersionText = ''  ??
    
    
      CharPos := 1;
    
    
      FMajorVersion := StrToIntDef(ExtractNumberWord(VersionText, CharPos), 0);
    
    
      if CharPos <= Length(VersionText) then
        FMinorVersion := StrToIntDef(ExtractNumberWord(VersionText, CharPos, 1), 0);
    end;
    Are you using Delphi or FPC/Lazarus? What version? Specs of OS X machine?

    This issue is likely caused by using OpenGL 3.0 with Forward Compatibility profile, which deprecates old functions, including "GL_VERSION" parameter. However, to be able to investigate it, I need details asked above. Also, you can report PXL bugs directly on its Bug Tracker.

  3. #23
    Quote Originally Posted by SilverWarior View Post
    No there is a TCustomDrawableTexture that is intended to be used as a render target.
    Zimond also asked this by e-mail and I've explained that PXL does support render targets similar to earlier Asphyre versions, just now they are called "drawable textures" as you've accurately explained. This new name was chosen to be something in the middle between "render targets" in DX and "frame buffer objects" in GL. However, PXL introduces TBitmap in "PXL.Bitmaps.pas", which can be used as an alternative to TAtlasImage. TBitmap can have multiple internal "storage" options: system texture (so you can access it via Bitmap.Surface.Scanline, Bitmap.Surface.Pixels and so on), lockable texture or drawable texture (both of which can be accessed through Bitmap.Texture). The storage type is chosen and/or gets changed automatically depending on how you use it, but you can also control it explicitly via Storage property.

    TBitmap also owns "Canvas", so you can draw to it easily. Something like:
    Code:
      MyBitmap := TBitmap.Create(MyDevice); // MyDevice must be already initialized here.
      MyBitmap.SetSize(256, 256);
    
      // Render something on bitmap using GPU.
      if MyBitmap.Canvas.BeginScene then
      try
        // Draw something on bitmap (in this case, green rectangle filling entire surface).
        MyBitmap.Canvas.FillRect(0, 0, 256, 256, IntColorRGB(0, 255, 0));
    
        // Draw another bitmap onto this one.
        MyBitmap.Canvas.UseImage(AnotherBitmap);
        MyBitmap.Canvas.TexQuad(FloatRect4(30, 40, 128, 128), IntColorWhite4);
      finally
        MyBitmap.Canvas.EndScene;
      end;
    
      // Now access bitmap pixels directly (in this case, set one pixel to purple).
      MyBitmap.Surface.Pixels[25, 50] := IntColorRGB(255, 0, 255);
    
      // Save final scene to disk.
      MyBitmap.SaveToFile("test.png");
    What's great about that triple storage thing is that you can render to bitmap using GPU acceleration and then switch storage to "System" and access its pixels directly, if you have to. For obvious reasons, constantly changing bitmap storage type, especially for large bitmaps, is resource-intensive and should be done with care. The framework's official package has "Tunnel" sample that illustrates usage of bitmaps.
    Last edited by LP; 22-06-2016 at 08:30 PM. Reason: improved sample code

  4. #24
    I Use DelphiXE8 and OSX10.9.5.
    I Want to how report PXL bugs directly on its Bug Tracker?

  5. #25
    Hi, Dear LP. win7 OS, in 64 bit model, compile basic project, report this error: Left side cannot be assigned to.

    [dcc64 Error] PXL.Formats.pas(577): E2064 Left side cannot be assigned to


    2016.07.19 fixed: add xe 10.1 berlin compiler directives. PXL.Config.inc
    {$IFDEF VER310} // Delphi XE 10.1
    {$DEFINE DELPHI_2009_UP}
    {$DEFINE DELPHI_2010_UP}
    {$DEFINE DELPHI_XE_UP}
    {$DEFINE DELPHI_XE2_UP}
    {$DEFINE DELPHI_XE3_UP}
    {$DEFINE DELPHI_XE4_UP}
    {$DEFINE DELPHI_XE5_UP}
    {$DEFINE DELPHI_XE5}
    {$DEFINE DELPHI_XE6_UP}
    {$DEFINE DELPHI_XE6}
    {$DEFINE DELPHI_XE7_UP}
    {$DEFINE DELPHI_XE7}
    {$DEFINE DELPHI_XE8_UP}
    {$DEFINE DELPHI_XE8}
    {$DEFINE DELPHI_XE10_UP}
    {$DEFINE DELPHI_XE10}
    {$DEFINE DELPHI_XE101_UP}
    {$DEFINE DELPHI_XE101}
    {$ENDIF}
    Last edited by devchenxip; 19-07-2016 at 02:26 AM. Reason: fixed

  6. #26
    Report a bug: TBitmapFonts.Font[fontname] return a nil value, change TBitmapFonts.insert(...) code:

    Code:
    function TBitmapFonts.Insert(const Font: TBitmapFont): Integer;
    begin
      Result := Length(FFonts);
      SetLength(FFonts, Result + 1);
    
    
      FFonts[Result] := Font;
      FFonts[Result].StyleTags := FStyleTags;
      FFonts[Result].Canvas := FCanvas;
      FSearchListDirty := True; //add this code
    end;
    Last edited by devchenxip; 29-06-2016 at 10:14 AM.

  7. #27
    Hi LP,
    is there a plan to support openGL ES2 on Windows as well?
    I find this useful as modern crossplatform solution.

  8. #28
    Why are you asking about support for OpenGL ES on Windows? Do you know that OpenGL ES is just a subset of standard OpenGL API designed for Embedded Devices so that you can use similar approach for graphical rendering on those devices as you would on desktop computers?

  9. #29
    Subset yes, but GLES 2, 3 are fully shaderbased and suffice in my case.
    The advantage is easier support in my crossplatform app.
    OpenGL drivers are not a very sure thing on Windows,
    that's why I go like the major webbrowsers (which use libGLESv2.dll for webGL
    and others). The swiftshader software renderer libGLESv2.dll is OpenSource,
    and also the speedier libGLESv2.dll Angle. This can be used as fallback
    if a hardware driver (openGL ES or matching openGL) is lacking.

  10. #30
    Quote Originally Posted by pixelwriter View Post
    OpenGL drivers are not a very sure thing on Windows,
    So why do you think that driver support for OpenGL ES would be any better since OpenGL ES is primarily developed for embedded devices and not for desktops?
    A quick search on web will tell you that in order to be able to use OpenGL ES on Windows you either need special drivers or additional SDK's for it or even worse run your software through a special OpenGL ES emulator.
    http://developer.amd.com/tools-and-s...opengl-es-sdk/
    https://www.g-truc.net/post-0457.html
    http://developer.download.nvidia.com..._pack_v100.pdf

    I personally feel that it would be better to add support for Vulkan API (https://www.khronos.org/vulkan/) which was build from the ground up to be a cross-platform graphical API. And based on initial information it can also rival with DirectX 12.
    Now while at the moment there is still limited hardware support for Vilkan API that will definitely change in the future. You see the official specifications for Vulkan API has only been officially released on 16th of February 2016 so hardware vendors did not have much time to prepare for its arrival.

Page 3 of 4 FirstFirst 1234 LastLast

Tags for this Thread

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
  •