Sweet mother of this keyword. If ambiguity were playing a game you'd be the optional super boss. So helpful though, I couldn't find a decent camera tutorial anywhere.
I had an issue where my sprite was flipped along its vertical axis so that the rightside was on the left. I fixed this issue by having the GetZFromHeight function return a negative value and swapping the zoom values around. I noticed this because my sprite was not symmetrical across any axis so these issue are easy to spot. What is happening is that the a positive Z value is heading into the screen while a negative z value is heading out towards the player, so by setting the camera's position to be a positive z it was "behind" where we think the drawing plane is so we are seeing a mirror version when the camera takes what it sees and projects that on our monitors. A negative z value for the camera places it closer towards the person looking on the monitor so that our perspectives are aligned. I hope I explained that well. It makes a lot more sense in my minds eye.
@@two-bitcoding8018 I had to change more than that to get this working for me. The Clamp function caused it to reset the camera to a positive z when zooming. The extra changes I made: MinZ and MaxZ made negative CreatePerspectiveFieldOfView has Camera.MinZ and MinX values set to negative (thus positive) When z is clamped in MoveZ Camera.MaxZ and MinZ are swapped (error: -1 < -2048 otherwise) There is probably a cleaner way to do this. I'm only just about following this tutorial though. Very much new to all this. I'm confused why CreatePerspectiveFieldOfView won't accept negative values for near and far plane distance when negative/positive gives you a view from the player side/ opposite site.
Thank you for watching! This is a really good question. I use “readonly static” because these are values that I may want to change in future versions of the library. It is my understanding that when you compile a “const” value the actual value gets “baked” into the compiled code regardless of the assembly being compiled. A “readonly static” is referenced by the assembly at runtime. This means I can change the value in a later version of the Flat library and the end user won’t need to recompile any of their compiled code for it to work. For instance: If I decide that a better “MaxZ” would be 1024 instead of 2048, I can simply change it in the Flat library and then any other assemblies that reference the Flat library will get the new “MaxZ” without the need to recompile.
I got to the part where you used MathF to get the tangent, but when I tried it, MathF wasn't recognized. There was only Math and MathHelper. Ive been following along with the videos and normally when something's not recognized I'm just missing a "using" command at the top, but this time I had all the right "using" commands but it still didn't work. I tried MathF in different classes as well and it's only recognized in Game1 even when the "using" commands are the same. I think I can get away with using Math instead of MathF but I would like to know why MathF doesn't work. These tutorials are awesome btw
Thanks for watching! You can use the Math class instead of the MathF class. You will just need to cast the result to a float. MathF is part of .net core. If you are using .net framework then you will have to use Math instead. In your project properties you can see which version of .net is being used.
@@two-bitcoding8018 Thanks a ton for the explanation, I looked at the properties and the .net was different in the flat project just like you said. Also I casted Math to a float and it worked great.
![Basic Mouse Singleton - MonoGame 2D [#09]](http://i.ytimg.com/vi/9B6n45pF01s/mqdefault.jpg)
![Basic Mouse Singleton - MonoGame 2D [#09]](/img/tr.png)
![Coding Games [#06] - Shape Drawing part 1 - Batching and Rectangles](/img/n.gif)
The best Monogame tutorial series going on rn. Keep it coming
Thanks!
Agreed.
Sweet mother of this keyword. If ambiguity were playing a game you'd be the optional super boss. So helpful though, I couldn't find a decent camera tutorial anywhere.
Cool! I'm glad it was helpful!
I had an issue where my sprite was flipped along its vertical axis so that the rightside was on the left. I fixed this issue by having the GetZFromHeight function return a negative value and swapping the zoom values around. I noticed this because my sprite was not symmetrical across any axis so these issue are easy to spot. What is happening is that the a positive Z value is heading into the screen while a negative z value is heading out towards the player, so by setting the camera's position to be a positive z it was "behind" where we think the drawing plane is so we are seeing a mirror version when the camera takes what it sees and projects that on our monitors. A negative z value for the camera places it closer towards the person looking on the monitor so that our perspectives are aligned. I hope I explained that well. It makes a lot more sense in my minds eye.
Thanks for the info!
@@two-bitcoding8018
I had to change more than that to get this working for me. The Clamp function caused it to reset the camera to a positive z when zooming.
The extra changes I made:
MinZ and MaxZ made negative
CreatePerspectiveFieldOfView has Camera.MinZ and MinX values set to negative (thus positive)
When z is clamped in MoveZ Camera.MaxZ and MinZ are swapped (error: -1 < -2048 otherwise)
There is probably a cleaner way to do this. I'm only just about following this tutorial though. Very much new to all this. I'm confused why CreatePerspectiveFieldOfView won't accept negative values for near and far plane distance when negative/positive gives you a view from the player side/ opposite site.
Cool! Thanks!
Could you explain if there is a reason why you are using 'readonly static' instead of the const keyword for public constants?
Thank you for watching! This is a really good question. I use “readonly static” because these are values that I may want to change in future versions of the library. It is my understanding that when you compile a “const” value the actual value gets “baked” into the compiled code regardless of the assembly being compiled. A “readonly static” is referenced by the assembly at runtime. This means I can change the value in a later version of the Flat library and the end user won’t need to recompile any of their compiled code for it to work. For instance: If I decide that a better “MaxZ” would be 1024 instead of 2048, I can simply change it in the Flat library and then any other assemblies that reference the Flat library will get the new “MaxZ” without the need to recompile.
@@two-bitcoding8018 That makes sense, thanks for the reply!
I got to the part where you used MathF to get the tangent, but when I tried it, MathF wasn't recognized. There was only Math and MathHelper. Ive been following along with the videos and normally when something's not recognized I'm just missing a "using" command at the top, but this time I had all the right "using" commands but it still didn't work. I tried MathF in different classes as well and it's only recognized in Game1 even when the "using" commands are the same. I think I can get away with using Math instead of MathF but I would like to know why MathF doesn't work. These tutorials are awesome btw
Thanks for watching! You can use the Math class instead of the MathF class. You will just need to cast the result to a float. MathF is part of .net core. If you are using .net framework then you will have to use Math instead. In your project properties you can see which version of .net is being used.
@@two-bitcoding8018 Thanks a ton for the explanation, I looked at the properties and the .net was different in the flat project just like you said. Also I casted Math to a float and it worked great.
Thanks for this tutorial 👍