-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Break up HUD elements into individual OSD elements #9199
base: master
Are you sure you want to change the base?
Conversation
Break up hud elements as individual OSD elements to allow different layouts to show/hide those elements.
Previous number was 4(hud_radar_disp max) + 1 Now it is 6 + 1.
Still depend on the crosshair, but should be clearer. Needs testing
I am curious to see how this would work with the hud clearing happening in the crosshair, and the drawing of the individual hud elements happening afterwards. Due to the nature of how the drawing happens (by element id), the behavior should be similar, except that osdHudDrawHoming() used to happen before clearing hud, and now will happen after. If there are side effects, we can move the individual elements back to the OSD_CROSSHAIRS case and just check if the individual elements are supposed to be displayed (like the first draft). |
This lets the OSD element visibility be the only setting that controls the visibility of these elements in the HUD
I saw some strange artifacts, reverting to old style display for now.
Breaks up hud elements as individual OSD elements to allow different layouts to show/hide those elements.
This needs testing, as there may be side effects due to the order elements are drawn. We still check for the crosshair to be there, are it has a call to osdHudClear
This also need mentioning in the Release notes, as osd_hud_homepoint and osd_hud_homing settings have been replaced by the equivalent OSD elements and osd_hud_radar/wp_disp no longer control INAV Radar element visibility in the HUD.