Pascal eXtended Library (aka Asphyre) released!

[devchenxip]

Basic Simple（FireMonkey） has leak found:

---------------------------
Unexpected Memory Leak
---------------------------
An unexpected memory leak has occurred. The unexpected small block leaks are:

1 - 12 bytes: TFireDX11Provider x 1
117 - 124 bytes: TMultimediaTimer x 1


change this program Destory Event:

procedure TMainForm.FormDestroy(Sender: TObject);
begin
  EngineTimer.Free;
  EngineFonts.Free;
  EngineImages.Free;
  EngineCanvas.Free;
  EngineDevice.Free;
  DeviceProvider.Free;
  FMBridge.Free;
end;

[Zimond]

Hi there.

Maybe someone can give me a hint here :

(From the Tunnel Example)

var 
BitmapMain: TBitmap;
.
.
BitmapMain := TBitmap.Create(EngineDevice);
.
.
BitmapMain.Canvas.FillRect(0, 0, 512, 512, $FFFCFCFC, TBlendingEffect.Multiply);

Is this now the way how rendertargets work? By using Tbitmaps and creating them with the enginedevice?

[SilverWarior]

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

[pixelwriter]

I would prefer Vulkan too, but I see no fallback on older systems; so I cannot use it. GLES2 (and GLES3 almost) is viable TODAY, no need to wait. The Windows enduser has two options: a) use GLES dll of Angle, or b) use GLES dll of Swiftshader (software only, but works 100% on all systems, even winXP) We can use the dll in standard way (context via EGL) GLES Angle handles internally all driver bindings (is also looking for native GLES driver first). GLES Angle also looks for Vulkan, useful in a future when other drivers lose performance. Both Google and Microsoft work on Angle. As to MS Windows, here is the relevant page: https://github.com/Microsoft/angle/wiki Also advice about Windows OpenGL vs. Angle here: https://wiki.qt.io/Qt_5_on_Windows_ANGLE_and_OpenGL is from mid 2015, but still has valid points.

[pixelwriter]

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.

[SilverWarior]

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.

[devchenxip]

PXL.Archives.Loading.pas

add code in 415line: Image.Name:= Key;

Otherwise, according to the name lookup complains

[LP]

dear LP, PXL change too much, if you can continue to support tulip UI.

Indeed, UI has been a requested feature and even I've been offered to help porting UI. I've previously started to port Asphyre Sphinx UI to PXL, but as I'm trying to use RTTI now, it has been going slowly. Tulip UI was made by Marco Cestari, but I don't have the source code for its editor and haven't received answer to my last e-mail, so am still waiting.

By the way, there was a recent fix to FontTool, solving some issues with Unicode characters.

PXL.Archives.Loading.pas

add code in 415line: Image.Name:= Key;

Otherwise, according to the name lookup complains

Thanks! I've fixed this in both "v1.0 updates" and "master" branches.

Currently I'm still working on embedded target in master branch with full support for LPC1114, which would also serve as an example for adding support to other chips. Michael Ring has also kindly provided me additional FPC units for supporting Atmel SAM3x8e (Arduino Due) and several others, including some ARM Freedom and Nucleo boards, so I'll be testing those as well. I could also run AVR code on ATtiny2313 (smaller/cheaper chip than ATmega used in Arduino Uno), but have found few compiler optimization bugs there, so am waiting until they are fixed.

I've been also struggling with multiple hosting providers and forum software, but it seems that sorted things out and there shouldn't be any more trouble (I hope).

[Akira13]

Wow, this is a SERIOUS upgrade from the last version of Asphyre Sphinx... by far the best Object Pascal-based DirectX 11 rendering backend available. Very wise decision to do a fresh implementation of the headers, too, rather than using the terrible old JSB headers like everyone else out there.

[pixelwriter]

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