Amiga.org
Coffee House => Coffee House Boards => CH / General => Topic started by: Nick on May 18, 2008, 07:57:42 PM
-
Hello people. Just wondering how you find out the co-ordinates of a point on a circle. I've not needed to know this for a while, so i've forgotten how to do it. All examples of when I last did it have gone for some reason. I've almost got it, but its driving me mad! Its not quite working properly.
Thanks
Nick
-
It's fairly simple trig, but what do you supply as input?
-
Yeah it isn't that difficult. I've got it to a point, but its just not right.
I have the X,Y of the centre of the circle
Radius of the circle
The angle is currently in degrees
-
Ok. For a unit circle located on the origin, the coordinates of point P are simply (assuming that cos() and sin() take radians instead of degrees):
P_x = cos(angle * \pi / 180)
P_y = sin(angle * \pi / 180)
The radius of the circle is now R, and the origin is at (O_x, O_y), meaning that point P now resides at
P_x = O_x + R * cos(...)
P_y = O_y + R * sin(...)
If cos() and sin() take degrees, you can omit the \pi * 180 correction factor. Good luck!
-
Thanks for this. Sorry I forgot to thank you. As I got distracted my my game actually work! :)
-
I've just realised I need some more help with this. As I'm working in 3D, how do I workout a point on a sphere properly? I can work it out to a point, but it still doesn't work properly! I'm going to go crazy soon.
-
Well, a sphere is something else again. You need 3 coordinates to locate a point on a sphere: two are angles, and one is a distance. The first angle is to indicate how far you should rotate in the plane going through the center of the sphere. Think of an orange you slice in two, and then trace the outer rim of one half. The other angle indicates how much up or down you should go---on the orange, once you've selected a point on the rim, trace from there to the top (or bottom) of the fruit following the outer surface. The distance then simply moves a specified amount outward.
Assuming that the first angle is called \alpha and the second \beta, with distance R, then your formulas will then become:
P_x = O_x + R * cos(\alpha) * sin(\beta)
P_y = O_y + R * sin(\alpha) * sin(\beta)
P_z = O_z + R * cos(\beta)
Keep in mind that the definition of \beta is a little awkward: 0 degrees is straight up; 180 degrees is straight down. If you prefer to go with he more familiar 90 degrees straight up and -90 degrees straight down (note the minus!) then you should calculate
\beta_0_to_180 = 90 - \beta_90_to_90
first before inserting \beta_0_to_180 straight into the above equations. 3D geometry is a lot more complex than 2D geometry, as you can see.
-
Thanks. This is going to take some figuring out. I'm using this to work out the thrust angles in my space game. The difficult part is making it so it only gives angles between 0 and 180 and allow the ship to rotate on all axis. I'm also using this to workout where the nose is pointing, and the trajectory. It works in 2D at the moment, but the second you go into the 3rd dimension things go all 5th dimension :) All the angles go crazy. I'll probably spend half of tomorrow using this!
-
This is getting annoying now. Basically I'm making a 3D space game. I'm new to 3D programming. I want to make my spacecraft be able to rotate on all axis (which is simple) and be able to fire thrusters in any direction (on all axis). Its this problem which is halting my project. I've got it to partially work, but it just won't go in the direction the thrusters are facing. Do you have any thoughts? You seem better at maths than me! Once I've got my head around this I'll be happy!
Nick
-
Nick wrote:
This is getting annoying now. Basically I'm making a 3D space game. I'm new to 3D programming. I want to make my spacecraft be able to rotate on all axis (which is simple) and be able to fire thrusters in any direction (on all axis). Its this problem which is halting my project. I've got it to partially work, but it just won't go in the direction the thrusters are facing. Do you have any thoughts? You seem better at maths than me! Once I've got my head around this I'll be happy!
Nick
This sounds like you haven't got your plan sorted out...
Are you able to give more details about the the 3D engine you are using?
-
I had planned it (this part of it), but as I'm only learning it didn't work. This is basically a test version of the game. Once I've got this figured out I'm planing on starting from scratch, using the knowledge gained to start properly. I'm using DarkBASIC. Its not bad actually. I'm impressed at how easy it is to get stuff working....unless it's complicated maths. Theres not much you can do about that!
-
Nick wrote:
I had planned it (this part of it), but as I'm only learning it didn't work. This is basically a test version of the game. Once I've got this figured out I'm planing on starting from scratch, using the knowledge gained to start properly. I'm using DarkBASIC. Its not bad actually. I'm impressed at how easy it is to get stuff working....unless it's complicated maths. Theres not much you can do about that!
I get it, this is the exploratory run... Ok... but I'm still keen to know more about your 3D engine...
-
The 3D engine is at http://darkbasicpro.thegamecreators.com/
-
Nick wrote:
The 3D engine is at http://darkbasicpro.thegamecreators.com/
Hmmm... doesn't that provide a set of functions for keeping track of your objects and thair properties... is DarkBASIC object oriented?
-
No its not object orientated. Its just like BASIC except simple commands load and move objects around etc. It can keep track of objects. The move commands I have (you can get extra plugins) won't do exactly what I want, so I'm trying to get around them. Its an easy programming language. Within my second day of using it I had made a simple 3D landscape using a displacement map (which was grabbed from a small bitmap I made). A simple 3D object was driveable with the camera following it. It also drove over the landscape properly, well except I didn't even start the problem of it not rolling on the hills, it only pitched up n down. It was a good start I think. No help was needed on that one! Its just this mathematical problem has got me. I've been wanting to make this game for like 10 years! :-)
-
Nick wrote:
No its not object orientated. Its just like BASIC except simple commands load and move objects around etc. It can keep track of objects. The move commands I have (you can get extra plugins) won't do exactly what I want, so I'm trying to get around them. Its an easy programming language. Within my second day of using it I had made a simple 3D landscape using a displacement map (which was grabbed from a small bitmap I made). A simple 3D object was driveable with the camera following it. It also drove over the landscape properly, well except I didn't even start the problem of it not rolling on the hills, it only pitched up n down. It was a good start I think. No help was needed on that one! Its just this mathematical problem has got me. I've been wanting to make this game for like 10 years! :-)
It's seems quite good... have you tried Blitz3D/BlitzMAX... they are object oriented and I found them pretty easy to get a 3D game together in no time at all... I'll have a look at Dark basic and see how it compares...
Anyway... if you are doing FP then it can be easier to actually update the landscape objects an keep the camera static....
-
I did read a lot about Blitz3D as well as DarkBASIC. For ages I was thinking Blitz, for one it looked quite easy, but also I have BlitzBASIC 2.1 for the Amiga :-). Looking into it DarkBASIC looks the more powerful and more supported. Not having access to the forums while not registered didn't help either. I couldn't ask any questions. Ultimately I've gone with DB.
I did think about moving everything but the player. At the moment its just 3rd person. The camera is static but it follows the spaceship around. I've just been out and I now have a few new ideas to try out.
-
This is getting annoying now. Basically I'm making a 3D space game. I'm new to 3D programming.
3D programming is a very different kind of animal than is 2D. I'm not sure this simple math is sufficient to get your ideas off the ground, really.
I want to make my spacecraft be able to rotate on all axis (which is simple) and be able to fire thrusters in any direction (on all axis). Its this problem which is halting my project. I've got it to partially work, but it just won't go in the direction the thrusters are facing. Do you have any thoughts? You seem better at maths than me! Once I've got my head around this I'll be happy!
First things first: the 3D formulas I gave above assume degrees as angle units. If your version of cos() and sin() take radians, you need to apply a conversion step just before plugging them into the equations.
Second: your problem has a fairly simply answer. If your thrusters are facing the opposite way of the nose of the ship, then all you need to do is to keep track of where that nose is, and move in that direction. That is, after all, what will happen when a thruster fires. If, on the other hand, you are making a ship with vector thrusts---in other words, where the direction of thrust need not be diametrically opposite to the direction of flight---then things get a whole lot more complex. You need to take into account the fact that the shapeship will not just move forward in space, but rotate on its axis as well. My advice in this case would be to look for this sort of book (http://www.amazon.com/Physics-Game-Developers-David-Bourg/dp/0596000065) and work your way from there. But you'll quickly notice that such books do not use simple maths anymore, and for this there is no real remedy.
-
I've ordered the full version of DarkBASIC now, along with a plugin which makes this sort of thing more simple. When I get it I'll hopefully be able to cure this problem! Thanks for the help!
Nick