Orbiter 2024 Launch readiness

[GLS]

Somehow I got cmake to generate the documents! Well... 2 of them, as the technical manual fails, probably due to the need to convert the *.eps image files. Still not sure how to solve this... might just give up for now, move forward to the PR merge and fix later.

This progress on the documentation is excellent. It may already exist, but is there a centralized place where community members can report any issues with documentation, through GitHub or elsewhere? Some guidance on the opening pages of the actual documentation that points the user to where to report bugs and documentation issues might help herd most of the cats in the correct direction and put the information where it can be used effectively.

Isolated tickets can be posted, or at this point this ticket can be used as a centralized location for documentation issues. The issues I identified are already listed there.
Of course, the user can also correct the issue and post a PR, but before that, my conversion work PR, has to be completed and merged.

 

[GLS]

the technical manual fails, probably due to the need to convert the *.eps image files

Nop, just a silly typo...
So, all 3 documents can now be build/compiled by cmake (in just 15 seconds)!!!
One small issue is that the *.eps conversion leaves the *.pdf files in the repository folder, as opposed to the working directory with the other files. They don't show up in git as the *.pdf files are in the gitignore file, so it is not as bad as it could be, but it is not optimum. This one I don't think can be fixed without an explicitly deleting each file.
Anyway, this should be it. Tomorrow I'll delete the original doc sources (they can always be obtained from git history) and make the PR available for merge.

 

[Gondos]

Speaking of documentation, the Lua API doc should be ready to merge. The generated doc is attached here, feel free to comment if you find some errors.

 

[GLS]

I think this PR is now (at last) ready for review and merge. Again, IMO it is better perform a squash merge to minimize space requirements.

 

[DaveS]

What remains to be updated document-wise from and end user standpoint is the D3D9Client manual as it has no mention of the atmospheric rendering or the support for custom terrain flattening files (*.flt).

 

[jarmonik]

I think this PR is now (at last) ready for review and merge. Again, IMO it is better perform a squash merge to minimize space requirements.

It's been merger to orbitersim:latex_doc_update and ready for receiving updates, corrections and reviews. So far, I haven't been able to build the documentation due to some font problems. "NotoSansMono" font is a part of MikTex installation in MiKTex/fonts/truetype/google/noto/ but build process refuses to use it. I am trying to build with TeXnicCenter.

!pdfTeX error: pdflatex.exe (file NotoSansMono-Regular-tlf-ts1--base): Font NotoSansMono-Regular-tlf-ts1--base at 600 not found
 ==> Fatal error occurred, no output PDF file produced!

 

[GLS]

It's been merger to orbitersim:latex_doc_update and ready for receiving updates, corrections and reviews. So far, I haven't been able to build the documentation due to some font problems. "NotoSansMono" font is a part of MikTex installation in MiKTex/fonts/truetype/google/noto/ but build process refuses to use it. I am trying to build with TeXnicCenter.

!pdfTeX error: pdflatex.exe (file NotoSansMono-Regular-tlf-ts1--base): Font NotoSansMono-Regular-tlf-ts1--base at 600 not found
 ==> Fatal error occurred, no output PDF file produced!

Thanks!
I don't think a font is being (explicitly) set, so I'm not sure what the problem could be... I never got any font problems, both in TeXworks or cmake.

 

[n72.75]

I've been doing some testing, and I've discovered a strange lighting bug:

If you look very closely there is a Deltaglider in this image...



Easy way to replicate: put yourself in an orbit around Uranus or Neptune (and their moons). The problem goes away as soon as the gravity reference switches to the sun, and does not require a reload.

Buuuuut.....
Reloading fixes the "ghost ship" issue, and gives you a "no sunlight" condition.



It appears very similar to this issue but I can't find a connection.

I tested the rest of the solar, and Jupiter, Saturn, Mars, Earth, and a bunch of their moons all seem fine. Titan has planet-shine but no sunlight.

I think there is some edge-case where the "are we in sunlight" condition isn't being met. I am creating an issue on github, and will link it here:

 

[GLS]

Could we get a version of oapiCreateFontEx(), that can rotate the chars? The only function that allows rotation is oapiCreateFont(), but it doesn't allow the user to (precisely) select the font...

This is probably too much for this release, so it can wait for the next bus.

 

[Voyager_]

I've been doing some testing, and I've discovered a strange lighting bug:

If you look very closely there is a Deltaglider in this image...

View attachment 39075

Easy way to replicate: put yourself in an orbit around Uranus or Neptune (and their moons). The problem goes away as soon as the gravity reference switches to the sun, and does not require a reload.

Buuuuut.....
Reloading fixes the "ghost ship" issue, and gives you a "no sunlight" condition.

View attachment 39076

It appears very similar to this issue but I can't find a connection.

I tested the rest of the solar, and Jupiter, Saturn, Mars, Earth, and a bunch of their moons all seem fine. Titan has planet-shine but no sunlight.

I think there is some edge-case where the "are we in sunlight" condition isn't being met. I am creating an issue on github, and will link it here:

Maybe there's a typo in the coding.

 

[CaptainSwag101]

There appears to be an issue with texture mipmaps. When set to "Autogen missing", which worked fine for NASSP in Orbiter Beta R90, various elements in the cockpit with dynamic information get "covered up" by the mipmap layers, as you can see here:

This affects a very large number of cockpit elements, including talkbacks, indicator lamps, DSKYs, mission timers, and more. We can work around this issue by changing the Texture Mipmaps option in the D3D9Client config to "Load as defined", but then we don't get the benefit of auto-generated mipmaps to help reduce aliasing.
(Note: This GIF was recorded on the date of posting, with a version of OpenOrbiter built from the latest commit available. It occurs in both x86 and x64 builds. The issue has occurred for over a year, see my mention of it here.)

 

[jarmonik]

There appears to be an issue with texture mipmaps. When set to "Autogen missing", which worked fine for NASSP in Orbiter Beta R90, various elements in the cockpit with dynamic information get "covered up" by the mipmap layers, as you can see here:

I'll take a look at the code and see if there's something I can easily do. As far as i can tell NASSP runs very much in a DX7 emulation mode which do have limitations and stability issues. Trying to keep the DX7 emulation layer operational has already taken too much time. DX7 emulation layer is automatically enabled if graphics programming constraints are violated. Of which, most common is directly using GDI on panel background.

 

[jarmonik]

Could we get a version of oapiCreateFontEx(), that can rotate the chars? The only function that allows rotation is oapiCreateFont(), but it doesn't allow the user to (precisely) select the font...

This is probably too much for this release, so it can wait for the next bus.

There is Sketchpad::TextEx() that can rotate while printing.

 

[CaptainSwag101]

I'll take a look at the code and see if there's something I can easily do. As far as i can tell NASSP runs very much in a DX7 emulation mode which do have limitations and stability issues. Trying to keep the DX7 emulation layer operational has already taken too much time. DX7 emulation layer is automatically enabled if graphics programming constraints are violated. Of which, most common is directly using GDI on panel background.

Understood, we appreciate you looking at this. To make your job easier regarding DX7 fallback, is there any way for us to debug things on our end and catch these graphics constraint violations, to more easily identify problems in our code and fix them?

 

[jarmonik]

Understood, we appreciate you looking at this. To make your job easier regarding DX7 fallback, is there any way for us to debug things on our end and catch these graphics constraint violations, to more easily identify problems in our code and fix them?

There is "Enable Debug Break" check box in the config panel. It should break on violation. Also "going in DX7 compatibility mode" message is printed in the log if debug level is 2 or higher. Incorrect GDI use is the only thing that can trigger DX7 compatibility/emulation mode. Would be good idea to move to sketchpad since GDI is a windows specific and Vulkan has no native support for it at all.

 

[CaptainSwag101]

There is "Enable Debug Break" check box in the config panel. It should break on violation. Also "going in DX7 compatibility mode" message is printed in the log if debug level is 2 or higher. Incorrect GDI use is the only thing that can trigger DX7 compatibility/emulation mode. Would be good idea to move to sketchpad since GDI is a windows specific and Vulkan has no native support for it at all.

Thanks, looks like our 2D panel is triggering DX7 compat mode, which doesn't surprise me. We've been making efforts to switch to Sketchpad but I think it's not complete yet. Hopefully this info will help us improve things. However, our 3D virtual cockpit, where this mipmap bug is occurring, doesn't seem to be going into compatibility mode, at least not as far as I can tell.

 

[jarmonik]

Ok then, what is the code sequence used to draw the DSKY ?

SURFHANDLE hSrf = oapiGetMeshTexture(hMesh);
HDC hDC = oapiGetDC(hSrf);

That should fail. Dynamic textures do support GDI but they do not support mipmaps nor auto-generation of them on update. Only render-target-texture do.

With GDI:

SURFHANDLE hDraw = oapiLoadSurfaceEx("dsky.dds", OAPISURFACE_TEXTURE | OAPISURFACE_GDI);
oapiGetSurfaceSize(hDraw, &width, &height);
SURFHANDLE hSrf = oapiCreateSurfaceEx(width, height, OAPISURFACE_TEXTURE | OAPISURFACE_RENDERTARGET | OAPISURFACE_MIPMAPS);  // Autogen mipmap support
oapiSetMeshTexture(hDevMesh, 0, hSrf);

HDC hDC = oapiGetDC(hDraw);
// DRAW
oapiReleaseDC(hDC)

oapiBlt(hSrf, hDraw); // Copy drawing surface to a texture and enable mipmap update before use

With Sketchpad:

SURFHANDLE hSrf = oapiLoadSurfaceEx("dsky.dds", OAPISURFACE_TEXTURE | OAPISURFACE_RENDERTARGET | OAPISURFACE_MIPMAPS);  // Autogen mipmap support
oapiSetMeshTexture(hDevMesh, 0, hSrf);

Sketchpad *pSkp = oapiGetSketchpad(hSrf)
// DRAW
oapiReleaseSketchpad(pSkp); // enables mipmap update before use

 

[CaptainSwag101]

Thank you, I will try and do some digging into our code to figure out how to rework things, and talk with the other NASSP devs. Since it seems like many things in our cockpit have problems with mipmaps, I suspect this may be a systemic problem; hopefully one we can fix without too much work. I really appreciate the assistance and sample code.

 

[GLS]

There is Sketchpad::TextEx() that can rotate while printing.

I played with this and found that although it rotates the font with quite good results, it seems to not be respecting the requested angle (while rotating a char, it starts to slow down, and then jumps like 30º). Also, the function seems to take in degrees and not radians, as advertised in the header comment.
Only tried it in D3D9 (using GDI in MOGE).

 

[Dambuster]

Just wanted to drop in here to say a big thank you to everyone working on this. I can see it's a long and difficult road - I really appreciate all the effort you are putting in to keep this amazing simulator alive and growing.