I just released a new version of static and dynamic raylib binding.
This was completely regenerated using (an automatic) parser from the raylib 4.0.0 sources.

• Github repo
• See also wiki for details.

On Wednesday, 3 November 2021 at 07:52:45 UTC, o3o wrote:

I have some questions:

1. Why raylib 4.0.0? It’s not released yet
2. Why a new project? What is the difference between this and your bindbc-raylib project?
3. Why “3” as a suffix?

-Steve

On Wednesday, 3 November 2021 at 11:24:09 UTC, Steven Schveighoffer wrote:

My apologies for the late reply.

When I started porting, raylib was at version 3, a few days later ramon released version 4...

bindbc-raylib code is "handmade" and contain all raylib versions (many versions conditions) but was very difficult to follow all the breaking changes on raylib API.
bindbc-raylib3 contains only raylib version 4.0 and the code is automatically generated.

On 12/10/21 2:57 AM, o3o wrote:

OK. I think when I wrote this, 4.0.0 was not released (but I think it happened in a couple days from then)

OK interesting. So you can use the same raylib binding but just define the version you want?

I agree that auto-generating is the way to go. That's what raylib-d now does.

raylib 4.0.0 I think had some drastic API changes.

You may be interested to note that starting with the next version, raylib will define a version string that is an exported symbol. I plan to use this to avoid incorrect bindings at runtime: https://github.com/raysan5/raylib/commit/ef6959ed540cd650e13611c35ea543922ab83a98#diff-25a6634263c1b1f6fc4697a04e2b9904ea4b042a89af59dc93ec1f5d44848a26

-Steve