Maybe start a new thread for this so we can dive into it more.
Does your minimal test project have models that would use the FbxImporter?
When you build in the Editor, are you still building as for WindowsStoreApp?
It seems like it’s loading Assimp64.dll from the wrong path, but in my nuget cache I see the DLL right there alongside the app.
I realized after I posted that I should have just started a new thread. I’ve just done so and will follow up there.
WindowsDX shouldn’t be targeting core 3.0, that is already out of support. It should be targeting 3.1 as it’s under long term support for the next 1.5 years. (well until .net 6 comes out)
It already is… I probably could have been more clear.
1 Like
I tried it on a Mac mini immediately after a clean installation of macOS 10.15.5 catalina.
I got two errors when compiling Content.mgcb with pipeline tools.
Instant solution (1)
I changed the file name.
Now everything works fine.
ln -s libassimp64.dylib libassimp.dylib
Instant solution (2)
I replaced it with freetype installed from homebrew.
Now everything works fine.
brew install freetype
mv libfreetype6.dylib libfreetype6.dylib.bak
ln -s /usr/local/lib/libfreetype.6.dylib libfreetype6.dylib
1 Like
Sup guys just a couple quick questions for those in the know - has the Microsoft.Xna.Framework.Input.KeyboardInput class deliberately been omitted from the Monogame.Framework.DesktopGL dll, only reason i ask is since the mg netstandard template includes the mg desktop GL framework by default; building a game for IOS and Android means “KeyboardInput” isnt accessible from the shared netstandard lib.
Alternatively I could reference the Monogame.Framework.Android (or IOS) dll which then leads me to my next question - what is the difference between the mg frameworks for Android and IOS
With monogame 3.8, i can compile effect files on mac!
The command line (dotnet tool run mgcb) works fine.
However, I cannot understand how to set the “MGFXC_WINE_PATH” environment variable in Visual Studio for Mac.
1 Like
Try echo "export MGFXC_WINE_PATH=$HOME/.winemonogame" >> ~/.zprofile
If you are asking how to set it up, and not just about vs for mac, you need to install wine64 and 7z, and than run the following script: https://github.com/MonoGame/MonoGame/blob/develop/Tools/MonoGame.Effect.Compiler/mgfxc_wine_setup.sh
Awesome news, a massive congrats to the team!
I have not had a chance to try it out yet but I am curious did DesktopGL get updated to OpenGL 4.6? It be really nice if that path was now on par with the DX11 support in MonoGame.
Anyways all the best and again a huge congrats to the team and I look forward to the PS5 and XBSX support with 3.8 down the road!
That’s… not how OpenGL works. If we did upgrade to a newer OpenGL, most older devices wouldn’t be able to run MonoGame and you would see no performance benefits. Like macOS doesn’t even support stuff past 3.3 at all.
I don’t think anything has been omitted. There’s no real pure interface layer for the netstandard shared library, but I think DesktopGL is commonly used because it’s the most neutral and most common of the packages. I think theoretically you could use any of the packages in your shared library, as long as you set <PrivateAssets>all</PrivateAssets> and avoid using platform-specific APIs.
The Android and iOS packages have lots of platform-specific code regarding graphics, inputs, sensors, etc., and they also have properties that instruct mgcb to build your content for their own platform.
1 Like
My project is currently based on Windows + DX11, I don’t work with OpenGL.
I was looking forward to a Switch port which I believe only supports OpenGL 4.5 and Vulkan so that is why I asked since MonoGame OpenGL is on 3.3. I don’t have a Switch Dev Kit yet and was thinking ahead in regards to the performance and porting issues going to the Switch.
My apology for asking ahead of time and not waiting till I had My Dev Kit.
Fantastic work team, spotted this accidentally while I was testing some other features the other week and now 've stumbled on the official update .
Happy testing / updating times ahead. Plus updating the samples again 
2 Likes
How do we make extensions for the content builder? I tried generating a project with dotnet new mgpipeline, but it doesn’t compile because it references two nuget packages v3.8 that doesn’t exist on nuget.
- MonoGame.Framework.Portable
- MonoGame.Framework.Content.Pipeline.Portable
Maybe that template wasn’t updated with the newest packages. Odd that it would have the new version but the wrong packages. I think you need to reference
- MonoGame.Framework.Content.Pipeline
- MonoGame.Framework.DesktopGL (as the portable package, like when you make a netstandard shared library; theoretically you’d want to set
<PrivateAssets>all</PrivateAssets>for this, but your pipeline extension project probably won’t be referenced by any published game, so it doesn’t matter in practice)
Looks like that fixed it, maybe the template should be updated? https://github.com/MonoGame/MonoGame/blob/develop/Templates/MonoGame.Templates.CSharp/content/MonoGame.Library.Pipeline.Extension.CSharp/MGNamespace.csproj
Another issue. I get a runtime exception when trying to build content with my extension. A System.PlatformNotSupportedException: Sysem.Drawing is not supported on this platform. is thrown when trying to invoke System.Drawing.Image.FromFile. This code worked fine in 3.7. Some of my assets are images (masks) that I convert to my game objects using the content extensions, being able to use System.Drawing helps me a lot. I had to to import the package System.Drawing.Common to use with dotnet standard/core, maybe the mgcb tool needs to reference this as well?
System.Drawing is not part of .NET standard, its also not really crossplatform. We should avoid referencing it like its a plague.
Also yup about the template, will update it later today.
1 Like
I guess I’ll experiment with some other libraries for image processing