bindbc-raylib3 release 0.4.0

Steven Schveighoffer schveiguy at gmail.com
Sat Dec 11 01:56:58 UTC 2021


On 12/10/21 2:57 AM, o3o wrote:
> On Wednesday, 3 November 2021 at 11:24:09 UTC, Steven Schveighoffer 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?
>>
> 
> My apologies for the late reply.
> 
>> 1. Why raylib 4.0.0? It’s not released yet
>> 3. Why “3” as a suffix?
> 
> 
> When I started porting, raylib was at version 3, a few days later ramon 
> released version 4...

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

> 
>> 2. Why a new project? What is the difference between this and your 
>> bindbc-raylib project?
> 
> 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.

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

> bindbc-raylib3 contains only raylib version 4.0 and the code is 
> automatically generated.

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


More information about the Digitalmars-d-announce mailing list