The code I wrote: gist.github.com/karl-zylinski/5ef25b68281b899acb1dd7774f035177 The bindings I used (I submitted a PR with the -strict-style / -vet compile error fixes, it has already been merged): github.com/cr1sth0fer/odin-box2d
I changed the draw rectangle line to this after the stream: rl.DrawRectanglePro({position.x, -position.y, 40, 40}, {20, 20}, a*(180/3.14), rl.YELLOW) ... It made the boxes have the correct origin and also rotate correctly. I was so close to doing it correctly on stream but The Hour Was Upon Me.
Oof, I never knew Box2D is y-up! ☹That throws me off, as my personal experience with y-up stuff has always been riddled with headaches. I'm not even surprised you had so much trouble getting it to work. Gonna have to check if there are alternatives that don't do that.
I think learning to do the coordinate system flips between different APIs and libs is just part of programming life. I think you can do it in a few places once and then don't have to worry more after that.
@@karl_zylinski well, if you use apis that disagree on it, then yes, that will become part of your programming life. But haven't had the experience of it ever becoming a non-issue. There was always some new problem with new nuances I've never quite worked out before, and I had to waste more time and effort with them. I spent some two years trying very hard to grow over the y-up-ness of the MicroStudio game engine, and it didn't happen. It's the rendering that is y-up in this case, as well as the Map class (for tile-based game maps). At some point I was trying to emulate a terminal for text roguelikes in it, and the y-up stuff started conflicting with the y-down stuff once again, and I wasted about a week trying to fit everything together. I succeeded (iirc), but ended up burned out, and I never touched that project again. It's just not worth it, imo, when I could just grab some other framework/engine where things just fit together. To each his own, but personally I rather not open that can of worms again. :) If you could have a system where everything is y-up, you wouldn't have any issues. But I don't think that system exists or that it's even possible. There are only systems where everything is y-down.
It is simply put that box2D uses positive Y up while raylib uses negative Y up. I think it's possible to just interface with box2D in a way that you must flip the Y coordinate before putting it into there. Perhaps one can have a proc that flips Y. And also a proc that offsets the Y position of rectangles (rectangles in raylib have origin at top left, rectangles in box2d have origin at bottom left). Since I only had one hour I didn't do this properly, but I'm sure it's possible to do it in a consistent and simple way.
The code I wrote: gist.github.com/karl-zylinski/5ef25b68281b899acb1dd7774f035177
The bindings I used (I submitted a PR with the -strict-style / -vet compile error fixes, it has already been merged): github.com/cr1sth0fer/odin-box2d
I changed the draw rectangle line to this after the stream: rl.DrawRectanglePro({position.x, -position.y, 40, 40}, {20, 20}, a*(180/3.14), rl.YELLOW) ... It made the boxes have the correct origin and also rotate correctly. I was so close to doing it correctly on stream but The Hour Was Upon Me.
Oof, I never knew Box2D is y-up! ☹That throws me off, as my personal experience with y-up stuff has always been riddled with headaches. I'm not even surprised you had so much trouble getting it to work.
Gonna have to check if there are alternatives that don't do that.
I think learning to do the coordinate system flips between different APIs and libs is just part of programming life. I think you can do it in a few places once and then don't have to worry more after that.
@@karl_zylinski well, if you use apis that disagree on it, then yes, that will become part of your programming life. But haven't had the experience of it ever becoming a non-issue. There was always some new problem with new nuances I've never quite worked out before, and I had to waste more time and effort with them.
I spent some two years trying very hard to grow over the y-up-ness of the MicroStudio game engine, and it didn't happen. It's the rendering that is y-up in this case, as well as the Map class (for tile-based game maps).
At some point I was trying to emulate a terminal for text roguelikes in it, and the y-up stuff started conflicting with the y-down stuff once again, and I wasted about a week trying to fit everything together. I succeeded (iirc), but ended up burned out, and I never touched that project again. It's just not worth it, imo, when I could just grab some other framework/engine where things just fit together.
To each his own, but personally I rather not open that can of worms again. :)
If you could have a system where everything is y-up, you wouldn't have any issues. But I don't think that system exists or that it's even possible. There are only systems where everything is y-down.
I'm very interested in knowing what was up with the coordinate systems! If you find the solution do let us know :) fun stream!
It is simply put that box2D uses positive Y up while raylib uses negative Y up. I think it's possible to just interface with box2D in a way that you must flip the Y coordinate before putting it into there. Perhaps one can have a proc that flips Y. And also a proc that offsets the Y position of rectangles (rectangles in raylib have origin at top left, rectangles in box2d have origin at bottom left). Since I only had one hour I didn't do this properly, but I'm sure it's possible to do it in a consistent and simple way.
Can even get the binary(of box2c) working for Mac. it builds fine, but I get runtime errors