RenderTarget2D creation issue on macOS about fna3d

[TheSpydog]

It looks correct on my machine. What hardware are you testing with?

[HybridBeasts]

We use two Mac Mini (2017 & 2018) for testing. Maybe the integrated Intel graphics are the problem? Are these not fully compatible with FNA? What machine are you using?

[TheSpydog]

Integrated graphics cards are definitely supported by FNA. I'm using a MacBook Pro 2016 with an Intel Iris Graphics 540.

Something I just found -- if I launch the game directly from Steam, everything renders as it should. If I run the executable manually with mono, it displays incorrectly, just like in your screenshot. Very odd.

@flibitijibibo Any ideas?

[flibitijibibo]

Does running it outside of Steam with the kick binary have any impact?

[TheSpydog]

Running with the kick binary looks the same as when running with mono. Interestingly, macOS is complaining that the .app "file" is malformed when I try to directly open it. Might be related...?

The application cannot be opened for an unexpected reason, error=Error Domain=NSOSStatusErrorDomain Code=-10827 "kLSNoExecutableErr: The executable is missing" UserInfo={_LSLine=3665, _LSFunction=_LSOpenStuffCallLocal}

[flibitijibibo]

I feel like it might be missing something important in Info.plist... the app being corrupt actually would explain weird issues since the base directory heavily depends on the app bundle's structure.

[HybridBeasts]

Well, this is the current Info.plist. I wonder how this could impact the tile rendering.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>CFBundleDevelopmentRegion</key>
    <string>en</string>
    <key>CFBundleExecutable</key>
    <string>HybridBeasts_FNA</string>
    <key>CFBundleIconFile</key>
    <string>HybridBeasts_FNA</string>
    <key>CFBundleIdentifier</key>
   <string>com.hybridbeasts.www</string>
    <key>CFBundleInfoDictionaryVersion</key>
    <string>6.0</string>
    <key>CFBundleName</key>
    <string>Hybrid Beasts</string>
    <key>CFBundlePackageType</key>
    <string>APPL</string>
    <key>CFBundleShortVersionString</key>
    <string>0.133.7</string>
    <key>CFBundleSignature</key>
    <string>????</string>
    <key>CFBundleVersion</key>
    <string>1</string>
    <key>LSApplicationCategoryType</key>
    <string>public.app-category.games</string>
    <key>LSMinimumSystemVersion</key>
    <string>10.6</string>
    <key>NSHumanReadableCopyright</key>
    <string>Copyright © 2020 BeastBits. All rights reserved.</string>
    <key>NSPrincipalClass</key>
    <string>NSApplication</string>
</dict>
</plist>

[HybridBeasts]

We just realized that (probably unrelated to that graphical issue) we are currently using the same plist files for the demo and the full version that start with differently named executable names (HybridBeasts_FNA = full, HybridBeasts_Demo = demo). The current plist file points to the executable name of the full version. Since these two version share all the data (and only differ in the executables), we probably would need two Info.plist files if possible (or we need to senselessly duplicate the game data on macOS).

[flibitijibibo]

The demo and full version should be different appids and depots to begin with, no?

[HybridBeasts]

The idea was to share an installation directory between demo and full version to prevent to need to re-download Hybrid Beasts when purchasing the full version after trying out the demo. The only difference really is the executable, 95% of the data (~800 MB) are the same.
On Windows and Linux it seems no problem having two executables in the same game directory.

[flibitijibibo]

Different platforms have different needs - I would strongly suggest splitting the executables out into separate depots and having the content be shared in a single depot, or using the Steamworks APIs to determine if the user owns the appid in question. Trying to sidestep the plist isn't going to happen.

[HybridBeasts]

Well, completely agreed. The plist issue for the demo will be fixed asap. However, since the plist is correct for the full version, and the graphical issue persists there, this is unlikely to be the cause of original issue?

[flibitijibibo]

An apitrace of both scenarios should be able to verify any differences between the two scenarios. I don't know how easy this is on macOS though, you may only be able to capture an instance outside of Steam (but that's what we care about anyway).

[HybridBeasts]

Integrated graphics cards are definitely supported by FNA. I'm using a MacBook Pro 2016 with an Intel Iris Graphics 540.

Something I just found -- if I launch the game directly from Steam, everything renders as it should. If I run the executable manually with mono, it displays incorrectly, just like in your screenshot. Very odd.

@flibitijibibo Any ideas?

The plist issue is now fixed. Interestingly, with an additional reinit of the rendertargets and by passing /gldevice:OpenGL as a launch argument, it now works when started directly from Steam. Do you still get the error when starting the game from outside Steam but using /gldevice:OpenGL as a launch argument ?

[TheSpydog]

Do you still get the error when starting the game from outside Steam but using /gldevice:OpenGL as a launch argument ?

The game works fine when launched outside of Steam using the OpenGL backend. I believe the Steam configuration for the game always forces OpenGL, which would explain why it has always worked for me when starting it with Steam.

I've found the bug with the FNA3D Metal backend, but it may take some time to fix. I should be able to get it working either by tonight or this weekend. But in the meantime, forcing the GL backend like you're already doing is a sufficient solution.

[HybridBeasts]

For us, using the GL backend is completely fine since we see not substancial difference in performance. Would you in general recommend using Metal on macOS?

[flibitijibibo]

Metal is nice to have, but you may want to have it as a separate launch option.

Depending on how Vulkan goes we may end up deprecating the direct Metal renderer in favor of MoltenVK, but we need to do a LOT of work on Vulkan first before we even start that assessment.

[TheSpydog]

Fixed by 1f7acd0.