I might as well make public the code I used for my simple flight sims. It is not a standard calculated physics method, but it IS an exact formula for the way the main forces are spread between axes. I think it would useful for someone wanting an easily understandable and easily adjustable bit of code to use with a non-sim game. I think of say, a game character or object which transforms into a flying state and uses this code to zoom about. Or to do ground attack etc.
If you can come up with a good A.I. for enemies, an aerial warfare scenario is possible. If I remember correctly, you can add , at intervals, a random change of turn/ roll input and by monitoring the current altitude, apply (graduated) elevator action to hold an enemy plane within certain altitude limits.It is also possible to turn this code into a simulator which is almost indistinguishable from the true calculated variety. In the demo code, there are suggestions of what further code is needed, and after that it is a matter of scaling the size and parameters to the 3d world accurately (see further down this page) . Which, if you think about it, is what make a scientific calculated physics engine useful . It is scaled within itself, so to speak, but you still have to scale it to your 3d world.
There are two versions of the stand alone demo here (just a few lighting differences) One for the latest 1.2 version of classic dark basic and one for the earlier 1.13 .. It should work with DB pro as well, perhaps with a few changes in wording, but I cannot test that since my demo version expired.
There are quite a few explanatory comments within the .dba file
Here's the link to the 1.2 version >>>
Here's the link to the 1.13 version >>>
Some additional info. on the use of angles for this style of sim.
The latest DB classic version I have used ( 1.13 and 1.2 ) returns an ' object angle Z () ' with "free flight" objects which does work for a flight sim if used with the rest of my flight code - though it does not produce a result accurate in the same way.
With earlier DB versions I used the following trick method to get the Z rotation angle in a different form. It turns out to be best with the latest versions and with DB Pro as well.The method (as in the demo code above ) ;-
read 'flying object's height
turn 'flying object' right 90 degrees and move 1
read new height and get difference from previous height.
then move object - 1
turn left 90 degrees ... original object orientation and position is now restored.I imagine one can see that if the wing is rolled the 'move' will produce a different height reading. Note that the difference is altered if the object is 'turned' while rolled -- all an essential part of the method.
Using 'move 1' , directly gives equivalent of sine roll, but it can be extended to read wingtip /ground/ matrix collisions at the same time.
You can also use the same method with hidden 'dummy' limbs on an object to read the height difference when parent object is rolled or pitched. DB pro has a command which can give an angle relative translation of the object to get the same readings .
Some DB programmers then use asin(height difference) to get the angles in 0-360 though I seem to remember it does it only 0-180. or is it 270 - 0- 90 ?-----------------------
One also often needs DIRECTION and PITCH for a flight sim, and there are two ways to get these on the latest DB versions.
One way is to do the following sequence, ... as I used to ...similar to the roll ..
read current object x,y z positions ( if not recorded already)
move object back - 1
read new x,y,and z positions
move object forward +1 ( to restore original position )I use pitch usually as a sine, so the simple height difference does this directly.
One can calculate the object direction using 'atanfull' on the 'offset' between the x, z co-ords.Alternately, use the 'limb direction' commands. The help file says not to normally refer to the limb zero of an object ... but they do not say why.
In any case, it works at the moment, (hopefully it will do so on DB PRO)-- so..
limb direction y (object number, 0 ) returns the world direction 0 to 360.
and limb direction x (object number, 0) returns the world pitch 0 to 360.
I would be using the sine of this pitch normally.( It seems that if you have changed and fixed the object pivot , the limb direction will need an addition of the amount ( wrapvalue). Test first. )
--------------------------------------
Some further notes on using this code for a realistic flight simulator
I started this code by assuming the flight controls always- ( unless the plane is stalled) cause a reaction that can be shown on the D.B. axes of turn, pitch or roll, but that the actions are modified by the angle of the plane and the lift of it's wing, to the world vertical ( the direction of gravity) . Hence the need for code to be related to the real world angles.
Much of this is taken care of automatically if you use the roll angle as in the demo code at the start of this page.However, in a full simulation the plane is quite often pointing in a slightly different direction and pitch from the way the centre of mass (= centre of rotation) is moving . My flight sims started with a simple design, where the plane aligned with the direction of motion. Other parameters were added separately according to the program and how lazy or experimental I was feeling.
Later , change of wing/fuselage incidence to the airstream were extensively tested and I have a functional incidence showing and kinetically modified flight path version of the earlier combat program. All done with a few lines of simple code .. which rather disguises the preceeding mental confusion in the face of what seemed too many interlinking variables. It is worth pointing out however, that such realism is NOT evident a lot of the time for the pilot. It is mostly in the fly-past view that it can be seen, if at all.The same is true for my most complete simulation in the 'NZ r/c model simulator'. Several elements are simply undetectable.
Perhaps the things that most decide the feel of reality are :- gravity being accurate, drag, and general degree of control response, with at least some inertia effect, and true scale of turn and pitch against kinetic energy. After that it is more subtle.The sort of information I used to make my code more accurate was as follows......
Consider any object moving in a straight line, but with a force being exerted on it at right angles to the dominant forward motion. You can calculate a new position of the object in the world ( according to the physics book in front of me) by a vector and calculus approach. Over time, a gradual change of direction of the object produces a curve. The position change along the curve could be described too, by physics formula, taking account of the relation of kinetic energy to the forward speed squared .. etc.
However, in my system, the change in angle is primarily considered. The change is made relative to the forces, the degree of bank, modified by the speed and any control input, and then is 'moved ' forward (i.e. a 'projection') . The degree of curve over time is set to correspond to the known flight pattern of aircraft. As a side effect the downward drop of the aircraft when rolled is also scaled to match gravity. i.e. the 1g of wing lift, is now 1g downwards ... crafty isn't it . ( The magic bit was that the fornula gets it accurate between the horizontal and vertical roll extremes.. and it applies at every orientation of the plane )Then you have to scale to real life performance. The best test relies on the fact that to maintain altitude the same throughout a banked turn requires exactly 1 G of the wings lift be directed upwards, and the total force required is proportional to the speed and the degree of bank. I did it manually first, but later set up an automatic pilot that maintained altitude with elevator action, while at a constant bank angle, and ( having worked out the size scale of the 3d world so as to set the correct speed ), printed out the rate of turn. I had a variable which I jokingly called "kineticfactor# " which divided into the amount of turn and pitch being applied .. and adjusted this variable till the angle response gave the correct rate of turn. It was fairly simple in practice. If you are more so inclined than me, it might be possible to work it out mathematically.
Some of the 'real life' rate's of turn when the nose is held level through a banked turn are as follows, they use 'knots':- 1 knot = 1 nautical mph = 1.15 mph )
at a constant roll/bank of 30 degrees and all at 1.3G on pilot ( trig. on bank angle gives the total g force)
60 knots -- 10.5 degrees per sec radius .09 nm
150 knots -- 4,2 degrees per sec. radius .57 nm
180 knots -- 3.5 degrees pers sec. radius .82 nm
(estimate from a graph, 300 knots about 2 degrees per sec.)some turn rates and G at different roll/bank -
60 knots -- 9 degrees/sec - 9 degrees roll - 1G
150 knots -- 7,2 degrees/sec. - 32 degrees roll - 1.4 G
180 knots -- 8.6 degrees /sec - 55 degrees roll - 1.7 GBut once scaled to one turn rate, the axis formula is correct for all.
You will also have to learn more about what a real plane does if you want to put in extra elements of realism. For example, planes have inertia and so change speed gradually and move smoothly. And they behave differently according to type and weight and stability factors etc. The demo code has a description of some formula for a gliding state, but note that the pitching of a plane according to speed is present all the time.
If you resort to books , don't entirely trust the first one you read, as I don't think aerodynamics are always explained accurately. ( The famous 'lift being produced by low pressure over a curved surface' being a good example. ... it is incomplete and therefore misleading.. )Perhaps the most challenging thing for completeness is getting correct the actions at and near a stall, when all the aerodynamics step outside the steady flight rules. Similarly for display of angle of attack of the wings, and of the angle of the plane to the forward motion. This is where a calculated physics engine works best, and for myself I will be refining ( eventually! ) my near stall routines by use of maths. ( lift and angle of attack being taken account of. )
------------------------
Just for interest, here's a history of my learning progress
When I started with dark basic it seemed straightforward in comparison with my earlier simulation attempts using limited rotation systems ( the amiga and amos 3d) . After luckily seeing a way to read the z angle of a 'free flying' object - which always read zero at that time - I immediately found a simple flight method that looked correct at all angles though it had no 'reality adjusted' dynamics to speak of.
Then, after I did the combat program, I was approached by another DB programmer (Mick Trist) and it is thanks to his thoughts and questions that I felt forced to work out how accurate or not the simulation was. My mind can be slow , and is mathematically inexperienced ( it wants to stay that way, is the problem !) and it took a while to realize that my method was matching several flight parameters at one time. This knowledge made it possible to modify rotations when different, or more exact results were wanted .
In fact, it has been an on-going business of learning. Every so often, I find myself realising some new factor I have overlooked, and which, by good luck only, is taken care of by the code method used.
BTW, here is a link to a demo of how the different rotation orders work in DB. It was originally a nice piece of work by Simon Harrison and I think I obtained it from the DB forum. I have added to it ... I hope he doesn't mind if he ever finds this. I have set the text size very small to suit the new 1.2 classic version. Change back to 14 pt if needed for your installed version.
Here's the link (17k) :-
And while I am about it, here is a note and code for the rotating 'radar' map on the old combat program, which I had to remove from this site to make space, but which several people have asked about ..
here is a a link to it >>
---------------------------------
A note on using blitz basic for flight simulation instead
It may interest dark basic programmers that I have now tried blitz basic for suitability with flight sims.
It is very good. Indeed I am tempted to use Blitz rather than DB Pro. if I want to advance further.1. The rotation system used is simpler and more unified than dark basic, using roll, turn and pitch angles only, and returning them in true relation to the 3d world. To use with my system it needs one extra cosine, but because other things are not needed, it is in total , simpler.
2. Landscapes can be large and smoothly shaped because of the great detail possible with L.O.D terrains. ( they retain their speed of render due to detail level being dropped with distance) Blitz terrains shade well ( though without any real control over degree as I would prefer) and can be multi textured.
Best of all, blitz seems more exact in 3d position, so that objects placed over the landscape do not visibly 'waver' at the intersection of planes. This also allows more detailed small terrains with different texture, to be placed over the main one where necessary.
The only limit I have found is that terrains cannot re-use 'tile' images as DB can on a matrix. The texture must be one very large one, or a repeating pattern. These can be combined over each other very effectively but for a fully detailed landscape one must use large images and/or several terrains.
Lately, I discover, that DB pro L.O.D.terrains have been greatly advanced, with levels of shadow and lighting. All in all, probably better than Blitz.3. The blitz mip mapping works better for fine detailed objects. (my DB pro demo version turns them into blobs)
4. Objects themselves show all aspects and lighting -- DB pro requires a lot of changes to my models and I still don't understand why. Some remain stubbornly invisible.
5. And overwhelmingly for me, blitz is much faster to compile and much more compact in the final exe. DB pro, I suspect, will always be slow to compile ( I spent a lot of time just staring at the screen) and have a large exe because of it's large (and growing) command set. In fact it is now (nov.07) full of commands for just about anything, with numbers of add on libraries. It is a great pity about the compile speed.
6. Blitz has infinite plains ( the texture repeats at any specified scale) for sky or ground or water.
7. The textures have proper alpha blending at a level that can be specified.. basically easier and better than just the light or dark ghosting of DB.
8. You can set 'object priority' in blitz. Very useful , especially for skyboxes. It amazes me that dark basic pro has not got this in the same way.
Well that's the current observations on blitz. I don't entirely like the style or .. hmmm ... 'grammar' of the language, but I could live with it. I think it takes extensive testing before you can be sure any language will do what you want. You may find it lacks the one critical capability which for you is an essential, making all the good points irrelevant.
Good luck ... David L. oct 07
Link back to dark basic page