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