Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support the MSFS SDK #304

Open
nakajimayoshi opened this issue Dec 20, 2022 · 2 comments
Open

Support the MSFS SDK #304

nakajimayoshi opened this issue Dec 20, 2022 · 2 comments

Comments

@nakajimayoshi
Copy link

nakajimayoshi commented Dec 20, 2022

Please include the following information in your issue:

  1. Which version of units you are using
    2.3.3

  2. Which compiler exhibited the problem (including compiler version)
    VSC 2022

My earlier issue led me to investigate more and I found that the issue was related to a self-defined function, not the units library . However, upon further investigation I found that the units library has macro clashes with the target architecture (MSFS).

Background

Microsoft Flight Simulator 2020 is the latest iteration of the decades long Microsoft Flight Simulator series and an extremely diverse program with thousands of different tools and ways to conduct real-life aero simulations. MSFS recently released a variety of tools, namely building Web Assembly modules using C/C that can do anything from rendering displays, drawing 2d vector graphics, and calculating system inputs and outputs (e.g. battery voltage and current).

Problem

When writing these modules, we cannot use standard architecture targets like x64 and x86, but rather an Asobo developed toolset which leverages the MSFS SDK. This architecture is specifically designed to compile C/C to a .wasm binary rather than a common architecture, ensuring compatibility with a variety of systems as well as Xbox where the simulator is also available. I've explored other C unit libraries, but I am a proponent of this one despite the incompatibilities for three reasons:

  • Single header include
  • No external dependencies
  • optional usage of units in type declarations rather than forced literals

We'd like to guarantee type safety and strict adherence to dimensional analysis for recreating large and complex aircraft systems, but as of now I'm afraid there are no C libraries out there that support the C WASM framework published by Microsoft and Asobo.

Solution/info

Fortunately this seems to be an easily fixable problem, mostly related to the min() macro invoked on line 2065 of the header file

	detail::abs(nls::m_value - units::convert<UnitsRhs, Units>(rhs.m_value)) < std::numeric_limits<T>::min()

I've provided a screenshot of the error list below, as well as a link to download the latest version of the MSFS SDK if you'd like to try it. I will provide updates as I attempt to fix the library to support the architecture.

image
MRE:

#include "units.h"

class MainBattery {
public:
    auto getPower() -> units::power::watt_t;
};

auto MainBattery::getPower() -> units::power::watt_t {
	return static_cast<units::power::watt_t>(0.);
};

MSFS SDK Installer
SDK Documentation

@nakajimayoshi nakajimayoshi changed the title Support MSFS SDK Support the MSFS SDK Dec 20, 2022
@ts826848
Copy link
Contributor

ts826848 commented Jan 12, 2023

This smells like an issue due to <Windows.h> and/or <windef.h> defining min and max macros, which conflict with functions of the same name. If the issue is indeed the same, you'd get similar errors if you include <algorithm> or <limits>. I admittedly have not tried installing the SDK, so I can't say for sure whether that's the actual reason.

Is defining NOMINMAX before including anything that includes <windows.h> possible, or would that break something else?

@nakajimayoshi
Copy link
Author

nakajimayoshi commented Feb 16, 2023

Defining NOMINMAX isn't possible, as it would break the program, but I was able to get around the issue by renaming the min and max macros in Windows.h to minimum and maximum

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants