MDU/IDP coding

[Urwumpe]

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.

I suggest, we use StretchBlt as little as possible - for example we scale the font bitmap only once during creation before we use it for drawing.

 

[SiameseCat]

I suggest, we use StretchBlt as little as possible - for example we scale the font bitmap only once during creation before we use it for drawing.

The problem is, I'm loading the bitmap at startup and then creating a DC compatible with the MFD each time the MFD is updated. I'm not sure if there's a way to resize the bitmap without loading it into a DC first.

 

[SiameseCat]

I've managed to get it working with a decent framerate, but it still needs the HALFTONE Blt mode, which will prevent SSU from being used on Windows98 and WindowsME.

 

[Urwumpe]

Looks good

 

[SiameseCat]

I've uploaded the drawing code to sourceforge. I also removed the yellow lines between the letters from DEU_Raw.bmp, since they were appearing around when blitted into the DC.

Also, how should the Paint function be called? At the moment a single MDU is created in the constructor and used by all instances of CRT MFD.

 

[Urwumpe]

I've uploaded the drawing code to sourceforge. I also removed the yellow lines between the letters from DEU_Raw.bmp, since they were appearing around when blitted into the DC.

Also, how should the Paint function be called? At the moment a single MDU is created in the constructor and used by all instances of CRT MFD.

The MFD would get the MDU ID of the connected MDU during it's creation and be able to get the pointer to the MDU object by calling Atlantis::GetMDU(unsigned short usMDUID)

With that, you could call Paint.

Theoretically we could bypass the MDUID in creation and directly give the pointer to the MDU, but I think the MDUID is more secure when loading/saving scenarios.

 

[SiameseCat]

Okay. Is it a problem for you to implement the DPS screens as IDP software objects? I wanted to do it that way, so we can manage the actual software configuration in a easy way (just load different programs and tables).

At the moment, each DPS screen is drawn by a function in the MDU class. It shouldn't be difficult to move these functions to the IDP class, if that's what you want. For managing software configuartion, the best thing to do might be to have a separate class for each software configuration containing functions for all the available DPS displays.

 

[Urwumpe]

For managing software configuartion, the best thing to do might be to have a separate class for each software configuration containing functions for all the available DPS displays.

Would also be a good alternative design. We should just be able to reuse as many displays and related functions as possible.

 

[SiameseCat]

Would also be a good alternative design. We should just be able to reuse as many displays and related functions as possible.

How about this: each class contains an array of function pointers. For each display (SPEC 0, 1, 2..) the array has a pointer to the associated drawing function. We can use a similar method to handle data input (has opposed to one, MASSIVE function).

 

[Urwumpe]

How about this: each class contains an array of function pointers. For each display (SPEC 0, 1, 2..) the array has a pointer to the associated drawing function. We can use a similar method to handle data input (has opposed to one, MASSIVE function).

Yes, that was the plan for me, a hash table of OPS numbers and a hash table of SPEC/DISP numbers, all also for the three major functions. Each entry pointing to a function.

 

[SiameseCat]

I've copied a few posts from the 'CTD with latest rev of CRTMFD' thread here.

I'm currently working on the functions discussed above. I've rewritten the IDPSoftware class to hold functions for updating the display and processing keyboard input. Each software load will have its own cpp file containing the different IDPSoftware classes. Any comments?

 

[Urwumpe]

I've copied a few posts from the 'CTD with latest rev of CRTMFD' thread here.

I'm currently working on the functions discussed above. I've rewritten the IDPSoftware class to hold functions for updating the display and processing keyboard input. Each software load will have its own cpp file containing the different IDPSoftware classes. Any comments?

Is OK for me, but maybe name the files IDP_xxxxx for knowing that it is related to the IDP. Important for me is, that software can get reused as good as possible... the MNVR displays for example are having only small changes, so it should be possible to refer to a generic MNVR base.

 

[SiameseCat]

We can use generic base classes for that. These should probably have their own file.


-----Posted Added-----


How should the classes access private Atlantis variables?
Most of the Atlantis variables will have to be available for display and/or editing. I don't want to make them all public, and I don't want to have to declare all the display classes as friends of Atlantis.
EDIT: Maybe we can have a DataBus class with functions providing access to all the relevant data members. Comments?