New Orbiter SVN commit (r.71, Oct 14 2017)

[Ripley]

Will the torrents be repacked as well with the new content?

 

[kuddel]

The current label legend config file documentation seems to be incorrect (but it might be valid after next commit)
I only got the selection Dialog working, and only with this "format":

C x O 255 255 255Cities
W o D 255 0 0Water
M o M 0 255 0Mountains
A x W 0 0 255Airports

Format:
<typeid> <default-visible> <symbol> <r> <g> <b><typename>

Note the "missing" space between <b> and <typename>! Else the name is listed with a leading space.

<typeid> is a character defining the type, corresponding to the IDs in the quadtree files,
<default-visible> is one of characters ‘x’ (visible by default) or ‘o’ (not visible by default),
<symbol> is a character defining the style of the marker symbol -one of 'S' (rectangle), 'O' (circle), 'D' (delta), 'N' (Nabla)-.
<r>, <g> and <b> are the red, green and blue components (0-255) of the colour with which the labels are displayed, and
<typename> is a string describing the label type.

But as noted, with this I was only able to let the selection dialog work - no rendering of the Labels (yet).

 

[Face]

But as noted, with this I was only able to let the selection dialog work - no rendering of the Labels (yet).

Did you try debugging the new OVP D3D7 code to check what GetSurfaceMarkerLegend() returns in the struct? It's in the TileLabel class Render() method.

 

[kuddel]

Did you try debugging the new OVP D3D7 code to check what GetSurfaceMarkerLegend() returns in the struct?

...kind of :lol:

The following...

//...
const GraphicsClient::LABELTYPE *lspec;
DWORD dummy, nl = gc->GetSurfaceMarkerLegend(hObj, &lspec);
for (auto i = 0; i<nl; ++i) {
  ++dummy;
}
//...

...was inserted in some other project[1] I had lying around. But other that that, I did exactly that!

[1]...it wasn't OVP D3D7 :lol:

 

[Face]

...kind of :lol:

The following...

//...
const GraphicsClient::LABELTYPE *lspec;
DWORD dummy, nl = gc->GetSurfaceMarkerLegend(hObj, &lspec);
for (auto i = 0; i<nl; ++i) {
  ++dummy;
}
//...

...was inserted in some other project[1] I had lying around. But other that that, I did exactly that!

[1]...it wasn't OVP D3D7 :lol:

Did it come up empty, then?

 

[kuddel]

Did it come up empty, then?

Didn't check the "empty" / "no config files" scenario, just started with your suggestion and tweaked them until it "fitted".

Just checked: In case of missing Label.cfg, GetSurfaceMarkerLegend() returns 0 and sets the LABELTYPE pointer to NULL! As expected.

 

[Face]

Didn't check the "empty" / "no config files" scenario, just started with your suggestion and tweaked them until it "fitted".

What I meant was if you already tried the GetSurfaceMarkerLegend() call with your tweak (the one where you've got selection entries) and checked what was inside the struct. And whether it was empty or not.
Thing is: if it is not empty, I bet the D3D7 OVP client renders the labels, because the code suggests so. If it was empty - although you used the "showing entries" Label.cfg - there is some bug in Orbiter, at least in the OVP layer.

 

[kuddel]

What I meant was if you already tried the GetSurfaceMarkerLegend() call with your tweak (the one where you've got selection entries) and checked what was inside the struct. And whether it was empty or not.

I tweaked the Label.cfg until the returned structure was plausible, so GetSurfaceMarkerLegend() works in general, but does not read the Label.cfg according to the documentation.

In case of missing Label.cfg, GetSurfaceMarkerLegend() returns 0 and sets the LABELTYPE pointer to NULL! As expected.

Thing is: if it is not empty, I bet the D3D7 OVP client renders the labels, because the code suggests so. If it was empty - although you used the "showing entries" Label.cfg - there is some bug in Orbiter, at least in the OVP layer.

OVP D3D7Client (external) might render the labels, inline doesn't.
I haven't bothered to compile D3D7Client :blush:

---------- Post added at 19:45 ---------- Previous post was at 19:29 ----------

@martins: Hey Martin,

My compiler (Visual Studio 2015) complains about a superfluous 'typedef' in GraphicsAPI.h line 1675.

c:\Orbiter\D3D9ClientDevelop(Orbiter BETA r67)\Orbitersdk\include\GraphicsAPI.h(1675): warning C4091: 'typedef ': ignored on left of 'oapi::GraphicsClient::LABELTYPE' when no variable is declared (compiling source file AtmoControls.cpp)

I think he is right about that

Would you mind removing that 'typedef'?

1669|	[COLOR="Red"]typedef[/COLOR] struct LABELTYPE {
1670|		char labelId;    // label type id
1671|		char markerId;   // marker shape id
1672|		COLORREF col;    // label colour
1673|		char *name;      // label type name
1674|		bool active;     // label type active?
1675|	};

Thanks in advance,
Kuddel

 

[Xyon]

Will the torrents be repacked as well with the new content?

Eventually - I mean, this is on my to-do list, but I have been struggling to find the time.

 

[martins]

I was about to push a new commit to fix the missing files, but for some reason can't get access to the repository now. Is it just me or is the SVN repository down?

Anyway, I'll try again tomorrow.

 

[martins]

Scrap last - problem was on my end. I've committed #68 now with the missing Label.cfg files. Also prepared label layer for Moon. Pick up the Moon labels from here. (I'll add the link to the download page tomorrow).

Please let me know if there are still problems.

 

[kuddel]

Please let me know if there are still problems.

Seems OK so far.
But is it true that the inline engine currently (r.68) does not render the new labels?



Side Note: (from PlanetTextures.pdf)

<markerid> is a character defining the marker shape: ‘S’ (square), ‘O’ (circle), ‘D’ (Delta) or ‘N’ (Nabla)

...now the 'S' makes much more sense, than with my guess :lol:

 

[GLS]

Seems OK so far.
But is it true that the inline engine currently (r.68) does not render the new labels?

Nothing is showing on my end...

 

[martins]

Seems OK so far.
But is it true that the inline engine currently (r.68) does not render the new labels?

Well it does for me :shrug: Are you sure that you

• set orbiter to accept compressed archives (Extra->Visualisation parameters->Planet rendering options->Tile sources: load from compressed archive only or Try cache first, then archive)
• enabled surface markers (Ctrl-F9->Planetarium->Markers->Surface)?

I just checked out a fresh #68 to make sure, and the inline client does render the new labels ok.

 

[GLS]

Well it does for me :shrug: Are you sure that you

• set orbiter to accept compressed archives (Extra->Visualisation parameters->Planet rendering options->Tile sources: load from compressed archive only or Try cache first, then archive)
• enabled surface markers (Ctrl-F9->Planetarium->Markers->Surface)?

I just checked out a fresh #68 to make sure, and the inline client does render the new labels ok.

There's your problem. With "try cache" it doesn't work, but with "archive only" it does.

Man, there are a LOT of labels, even the villages around my middle-of-nowhere hometown have labels.

 

[martins]

There's your problem. With "try cache" it doesn't work, but with "archive only" it does.

Ah ok, I can reproduce this behaviour. Will try to fix that.

 

[Ripley]

Eventually - I mean, this is on my to-do list, but I have been struggling to find the time.

Thanks Xyon.

Just a memo for when you'll find time:
Besides the new label.tree files, I also meant the (missing) torrent for the new HRSC Mars textures.

 

[martins]

A new beta commit #69 should fix the missing labels when cache+archive loading is active. To add more beef to the commit I also implemented some experimental font sizing trickery.

There is also a new OVP commit #60 that implements the changes in the D3D7 client.

 

[GLS]

A new beta commit #69 should fix the missing labels when cache+archive loading is active. To add more beef to the commit I also implemented some experimental font sizing trickery.

There is also a new OVP commit #60 that implements the changes in the D3D7 client.

Yes it's fixed, thanks!
Any news on this and this?

 

[martins]

Yes it's fixed, thanks!
Any news on this and this?

Ah sorry, I missed that one. As for the first question:

Yes, first vessel-specific MFD mode registered with VESSEL4::RegisterMFDMode receives ID 1000, and the ID is incremented by 1 for each subsequently registered mode. I'll update the description for RegisterMFDMode to say this.

The second one is a bit more intricate. The elevation grid Orbiter uses for computing vessel elevations, shadow normals, etc. is not necessarily the same as used for rendering the surface. For example, at high altitude, Orbiter doesn't use the highest available resolution tiles for computing altitudes, because that would require loading a new tile at each frame for each vessel. Even at low altitudes, the tile resolution may be capped to avoid too many reloads. However, this may require more fine-tuning. The question has come up before, and it's on my to-do list.