A weird linux build bug? Sprite becomes super tiny when passing some "threshold"

So I've been developing a game, and I built a linux version of the demo I had.

But for some reason, when this ONE specific enemy passes a threshold, it becomes super tiny?

It's only on the linux, not even on Steam Deck which USES the exact same linux build.

I'm not really sure what's happening and I've looked into what might be causing it on the scripting side, and there's nothing to my knowledge...

Below is the link with the timestamp where I saw this happen and multiple demo players have also reported the bug!

youtu.be/6C6v6bmb5gM

It doesn't get any smaller; you can see in the video how you hit it with a bullet, which means the collision is the same, but something happened with the rendering.

I see the sprite moving on the floor though, but yeah the collision is the same!

Not really sure what is causing it!

A community member found out that if you change the launch option to the following it will fix the problem!:

--ozone-platform=x11 From --ozone-platform=wayland

Is there a way I can make this default so they don't have to do it?

If you have weird graphical issues on Linux only, it's most likely a graphics driver bug. Installing the latest drivers may help, or installing proprietary drivers if you're using open-source drivers.

Unfortunately poor quality graphics drivers are an industry-wide problem, and Linux can be particularly problematic with them as well.

If you have weird graphical issues on Linux only, it's most likely a graphics driver bug. Installing the latest drivers may help, or installing proprietary drivers if you're using open-source drivers.

Unfortunately poor quality graphics drivers are an industry-wide problem, and Linux can be particularly problematic with them as well.

It seems like it's happening on EVERYONE who plays on linux though.

I suppose it could still be a driver issue and some linux players who aren't running into trouble are playing just fine and haven't looked in the steam forums.

If you ask for hardware details of those affected it can help identify it. For example if everyone affected is using an NVIDIA GPU, and people using AMD GPUs are not affected, it's likely an NVIDIA Linux driver bug. If everyone with all sorts of GPUs are affected, it probably means it's not a driver bug. Don't discount that it could be a mistake in your own project's logic - it is possible even if it seems like it only happens on Linux. There could be something different about Linux (such as resolution, frame scheduling, etc) that causes a bug in your project logic.

If you ask for hardware details of those affected it can help identify it. For example if everyone affected is using an NVIDIA GPU, and people using AMD GPUs are not affected, it's likely an NVIDIA Linux driver bug. If everyone with all sorts of GPUs are affected, it probably means it's not a driver bug. Don't discount that it could be a mistake in your own project's logic - it is possible even if it seems like it only happens on Linux. There could be something different about Linux (such as resolution, frame scheduling, etc) that causes a bug in your project logic.

Thanks, Ashley!

So is there a way to build a linux build with this setting I mentioned in an above thread being default?

"A community member found out that if you change the launch option to the following it will fix the problem!:

--ozone-platform=x11 From --ozone-platform=wayland"

I don't think there's currently a way to make a build with additional command-line flags, but you can always use a small script or a desktop shortcut to run another executable with additional arguments.

I would caution against changing random undocumented settings via the command-line to solve problems though. It's the software version of putting wallpaper over structural cracks. It could also cause new problems, and in some cases those problems may be worse than the one you are trying to fix. In general such things should only be done on a temporary basis while the root cause issue is identified and fixed.

I see.. that makes sense.

I'll try to figure it out! But it's hard since I don't actually have a Linux hahaha.

Thank you again!!

Oh Ashley, could this possibly be a bug that happens due to the fact I unzipped my game on a windows system before uploading it to the build servers on steam?

Or if that was a problem, the game just wouldn't run at all?

I just read the exporting for linux tutorial and saw that I wasn't suppose to do that but that's how I'd been uploading it before haha

If you extract a project on Windows then transfer it to Linux, generally that means all the executable file permissions are lost, and then the project will fail to run at all on Linux. So if it runs at all, it's probably not that.