You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The lower 32 bits of the width, height and mipmaps values are correct, it is the upper 32 bits that gives rise to these bizarre values (format and id may be correct as well, I am not sure).
On my system compiling raylib using the defaults results in the size of an int and a long being different. I noticed that the generated bindings have the line Int = c_long but changing the definition to be c_int gives the output:
Texture: 3298534883331 128 1 7 32766
Any idea how to address this?
The text was updated successfully, but these errors were encountered:
That is quite strange. I'll have to confirm, but maybe the problem is because I didn't added any checks in the code to address this possibility.
I fail to see exactly if and why having raylib built on your machine could cause this, but can you confirm whether the same thing happens when you use the binaries provided by raysan5? In case you discover the root cause to be on the binaries side of the binding, I probably already showed you the best of my knowledge (because I suck at C/C++, unfortunately).
A minimal example using "scarfy.png" from the raylib examples which has the dimensions 768 x 128 :
gives the output
The lower 32 bits of the width, height and mipmaps values are correct, it is the upper 32 bits that gives rise to these bizarre values (format and id may be correct as well, I am not sure).
On my system compiling raylib using the defaults results in the size of an
int
and along
being different. I noticed that the generated bindings have the lineInt = c_long
but changing the definition to bec_int
gives the output:Any idea how to address this?
The text was updated successfully, but these errors were encountered: