search

ggez / ggez-goodies

Useful modules for the ggez Rust game framework.
MIT License
63 stars 17 forks source link

Make Camera use nalgebra Transforms #2

Closed fu5ha closed 7 years ago

fu5ha commented 7 years ago

The start of converting Camera to use nalgebra Transform types (Similarity2 and Projective2). This commit achieves feature parity (tests pass), but I want to implement and test the extra zooming and rotation functions before merging.

I might use this for a game I'm planning on making in the near future, and if so, I'll be implementing some of the camera easings etc, but that will be a different PR I think.

fu5ha commented 7 years ago

I'm having a bit of trouble figuring out why my zoom with respect to point methods are not working properly... I'll probably figure it out eventually (probably when I wake up with a fresh brain tomorrow morning), but if you could take a look and let me know if you see anything obviously wrong that'd be great.

icefoxen commented 7 years ago

Sorry for the delay. I like it in concept, just haven't had time to eyeball it in detail and make sure it works with my own use case.

fu5ha commented 7 years ago

Cool, no problem. Finally got the zoom with respect to a point working now! Got a couple more tweaks I want to make/try before I would call this ready to merge.

fu5ha commented 7 years ago

Alright well I spoke too soon before, it wasn't actually fixed and I went back to beating my head against the wall. Then I finally figured it out and wanted to kms because the error I had been making was so dumb. Anyway, it's fixed now.

I also moved to floating point precision on the world -> screen coordinate conversions and made the point field that is drawn based on software rendering because it seems like rendering an image generated that way looks better than using points()

fu5ha commented 7 years ago

Alright, I think I'm basically happy with this stuff for now. Cleaned up a lot of the nits I had. Let me know what you think when you get the time.

The only other things I was thinking about implementing were pinning and physics smoothing, but those things would either require passing in and out complex state to the method call each frame or an update method to be called each frame which both seem to add a new level of complexity to the struct and should be relatively easy to implement on your own given the current methods.

Gonna start playing with sprite batching, was just reading the LOVE implementation.

fu5ha commented 7 years ago

Hmmm, thinking about it some more actually, I might redo how the easing functions work slightly to make them easier to use. Plus I think that they aren't actually working properly currently because it's constantly re-sampling the interpolation each frame since it's using the camera's current position...

fu5ha commented 7 years ago

Right, so I re-did it in a different way that seems to work pretty well. There's probably some pieces that are not idiomatic Rust but that I didn't know how to solve without what felt like kind of hack-together solutions because I'm still a noob, so let me know any suggestions you have on how to improve things.

fu5ha commented 7 years ago

Alright, I'm calling this "done" I think, pending review anyway heh.

fu5ha commented 7 years ago

I lied... making more changes again.

fu5ha commented 7 years ago

Okay, I like how this is structured a lot more now. It uses the view and projection matrices properly which allows for non-uniform scaling (meaning camera view sizes don't need to directly match with the screen size) and makes everything make much more sense.

Also, the ease actions are structured in a more obvious way and integrate with ezing which allows much more flexibility without having to include copies of a million and one ease functions in our own module.

fu5ha commented 7 years ago

Moving this to a new PR from a branch on my local repo...