added ability to transform points to screenspace when window resizes #4
Conversation
src/smk/Window.cpp
Outdated
| @@ -107,6 +107,11 @@ void GLFWCharCallback(GLFWwindow* glfw_window, unsigned int codepoint) { | |||
|
|
|||
| } // namespace | |||
|
|
|||
| glm::vec2 smk::Window::ToScreenSpace(const glm::vec2& world) { | |||
| glm::vec2 factor = glm::vec2(initialSize_.x/width_, initialSize_.y/height_); | |||
| return glm::vec2(world.x*factor.x, world.y*factor.y); | |||
There was a problem hiding this comment.
The view can also be rotated / skewed.
Line 74 in 24049a5
- I think it would be better to use the RenderTarget::project_matrix for this.
- I don't think we need to keep track of the initial size.
- I think this can be moved to RenderTarget.
There was a problem hiding this comment.
Hm yeah the view could be accounted for. That would make sense and become very useful. My original intention was to match the window size even after resizing. I originally had this event handled by Input and used the resize event for glfw to feed it, but I thought maybe it was more appropriate for the window.
src/smk/Window.cpp
Outdated
| @@ -107,6 +107,11 @@ void GLFWCharCallback(GLFWwindow* glfw_window, unsigned int codepoint) { | |||
|
|
|||
| } // namespace | |||
|
|
|||
| glm::vec2 smk::Window::ToScreenSpace(const glm::vec2& world) { | |||
There was a problem hiding this comment.
The name is a bit confusing, I would have thought we went from screen space to world coordinate.
What about MapPixelToWorldCoordinates?
There was a problem hiding this comment.
the input is the world position and the output is the screenspace. This is pretty standard convention. Unsure how to make this more clear.
There was a problem hiding this comment.
MapPixelToWorldCoordinates would be appropriate the more I think about it. SFML uses this name too for that purpose I assume
|
I changed the name of the function to MapPixelToCoords Ideally this function should go into Regardless if you accept or reject this merge, I am upgrading the View class to use an internal projection matrix like SFML does in order to achieve the aforementioned upgrades. You can see my progress here: https://github.com/TheMaverickProgrammer/smk/tree/feature/UpgradedViewStruct Unfortunately my math is wrong somewhere because the projection matrix ends up skewing the screen diagonally. (I even changed where I needed to pass in the projection matrix at the shader level but reverted it since clearly something is wrong somewhere). |
I totally agree.
This sounds like a good thing to do. I don't fully remember why I didn't used a glm::mat4 internally. Maybe I wanted to provide accessors like Width() and Height(). If you are facing some problems and think you can't make any progress anymore, feel free to tell me and I will try fixing the remaining problems. |
|
I have halted working on it to finish the coding style corrections. Feel free to pull the branch and poke around. I was close. Once I'm done with coding style fixes I'll switch to that. |
|
The end of 2020 was not kind to me and delayed me. This is just an update that I will return to this project early this year. 👍 |
|
Update: early did not happen. But I will return because I want to port my game engine to smk: |
;-) I never doubted you would come back! The latest video of the looks really nice! A great attention to detail. Happy to help you if there are any missing features in SMK. |
The window resizes but the mouse position returns values that is unusable for proper tracking. I added variables to track the initial window size and then provided a utility function to transform the input position to proper screen-space values that can be used after resizing.
I updated the framebuffer example to showcase this feature