Thanks. How about d3d9?
It's part of the OpenOrbiter. Comes with the package.Thanks. How about d3d9?
So open orbiter will be 2024?It's part of the OpenOrbiter. Comes with the package.
Attached a demo, result of ~45 minutes of work (most of it spent setting up the code block), based on the SSV manual. I favor a simple style, which ends up being easier to maintain and probably has less dependencies, but the cover should be made prettier.One thing that has apparently changed in D3D9 is the handling of the HUD mesh group (the behavior in MOGE remained unchanged). In Orbiter 2016 it worked (i.e., mesh not visible, only the drawing) if the group had a material defined. Now, the material has to be set to 0 or the group will be visible.
This should be mentioned somewhere for future reference. In API_Guide.pdf there is a section "1.13.7 Defining the HUD in the virtual cockpit", but all it has is "< to be completed >".
I could write something about this, but looking at the rest of the pdf, it looks a bit dated, plus the source is binary, so keeping track of edits is pretty much impossible, and will cost storage space in github. Maybe the solution is to convert all the docs to LaTeX sources? Sometime ago I played a bit with having LaTeX sources converted to pdf via command line for SSV (although I never went thru with it... yet), so it should be possible to have this process automated in cmake, which would take care of the "building the documentation"problem. Yes, LaTeX can be a PITA sometimes, but the sources are plain-text, so they would be as "workable" as code.
Any thoughts?
One thing that has apparently changed in D3D9 is the handling of the HUD mesh group (the behavior in MOGE remained unchanged). In Orbiter 2016 it worked (i.e., mesh not visible, only the drawing) if the group had a material defined. Now, the material has to be set to 0 or the group will be visible.
This should be mentioned somewhere for future reference. In API_Guide.pdf there is a section "1.13.7 Defining the HUD in the virtual cockpit", but all it has is "< to be completed >".
There's no lens flare, just the sun glare which can be tuned in realtime from D3D9Graphics Controls, you can also customize it by editing Glare.hlsl in /Modules/D3D9Client/Just want to say, very impressed so far, on all levels, GUI, gfx, performance, also microtex. is way better! (don't like the lens flare options though).
DG needs normal maps etc. (I think somebody made some?) stock bases need flattening.
I have no problems with the new implementation: it works and it's one less material. The default vessels are also not using a material in the HUD mesh, so that seems to be the standard, so there is nothing to fix. It just should be indicated somewhere how it works.The changes in the HUD are not intentional. I'll compare the code to O2016 and try to fix it.
What do you mean, to document the API functions?Are there any LaTeX editors those would allow to create documents without needing to write the source code ?
I used lyx a looong time ago, it's WYSIWYG. Don't know how it fared with time though.What do you mean, to document the API functions?
For the demo above, I used TeXworks. I might have an old version by now, but it has a basic editor and one button conversion to pdf. The source .tex files can be edited there, or in any text editor.
Did you install it over Orbiter2016 for the textures? If so, there might be two Orbiter executables, orbiter.exe and Orbiter.exe. Orbiter.exe is the Orbiter2024 version.So I made a new folder Orbiter2024 and downloaded the x86 and extracted.
I noticed the start screen says Orbiter 2016?
That is the doxygen-generated pdf, and that should "just" be pointing doxygen to the source files (easy), and have the code documented (not easy).I know there are a few new things in the API reference that need to be documented.
They all do.The API guide needs work too.
A possible implementation for the "code block" is already provided in my demo above.I can transcribe the API Guide into LaTeX if no one else wants to.