FS2004 Change fs9 GPS line width

[eric_marciano]

Hi experts,

Do you think it is possible to change the line width on the fs9 GPS display?
I know the line drawing is done in a DLL that is the result of C/C++ code compilation, so this requires some "hacking" in the generated code, but I know some people are good for this. Some people were able to provide DLL replacement to change the virtaul ATC behvior, change the ground friction or allow a system of moving cameras in fs9. So maybe someone would be able to change the line width to make the display nicer?
Honestly I think it is impossible, I just ask in case someone feels capable of doing it...

I think it has been designed that way at a time when our computers had low resolution display, but the result today is ugly. I think the GPS display would look much nicer if the green ILS arrows and the blue airspace boundaries were just 1 pixel thick instead of 2 or 3 as they are today. By the way, the lines are thinner in the FSX GPS display and it looks much better in my opinion, so I would like to have the same in fs9.

Any possibility?

Thanks,
Eric

 

[rpmc]

I'm definitely with you Eric, I wish there were a simple way to change some of the line widths*, especially airspace. I suppose a 'hack' would look something like: Turn off LayerAirspaces and LayerILSs, redraw with something more powerful than XML, and superimpose.

Someone might have done this already. Dunno. There's an interesting "Graphical representation of the Airspace (Boundary)" discussion here that you might want to take a look at. ILSs would be even simpler.

Bob

* in addition to Rose, FlightPlan and Approach that already have line width gps vars

 

[eric_marciano]

The hack I was thinking about is much simpler: find the pen definition used to draw these lines and change the thickness value from 3 to 1. Easier said than done...

The complexity is in finding this line width value, it requires "decompiling" the DLL and find the code involved (which I think is impossible) or analyse the generated machine code language to find this value. This requires an expertise that I don't have...

 

[eric_marciano]

Bob, I think your link is wrong because it redirects to this page
Anyway, I already thought about your idea to draw the moving map better than what the GPS does. I created a moving map that uses the same symbols as the paper VFR charts every pilot knows (I developed this some years ago and never released it, I will try to find some screenshots to show you).
It was working fine, but... I had some issues:
1) I couldn't find the way to draw the airspace boundaries (even using your great GPS guide, I couldn't make it)
2) I don't have any map/terrain background the draw. To solve this, I used the map/terrain GPS display but again I had issues:
- The map refresh was strange because my GDI+ drawn symbols for airports, navaid, intersections... were refreshed at each cycle (approx 18 times a second) while the map/terrain background is only refreshed 1 time per second approx. This is especially strange when turning.
- My GDI+ drawn symbols cannot be transparent to be drawn on top of the map/terrain background. In fact, I was lucky because I could superimpose the XML-based background and my GDI+ based gauge and it was working fine almost all the time. I said almost, not always...

EDIT: I found old screenshots, quicker than expected

Global display with terrain background and some traffic:

Same display with GPS map instead of terrain:

Zoomed view with my moving map in an undocked panel window:
(I like it because it shows airport runway details when zoom factor is big enough)

 

[rpmc]

Apologies for the bad link. This is the correct one.

The reason I found that interesting is that it talks about drawing an airspace boundary:

"Airspaces represented graphically in the map of FSX have this structure.
Excerpt from the SDK:

BoundaryStart
This element is used to indicate the start of a Boundary volume. This element is not allowed to contain other data and must be terminated with ‘/>’.

<BoundaryStart
lat="41.45240683"
lon="-87.01929230"
minimumAltitudeType = "UNLIMITED"
altitudeMinimum="235.00079346"
maximumAltitudeType = "UNKNOWN"
altitudeMaximum="240.00079346"/>"

To me, this is very important as it indicates you can access the airspace boundary data, so then the need is for a method to draw lines connecting all of the boundary points. ILS arrows would be even simpler since the 'cone width' is a function of runway length and the length of the arrow can be made to please the eye according to zoom.

What I didn't realize, however, is that the GDI on top of CustomDraw terrain overlay idea wouldn't work. That's a shame. Same limitation using C++? My presumption out of the gate was that decompiling the gps.dll to change line width was technically impossible, a non-starter, and a violation of the EULA. So, even if one could pull that off, Arno wouldn't let you post it in this website.

Refresh rates ... yeah, the CustomDraw map doesn't refresh as fast as you might want. Did you try experimenting with Priority, MapLoading and UpdateAlways parameters? I never fully understood those.

I seem to remember an earlier thread of yours showing your custom symbols. Really like it.

Bob

 

[eric_marciano]

Yes, you're right, the images of my Moving Map shown here are the result of a discussion I had with some members of this forum, maybe you were part of them, to understand the fs9 and FSX projection systems to make sure my symbols were correctly positioned on the map.

My Moving Map is coded in C++ using GDI+, it is nicely drawn with anti-aliasing and it is very fast, so it can easily redraw at each refresh cycle. Drawing GDI+ graphics with C++ on top of the GPS map is difficult but it should work with FSX Acceleration and later (FSX SE, P3D, ...) because of the drawing flag that was added in FSX Acceleration for the F/A-18 HUD (the flag is IMAGE_ALWAYS_ERASE or something similar). I think it would work, but the refresh rate problem would still be there. I don't think any variable can make the GPS redraw faster. I am sure the Microsoft developers did this to avoid consuming too much CPU power. If the GPS takes 18 cycles to redraw each second, it doesn't need much CPU...

I had a quick look at the corrected link about the airspace boundaries. I also found interesting info about this, but I couldn't find how the polygons are defined, so I don't know how to draw them. AFAIK the discussion that you pointed doesn't help on this regard.

 

[rpmc]

AFAIK the discussion that you pointed doesn't help on this regard.

Bummer.