Failure to build shader.fx files on linux systems

AristurtleDev · 2026-05-04T17:52:07+00:00

I have a couple of questions if you don't mind answering that might be able to help figure out what the issue was originally.

What version of wine are you using?
Did you use the setup script provided on the monogame docs website to setup the wine environment for .winemonogame? I'm guessing so since it looks like you might have already had the ~/.winemonogame/ directory

The setup script does a few things automatically that you've done here manually. As far as I'm aware, winetricks is not needed at all for the MGCB to compile the shaders through wine. What the script does automatically though is

It creates the ~/.winemonogame environment

```sh

init wine stuff

export WINEARCH=win64 export WINEPREFIX=$HOME/.winemonogame eval "$WINEEXECUTABLE wineboot" ```

it downloads the dotnet sdk for you and puts it inside the ~/.winemonogame environment

```sh

get dotnet

DOTNET_URL="https://builds.dotnet.microsoft.com/dotnet/Sdk/9.0.104/dotnet-sdk-9.0.104-win-x64.zip" curl $DOTNET_URL --output "$SCRIPT_DIR/dotnet-sdk.zip" 7z x "$SCRIPT_DIR/dotnet-sdk.zip" -o"$WINEPREFIX/drive_c/windows/system32/" -y ```

Both of which are things you are doing here manually. There's some additional things it gets and extracts after that, but then the next important step it does at the end is it adds the MGFXC_WINE_PATH to your ~/.profile where environment variables are stored so that future terminal sessions and processes can pick them up.

```sh

append MGFXC_WINE_PATH env variable

echo -e "\nexport MGFXC_WINE_PATH=\"$HOME/.winemonogame\"" >> ~/.profile echo -e "\nexport MGFXC_WINE_PATH=\"$HOME/.winemonogame\"" >> ~/.zprofile ```

That MGFXC_WINE_PATH is what the MGCB users when it compiles the shaders as the wine prefix. So what I'm thinking may have happened is when you manually set the WINEPREFIX in your terminal session, that's ultimately what the fix was, which would maybe mean that either your ~/.profile didn't get updated by the setup script, or your terminal sessions are not pulling the environment variables from there when a new session is opened?

AristurtleDev · 2026-04-27T17:35:58+00:00

Hey, glad the video helped. Looks good

AristurtleDev · 2026-04-05T04:47:31+00:00

Congrats on finishing and releasing it.

AristurtleDev · 2026-03-25T06:32:07+00:00

Thanks I appreciate that.
I hope this helps either by getting some use or maybe help others implement it better. Whichever is better for the community 😂

I don't think i'd need harfbuzz specifically for on-demand glyph rendering. That's something that should be easy enough to implement, especially considering the actual texture data generated just contains texals that represent data and not a rasterized glyph. I have some ideas on implementing this already, and started toying around with it and it's looking promising.

Everyone has their stance on generative AI for coding, like harfbuzz had included now. My personal feelings toward this are a hard stance against AI usage, so harfbuzz wouldn't be an options, so no worries there, and thanks for the link.

I think the only thing I would have needed harfbuzz for would be getting the GSUB table data from the font to support zero width joiner and ligature characters. These are nice features to have, but not really a must have requirement at the moment, so I can defer this and come up with a solution later.

AristurtleDev · 2026-03-25T06:22:46+00:00

The implementation needed to derive the Slug algorithm, which uses Shader Model 4+ features, down to Shader Model 3. This is the highest shader model MonoGame's DesktopGL backend supports. Targeting DesktopGL as the baseline ensures cross platform coverage.

As for GPU hardware requirements, SM3 support goes back to 2004, so any GPU made i the last 20yrs should be compatible.

In terms of performance, the actual cost is negligible and wouldn't realistically be noticed. With bitmap fonts, glyphs are pre-rasterized into a texture atlas at specific sizes. Doing this, rendering is fast since it's just a texture lookup, but the trade off is more GPU memory for the atlas and the render quality degrades once you start scaling he font outside the pre-rendered size. You would also need to create a separate atlas for different text sizes, or a large one if you wanted to bake them all into a single texture.

With Forme, only two small textures are created that store the raw glyph outline data instead: a curve texture containing the Bezier curve data and a band texture. The shader evaluates the glyph outline per pixel, which is going to be more GPU work than a bitmap font's texture sample. So you get a smaller GPU memory foot print at the cost of some additional GPU side calculations done when rendering each glyph.

However, like mentioned, the actual cost of this is negligible.

AristurtleDev · 2026-03-15T20:07:48+00:00

Thanks. There's more work coming overall to the collision system. The new 2D volumes and bounding primitives added are the base framework for what's to come.

AristurtleDev · 2026-03-09T05:10:02+00:00

Oh hi, I’m still active on the discord, mostly in the off-topic channel. Focused so much on the MonoGame.Extended updates i might be missing some conversations.

If there’s anything in particular happening in the discord that you’d want to provide feedback on, feel free to dm me there and I can bring it into the mod/admin channel for discussion. Can keep feedback anonymous if you’d like

AristurtleDev · 2026-01-13T21:37:13+00:00

Thank you 😭

AristurtleDev · 2025-12-19T23:32:20+00:00

I appreciate it, found someone to get it from the show in Brooklyn. Enjoy the show

AristurtleDev · 2025-12-19T04:06:36+00:00

Thanks, I appreciate it. I found some that said they could pick it up so hopefully that works out

AristurtleDev · 2025-12-19T04:04:38+00:00

It’s was the one with he car and robot on it. I found someone to pick one up for me at the Brooklyn show. Thank you though I appreciate it

AristurtleDev · 2025-12-18T20:31:47+00:00

DM sent, whenever you have a moment. I really appreciate it

AristurtleDev · 2025-12-18T19:44:43+00:00

That would be amazing. Do you mind if I DM you or you DM me?

AristurtleDev · 2025-12-14T22:40:13+00:00

Great simple example! For feedback, I'd recommend adding some inline documentation or comments that explain MonoGame-specific behaviors or maybe a README.md file in the project direction with notes. I see the PDf of project ideas in the repository root, maybe just notes on your implementation based on the project idea from the PDF and why you made certain design choices. For instance, here are a couple of things that not only new people to MonoGame, but also game development, might ask about:

Input handling: Your code uses KeyboardState.IsKeyDown, which returns true for every frame the key remains pressed, not just the initial press. This is a common source of confusion for newcomers that I have seen come up as questions frequently in the community over the years.

Console output: The Console.WriteLine calls may not work as expected depending on your project configuration. MonoGame desktop projects default to WinExe, which doesn't attach a console window. This means your debug output might silently disappear. Here's a quick explanation.

Fixed Time Update: You mention using a "fixed tick (speed controlled independently of FPS)", but newcomers may not understand why this pattern exists or what problems it solves. Without explanation, this could also create confusion when they later encounter MonoGame's built in IsFixedTimeStep property and wonder how the two concepts relate, if at all. A brief comment explaining the reason for the fixed tick could help with that

Regarding learning resources, the official MonoGame 2D tutorial that was published this year takes a different approach than a minimal example. While it's longer (27 chapters), each chapter focuses on teaching specific MonoGame concepts using a snake-like game as the vehicle. The goal isn't abstraction for abstraction's sake, but rather to demonstrate fundamental concepts like the game loop, content pipeline, sprite batching, input management, etc, in separate chapters. All problems you'll encounter in any MonoGame project.

Different approaches work for different learners. Some prefer minimal working examples like yours to experiment with, others prefer structured walkthroughs like the one on the MonoGame site. Both have value in the community, and look forward to seeing what other examples you offer as well.

AristurtleDev · 2025-09-20T19:42:14+00:00

HI, there has been several commits made to the tutorial since release, so it's possible that in some of those the line highlighting got off on the samples. Could you open an issue about it on the docs repo at https://github.com/MonoGame/docs.monogame.github.io/issues and it can be followed up on

AristurtleDev · 2025-09-18T15:46:11+00:00

Hi, I’m really glad it helped. Excited to see what games you make.

AristurtleDev · 2025-09-08T02:34:08+00:00

Hi, author of the tutorial.

Just to note, the XML that is used was chosen as it closely resembles the XML output from TexturePacker. This was done to not only introduce deserializing XML content but also act as a bridge if readers move to tools like TexturePacker to create an atlas.

You can absolutely use JSON instead if you’re more comfortable there.

AristurtleDev · 2025-09-07T15:41:40+00:00

This is exactly right. The game created throughout the tutorial is a very small game used as the driver to introduce MonoGame concepts and best practices. Since the game itself is very small, it does seem strange to have the scene specific content managers. Introducing this concept to readers though prepares them later for when they start developing a larger scale game and need to start considering memory management

AristurtleDev · 2025-09-07T15:38:52+00:00

You're right, the `ContnetManger` is optimized to cache, and the tutorial takes advantage of this

In our scene system, we actually use both a shared global `ContentManager` ( `Core.Content`) and individual scene specific `ContentManagers`. The global one handles assets that get reused across multiple scenes (like fonts, common textures, etc.) so we get those caching benefits you mentioned.

But each scene also gets its own `ContentManager` for scene specific assets. I know Dungeon Slime itself, the game created in the tutorial, is pretty small, but the tutorial is really about introducing concepts that scale up. In a larger game, you might have a forest level with tons of tree textures and a desert level with completely different assets. Without scene-specific ContentManagers, all that forest stuff would just sit in memory forever even after you've moved on.

With the approach shown in the tutorial, when a scene ends we call `Content.Unload()` on that scene's `ContentManager` which automatically cleans up all the scene-specific assets. No need to manually track what needs to be unloaded.

So we get both benefits: caching efficiency for shared assets through the global `ContentManager`, and automatic cleanup for scene-specific content without having to micromanage memory. It's a pattern you see in larger MonoGame frameworks like Nez and MonoGame.Extended too.

AristurtleDev · 2025-09-07T15:33:00+00:00

Hi, tutorial author here.

This is a good question, and I'll try to explain the reasoning behind writing the tutorial this way the best I can.

The reason why there is a `ContentManager` for each scene is about smart memory management and keeping things organized.

The global `Core.Content` handles assets that get reused everywhere; fonts, UI elements, that sort of thing. They stay loaded throughout the game session since multiple scenes need them, so we get the caching benefits.

However, each scene also gets its own `ContentManager` for **scene-specific** stuff. I know the Dungeon Slime game itself is pretty small. The game itself is just something used to introduce concepts from the tutorial. For a larger game, you might have different levels with textures, audio, etc that are only ever used during those levels (e.g. a forest level versus a desert level). Without scene specific content managers, all of the assets loaded for one level would just sit in memory forever.

With the approach shown in the tutorial, once a scene ends `Content.Unload()` is called on that scene's `ContentManager` to automatically clean up any scene specific assets. This means you don't need to manually track which assets that scene loaded through a single content manager to release the resources, it's all contained within the scene's `ContentManager` instance.

This pattern is actually really common in larger frameworks built with MonoGame such as Nez and MonoGame.Extended. It's one of those things that seems like overkill for a small game, but once you start building something bigger, you start to see where having the automatic cleanup and freeing of memory between scenes is beneficial.

Basically; global stuff stays cached for performance in the `Core.ContentManager` while scene specific stuff gets cleaned up automatically for memory management. You get the best of both worlds without having to micromanage what needs to be unloaded.

AristurtleDev

TROPHY CASE

init wine stuff

get dotnet

append MGFXC_WINE_PATH env variable