Hey guys, I'm new to programming and SFML. I'm trying to make something like a canon. It's gonna fire balls that will be flying in an arc. Sounds like a very simple task to accomplish, yet I cannot seem to figure out how angles work in SFML. For example, with ang_const = 0.13 Rad (7.44 Deg), my balls flies in a beautiful arc. However, when I change the value of ang_const to 0.14 Rad (8.021 Deg), the ball flies in the opposite direction! If I change the angle to 0.19 Rad (10.88 Deg), it flies downwards for whatever reason.
Hello, @Ashmor.
You can get an analytic solution for any time using the "suvat" equations, since this is constant-acceleration motion (in two dimensions). Google "suvat equations" or "projectile motion" to follow that up.
Alternatively, you can repeatedly step forward in time by a time increment delta_t. A simple, slightly inaccurate version is
With stepping you will also, ultimately, be able to add drag (due to friction) or lift (due to spin).
The equation which you appear to be trying to use is really only that for the INITIAL velocity components:
vx = V * cos(angle)
vy = V * sin(angle)
(The latter equation may have a minus sign if you take y positive downward).
Thereafter, you should be using the suvat equations. The angle will change (and be pretty useless).
I'd seriously suggest that you sorted the maths out first.
Thank you for the explanation @lastchance! It's very helpful!
I'd seriously suggest that you sorted the maths out first.
Yeah. I know. I'm currently reading a Physics book (chapters about Kinematics and Newton's laws of motion.) and trying to implement what I learn from the book.
If you want a more physics engine/game engine oriented text on the subject(s), consider either
Game Physics Engine Development, by Ian Millington
Or any of the "Wild Magic" series by David Eberly (along with his open source engine on physics and rendering).
The reason I suggest these is that simulation for games (and other more serious targets) is quite different than a scientific (and other more formal targets) approach to the subject of motion in real time systems.
The issues of display rate vs time is covered, issues regarding performance are covered, and a lot of material related to the computational limits of modern processors and how that impacts the calculations.
For example, there are various designs of representation, and many tend to "oscillate" or constantly "bounce" due to calculations that reach very small (or very large) values. This is something a science based text will not address, and you might end up trying to retrace the thought and design work to deal with that yourself.
It appears you're focused on 2D, and there are typical "specializations" for 2D physics. If you move to 3D physics, you'll probably not find the use of quaternions in a science based text. They are an important tool in 3D.
Of course, the authors of these (and related) texts have used science behind their work, so what I'm suggesting is a compliment to the study, if not a change of direction.
I have another thought for you based on your last phrase.
Some study to make game engines, which is a bit different than game development in the modern era (last 10 to 20 years).
Physics engines are rather involved libraries. They're touchy, and a bit of a black art. Decades have gone into the research (Eberly is a PhD, consulting for the industry for many years).
Game development, on the other hand, usually involves the use of a game engine. I've discovered some students, early in the study, tend to develop the viewpoint that this is some kind of cop-out.
If you intend to work toward the development of game engines themselves, that's one avenue. It naturally divides between physics and graphics (real time rendering). Both are relatively deep fields of study. To match even an older game engine (one of the big 4 or 5) would take several years to write.
The days when a team would write everything from blank page to finished game is over. The targets are simply too complex and varied. Just the API's for modern rendering are a major undertaking. Vulkan, DX12 and Metal (Apple) are the 3 primary API's now. Even though older DX versions and OpenGL (ES) are still somewhat in use, they will fade into history fairly soon (as in no hardware will bother to support them, or the platforms will loose support).
However, someone has to be able to engineer advancements on the existing engines, and maybe some new ones eventually. It is, certainly, a valid direction of study.
If, however, your intent is game development, then you may benefit some from a study of engine development (for a perspective), but you really would be well advised to switch directions and experiment with some of the major game engines.
Even if you do intend to study engine design and development, running through the tutorials on the big 3 or 4 Engines would provide a good view of the modern expectations.
Thanks for the answer. I'm planning to make an indie game at some point and maybe I'll even be able to accomplish it. I totally agree with you that it's best to use a game engine instead of trying to make one on your own which is an extremely difficult task. For now, I want to get game development basics before moving on to one of the game engines.