Port to gfm:math from gl3n
ColdenCullen opened this issue · 16 comments
I think switching from gl3n to gfm is the right move for Dash in the long run. Unfortunately, it's going to take a lot of work.
This would be a great project for an external contributor to work on, to get to know the engine. The effort has already started here, so that would be the place to pick up from.
Is there any feature/aliases/functions to add that would make it less work?
Damnit, I totally thought I responded to this, my bad. If I miss something like this in the future, feel free to ping it.
Most of the work for this is going to come from renaming vec3s from gl3n to vec3f, of gfm, and the like. I actually prefer this naming convention, as it explains what the type is much more clearly.
That said, there are some things that gfm is missing, mostly in Quaternion. I'll try to make a list here soon, and open issues on GFM. The most obvious things I can think of are I would like an alias of quatf (rather than quaternionf, which is too verbose for my tastes), and also a constructor that takes 4 Ts.
Fun fact, I think gl3n's vec3 is an alias for vec3f. Not that that's an argument against moving to gfm haha
@Zedoctor That's what I thought too, but turns out gl3n doesn't have a vec3f.
I'm all for quatf, but not for vec3. I know this is the GLSL name, but float is not special.
I agree with you on the vec3, I think it's just confusing. I'll be glad to not use it anymore.
Renamed quaternionf to quatf/quatd, added a quaternion constructor with 4 Ts.
d-gamedev-team/gfm#86
Great, thanks for doing that for us!
Hi, the new fromEulerAngles/toEulerAngles have changed to use a better ordering of axis, this could break your code if you already used it.
d-gamedev-team/gfm@f78e236
Thanks for the heads up. I'm running everything through an abstraction layer at this point, so it should be an easy fix.
Hi again, if upgrading the gfm:sdl2 dependency to 2.0.x, you'll be able to drop some useless code and the dependency to the "colorize" package.
Does gfm:sdl2 depend on colorize? If so, what does it use it for? Just out of curiosity's sake.
Also, we do actually use colorize, so it don't think it makes sense to drop it.
Yes before 2.0.x gfm:sdl2 depended on gfm:core which contained a Logger implementation which depended on colorize. This was odd and this is not the case anymore. Cool to see you used colorize anyway.
Ok, so is the Logger that SDL.this() takes here an std.experimental.logger? If so, I'll definitely send ours in.
Yes, it is a std.experimental.logger.
(Unrelated: if upgrading to gfm:sdl2 2.0.x, beware because no SDL subsystem will be initialized anymore by SDL.this(). Eg: https://github.com/d-gamedev-team/gfm/blob/master/examples/simpleshader/simpleshader.d#L27 )
Ahh, good to know. I'll try to do that upgrade this evening. I think we should just need EVENTS and VIDEO like the example.