RayLib 5.0

[Guva]

Hello everyone
The new ray4Laz release is available on github at https://github.com/GuvaCode/Ray4Laz   

New version is also available in the network package manager.

there are a lot of changes in this release !!!

here are some of them :

• NEW Platform backend supported: SDL: Thanks to the new rcore platform-split, the addition of new platforms/backends to raylib has been greatly simplified. As a proof of concept, SDL2 platform backend has been added to raylib as an aternative for GLFW library for desktop builds: platforms/rcore_desktop_sdl. Lot of work has been put to provide exactly the same features as the other platforms and carefully test the new implementation. Now SDL2 fans can use this new backend, just providing the required include libraries on compilation and linkage (not included in raylib, like GLFW). SDL backend support also eases the process of supporting a wider range of platforms that already support SDL.
• NEW Platform backend supported: Nintendo Switch (closed source): The addition of the SDL backend was quite a challenge but to really verify the robustness and ease of the new platform plugin system, adding support for a console was a more demanding adventure. Surprisingly, only two days of work were required to add support for Nintendo Switch to raylib! Implementation result showed an outstanding level of simplicity, with a self-contained module (rcore_swith.cpp) supporting graphics and inputs. Unfortunately this module can not be open-sourced due to licensing restrictions.
• NEW Splines drawing and evaluation API: A complete set of functions has been added to draw and evaluate different types of splines: Linear, Basis, Catmull-Rom, Quadratic Bezier and Cubic Bezier. Splines are extremely useful for game development (describe paths, control NPC movement...) but they can also be very useful on tools development (node-conections, elements-movement, 3d modelling, animations...). This was the missing feature on the raylib rshapes module to make it complete! Note that rshapes module can also be used independently of raylib just providing the only 6 functions required for vertex definition and drawing.
• NEW Pseudo-random numbers generator: rprand: After several years of users asking for this missing piece, a brand new pseudo-random generator module has been added to raylib. rprand implements the Xoshiro128** algorithm combined with SplitMix64, specially suited for fast software pseudo-random numbers generation. The module also implies some useful functions to generate non-repetitive random numbers sequences, functionality exposed by raylib. usage of this module can be controlled by a compilation flag, in case the default libc rand() function was preferred.
• NEW Automation Events System API: This new system was first added in raylib 4.0 as an experimental feature but it was a bit clumsy and there was no API exposed to users. For the new raylib 5.0 the system has been redesigned and proper API added for the users. With this new events automation system, users can record input events for later replay, very useful feature for testing automation, tutorials generation, assisted game playing, in-game cinematics, speedruns saving or even AI assited game playing!
• NEW raygui 4.0: The official raylib immediate-mode gui library designed for tools development has been updated to a new version, aligned with raylib 5.0. This new version is a complete redesign of raygui to unify all controls structure and usage, now all controls have the same function signature!. raygui has been battle-tested with the development of +12 published tools in the last few years. The tools can be seen and used for free in the raylib technologies tools page. Worth mentioning that several of those tools have been open sourced for anyone to use, compile, contribute or learn how the code works.

ps: added compiled raylib (with physics and gui enabled) for Linux x32 and x64, Windows x32 and x64 platforms.

[DrakkTheSeafarer]

great work!

[YiannisKam]

In raymath.pas, line 132 the function Vector2Equals(p, q: TVector2): TVector2; ... should return an integer not a TVector2.

[Guva]

In raymath.pas, line 132 the function Vector2Equals(p, q: TVector2): TVector2; ... should return an integer not a TVector2.

thanks I fixed it

[YiannisKam]

You're welcome, thank you too.

[Mongkey]

Hello @guva,

is there a container for raylib in a form? i would use raylib 5.0 for data visualization, this one is much cheap cpu usage game engine.

I couldn't run gui example, it always crash.

Thank you.

[Mongkey]

I found a sample

https://gist.github.com/ChrisDill/c2ca6a0ccf592c073a8d2aaeaa4adb7f
https://gist.github.com/flibitijibibo/cf282bfccc1eaeb47550

Thank you

[Guva]

I found a sample

https://gist.github.com/ChrisDill/c2ca6a0ccf592c073a8d2aaeaa4adb7f
https://gist.github.com/flibitijibibo/cf282bfccc1eaeb47550

Thank you

you can see how the renderer for lcl is implemented in zengl
https://github.com/Seenkao/New-ZenGL/tree/ZenGL_4_2/Zengl_SRC/demos/Lazarus/18%20-%20LCLZenGL

next weekend I'll try to realize

[Seenkao]

you can see how the renderer for lcl is implemented in zengl

Это не совсем правильная реализация. Но работать будет. ZenGL считается однопотоковым приложением и данные не защищены от многопотока. Лучше всего реализовать в таких случаях защиту данных в многопоточных приложениях.

В дальнейшем я буду думать над правкой ZenGL для многопоточных приложений. И, вернее всего, потом не нужны будут данные ограничения для таймера в каждой вызываемой процедуре/функции.

Google translate:
This is not a completely correct implementation. But it will work. ZenGL is considered a single threaded application and the data is not thread safe. In such cases, it is best to implement data protection in multi-threaded applications.

In the future I will think about editing ZenGL for multi-threaded applications. And, most likely, then these restrictions for the timer in each called procedure/function will not be needed.

[Guva]

you can see how the renderer for lcl is implemented in zengl

Это не совсем правильная реализация. Но работать будет. ZenGL считается однопотоковым приложением и данные не защищены от многопотока. Лучше всего реализовать в таких случаях защиту данных в многопоточных приложениях.

В дальнейшем я буду думать над правкой ZenGL для многопоточных приложений. И, вернее всего, потом не нужны будут данные ограничения для таймера в каждой вызываемой процедуре/функции.

Google translate:
This is not a completely correct implementation. But it will work. ZenGL is considered a single threaded application and the data is not thread safe. In such cases, it is best to implement data protection in multi-threaded applications.

In the future I will think about editing ZenGL for multi-threaded applications. And, most likely, then these restrictions for the timer in each called procedure/function will not be needed.

Серж, ну я не говорил что нужно использовать именно код из ZenGl. Я имел ввиду что можно посмотреть как реализовано.
С наступающим новым годом

Yandex translate:
Serge, well, I did not say that it is necessary to use the code from ZenGl. I meant that you can see how it is implemented.
Happy New Year

[Mongkey]

Still waiting for sample in regular lazarus form 

[Guva]

Still waiting for sample in regular lazarus form 

here is an example for c#. it should not be hard to implement it for pascal under vindows
https://gist.github.com/ChrisDill/c2ca6a0ccf592c073a8d2aaeaa4adb7f

[mosquito]

Hello, thank you very much for the Ray4Laz.
It seems that the compiled binaries are not dependent on any dynamic libraries, but you provide a .dll or .so in your package. So, what is the desired behavior when compiling: totally static or dynamic?

[Guva]

So, what is the desired behavior when compiling: totally static or dynamic?

Well, it's as convenient for you.
But for Windows, it is better to compile the library yourself, since cross-compilation from linux does not catch raygui.