I am starting a rewrite of my 2D hardware accelerated Pascal graphics library based on an OpenGL 3D backend, and I stumbled across an open source project called NanoVG. I am impressed with how small and self contained NanoVG is, and although I will recreated my 2D graphics library upon OpenGL without using NanoVG, I though some of you on the mailing list might have some interest.

Here is some reference material on NanoVG:

Original github page, but there might be an improved fork I can't find at the moment <https://github.com/memononen/nanovg>
How to build User Interfaces and 2D Shapes with NanoVG <https://www.geeks3d.com/hacklab/20160205/how-to-build-user-interfaces-and-2d-shapes-with-nanovg/>

What's important is that several people have ported the projects to other languages and backends (DX11 for example). Looking at how small and self contain it is, it would seem like a task that would not that difficult to port to Pascal.

I believe it would be an interesting project that would benefit us Pascal users greater if it were ported and was wondering if anyone of you might pick up the torch so to speak. Normally I wouldn't have too much of an issue with porting a project like this, but my graphics backend has already been written once and I will be adding a few features beyond NanoVG, and also using a different design. I would rather compare the two, NanoVG written in Pascal, and my library rather than merge them or at the least be though of as having copying ideas from NanoVG, so I want to keep these worlds separate.

If anyone has thoughts about a Pascal version of NanoVG, possibly even from a more updated git repo, please send you feedback to others in this thread.

Thank you, Anthony.
<https://www.geeks3d.com/hacklab/20160205/how-to-build-user-interfaces-and-2d-shapes-with-nanovg/> -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20200126/1e42c4b2/attachment.html>

What thinks about Anthony?

Translate NanoVG sources from C to Pascal or made a library bindings for that?

Em dom., 26 de jan. de 2020 às 04:14, Anthony Walter via lazarus <

On Jan 26, 2020, at 2:13 PM, Anthony Walter via lazarus wrote: What's important is that several people have ported the projects to other languages and backends (DX11 for example). Looking at how small and self contain it is, it would seem like a task that would not that difficult to port to Pascal.

It looks like a great library but glancing over the project tells me that porting all of that to Pascal would take many days. Probably best to just make a binding.

Regards,
Ryan Joseph

I've been playing with the demos on VC2017, it requires 2 other external libraries to run.

Marc

I've been playing with the demos on VC2017, it requires 2 other external libraries to run.

Marc

Marc,

The library does not have any code to manage creating a window, creating a valid opengl context, or handle event processing. These are things which are not exactly trivial in nature, especially in a cross platform manner. Typically for simplicity makers of OpenGL demos rely upon things like GLFW (Graphics Library FrameWork) to get a demo working. Other libraries to do the same thing are SDL, GLUT, SFML, or other similar libraries.

The good news is that NanoVG is designed to work independently of those things. The original C implementation has a callback stub to load the appropriate OpenGL functions based on which back end you choose. Fortunately this tool named Glad <https://glad.dav1d.de/> makes it very simple to create a correct Pascal (or other language) file for the various OpenGL versions. This is probably something we ought to consider using in the FCL, so that for example people would know what functions to load for OpenGL ES versus the full version of OpenGL.

And finally the LCL and TOpenGLControl provided in the components folder handle all the requirements already, so if you wanted to use a NanoVG port with Lazarus it ought to be as simple as including some NanoVG.pas in your project and putting a few NanoVG drawing function calls into your TForm1.OpenGLControl1Paint method. In this way using hardware accelerated animated vector text and graphics in any desktop project would be very easy. NanoVG even includes functions to draw vector controls such as sliders, check boxes, buttons, and combo boxes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20200128/9c53ac70/attachment.html>

Hi Anthony,

Have you considered GPLT for OpenGL context creation?

https://github.com/daar/GLPT

Rgds, Darius

Verstuurd vanaf mijn iPhone

The library does not have any code to manage creating a window, creating a valid opengl context, or handle event processing. These are things which are not exactly trivial in nature, especially in a cross platform manner. Typically for simplicity makers of OpenGL demos rely upon things like GLFW (Graphics Library FrameWork) to get a demo working. Other libraries to do the same thing are SDL, GLUT, SFML, or other similar libraries.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20200128/d9907fa8/attachment.html>

Darius,

No I hadn't heard of GLPT before you posted the link. It looks interesting, but I was just reading up on SFML and had a few thought which are pertinent. I've been using SDL, and although it's a fairly good library, there are other libraries which offer a few more features that I'd had to implement in my toolkit, and now in retrospect I believe ought to be included in libraries of the same vein, including the GLPT library you mentioned.

Here are some of the things both GLPT and SDL do not handle, but I believe ought to be included in a game/multimedia framework as they sometimes require a bit of work and are things everyone will eventually need is they write enough of these types of programs:

A stereo audio mixer that can handle mp3, ogg, and direct wav samples without the need to include 3rd party additional modules Text rendering with the ability to load local ttf files, get metrics, draw to a texture, and possibly generate vector shapes
A unified TCP and UDP network stack
A unified image load, saving, and capture system
Audio input or recording function optionally with VOIP support A tessellator to turn a complex shape into triangles with indexes, supporting winding modes
The ability to ask for a graphics API type and version (eg, OpenGLES 2.0 or Vulkan 1.1) receive a callback to load said API functions A video decoder to take a video stream and convert frames to textures or render buffers

Having listed those items, SFML handles a lot of those things. SDL can handle most of them as well with their SDL modules, but I always avoid SDL modules. GLPT doesn't handle much beyond window creating, events, some image loading, and maybe a few basic text features.

Personally, I have gone the tough route and written Pascal units to interface with several 3rd party libraries to add text and font features (FreeType), audio decoders (mpg123), and video steam processing to render buffers (libmpv). Now maybe it is convenient to use my library, but it's Pascal and rider on top of all these things, which I am sure how SFML works, but I am also fairly confident that a single well maintained cross platform library with many more users, such as SFML or SDL with modules, might be more attractive to people wanting to get started with everything packed more neatly than the way my requirements are gathered. -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20200128/657eac95/attachment.html>