TERRAIN/GPS Data

[qsysk]

Hello again,

I was experimenting a little bit with the fs9gps:map and rose.
Actually i wanted to use these IGaugeCDrawable(s) via a c++ gauge. Using the panel_get_registered_c_callback etc.

I managed to create them both (note that id for the map is 0x10001 and for the rose is 0x100002 ) but unfortunately map doesn't draw at all.

The code behind the Draw method exposed by the map interface is empty.
The call address is 0x20856550 which is inside gps.dll but if you check the address you will see this.

xor al, al
retn 14h

As you can understand this portion of code can not draw the map.

I have tried to identify where the map is drawn but i couldn't find it.

One more thing. There a window (found with Spy++) having caption "MapWindow" (thats inside the fsui not in the 3d). This window is used by the weather dialog and the flightplan dialog is order to show the map (u know airspaces airport stations etc). MapWindow uses the same visualization with th fs9gps:map fact that leads me to the conclusion that the actual drawing is happening somewhere outside the gps.dll (note that only the rose map draw proc uses some gdi function inside the gps.dll which means that there is no other drawing inside the dll)

Is there any idea where the map drawing happens.

Thanks in advance!!

Kioussis Konstantinos.

ps. I have found where the L:vars are stored and also i made a 'hijack' at panels.dll in order to callback a user defined proc when write/read occurs.

 

[eric_marciano]

Hello Kioussis,

I am interested in your PS more than in the post itself.
You say you have hijacked panels.dll to 'intercept' read/write. What read/write are you talking about? Are you talking about load/save a flight? Is it for FS9, FSX or both?

Thanks,
Eric

 

[qsysk]

intercepts the L: style variable access on read or write

lets say that we have an LVAR called X

ex.
(L:X,number) (>L:SomethingElse...) is a READ
(L:SomethingElse...) (>L:X,number) is a WRITE

or

ID i = check_named_variable("X");
... = get_named_variable_value(i); is a read
set_named_variable_value(i,34225); is a write

it intercepts any type of access to the variable.
from simple get_named...blahblah to the execute_calculator_code or even FS internal access.

There is only 1 case in the initialization where the FS internal clears the whole LVAR vector in which i can not intercept.

I have tested it @ FSX. i believe that there will be no difference @ fs9. the intercept is performed by dynamically overriding proloque code of some function within the panels.dll(which in both cases is IA32 so no difference on the interception itself).

 

[eric_marciano]

OK, I now fully understand, but I don't really understand the interest of doing this. But I'm sure there is interest

Eric

 

[n4gix]

Is there any idea where the map drawing happens.

If you carefully study the XML code for the map portion of the default G500 GPS, you'll see the pattern exposed. Translating that to a C++ method is possible, but rather convoluted and difficult.

The fs9gps.dll is our "blackbox" into the system ACES set up. For our purposes we don't absolutely need to know what happens internally. Obviously the DLL is doing a lot more "behind the scenes," but we simply need to know how to properly send our request for information (what I call the "goesinta"), then capture and use the results of our query (what I call the "comesouta). In effect, this is all that the XML script does.

Obviously, the fs9gps.dll is handling all of the numerous data lookups from the sim's .bgl files, but we aren't privy to ACES' own proprietary data formats so are unable to easily do our own, direct lookups...

Unfortunately, the code I have is proprietary so I'm not free to distribute it (it's used in our Avidyne Entegra as well as the Mindstar G1000), but I can and will give you some hints. Sometimes simply knowing something is possible is all that's needed...

The "map" is the result of a two-step operation. The first step is to issue a query to the fs9gps.dll via a function call, followed by a request to send the map back to our hdc buffer:

//MAP
// Create instances of IGCD_create_parameters & IGCD_draw_parameters
// used to get the parameter ID's and to pass the values of the parameters to the flightsim

	pMap_IGCD_create_params = static_cast<IGaugeCDrawableCreateParameters *>( new map_CreateParameters() );

	pMap_IGCD_draw_params = static_cast<IGaugeCDrawableDrawParameters *>( new map_DrawParameters() );

The "map" is assembled by fs9gps.dll and returned via the

pMap_IGCD = pMap_IGCC->CreateGaugeCDrawable (MAP_ID_map, pMap_IGCD_create_params);

function.

Once the fs9gps.dll has finished the request, then we blit the buffer to our DIBSECTION using the SET_OFF_SCREEN(); function:

map_timer ++;
if (map_timer>36 && pelement_surf && hdc_surf) //was 18
{
		SET_OFF_SCREEN(pelement_surf);
		map_timer = 0;
}	// END map timer

I do hope that this is helpful. Believe me, it is far more than I got from Susan Ashlock (Lead Gauge Programmer at ACES) from my discussions with her...

 

[qsysk]

Far beyond of just ‘helpful’..