- EICAS implementation: I noticed that you used bits to drive the screen. I wanted to add another screen, but bits aren't my strongest parts in C++. Also, I don't know how the shifting is actually done. I know that you change the vortices (IIRC), but how this is being done?
- Mesh implementation: I want to add a speed brake, but I don't know anything about how to do this in the mesh.
- DVC implementation: I never understood how the switches rotation axis is set. Get Vector Tool in 3ds Max sometimes gives wrong results.
The EICAS panels are driven by moving the UV coordinates of the four vertices cornering each screen across the large single image that's used to render all possible screens.
That means that if you have two panels showing the same screen, they will do so simply by shifting their textures to show that part of the image. The draw code for the panels then runs only once per frame, even if all 6 displays are set to show the same screen.
This is where the bit-mask comes in. Each screen is numbered in reading order from the top left as they appear in VC_EICAS_SRC.bmp
Most of the relevant code for this is in G422_DVC_DISPLAYS.cpp
There, you'll find a "drawEicas" variable which is used to determine what screens need to be redrawn according to how panels are configured.
This is set up such that each bit of that integer represents one of the 12 possible screens. With 32 bits, there is room to spare.
G422::selEicasMode also does the shifting of the 4 vertices in the given panel mesh object to line up with the corresponding screen for the required "mode", it is a simple matter of dividing modes 1~12 into 3 rows with 4 columns.
There is no "mode zero" as in order to tell that a panel is turned off, the selected mode value for that panel is turned negative. That way we can recall it back to life without need for a separate variable (remember, I made this ship as a C++ learning exercise)
In that same function, we set "drawEicas" by shifting 1 with this mode index of each screen "(1 << mode)". The bit for each mode is thus toggled on or off so that it can be checked on the draw function below. (see bottom few lines of function)
Code:
// disable redraw on invisible pages
//
drawEicas |= (1 << mode); // set bit at position corresponding to the given mode
if (lMode < 0) return; // the rest if this is irrelevant when toggling screens ON from formerly OFF state
for (int i = 0; i<6; i++) // check if any of the 6 panels are still displaying the page that was just closed
{
if (VC_eicas_screens[i] == lMode) return; // stop here if any are found
}
// otherwise, flag disused page OFF so it doesn't go on redrawing while invisible
drawEicas &= ~(1 << lMode);
G422::clbkVCRedrawEvent then checks each bit of drawEicas every frame, thus deciding whether or not it needs to bother drawing the screen whose mode index corresponds to that bit.
This is just to we don't go drawing screens when no panels are set to show them
--
As for adding a new screen mode, it'd be difficult. There are 12 modes because this is the number that would best fit inside the square single image where they are drawn...
Not all the modes had been actually implemented though - So that half of them at least had been mostly ornamental, last I checked... You could perhaps edit one of those unused screens to whatever you were thinking of adding maybe?
What is it you wished to add? I could point you in the direction most in line with the original design philosophy for the G42-200 if I knew what it was.
--
Now, adding speedbrakes.... The mesh has no panels modeled for this purpose - I think I meant to have the inboard aileron panels split apart, like in the A-10 Warthog. Or maybe the rudder would split in the same way, like the Shuttle did - Possibly both even.
I can't recall whether anything about this was done in the model - But looking at the center console, there is indeed a lever to control these.
I think I hadn't actually began on modeling that - but it was definitely meant to be done by splitting the control surfaces apart rather than by having separate panels open just for that
--
As for the VC switch rotation axis: They all rotate around X, have you noticed? I never got around implementing any of the switches that would turn in any other direction. - So it's just good old {1f, 0f, 0f} "red arrow X" for all switches that can currently be flipped.
I had meant to do this at some point, however. And there were measures taken to allow for this.
Specifically, the _X constant at the end of each entry defines the pivot axis for each of the switches (as seen in G422_DVC_SETUP.cpp):
Code:
{ MGID_SW3_APU_HYD, SW3_MID, _V(0.0145013, 2.18092, 38.5786), _V(0.00857984, 2.16485, 38.576), _X },
should you replace this with another vector, ("_V(x,y,z)" instead of "_X") the given switch would then pivot around that axis when flipped.
Cheers
But i've got CTD when trying to use BaseSync in the VC. As there are things to do i the VC for this kind of task (engines set up, wings, etc), it could be tricky in 2D cockpit :hmm:. Yes, all modules work in 2D panels. Does anyone know something about this ? I'm using the latest version of BaseSync and MM. Thank you !
