Moving HUD from Cockpit View

[Ossenbrugge]

Hi all,

First post, long time lurker. I am working on a Simpit of my own homebrew design, and I was wondering if it is possible to move the HUD from the cockpit view to an MFD or something that can display just the HUD data (I'm looking into building my own HUD projector). Is this possible? Also is it possible to remove some of the other information one gets from the cockpit view (Date, Sim Time, etc)? I am attempting to get a plain (no console or VC) view for a projection (or LCD panel) that would be "outside" the pit.

(If this needs to be moved to another forum, apologies for posting in the wrong place).

Any help or advice from others who have Sim Cockpits or Developer/Guru's in the inner orbiter workings would be appreciative.

Thanks,

Ossenbrugge

 

[martins]

Here are some suggestions:

Method 1:
One possibility would be to draw your own HUD, based on avionics data you retrieve from the vessel. This is a bit work-intensive, since it needs recalculation of the pitch ladder, compass ribbon, and whatever else you want to display, but it would be the most versatile, since you have complete freedom in design and resolution.

Method 2:
Intercept the VESSEL2::clbkDrawHUD method. This is called by the orbiter core to allow a vessel to modify the HUD before rendering it. The HUD surface is sent to the vessel at each frame as a bitmap that can be painted into. The disadvantage is that this solution is vessel-specific: you need to modify the vessel DLL, and it only works for those vessels, not in general.

Method 3:
There is a method GraphicsClient::GetVCHUDSurface() in the graphics client API (currently only in the beta version). This function is used by the graphics client to render the VC HUD. You could therefore in theory implement your own graphics client that uses this method to obtain the HUD contents and process it for external rendering. This has the advantage that it is vessel-independent. There are however disadvantages:
- only works in VC mode
- resolution is not great (256 x256)
- you are stuck with the predefined layout

Also, this method may not be entirely trivial to implement. The GraphicsClient class is in beta development and for now may change without notice, with the danger of leaving you stranded with your own development.
The GraphicsClient base class defines the HUD contents as an abstract SURFHANDLE object. So to actually do anything with it, you would have to derive your own class from one of the device-dependent clients (DX7, DX9 or OpenGL) to obtain a device-dependent surface object (e.g. LPDIRECTDRAWSURFACE7 for the DX7 client). This you could then either render directly via the client, or if necessary blit into a bitmap for further processing.

 

[Ossenbrugge]

Martin,

Thanks for the quick response and a fantastic simulator. I'll give all three options a go and see what shakes out from each attempt. I know each attempt has its drawbacks but you've at least been able to point me in a direction that gives me a better understanding of the problem set. I was hoping that someone else has come across and solved this puzzle, but seeing as I am an unintentional pioneer here I'd be willing to collaborate or share any results I could come up with.

Thanks Again for the great Sim, and fast response.

Regards,

Ossenbrugge