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'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'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.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.
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.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.
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.
let me know if you need any screens textured.
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.
Does any one know what kind of font the MDUs use? Also, how often do they update the data?
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'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.