Change in TERRAIN direction.

[Wudpecker]

Didn't I read of some ready-made sim code available?
Sorry I don't recall the exact name or link.

Let's say it was "modern" code.
Then you could modify it without having to re-invent it all.
Sorta like we are doing with EAW-- but without being stuck with an outmoded set of algorithms.

[sydbod]

Hi Wuddy,

Getting some one else's code and modifying it is not very productive.
One only gets a view from within the modules and one never gets a global perspective of how a game should function.

Starting from the overview and then developing the bits and pieces has given me more insight in the last few months than any of the opposite directed work that I did with EAW over the last 2 years or longer.

If one works on a particular code module only, without knowing the overall functioning of the game, then one never knows why a particular piece of code has to be a certain way and how it interacts with other modules. Basically one can tinker with the functioning of the modules, but one can not tinker with the functioning of the game.

I guess we all have our own challenges in life.

[sydbod]

Time for another progress report.

Even when using Z buffers based models things are not as simple as people sometimes expect.

Have a look at this picture ( look at the propeller disk of the aircraft flying towards us)


As you can see, the part of the aircraft behind the propeller disk does not show up.
It turned out that if a transparent mesh gets rendered to screen before a more distant mesh, then the Z buffer assumes that the more distant mesh should not get rendered behind the transparent mesh.
We can see how this causes a defect in the display of the aircraft.

It became necessary to make sure that all the solid parts of the aircraft get rendered before any transparent parts. This way we will always be able to see the solid parts through any transparent parts.
Here the problem was fixed up.


I could not find any program that would allow me to rearrange the rendering sequence of the meshes making up a model so it became necessary to delve into the aircraft model data files and manually move mesh information by hand.
An interesting bit of information that came to light is that meshes are not rendered , starting from the front of a model file and progressing towards the end of the file. It is the exact opposite. Rendering starts from the last mesh, towards the first mesh. It looks like I may have to make a utility to allow this sort of internal model file manipulation to be done more easily.
It seems that all the model creators that I have talked to, do not know about this problem, as they are never involved in the actual coding, and it seems that all the coders I have talked to, do not use models with transparent meshes on them, because they don't know how to handle them.
Anyway, the last week and a bit has been totally spent on things other than doing any coding. It is looking like coding will probably represent maybe less than 10% of the work, towards getting this project under way.

Until next time ....

[sydbod]

Hi All,

Just a small update.
A kind model creator has donated 4 aircraft models for this project.
The only major limitation he placed was that I have to find some way to protect the native files for the models so that other unscrupulous people do not pinch them, as he makes a living from creating and selling these creations.

Here is a snapshot of one of these creations in the game.


I now have matching Zero with Val, and P51 with Avenger.

I may have to redirect the game into a Pacific aircraft carrier based battle system, based on the resources I now have available.

Once the Christmas/ NewyYear festivities are over, I will get more involved in a proper front end for the game (use some of the knowledge from the 7217 error mitigation projects I initially played around with), and then continue the game collision logic.

I must admit, I have been doing a small look into another game engine called "Leadwerk", and although it looks to be significantly better than what I am using now, I just dont know if I want to change at this late stage.

Till next time, syddy

EDIT: Oh yes, those little white lines are bullet tracers. I just wanted to see what the FPS would be like with 200 aircraft and 750 bullets, flying at the same time.

[Wudpecker]

Out of curiousity, how is your 2 or 3- camera "Z" buffer working out?
Any transition problems switching from one "camera" view to another?

Correct me if I'm wrong, but the 3 models of EAW aircraft were an interesting solution to the frame rate problem, like the one you came up with. The simplified models, like the simplified shadows, cut the rendering time by quite a bit (and gave EAW an edge).
Not a kludge, but a creative answer in your case.

The close, medium, and far distance models (plus dots for super distance) in EAW worked well enough if the transitions between models are far enough away.

But one thing I discovered in trying to enlarge the aircraft (for better viewing and identification at a distance) was the transitions became difficult to manage without being noticeable.
(Aside from the fact you started shooting way too early, as Crashin' Jack pointed out in trying the larger aircraft )
------------------

I haven't tried it, but I've also been wondering what effect cutting the clock cycles from the EAW standard of 70 per cycle would have on gameplay.
My reflexes aren't as young as they were. Would this slow the game down a bit so our ground "interdictions" had more time?
I am sure EAW was pretty close to "real" on its flying speeds by the numbers. But sitting at a computer does not give the same sensation as being in an actual aircraft. Things go way too fast for me!

[sydbod]

Hi Wuddy,
The 3 camera setup is there to solve 2 separate problems.

The screen image is displayed firstly from Camera 0.
That image is overlaid with the the view of Camera 1.
Finally the image is overlaid with the view of Camera 2.

Camera 0 and 1 are the 2 cameras that are moved around in the 3D world, and view from the same view point.

Camera 2 is located at world coordinates close to 0,0,0 and only looks at a cockpit model of the aircraft. This was done to eliminate rounding errors and cockpit shake if the cockpit was moved a significant distance from the world 0,0,0 position. (floating point numbers only have 7 significant digit accuracy)

Here you can see the setup function for the cameras and their frustum settings.

Code: Select all

void SetupCamera( void )
{
      // Camera variables
   float fHorizontalPixels = 1024.0;
   float fVerticalPixels = 768.0;
   float fAspect = fHorizontalPixels / fVerticalPixels;
   float fFov = 1;// in radians *******
   float fNear = 0.3f;
   float fMiddle = 300.0f; // change over point between the 2 cameras
   float fFar = 300000.0f;
   float fAircraftRadius = 20.0f; // default radius aircraft cockpit view fits into.

   dbMakeCamera(2);// create the cockpit camera (closest camera).
   dbMakeCamera(1);// create the second camera.
   dbSetCameraRange ( 2, fAircraftRadius / 1000, fAircraftRadius );
   dbSetCameraRange ( 1, fNear, fMiddle );
   dbSetCameraRange ( 0, fMiddle, fFar );
   dbSetCameraAspect ( 2, fAspect );
   dbSetCameraAspect ( 1, fAspect );
   dbSetCameraAspect ( 0, fAspect );
   dbSetCameraFOV ( 2, 180/3.14 );
   dbSetCameraFOV ( 1, 180/3.14 );
   dbSetCameraFOV ( 0, 180/3.14 );

   /**********************************************************************************************************************
   * Disable the backdrop of the closest cameras so we can see the content of the furthest camera behind it.
   * REMEMBER.. cameras create their picture starting from lowest number camera sequentially upto highest numbered camera.
   ***********************************************************************************************************************/
    dbBackdropOff(2);
   dbBackdropOff(1);
}

Here is a snapshot being built up one camera at a time.

This is what the default camera 0 can see. (from 300meters up to 300000meters, with a blue sky backdrop)

All the close aircraft are missing.

Now we overlay the image of camera 1 to the image of camera 0 . (camera 1 from 0.3meters to 300meters)

All the closer aircraft have now been filled in.

Lastly we are filling in the visible part of the cockpit (at the moment we can only see the wingtip of the cockpit visible ... will still have to do some positioning fine tuning)

This cockpit view camera can only see up to the size of an aircraft in radius.



You are correct, that I will be introducing a LOD system similar to what EAW uses.
I will however go one step further to minimize wasted calculations.
I will be calculating ONLY ONCE in every frame the distance from the camera to every object (aircraft and bullet) and use this calculation to at the same time determine engine volume, engine doppler, aircraft LOD, bullet visible/not-visible, ....etc

Also, since my lower detail aircraft will by much higher in detail to what EAW uses, there should be no obvious difference when using Zoom.

The 70 clock cycles is just a unit of time measurement that EAW uses to do its calculations on. Dropping it to 50, or upping it to 100 should make little precision difference in the calculations (as far as games go). It is like having a game use standard time units of 0.1 seconds or 0.12 seconds or 0.08 seconds for its time calculations. It will have no effect on the actual FPS that the game runs at.

I remember once flying over the lip of a mountain range cliff in a small Cessna. We got caught in a down draught and lost 1000ft in a few seconds. There was a pen sitting on my friends lap and it went straight to the roof of the aircraft. At that time I had the same perspiration beads forming on my forehead as I sometimes get when flying against Knegel.
That cliff face went wizzing past us as we shot downwards. I can assure you that things in real life can happen just as fast as they do in EAW.

[Wudpecker]

I remember once flying over the lip of a mountain range cliff in a small Cessna. We got caught in a down draught and lost 1000ft in a few seconds. There was a pen sitting on my friends lap and it went straight to the roof of the aircraft.
At that time I had the same perspiration beads forming on my forehead as I sometimes get when flying against Knegel.
That cliff face went wizzing past us as we shot downwards. I can assure you that things in real life can happen just as fast as they do in EAW.

Hee, hee. That will bring out the perspiration, alright. We don't notice the updrafts and downdrafts much in the cockpit of EAW, though they are there.
But flying along the rugged Santa Cruz coastline in a 4-place coming in for a landing some years back, a windy down draught dropped us suddenly about 200 feet. Putting the dirt runway ABOVE us on the shoreline cliffs.
Luckily the nervous pilot was prepared, and jammed the throttle forward and the stick back. The craft literally clawed its way up the air in front of the cliff and plopped onto the end of the runway.
"Sorry about the rough landing," the pilot said.
"Don't worry," I told him. "At 10 feet I can always jump."
-----------
Thanks for the camera explanation and very interesting plan to simplify (or unify) your calculations for all objects and aircraft status for each frame. Quite a feat to achieve.

It was my understanding EAW's 70 clock cycles/second made it possible to adjust for different CPU speeds on different machines. So that all players saw virtually the same game speed.
Just how this works, I don't quite "get it".

[sydbod]

It was my understanding EAW's 70 clock cycles/second made it possible to adjust for different CPU speeds on different machines.....

You are basically correct here.
From memory, the computer has hardware circuitry that updates a counter 70 times a second.
The game loop looks at how many of these 1/70 second updates have occurred since the last pass through the game loop.
From this it knows how much time has passed since the last game loop.
The game also knows the rate of change for things like distance...rate of roll... etc that the aircraft is going through at that instant.
It therefor can now calculate by how much the position of the aircraft has changed, based on the aircraft's rate of change multiplied by the time increment.
If a machine is running at a slower FPS, then the time increment reading between game loops will be larger, and the program will therefor move the aircraft through larger values because of that slower FPS.