7 (more) days of code

[deimos]

I have a bit more than a week of spare time to continue working on my "game" (http://eab.abime.net/showthread.php?t=99179).

Previously, I didn't get as far as I wanted due, mostly, to falling down multiple blitter queue rabbit holes. But, I'm back, and this time I'd like to make things move - at the moment I can spin the camera around, and I can spin the visible aircraft around, but everything is in a fixed position.

Current state, WASD + QE move the visible aircraft, Cursor keys + ,. move the camera, F1-F10 + -= adjust throttle (not connected to anything but the display). The display of the throttle, artificial horizon and heading indicator / compass work. The instrument panel is 3 bitplanes, / 8 colours the main screen is 4 bitplanes / 16 colours. I'm drawing the sky and the ground with the blitter as part of clearing the screen, plus the one visible aircraft is drawn with the CPU.

In order to make things move about, I think I need some sort of basic physics engine.

I can't think of a way to make anything resemble reality without at least a basic representation of forces. So, gravity, always downward, aircraft lift, always in their +Y direction and proportional to their velocity. Velocity tied to, um, acceleration, but something about wind resistance tied to velocity.

At the end of the day it's a game, so playability is more important then realism, but I want it to feel like it's based in reality.

Does anyone remember their GCSE physics enough to offer an opinion on how I should proceed?

[deimos]

Google / Wikipedia tell me that the the 4 main forces involved are thrust, weight, drag and lift. Makes perfect sense. When thrust and drag are equal the plane has constant velocity. When weight and lift are equal the plane is in level flight. Ignoring the complexities of vectors, etc.

So, is my first step to put some values into those?

How much does a plane weigh?

Or what the forces / accelerations involved are, or how to calculate backwards to sensible starting figures?

Is there somewhere that has already done this work? Even if I need to simplify it?

[VladR]

1. What kind of debugging set-up do you have ? Can you do Edit&Continue while debugging through the code or do you just print out values on screen ?

2. This kind of experimenting is tedious&slow on the target HW, even at emulator (let alone deploying builds). From my own experience, long-term, it pays off having a PC-based Dev Environment where you can do Edit&Continue, use floats and experiment right in your IDE (implement a simple framebuffer-based rendering via DirectX/OpenGL/SDL/whatever). And only when stuff works like it should, you start concerning yourself about getting it to work on A500.

3. Before you go play with Newton laws, Forces, Momentum, Kinetic Energy and Rotational Dynamics, how about you translate your plane's world position along the current Direction vector and speed up/down accordingly ?

4. Then generalize the code and apply it to one enemy first (later to an array of enemies).

5. Now create a Waypoint system - struct SWaypoint { Vector3f StartPos, EndPos; } so you can spawn enemy at run-time upon getting to a target area.

6. Now get some basic AI going - implement couple states where enemy randomly rolls in the air, adjusts the speed for few seconds, and eventually when you're in his view frustum, starts shooting at you.

[deimos]

Originally Posted by VladR

1. What kind of debugging set-up do you have ? Can you do Edit&Continue while debugging through the code or do you just print out values on screen ?

I'm cross compiling from Windows, deploying into WinUAE. I can't do Edit & Continue, but I can do Edit, Build & Deploy pretty quickly.

Originally Posted by VladR

2. This kind of experimenting is tedious&slow on the target HW, even at emulator (let alone deploying builds). From my own experience, long-term, it pays off having a PC-based Dev Environment where you can do Edit&Continue, use floats and experiment right in your IDE (implement a simple framebuffer-based rendering via DirectX/OpenGL/SDL/whatever). And only when stuff works like it should, you start concerning yourself about getting it to work on A500.

I understand your reasoning here, but it's not for me - I really don't want to divert into a PC environment when I've come so far writing Amiga code.

Originally Posted by VladR

3. Before you go play with Newton laws, Forces, Momentum, Kinetic Energy and Rotational Dynamics, how about you translate your plane's world position along the current Direction vector and speed up/down accordingly ?

Fair point, I'll add simple motion to what I have first. I know I can move my objects because I've done it programmatically before, but it's different to have thing tied into key presses.

Originally Posted by VladR

4. Then generalize the code and apply it to one enemy first (later to an array of enemies).

Hopefully this will just happen as both the player and the enemies are the same thing.

Originally Posted by VladR

5. Now create a Waypoint system - struct SWaypoint { Vector3f StartPos, EndPos; } so you can spawn enemy at run-time upon getting to a target area.

6. Now get some basic AI going - implement couple states where enemy randomly rolls in the air, adjusts the speed for few seconds, and eventually when you're in his view frustum, starts shooting at you.

Maybe next year... I want to fly first.

To date all I've done is to collect a bunch of data and formulae.

I know I want my ceiling to be at 20,000 m.

I want my max speed to be 1,000 m/s.

I want my take off speed to be 50 m/s

The aircraft's weight should be 10,000 kg unarmed and unfueled. Fuel should be up to 5,000 kg and weapons should add up to another 8,000 kg max.

There are four forces in action, thrust, drag, lift and weight. Three of these are have atmospheric density as a dependency. There's a standard formula for this, but I think a look up table is probably appropriate.

The thrust should be proportional to atmospheric density and to the throttle position.

The drag should be proportional to atmospheric density and to the velocity squared.

The lift should be proportional to atmospheric density and somehow to velocity.

Weight should simply be the aircraft's total current weight (mass x g?).

I need to add a bunch of constants to tune those formulae so they "balance". I know that a max velocity thrust must be at max, and thrust must be equal to drag. I also know that at take off speed lift must equal weight.

And that's where I'm at.

[VladR]

I hear ya with quick Build/Deploy (was in same boat myself) but Edit&Continue environment has sped up experimenting tremendously for me. Sometimes I finish some experiments in 2 hours which would be utterly impossible with constant rebuild/deploy.
Don't forget that a Visual Studio has 4 tabs with Watches and at any time you see up to 50 variables in one watch window. That's huge for productivity.
Then, as an added bonus, you see the Output Window below the source code, where you can dump several arrays worth of data, so you really always see every single variable at any time without any effort. The code kinda debugs itself...


Looks like you're trying to get all 3 aerodynamic properties going at the same time.

Why don't you first experiment with a simple linear decrease of atmospheric density (say, a lerp between MaxDensity and MinDensity based on your altitude) and adjust thrust/speed accordingly ? The Density could really be just a simple floating point value <0.25f, 1.0f>

Once you got maximum thrust/speed at highest altitude going, as a second step, add the dependency on the gravity:
- your highest thrust is when your direction vector is Down (0,-1,0) : Full Engine + Gravity
- your lowest thrust is when your direction vector is Up (0,+1,0) : FullEngine - Gravity

And you simply lerp the thrust between the two.


Only when the above is working, I would go and introduce the weight into the equations.

[deimos]

Originally Posted by VladR

I hear ya with quick Build/Deploy (was in same boat myself) but Edit&Continue environment has sped up experimenting tremendously for me. Sometimes I finish some experiments in 2 hours which would be utterly impossible with constant rebuild/deploy.
Don't forget that a Visual Studio has 4 tabs with Watches and at any time you see up to 50 variables in one watch window. That's huge for productivity.
Then, as an added bonus, you see the Output Window below the source code, where you can dump several arrays worth of data, so you really always see every single variable at any time without any effort. The code kinda debugs itself...


Looks like you're trying to get all 3 aerodynamic properties going at the same time.

Why don't you first experiment with a simple linear decrease of atmospheric density (say, a lerp between MaxDensity and MinDensity based on your altitude) and adjust thrust/speed accordingly ? The Density could really be just a simple floating point value <0.25f, 1.0f>

Once you got maximum thrust/speed at highest altitude going, as a second step, add the dependency on the gravity:
- your highest thrust is when your direction vector is Down (0,-1,0) : Full Engine + Gravity
- your lowest thrust is when your direction vector is Up (0,+1,0) : FullEngine - Gravity

And you simply lerp the thrust between the two.


Only when the above is working, I would go and introduce the weight into the equations.

I'd have to get Visual Studio and learn how to use it first though.

I have added simple movement of the enemy aircraft. Now, at every screen update, it moves in the direction it's pointed in by a distance proportional to the throttle position. You can actually fly the plane around and turn the camera about to follow it. The motion isn't super realistic, but it's not terrible.

Edit: Uploaded executable. WASD/QE F1-F10 -+ to control the plane. Cursor/<> to control the camera. It's actually quite fun.

[VladR]

Oh, that explains it - if you haven't used Visual Studio, you don't miss the Edit&Continue, so it's all good.

Are you using the Direction vector as a Speed Vector ? How do you relate the two ? Via simple floating point constant ?

[deimos]

All fixed point, but yes, with a constant, 2.

The direction vector is held in 2:14 format, the throttle is an int, 0..100, currently. I multiply them together and then shift right by 13, resulting in a extra x 2.

That's just what seemed to work as I quickly mashed something together. I need to go back and work out what precision I intended world coordinates to be in and how that works with the velocities I need to use, taking into account how many times per second I can do the calculations.

[VladR]

Yeah, well - that's exactly the single greatest advantage of having the PC-based prototyping project:
- initially, you just work with floats
- you quickly prototype something interactive (in target Amiga resolution)
- given the performance of CPUs, you can literally get away with having a flatshader that calls DrawPixel (x,y,color), as it still will be 60 fps anyway - so you don't loose more than a day on flatshading
- you can quickly experiment and compare various ranges of worldspace, view distance and perspective matrix

And only when everything works, you start converting the floats to integer or fixed-point. Such code you just straight copy-paste into your Amiga project.


- How are you going to represent your level map ? Quadtree ? Loose Octree ? Simple array you will always traverse ?
- how many and what kind of ground objects will you have ?
- any mountains or terrain ?

[deimos]

Originally Posted by VladR

Yeah, well - that's exactly the single greatest advantage of having the PC-based prototyping project:
- initially, you just work with floats
- you quickly prototype something interactive (in target Amiga resolution)
- given the performance of CPUs, you can literally get away with having a flatshader that calls DrawPixel (x,y,color), as it still will be 60 fps anyway - so you don't loose more than a day on flatshading
- you can quickly experiment and compare various ranges of worldspace, view distance and perspective matrix

And only when everything works, you start converting the floats to integer or fixed-point. Such code you just straight copy-paste into your Amiga project.


- How are you going to represent your level map ? Quadtree ? Loose Octree ? Simple array you will always traverse ?
- how many and what kind of ground objects will you have ?
- any mountains or terrain ?

I've decided to not consider anything what comes after my flight physics until I have my flight physics working, but I do have a vague idea of grid a system with multiple layers and detail levels for the ground. There will not be many ground objects, and I don't plan on mountains or terrain, it will be just flat ground.

I don't find working with fixed-point to be that much of a big deal and I would rather consider the limitations up front. My main issue is that I didn't keep a lot of the work I did at the outset (a year or more ago), which laid out all the resolutions and precisions for each level, but I can recreate that.

Right now, I think the physics needs equations, and pen and paper work. I'd love it if someone provided all the equations and solved everything for me giving me all the constants. But, if that can't happen, I'll keep asking for hints.

[VladR]

It's been more than a decade since I last worked with my 6-DOF underwater action/simulator, but I don't think I was working with full physics/forces - it wasn't really needed - each class of vehicles had different coefficients for acceleration/strafing speed so it completely replaced the need to run any complex physics.

In the end, all you need to have is different aircrafts with different behavior, or not ?

Does it really matter whether you tweak your own constants or the physics engine properties ? You still need to tweak something anyway.

One of the game programming physics books I read back then had a section on flight simulators. If you spend an hour searching you should be able to find it, perhaps even in PDF format. I don't recall the full name unfortunately...

[deimos]

Originally Posted by VladR

It's been more than a decade since I last worked with my 6-DOF underwater action/simulator, but I don't think I was working with full physics/forces - it wasn't really needed - each class of vehicles had different coefficients for acceleration/strafing speed so it completely replaced the need to run any complex physics.

In the end, all you need to have is different aircrafts with different behavior, or not ?

Does it really matter whether you tweak your own constants or the physics engine properties ? You still need to tweak something anyway.

One of the game programming physics books I read back then had a section on flight simulators. If you spend an hour searching you should be able to find it, perhaps even in PDF format. I don't recall the full name unfortunately...

I certainly don't want any complex physics. But I do think concepts like gravity are important and most of the behaviour I want to implement, such as acceleration that's linked to the current mass of the aircraft, maximum velocities and altitudes, etc. should be a result of a physics engine and the four forces I talked about in the first and second posts.

[deimos]

This is what I've managed to work out today:

Thrust

T = r * (v_max - v) / v_max * t * e

where:

• T is the resulting thrust
• r is atmospheric density (normalised to a max value of 1 at sea level)
• v is the current velocity
• v_max is the maximum possible velocity (1,000 m/s)
• t is the throttle position (0..1)
• e is engine's maximum output (120,000 N)

Weight

W = m * g

where:

• W is the resulting weight
• m is the current mass of the aircraft including fuel and weapons
• g is 10 (close enough)

Drag

D = Cd * r * v^2

where:

• D is the resulting drag
• Cd is a constant
• r is atmospheric density (normalised to a max value of 1 at sea level)
• v is the current velocity

Lift

L = Cl * r * v^2

where:

• L is the resulting lift
• Cl is a constant
• r is atmospheric density (normalised to a max value of 1 at sea level)
• v is the current velocity

I need to calculate Cl and Cd from the other information I have. I don't know the correct way to do this, but I've thrown some calculations together based on a take off speed of 50 m/s and a max speed at sea level of 500 m/s and get Cl = 40 and Cd = 0.36.

I have no idea if those numbers are right or even sensible, but it looks like they're my starting point.

I'm also very dubious about my thrust formula.

These formulae are all forces, so they all need to be divided by mass to get acceleration, which gets be a change in velocity per second. I will need to scale this value according to how long it's been since the last update.

My world coordinate system is in metres, shifted to the left by 8 bits, which gives a resolution of around 4mm. I don't know if this will give noticeable errors due to rounding, particularly at low velocity or acceleration. I may need to accumulate errors.

[deimos]

Well, gravity seemed easy enough:

    LONG elapsedTime = GetElapsedTime();

    if (elapsedTime != 0) {
        for (Model * model = scene.firstModel; model; model = model->nextModel) {
            LONG weight = 10 << 8;
            LONG acceleration = -(weight * elapsedTime >> 10);
            ((Entity *) model)->velocity.value[Y] += acceleration;
            LONG delta = (((Entity *) model)->velocity.value[Y] * elapsedTime) >> 10;
            ((Entity *) model)->position.value[Y] += delta;

            if (((Entity *) model)->position.value[Y] <= 0) {
                ((Entity *) model)->position.value[Y] = 0;
                ((Entity *) model)->velocity.value[Y] = -((Entity *) model)->velocity.value[Y] / 2;
            }
        }
    }

Edit:

I've now completed this code for all the forces. It doesn't work very well, I think the major reasons are 1) that the drag formula doesn't take into account the orientation of the aircraft - it should increase greatly during a turn, and 2) that my turning isn't implemented as forces or even with any relationship to the rest of the aircraft's motion. I can see that the only way to do it properly would be to model a lot more forces including angular ones, but as I'm trying keep this as something an 8MHz 68000 can do I'm going to keep looking for ways to simplify and approximate, maybe by creating a look up table of the plane's cross section from different angles to feed into the drag formula, for a start.