MDU/IDP coding

[SiameseCat]

I'm planning to start changing CRT MFD to use the MDU to get display information. I think the best way to do this is to have an array of strings in the MDU. Each string will contain the output for one line on the MFD. Any comments?

 

[Urwumpe]

I'm planning to start changing CRT MFD to use the MDU to get display information. I think the best way to do this is to have an array of strings in the MDU. Each string will contain the output for one line on the MFD. Any comments?

I thought about storing the DPS data as an array of shorts as most data is integer with engineering units used for conversion. But I could also allow formating the data already inside the IDP. Would 128 outputs be enough or better 256 as limit?

For getting the connected MDU, you can use a function of Atlantis soon (MDU* Atlantis::GetMDU(unsigned short usMDUID)). We could also publish the mdu array, but this way we can also have error checking.

An alternative would be creating a font bitmap for the MFD and transfer the text buffer directly to the MFD surface.

 

[SiameseCat]

I thought about storing the DPS data as an array of shorts as most data is integer with engineering units used for conversion. But I could also allow formating the data already inside the IDP. Would 128 outputs be enough or better 256 as limit?

For getting the connected MDU, you can use a function of Atlantis soon (MDU* Atlantis::GetMDU(unsigned short usMDUID)). We could also publish the mdu array, but this way we can also have error checking.

An alternative would be creating a font bitmap for the MFD and transfer the text buffer directly to the MFD surface.

I'm planning to store the text in the array, along with the actual numbers, so 256 would probably be better. One potential problem with this could be displaying the delta and theta symbols. At the moment, I use functions in CRT MFD to do this, but this could be difficult from the MDU.

 

[Urwumpe]

I'm planning to store the text in the array, along with the actual numbers, so 256 would probably be better. One potential problem with this could be displaying the delta and theta symbols. At the moment, I use functions in CRT MFD to do this, but this could be difficult from the MDU.

Then, why don't we try using a font bitmap? I have the character table of the real DEU around here (was in the HAL-S docs), which is pretty similar to ANSI and ASCI. Would just take some moments. We could also solve the scale problem (different MFD sizes) by using StretchBlt once for creating a scaled copy of the original font map.

When we already have a character based drawing of the text, we could also just pass the whole text buffer and do the printing of text inside the MDU. :lol:

 

[SiameseCat]

Then, why don't we try using a font bitmap? I have the character table of the real DEU around here (was in the HAL-S docs), which is pretty similar to ANSI and ASCI. Would just take some moments. We could also solve the scale problem (different MFD sizes) by using StretchBlt once for creating a scaled copy of the original font map.

When we already have a character based drawing of the text, we could also just pass the whole text buffer and do the printing of text inside the MDU. :lol:

That might be a good idea. We could create the bitmap in the MDU and then pass it to CRT MFD, which could StretchBlt it into the HDC.

 

[Urwumpe]

That might be a good idea. We could create the bitmap in the MDU and then pass it to CRT MFD, which could StretchBlt it into the HDC.

Yes, but I think stretchBlting the font bitmap when creating the MFD will be more effective.

Well, can test. I personally would prefer keeping the rendering in the MFD for a moment longer, but i have no rational reason for it except "We already do it like that."

 

[SiameseCat]

Here's a suggested implemetation:

The MDU class already has a Paint() function. CRT MFD will pass an HDC to this function and the MDU will draw the output on the HDC. The MFD will then StretchBlt this HDC into the MFD's display HDC.

The Paint() function:
The MDU class has a textbuffer array. The data in this array will be printed onto the HDC, with appropriate formatting. The array will be updated at the MDU data refresh rate.

SC

 

[Urwumpe]

Here's a suggested implemetation:

The MDU class already has a Paint() function. CRT MFD will pass an HDC to this function and the MDU will draw the output on the HDC. The MFD will then StretchBlt this HDC into the MFD's display HDC.

The Paint() function:
The MDU class has a textbuffer array. The data in this array will be printed onto the HDC, with appropriate formatting. The array will be updated at the MDU data refresh rate.

Yes, thats the stuff I initially had dumped into the classes, but I would suggest some changes for speed and quality:

We draw directly on the HDC given by orbiter to the MFD. Scaling happens internally in the calculations. Alternatively, we draw on a backbuffer, which we can copy without scaling or reformatting.

Text buffer formatting: Known attributes are underlined, overlined, flashing, normal, bright and overbright.

Later, we can change the painting this way to draw on a dynamic texture of more than 256x256 pixels.

 

[Donamy]

let me know if you need any screens textured.

 

[Urwumpe]

let me know if you need any screens textured.

Do you have any plans in December?

I think we will keep the MFD rendering as standard for one or two versions.

 

[SiameseCat]

How are we going to store symbols (i.e. theta and delta) in the text buffer?

I'm planning to create a function in the MDU class to update the text buffer. For the moment, the IDP will be bypassed and the MDU will get MM information, etc. directly from the sts pointer.

 

[Urwumpe]

How are we going to store symbols (i.e. theta and delta) in the text buffer?

I'm planning to create a function in the MDU class to update the text buffer. For the moment, the IDP will be bypassed and the MDU will get MM information, etc. directly from the sts pointer.

The mathematical symbols in the DEU character set are placed between the alphanumeric ASCII characters. For example, Delta is 0x7F.

No problem with that first move, we can remove this once the IDPs work.

I would just suggest using the standard format of the DPS header lines for all major modes, the data displayed is quite important later for the IDP/GPC interface debugging.

 

[SiameseCat]

Does any one know what kind of font the MDUs use? Also, how often do they update the data?

 

[Urwumpe]

Does any one know what kind of font the MDUs use? Also, how often do they update the data?

The font seems to be a typical system font, the CRT was initially vector based, instead of pixel based, the MDU only mimics this.

This is the char set of the DEU, which effectively also used in the DPS window of the MDU:

We could turn this table into a number of bitmaps and blit each char on the screen.

The updating of data is not known to me, but the critical data inside the GPCs gets updated around 12.5 times per second max, most data only once per second.

So, it is unlikely the DPS display updates it's data faster.

 

[SiameseCat]

Here's the best font I've been able to create so far:

Its not too bad, but I can't say I'm particularly pleased with it. Does anyone want to try creating bitmaps to use for the font?

 

[Urwumpe]

Here's the best font I've been able to create so far:
Its not too bad, but I can't say I'm particularly pleased with it. Does anyone want to try creating bitmaps to use for the font?

I can give it a try, I am already delaying doing this for weeks.

 

[Urwumpe]

Can somebody confirm that the correct behavior of a major function transition is like that:

The transition to a new major function happens when you do a manual transition to a new major mode. Changing the switch position has no effect until the next manual major mode transition.

It is not very clearly explained in both versions of the SCOM, I have, but the checklists seem to fit. Does somebody have another source of information to check this?

If the behavior is like that, the IDP is responsible alone for telling the GPC which major mode and major function it should use.

 

[SiameseCat]

I've gotten a working version of the UNIV PTG display with the blitting (from DEU_Raw) to the HDC. The problem is that it causes a noticeable framerate hit at high MFD refresh rates. I'm using BitBlt to transfer the characters to a temporary HDC, than using StretchBlt to copy the HDC to the MFD HDC.

 

[Urwumpe]

I've gotten a working version of the UNIV PTG display with the blitting (from DEU_Raw) to the HDC. The problem is that it causes a noticeable framerate hit at high MFD refresh rates. I'm using BitBlt to transfer the characters to a temporary HDC, than using StretchBlt to copy the HDC to the MFD HDC.

Ok, that should be addressed first, if the framerate hit is too high.

 

[SiameseCat]

I've traced the framerate slowdown to the StretchBlt call. The code currently uses the HALFTONE StretchBlt mode, which is very slow (and, as it turns out, is only supported in WindowsXP and Vista). Unfortunately, none of the other modes seem to produce satisfactory results.