Given
typedef struct ELEMENT_DXGAUGE
{
HEADER;
UINT32 size_x;
UINT32 size_y;
}ELEMENT_DXGAUGE, *PELEMENT_DXGAUGE, **PPELEMENT_DXGAUGE;
#define MAKE_DXGAUGE( NAME, SIZE_X, SIZE_Y ) \
\
ELEMENT_DXGAUGE NAME = \
{ \
ELEMENT_TYPE_DXGAUGE, \
SIZE_X, \
SIZE_Y \
};
clearly the SIZE_X and SIZE_Y macro parameters don't end up in the size_x and size_y fields,
instead they become the next two HEADER values (resource_id and position.x if I'm not mistaken).
Does this not cause any problems?
[ANSWERED] MAKE_DXGAUGE strangeness?
- Beau Hollis
- Lockheed Martin
- Posts: 2452
- Joined: Wed Oct 06, 2010 3:25 pm
Interesting. That is probably why dx gauges would play nicely with mouse regions unless you have another element in the gauge. You might want to try adding the rest of the definition in your local version of the header:
RES_ID, \
POSITION_X, POSITION_Y, \
{0,0}, \
{0,0}, \
GAUGE_HEADER, \
NULL, \
(PPELEMENT_HEADER)(NEXT_LIST), \
(PFAILURE_RECORD)(FAILURE), \
DRAW_FLAGS, \
ASI_FLAGS, \
0,
Thankfully all the problems it creates can likely be worked around because the dx gauge has raw access to the renter target for the panel, so the dx code has to set up its own viewport and there aren't separate render callbacks for each dx gauge element, just one for the gauge. We basically just key off of whether or not the gauge contains any dx gauge elements to determine if we should make the render target available before calling the gauge callback.
In V2 we are depricating the dx gauge element. V2 will have a more flexible render to texture plugin architecture where you write a plugin that registers itself with Prepar3D as a texture by name. These textures can then be referenced in models (as with the $textures in the VC) as well as drawn into a section of a panel or as an element in an XML gauge. Thus, you will only need a true gauge if you need to add mouse interaction.
Thanks,
Beau
RES_ID, \
POSITION_X, POSITION_Y, \
{0,0}, \
{0,0}, \
GAUGE_HEADER, \
NULL, \
(PPELEMENT_HEADER)(NEXT_LIST), \
(PFAILURE_RECORD)(FAILURE), \
DRAW_FLAGS, \
ASI_FLAGS, \
0,
Thankfully all the problems it creates can likely be worked around because the dx gauge has raw access to the renter target for the panel, so the dx code has to set up its own viewport and there aren't separate render callbacks for each dx gauge element, just one for the gauge. We basically just key off of whether or not the gauge contains any dx gauge elements to determine if we should make the render target available before calling the gauge callback.
In V2 we are depricating the dx gauge element. V2 will have a more flexible render to texture plugin architecture where you write a plugin that registers itself with Prepar3D as a texture by name. These textures can then be referenced in models (as with the $textures in the VC) as well as drawn into a section of a panel or as an element in an XML gauge. Thus, you will only need a true gauge if you need to add mouse interaction.
Thanks,
Beau
Beau Hollis
Prepar3D Software Architect
Prepar3D Software Architect
Just out of curiosity, how are the D3DVIEWPORTS linked with the child windows? And if there isnt a gauge entry in the panel.cfg for that child window, is there still a IDirect3DSwapChain9 or IDirect3DSurface9 instance created for that window?
Jonathan Bleeker
Milviz systems dev
Formerly known as Naruto-kun
Milviz systems dev
Formerly known as Naruto-kun