search

thewierdnut / endless-mobile

Space exploration, trading, and combat game.
https://endless-sky.github.io/
GNU General Public License v3.0
113 stars 8 forks source link

[Question] Mobile Linux Support #135

Open ethical-haquer opened 3 days ago

ethical-haquer commented 3 days ago

Problem Description

First of all, I'm not really sure if this is better opened here or upstream, let me know if it's the latter.

I just got your mobile fork of ES to build on my PPP (PinePhone Pro). It was a bit of a challenge, since I'm running postmarketOS, which is based off Alpine Linux, which is based on musl libc. Since it uses musl, I had to tweak the SConfiguration file in order for it to build. (On a side note, ES is already packaged in pmOS, but it has the same issue as below, with scaling. Also, it doesn't have the tweaks for mobile that your fork has.)

After I got it to build, it wouldn't run. It said "Monitor resolution is too small!", and then crashed a few seconds later. ("crashed" as in the process ended, it never opened a window). According to the source code, it will say that if your screen is smaller than 640x480. However, the screen on the PPP is 1440x720. I'm not sure how scaling in phosh works, but by default the scale in settings is set to 200%. ES would only start after turning scaling down to 100%. (~it wouldn't start at 125%~ EDIT: It works at 150% or lower) However, setting the scale to 100% is not ideal, because it's system-wide and makes all other apps hard to use (e.g. their buttons are very small, etc.).

TIA, and once again, please let me know if this would be better for upstream!

Related Issue Links

I couldn't find anything about getting ES to run on mobile Linux, surprisingly.

Desired Solution

I'm hoping that in the future ES will "just work" on mobile Linux, and I was wondering what the best way to go about that is.

Alternative Approaches

N/A

Additional Context

No response

thewierdnut commented 3 days ago

My phone is 1440x720, and its quite playable. I'm curious what resolution will be listed if you adjust that error to say:

   ExitWithError("Monitor resolution is " + std::to_string(maxWidth) + "x" + std::to_string(maxHeight));
thewierdnut commented 3 days ago

I will note that I play this game on debian on a lenovo yoga in tablet mode, and the touchscreen controls work just fine.

ethical-haquer commented 3 days ago

My phone is 1440x720, and its quite playable. I'm curious what resolution will be listed if you adjust that error to say:

   ExitWithError("Monitor resolution is " + std::to_string(maxWidth) + "x" + std::to_string(maxHeight));

Great idea.

I will note that I play this game on debian on a lenovo yoga in tablet mode, and the touchscreen controls work just fine.

👍 The touchscreen controls seemed to work alright, albeit the buttons are a little hard to hit on such a small screen. I also added that compact-layout plugin that's used on Android.

Thanks for replying! I'll get back to you once I've messed with it (the code and the game) some more.

ethical-haquer commented 3 days ago

I just tested out that error you suggested, and it says: Monitor resolution is 720x360. So it's simply getting half the actual screen size due to the 200% scaling. Also, disregard what I said before, it will work up to 150% on this phone. 175% is 411 pixels tall. I'm wondering, is it possible to get the resolution without scaling? Or does scaling to 200% actually make each "pixel" displayed use four pixels on the display?

thewierdnut commented 3 days ago

What "scaling" are you referring to here? The in-game Main zoom factor does not affect the reported monitor resolution.

ethical-haquer commented 3 days ago

What "scaling" are you referring to here? The in-game Main zoom factor does not affect the reported monitor resolution.

The scale in GNOME Settings: Pasted image (5)

Sorry for not clarifying.

thewierdnut commented 3 days ago

Oh. Does the game work if you set that to 100%? You can scale the buttons in-game by changing the UI zoom.

ethical-haquer commented 3 days ago

Yeah, it works if I set it to 150% or lower, but like I said, that messes with all the apps scale. Changing the min values in the source code didn't work :rofl:: Pasted image (4)

thewierdnut commented 3 days ago

it also doesn't appear to be respecting the fullscreen setting.

ethical-haquer commented 3 days ago

I just didn't have it in full-screen, that part does work: Pasted image (6)

Also, I keep getting dozens of these in the output: Flushing user due to: AFBC write staging blit

thewierdnut commented 3 days ago

Windows tries to do the same thing on high resolution displays, and the upstream project sets the SDL_WINDOW_ALLOW_HIGHDPI flag to tell it to leave the SDL app alone. I wonder if there is a similar hint I can set for you.

thewierdnut commented 3 days ago

what sdl version do you have?

ethical-haquer commented 3 days ago

@thewierdnut 2.30.8, according to sdl2-config --version

thewierdnut commented 3 days ago

x11 or wayland?

ethical-haquer commented 3 days ago

@thewierdnut Wayland.

thewierdnut commented 3 days ago

Uhg. They added a flag to bypass wayland scaling in SDL 3 just this year. There isn't a quick way to get that working...

Can you add some logging statements here?

Something like

SDL_Log("WindowSize: %d %d   DrawableSize: %d %d", windowWidth, windowHeight, drawWidth, drawHeight);
ethical-haquer commented 3 days ago

@thewierdnut This is with the keyboard up: INFO: WindowSize: 720 133 DrawableSize: 1440 266 and the keyboard down (hidden): INFO: WindowSize: 720 360 DrawableSize: 1440 720 On startup: INFO: WindowSize: 720 313 DrawableSize: 1440 626 I'm getting flooded with Flushing user due to: AFBC write staging blit, do you happen to know how to silence those? Thanks for the help!

thewierdnut commented 3 days ago

INFO: WindowSize: 720 360 DrawableSize: 1440 720

Interesting. That implies that the pixels are still there, its just lying about the surface size. That means that if I make it so that you can scale the window size to less than 100%, it should still look good.

Flushing user due to: AFBC write staging blit

I've never seen this, and google isn't helpful either. it looks as though I'll have to dig into the graphics driver source code to find this one. What graphics driver are you using? (glxinfo)

thewierdnut commented 3 days ago

I've pushed an update that reduces the minimum zoom to 50%. Try setting that and see if it helps.

ethical-haquer commented 3 days ago

I hope this is the info you need: OpenGL renderer string: Mali-T860 (Panfrost). Let me know if it's not.

I tried with your changes, and it worked wonderfully: Pasted image (8) Pasted image (7)

thewierdnut commented 3 days ago

Let me know if you run across any user interface quirks. I've run into issues in the past where the window environment would reinterpret touch events as mouse clicks, even though the game handles touch events directly.

ethical-haquer commented 3 days ago

What is the standard way to open up the map or jump from the flight view? I've been pulling up the keyboard, but there must be a better way.

A different issue is that clicking buttons that are on the bottom of the display causes the top and bottom bars (in the OS, not the game) to show, essentially making it not go full-screen temporarily. That is an issue with phosh though, not the game.

thewierdnut commented 3 days ago

Where are your onscreen buttons? It should look like this: image

thewierdnut commented 3 days ago

Check these preferences in the second page of the settings menu: image

ethical-haquer commented 3 days ago

That was the problem, those were turned off. I guess since I'm using a Linux build those aren't turned on by default like they are for the Android build. Thanks for the tip. Pasted image (9)

How does the game typically handle starting from portrait? Like on Android does it automatically go landscape?

thewierdnut commented 3 days ago

I lock it into landscape with the manifest: https://github.com/thewierdnut/endless-mobile/blob/android/android/app/src/main/AndroidManifest.xml#L77

I'm not sure how to do something similar on a pinephone.

ethical-haquer commented 3 days ago

Your phone has a little more power than this PPP (look at the CPU/GPU load :smile:): Pasted image (10)

May I ask what phone you have?

thewierdnut commented 3 days ago

That was a screenshot from my desktop, which is just using the integrated graphics on a ryzen 9 7900 cpu.

This is a screenshot from my phone, a moto g7 power, which is much closer to the GPU limit: Screenshot_20241029-081942

thewierdnut commented 3 days ago

Note that you can turn some of the special effects off in the settings. I typically turn off at least motion blur.

thewierdnut commented 3 days ago

The game typically doesn't use up a lot of cpu. I've had it working on 12 year old tablets, no problem. I suspect that whatever is flooding your logs is causing your high cpu usage, probably more from the logging than from the actual issue.

ethical-haquer commented 3 days ago

You're probably right, I'm getting those nonstop, hundreds of them.

ethical-haquer commented 3 days ago

Have you ever flashed a custom ROM to your Moto G7 Power?

thewierdnut commented 3 days ago

Yeah. I ran lineageos for a while. It was unstable and the colors kept breaking. I eventually went back.

ethical-haquer commented 3 days ago

Cool, did it seem any faster on LOS? What do you mean by "colors"?

thewierdnut commented 3 days ago

No, lineageos was slower. By colors, I mean the color profile was wrong, and all of the reds and blues were swapped. Adjusting the color profile would fix it, at least until next reboot. I also couldn't reliably get phone calls or text messages.

ethical-haquer commented 3 days ago

Yeah, that sounds more like an unofficial LOS build. :grimacing: How long ago was that?

Regarding getting your build running on mobile Linux, I think that it's running pretty good now. Hopefully we can get the "hacks" for scaling implemented in a way that can be used upstream. Or will upstream not bother with mobile Linux? I guess it might just be something to get working on your branch. Then there's the tweaks I had to make in order to get it built with musl. Should I try to get those in upstream? (since it's not mobile-specific) TIA.

thewierdnut commented 3 days ago

Upstream won't accept merges for mobile or touchscreen support. That's why I maintain this fork.

I'll leave the zoom changes in place. I think that the first time it loads it will auto-compute the correct aspect ratio, as it tries to set it automatically as high as possible. Most mobile users never even mess with it.

thewierdnut commented 3 days ago

Then there's the tweaks I had to make in order to get it built with musl. Should I try to get those in upstream?

If you want to know, raise an issue upstream asking about it, or join the endess-sky discord and ask in #the-hub

thewierdnut commented 3 days ago

Hey, you mentioned you used scons to build it? I'm surprised that still works. I use cmake, and the upstream repo primarily does as well.

ethical-haquer commented 3 days ago

@thewierdnut Well, your README says: "Most development is done on using the SCons build tool to compile the project." And in the Linux build instructions: "Then, from the project root folder, simply type: $ scons, $ ./endless-sky" Oh, now I see that the upstream README says to use cmake. I think your README needs updating then. 😉

But yeah, I guess I was able to build it with scons. I should try building it with cmake then, and see what tweaks need to be done there.

ethical-haquer commented 3 days ago

Interesting, I'm not used to seeing Linux build instructions listed after Windows. Do most ES devs use primarily Windows? Your README (which I presume used to be the same as upstream's) lists Linux, Windows, and then macOS, which is more what I'm used to seeing.

thewierdnut commented 3 days ago

Yeah, I started with the upstream readme and stripped out what wasn't relevant, then haven't touched it since then. The upstream project has changed quite a bit since then.

edit: There, I added an issue to remind myself to fix the readme later.

ethical-haquer commented 2 days ago

@thewierdnut Nice. I'm working on getting it to build with cmake.