Increasing the MFD/HUD refresh rate on the F/A-18

[virtuali]

A tip to discuss a feature that probably wasn't noticed by everyone:

Everybody knows that the F/A-18 has a very smooth moving instrumentation and HUD. But, not everyone knows that is LIMITING ITSELF! It's actually capable of even smoother fps, but the default setting is a little bit conservative, in order not to have the airplane instrumentation risking to impact the scenery fps on lower-end machines.

BUT, there's a setting that allows you to control the refresh rate of the glass instrumentation (the 3 MFD's and the HUD), and if your machine is capable enough and if you are flying in an area were the fps is good, like over the sea, were the F/A-18 is supposed to operate mostly, you can enjoy even smoother instrumentation. Once you try the HUD at 60 fps, you'll not want to use anything else...

To access this setting, do the following:

- Go to the Top page, by pressing "MENU" from any page

- Select "BIT" (Built-in-Test, it's a key on the top)

- Select "GDI+ (on the low-right)

A screen with several options will appear, the most interesting is the "Refresh Rate" slider. By default, is set to 3, this can be checked by looking at the "REF3" soft-key option.

Pressing the "REF3" key, will change the refresh rate from 1 to 5. If you set it to 5, the refresh rate of the instruments will not be limited anymore, allowing to get an 1:1 refresh with the screen fps.

With the refresh rate set at 5, if your PC is able to fly at, let's say 60 fps on a certain area, the most important instruments, which are the HSI and the HUD (the F/A-18 has adaptive refresh rates for every instrument and for every different page of the MFD), will refresh at 60 hz too!

[Razgriz]

I knew it seemed a bit jerky, thanks!

[virtuali]

As I've said, you are not supposed to use it where your frame rate is low already.

Doing this, you are only worsening the situation because, it's obviously not a miracle fps enhancer. If your PC is already struggling to draw the scenery, increasing the refresh rate of the instruments will make things worse.

THAT'S why is NOT the default setting.

BUT, if you have horsepower to spare, and the scenery is not taking too much machine cycles, is possible to afford increasing the slider, and enjoy the instrumentation even smoother than already it is. I'd say it makes sense to use it when your fps are higher than 40-50 at least, which should be relatively easy to reach over sparse areas and over the ocean.

[wilycoyote4]

Tried it, nice, thanks, the technology of the VC continues to amaze me.  Yes, there is a fps loss but under certain conditions it is great to be at 5, or 4 for that matter.

[Razgriz]

As I've said, you are not supposed to use it where your frame rate is low already.

Doing this, you are only worsening the situation because, it's obviously not a miracle fps enhancer. If your PC is already struggling to draw the scenery, increasing the refresh rate of the instruments will make things worse.

THAT'S why is NOT the default setting.

BUT, if you have horsepower to spare, and the scenery is not taking too much machine cycles, is possible to afford increasing the slider, and enjoy the instrumentation even smoother than already it is. I'd say it makes sense to use it when your fps are higher than 40-50 at least, which should be relatively easy to reach over sparse areas and over the ocean.

I have 30FPS at NYC with it.

[virtuali]

I have 30FPS at NYC with it.

Which is good for NYC, but still not enough to afford to increase the refresh rate of the instruments because, if you put it at 5, you'll start to impact into the 30 fps, and that would become noticeable. If you, instead, are running at 50, and you maybe lose 3-4 fps by going from 3 to 5 refresh, the instruments will still give you a very nice to look at 47 fps refresh.

The absolute ideal smoothness would be reaching 60 fps with the refresh at 5, and VSync active, so you'll have the refresh rate for both instruments and scenery exactly synched the monitor refresh, without any tearing effects.

[172gb]

Please forgive my ignorance but where is the "menu" and "page" you're referring to?  Is it in the sim?

[virtuali]

On any of the 3 MFD screens, there's a MENU option, that will return to the top MENU. I suggest to download THIS file here:

http://www.fsdreamteam.com/forum/index.php?topic=249.0

To understand how the menus are structured in the F-A/18 MFDs.

[cfschris]

Hey is it possible to edit the .cfg in a way to always have the refresh rate at maximum? I have a very high end machine, and itd be nice if I didnt have to go into the BIT menu and change this every flight.

[JamesChams]

Virtuali,
I have two main questions (with sub-parts) about this:-

1. If users are able to alter this refresh rate, are these user selectable options ...
a). ...saved in a "state file" for future use/reloads somewhere (.xml/.txt file)?
b). ...just on the fly & need to be modified each time; therefore, can you grant permission to alter this for the former ability?

2. When clicking any of the OSB keys on the MFD's (DDI's) in the VC model some function is being implemented with identifier, parameters, variables within the .mdl files that are externally exchanged with the .dll gauge files, ...
a). ...what might those be?  Do you have a map/list, perhaps somewhere in the SDK, which list those labels, tags, etc. from the .mdl's functions?
b). ...I guess what I'm asking for is the ability to intercept the push buttons of the DDI's in order to implement added functionality?

Since MS no longer supports FSX will this still be intellectual prosperity at all, without upsetting EULA?  Not a GMAX modeler (at least not right now during this post) but attempting something and could use some FREE advise.

Ciao

[virtuali]

a). ...saved in a "state file" for future use/reloads somewhere (.xml/.txt file)?

No, they aren't

b). ...just on the fly & need to be modified each time; therefore, can you grant permission to alter this for the former ability?

Well, I can't grant any permission about anything on the F/A-18, because it never was our own IP property, it's always been MS property, that's why we couldn't release any "patches" or other fixes as FSDT, it would always go through MS. It's likely (but we don't have any knowledge about this) the F/A-18 rights hasn't even been sold to LM, since it's not included in P3D. Not that I find likely that LM would want to include a Boeing airplane in their own product...

a). ...what might those be?  Do you have a map/list, perhaps somewhere in the SDK, which list those labels, tags, etc. from the .mdl's functions?

That's actually fairly easy: we used custom events, if you look in the modeldef.xml file that comes with the Acceleration SDK, many events have an hex code rather than a name, such as this one for example:


  <PartInfo>
    <Name>switch_guard_fire_r</Name>
    <AnimLength>100</AnimLength>
    <Animation>
      <Parameter>
        <Code>
          (L:switch_guard_fire_r,number) 100 *
        </Code>
        <Lag>400</Lag>
      </Parameter>
    </Animation>
    <MouseRect>
      <Cursor>Hand</Cursor>
      <MouseFlags>LeftSingle</MouseFlags>
      <EventID>0x00011004</EventID>
    </MouseRect>
  </PartInfo>


This means, when you press the button of the left fire prevention guard switch in the F/A-18 model, an 0x00011004 event code will be generated. It will then be your own Gauge task to INTERCEPT that code, and do something.

b). ...I guess what I'm asking for is the ability to intercept the push buttons of the DDI's in order to implement added functionality?

You surely can do that, but you'll have to replace the whole DDI code with a new gauge you write, you can just add new features or pages to the exiting one. If you are prepared to rewrite the DDI code from scratch, then yes, creating new features it's surely feasible, same as others have replaced the HUD.

Since MS no longer supports FSX will this still be intellectual prosperity at all, without upsetting EULA?  Not a GMAX modeler (at least not right now during this post) but attempting something and could use some FREE advise.

If you replace the Gauges with your own, there's are IP issues whatsoever, and the information about custom events and their codes is already disclosed in the clear in the modeldef.xml file that comes with the SDK, which means products based on THAT information are explicitly allowed by the SDK EULA, as long as you don't distribute code from MS, but only use the information provided in the SDK to create your own work.

[Orion]

I posted a thread about this before but didn't get a response: is it possible to release updates that use delta encoding, which only includes the changed parts of the file?

[virtuali]

I posted a thread about this before but didn't get a response: is it possible to release updates that use delta encoding, which only includes the changed parts of the file?

The whole underlying issue has been already answered long ago, we don't have a complete F/A-18 model source ourselves: MS made some changes in the end, like adding the internal wing views and other small things, and they also changed something in the gauge code, probably to match such modifications they did to the .MDL.

Since we were never given back the source code for the released version (we never had any right to ask for it), what would come out as a "delta", would be something that would "downgrade" the model to an earlier version compared to the released one, a mix-up between what we gave to MS, with some eventual modifications added, and I don't even want to *begin* to think about possible legal ramifications of such distribution, because it would be a new binary obtained by delta patching of a binary compiled from pre-released source code covered by nda, any IP lawyer will go crazy about this, assuming he'll UNDERSTAND what really means...and that's not something we have the slightest intention to discover.

[JamesChams]

a). ...what might those be?  Do you have a map/list, perhaps somewhere in the SDK, which list those labels, tags, etc. from the .mdl's functions?

That's actually fairly easy: we used custom events, if you look in the modeldef.xml file that comes with the Acceleration SDK, many events have an hex code rather than a name, such as this one for example:


  <PartInfo>
    <Name>switch_guard_fire_r</Name>
    <AnimLength>100</AnimLength>
    <Animation>
      <Parameter>
        <Code>
          (L:switch_guard_fire_r,number) 100 *
        </Code>
        <Lag>400</Lag>
      </Parameter>
    </Animation>
    <MouseRect>
      <Cursor>Hand</Cursor>
      <MouseFlags>LeftSingle</MouseFlags>
      <EventID>0x00011004</EventID>
    </MouseRect>
  </PartInfo>


This means, when you press the button of the left fire prevention guard switch in the F/A-18 model, an 0x00011004 event code will be generated. It will then be your own Gauge task to INTERCEPT that code, and do something.

Yes, this is what I was looking for...  Thank you!

b). ...I guess what I'm asking for is the ability to intercept the push buttons of the DDI's in order to implement added functionality?

You surely can do that, but you'll have to replace the whole DDI code with a new gauge you write, you can just add new features or pages to the exiting one. If you are prepared to rewrite the DDI code from scratch, then yes, creating new features it's surely feasible, same as others have replaced the HUD.

I was able to locate the (e.g. DDI_x_btn00x) and see the implementations.  Of course, many of their internal functionality in C/C++ is hidden within your .gau files but that doesn't necessarily matter if a complete re-write is necessary.

However, I do have other questions regarding your specific implementation of the AI traffic within the function of the DDI's.  As I recall (correct me if I not, cause its been quite a while since I looked at this capability specifically), the gauges are able to see AI in both AWAKE, SLEEP and In_Air, On_Ground or On_Sea  modes, Correct?  I've been studying the ITraffic implementation within the SDK and I want to verify/clarify what the XML and C implementations permit, certain features that allow for correct segregation of AI types and states/mode that they are in.  Any clarification of your implementation are/are-not within the .gau files (without breaking trade secrets) would be helpful and appreciated.

Since MS no longer supports FSX will this still be intellectual prosperity at all, without upsetting EULA?  Not a GMAX modeler (at least not right now during this post) but attempting something and could use some FREE advise.

If you replace the Gauges with your own, there's are IP issues whatsoever, and the information about custom events and their codes is already disclosed in the clear in the modeldef.xml file that comes with the SDK, which means products based on THAT information are explicitly allowed by the SDK EULA, as long as you don't distribute code from MS, but only use the information provided in the SDK to create your own work.

OK, just to clarify (in case I'm seeing a typo), there are NO IP issues, right?  Also, this begs another question, if I use both the existing gauge in-place while intercepting the OSB's event ID while having another gauge (invisible) do something with it and then pass that along to your DDI gauge instead of what the .gau currently operates, does that also break the IP?   This is more to know about boundary/capability limitations for FSX as well as legally defined with in the EULA.  I see some developers user your gauges within their models but I'm not sure to what end it is yours and what is theirs.
 
Grazie! 

[virtuali]

However, I do have other questions regarding your specific implementation of the AI traffic within the function of the DDI's.  As I recall (correct me if I not, cause its been quite a while since I looked at this capability specifically), the gauges are able to see AI in both AWAKE, SLEEP and In_Air, On_Ground or On_Sea  modes, Correct?  I've been studying the ITraffic implementation within the SDK and I want to verify/clarify what the XML and C implementations permit, certain features that allow for correct segregation of AI types and states/mode that they are in.  Any clarification of your implementation are/are-not within the .gau files (without breaking trade secrets) would be helpful and appreciated.

There's nothing "specific" we did when reading AI states. Everything it's done 100% according to Simconnect specifications, so there's no need to repeat here what you can surely find in the FSX SDK.

OK, just to clarify (in case I'm seeing a typo), there are NO IP issues, right?

Yes, of course it was a typo.

Also, this begs another question, if I use both the existing gauge in-place while intercepting the OSB's event ID while having another gauge (invisible) do something with it and then pass that along to your DDI gauge instead of what the .gau currently operates, does that also break the IP?

Apart for the absurdity of doing it that way (I don't think it will really work, since you'll have to "fight" against the original gauge code to set the variables), I think my first reply was clear enough: you can do whatever you want, provided you DO NOT DISTRIBUTE ANY MS CODE IN ANOTHER PRODUCT.

But of course, anything I write here doesn't have any legal base whatsoever, since (as I've said, quite clearly) I do not own ANY of the F-A/18 IP anymore, if a Microsoft lawyer comes knocking to your door, don't expect to justify yourself with "Virtuali, the developer, told me it's ok", because even if I was the developer, I don't own such IP anymore because it has been bought by Microsoft long ago, so I don't have any power to allow/disallow anything about it, that's just my personal interpretation of the SDK EULA.