# New ReleaseD3D9Client Development

#### Face

Beta Tester
@Face: I was using the node 8b4a94a56e17c82f8b9ff49bb9c258721f543505, and I compiled with the 111105 build of Orbiter (some definitions used in the code needed the beta version).
That was the beta development line, that's why it needed Orbiter beta. I've pushed jarmonik's latest ZIP-archive as RC39b tag now. Check this for a graphical view of the development lines in this repo.

regards,
Face

#### Bibi Uncle

##### 50% Orbinaut, 50% Developer
Ok, thanks ! :thumbup:

#### jarmonik

Beta Tester
Ok, so I concentrate on reading the runway values from the config file and calculating the position of the beacons.
Ok, That would be great.:thumbup:

#### Bibi Uncle

##### 50% Orbinaut, 50% Developer
I've just finished the configuration finding method. I simply provide a class name and it automaticaly parses every file in the Config folder until it finds a corresponding class name (defined in the file with the flag "Name =" ). It was quite hard to code, but I did it.

The performances are quite good, but if Orbiter provided us with the config file name directly, it would be much faster... (subliminal message to Martin...)

#### orb

I've just finished the configuration finding method. I simply provide a class name and it automaticaly parses every file in the Config folder until it finds a corresponding class name (defined in the file with the flag "Name =" ). It was quite hard to code, but I did it.
Why to reinvent the wheel? The D3D11Client reads the configuration files for RUNWAYLIGHTS too, and it's open source, too. Just switch to D3D11Client branch of https://bitbucket.org/face/ovp mercurial. RUNWAYLIGHTS are in VBase.cpp.

#### Bibi Uncle

##### 50% Orbinaut, 50% Developer
Too late, it's already done :lol:

I did not know that the D3D11 client was already able to create the runway lights. In fact, I cannot even run it. I have an old Pentium 4 running XP. XP = No D3D10 nor D3D11.

#### orb

Too late, it's already done :lol:

I did not know that the D3D11 client was already able to create the runway lights. In fact, I cannot even run it. I have an old Pentium 4 running XP. XP = No D3D10 nor D3D11.
You don't have to run it. I haven't run it either. The code reading configuration files doesn't render anything, just reads and parses the files.

#### Bibi Uncle

##### 50% Orbinaut, 50% Developer
I specified that I cannot run the D3D11 client simply to explain why I'm not very up to date about its status. I did not really read the D3D11 thread...

By the way, I've just finished the reading part (obtaining the datas). I should study for my history exam now... :shifty:

#### Cras

##### Spring of Life!
Donator
Well for what it's worth, the D3D11's runway lights are fantastic. Using its methods can only result in a fantastic feature in my book.

Runway lights in the NG enviornment is something that has been needed for sometime now, and I very much appreciate asmi's and Bibi Uncle's efforts to get them in the D3D11 and D3D9 clients respectively.

#### asmi

I specified that I cannot run the D3D11 client simply to explain why I'm not very up to date about its status. I did not really read the D3D11 thread...

By the way, I've just finished the reading part (obtaining the datas). I should study for my history exam now... :shifty:
As an author of D3D11Client's code for config files parser, I'd actually encourage you to use my code for two primary reasons - first of all, the code will be tested more thoroughly so more bugs will be found, and the second one - it also reads some extended properties for the runway lights which will be absolutely neccessary if you will be implementing more or less real lighting, as default client seems to be using a hardcoded scheme which has very little to do with lighting that you can see on real runways. So using the same attributes will allow for a config file extended options to be cross-client. Just remember that there is more in rwy lights than just rendering a bunch of billboards - for example VASI/PAPI requires you to use different color based on from what angle are you looking at it. If you want you can just try back-porting rwy lights-related code from D3D11Client. You can find most recent code for the client here: https://bitbucket.org/asmi/ovp/, branch "D3D11Client".

The only thing is - you have to be somewhat familiar with C++ templates as config parser makes use of them...

UPDATE: You can also find updated config files for runways that includes my custom attributes, set up for every runway in the game in my source control. For example, this is what Habana's rwy looks like in D3D11Client:

Here is a picture that explains what all custom parameters are for (it also can be found in Doc/D3D11Client folder inside source control):

Last edited:

#### n122vu

Donator
For example, this is what Habana's rwy looks like in D3D11Client:
Wow. I haven't looked at D3D11 Client yet. That looks awesome. Excited to see something similar in D3D9 client as well, since I'm not sure my current card is D3D11 compatible. Keep up the good work, and thanks to all of you for your work on the respective clients.

#### asmi

Wow. I haven't looked at D3D11 Client yet. That looks awesome. Excited to see something similar in D3D9 client as well, since I'm not sure my current card is D3D11 compatible. Keep up the good work, and thanks to all of you for your work on the respective clients.
D3D11Client supports DirectX 10-compliant video cards as well, however it's strongly recommended to have DX11-compliant card as there are some planned features that are going to work on DX11-class hardware only, and D3D11Client is meant to be high-level client for middle to high-end systems. It already have some advanced features like HDR lighting, and more is coming

P.S. I'm sorry for the intrusion into the topic.

#### jarmonik

Beta Tester
I got the BeaconArray class mostly ready and it seems to be working pretty well. There is still a lot of calibration to do but can't do that properly without a proper set of a runway lights. Here is a screen shot of 10000 beacons. There is still a lot to do and I'll try to upload the source codes in a few days.

Last edited:

#### Bibi Uncle

##### 50% Orbinaut, 50% Developer
I'll stay with my config file parser and my runway lights class, because I looked in your code and using it would mean a lot of refactoring. However, I totally agree to take the same parameters as you, asmi. It creates much more realistic lights. The fact that you already did it one time will help me creating realistic ones too.

Perfect jarmonik! I'll try to work on the creation code this week-end, but I'm pretty busy.

Edit:
Some lights will have two colors; one for when we are landing towards it and another when we are not. For example, when we are landing, the latest runway center lines are red. However, the meaning of "latest" changes when we are landing on the other side. I don't know if my sentence is clear...

So, do I specify two colors (front and back colors) or I defined them twice. The first idea is cheaper on the memory, but the latest is cheaper at run-time... It all depends on your implementation of the beacons.

Last edited:

#### asmi

I'll stay with my config file parser and my runway lights class, because I looked in your code and using it would mean a lot of refactoring. However, I totally agree to take the same parameters as you, asmi. It creates much more realistic lights. The fact that you already did it one time will help me creating realistic ones too.

Perfect jarmonik! I'll try to work on the creation code this week-end, but I'm pretty busy.

Edit:
Some lights will have two colors; one for when we are landing towards it and another when we are not. For example, when we are landing, the latest runway center lines are red. However, the meaning of "latest" changes when we are landing on the other side. I don't know if my sentence is clear...

So, do I specify two colors (front and back colors) or I defined them twice. The first idea is cheaper on the memory, but the latest is cheaper at run-time... It all depends on your implementation of the beacons.
Ok, whatever is easier for you. In this case let me give you some clues (they all are in comments inside the code, so you might want to just read it through). I've done some research on the subject, including checking with FAA regulations, and here is a layout that I've implemented.
1. For lights along the runway's centriline:
If distance from the edge of the runway (that is the closest end of the runway) is more than 914 meters, then the light have to be white.
If distance is less than 914 m, but more than 305 m, the lights have to be interleaving white and red.
If distance is less than 305 m, the lights have to be red.
2. For lights along the runway's borders:
If distance from the edge is more than 610 meters - they have to be white, otherwise - yellow.
Here is a picture that visually represents what I've just said:

Remember that all these distances are calculated from the actual RWY start so END1/2-TD_DISP.
Please let me know if it helps, and if so - I can outline here the rest of details, or as I've said you can just refer to the code - I tried to put enough comments so readers whould get what is going on right from reading the source.

#### Bibi Uncle

##### 50% Orbinaut, 50% Developer
Thanks asmi!

I based myself too on this article. However, I have two questions.
1. The Runway Centerline Lighting System should have lights each 15m. In your code, I saw that you create them just like Orbiter; 40 lights each side.
2. In the edge lights, you wrote "it's close to edge, so has to be yellow when seen from center of the RWY". I do not really understand the last part. Are the lights always yellow, or are they yellow only when you land towards them (the latest lights you see)?
Also, i will take your default values of the additional runway settings in order to create a realistic lighting system even on config files that do not specify these settings. I'll take these default values:

PHP:
obj.Count = 40;
obj.TouchZoneDisplacement = 0;
obj.TouchZoneLength = 400;
obj.DecisionDistance = 300;
obj.ApproachStart = 1000;

#### jarmonik

Beta Tester
So, do I specify two colors (front and back colors) or I defined them twice. The first idea is cheaper on the memory, but the latest is cheaper at run-time... It all depends on your implementation of the beacons.
I need to think about that but it might be better to define them twice.

Here are my latest sources with the BeaconArray implemented. I am in a middle of implementing a few other things, so, some features are off-line or not working. So, no need to report bugs unless they are related into the BeaconArray.

Source only package. No binaries.

Last edited:

#### asmi

Thanks asmi!

I based myself too on this article. However, I have two questions.
The Runway Centerline Lighting System should have lights each 15m. In your code, I saw that you create them just like Orbiter; 40 lights each side.
Yes, that's because in the beginning I was going to use built-in Orbiter parameter that defines a count of lights. Afterwards I've figured that it doesn't look quite like I'd like it to, so I just multiply this number by 2 But yes, in general you are correct, but it would mean incompatibility with built-in feature, so I've settled on the middle-way. But now when I think about it - probably you're right and it would be better to just ignore this parameter alltogether and use 15m intervals...
In the edge lights, you wrote "it's close to edge, so has to be yellow when seen from center of the RWY". I do not really understand the last part. Are the lights always yellow, or are they yellow only when you land towards them (the latest lights you see)?
When you look from the center basically means "when you take off in this direction", so this edge will be the end of a runway (the picture in my previous post displays this situation). However, these lights will have to be white if you look another way with respect to runway heading. Here is exactly same edge of a runway but seen from direction opposite to previous one:

I hope that clears things up, if you still have questions - feel free to ask - I'm happy to help.
Also, i will take your default values of the additional runway settings in order to create a realistic lighting system even on config files that do not specify these settings. I'll take these default values:

PHP:
obj.Count = 40;
obj.TouchZoneDisplacement = 0;
obj.TouchZoneLength = 400;
obj.DecisionDistance = 300;
obj.ApproachStart = 1000;
Default value for the count is taken from Orbiter's documentation (this is a built-in parameter), the rest of values were taken from FAA regulations as recommended values.

#### Bibi Uncle

##### 50% Orbinaut, 50% Developer
@jarmonik: Just a little test of your new lighting system. I was not home this week-end, this is the result of just a late dev session.

It works flawlessly. I can't even notice a performance drop on my old PC (there's only 240 lights in this scene, 120 per runway, but that's a beginning). Notice that lights are placed in a very basic pattern for now.

@asmi:
I vote for the 15m intervals. If we do it at like that, does the edge lights must also be at 15m intervals... It is not specified in the Wiki article.

Ok, I understand the yellow pattern now. Thanks! :thumbup: