Log In  



Hey,

I am fully aware that Pico-8 does not have an android release
It does however have compiled linux binaries for x86_64 (amd64) and arm64 (aarch64)

Knowing I can't actually execute these binaries in "native" android, I started experimenting with proot-distros
I've had success running linux binaries in proot before, namely with titles like Dwarf Fortress using this person's research here:
https://www.reddit.com/r/dwarffortress/comments/r80m7y/dwarf_fortress_mobile_running_dwarf_fortress_on/
TL:DR proot debian, fill in required libraries, disable video/sound, force text rendering, launch linux binaries via box64

Obviously I can't force text rendering for pico-8 (although that would be baller if it could output to terminal using filled unicode characters and the already primitive color palette of a terminal window)
As such, my setup is similar but tweaked.
Its still a proot distro, all the libraries it claims to need are present, but I have the graphical interface piped through VNC or XSDL.

However, launching either the arm64 binary or the amd64 binary (via box64) results in the same error

 
SDL Error: Could not initialize UDEV

** FATAL ERROR: Unable to initialize SDL

I've compiled SDL from source in every configuration I can find, i've found virtualized distros that claim SDL support on older versions of android... Heck I even got openGL running with hardware acceleration. All I can think of is that I am misunderstanding what part of UDEV isn't initializing.
Is it failing to initialize the GPU rules? Sound rules? Input rules? I can't figure that out and that error is the full extent of the log file that I have.

I know its not strictly an Android issue as I've seen the threads where chromeOS people have successfully run Pico-8 on chromebooks using very very similar methods, but it looks like an arm64 android issue.

5

You can run earlier versions of Pico-8, @FlaxWombat, on a free Android App called, "P8 Player."

https://play.google.com/store/apps/details?id=com.ylstudios.p8player&hl=en_US&gl=US

It does mess up reading the screen though through touching it for X/Y coordinates.

Also if you have 24/7 internet on your Android device, you can just go to the main Lexaloffle website and play your cart direct there with no worries of it being too advanced for the playback.

I know about the various methods of playing carts, but I'm aiming for the full featured editor...

Is there a full-featured editor for the Android itself, @FlaxWombat ?

The releases I have are:

 
	Windows: installer | zip
	Linux: 32-bit | 64-bit
	Mac OS X: zip
	Raspberry Pi: zip

If it's outside of these it may not be the version you want.

No, there's not an actual android release. I started the thread saying I'm well aware of that fact. I'm trying to find help figuring out the error it's giving me so I can maybe hack the other versions into running on android.
1

Alrighty I've learned that udev flat out doesn't function in a proot environment as udev manages hardware and that's out of scope for proot... Unless of course you run proot as actual root which is unfeasible on most android phones. Which brings me back to my earlier question-ish, what hardware element is pico-8 calling that requires udev?

https://github.com/termux/proot/issues/47
1

@FlaxWombat

A forum page that might shed some light; it mentions SDL and udev:

https://forums.libsdl.org/viewtopic.php?t=9772 (Posted in 2013, though.)

First line: "SDL2 has dropped support for the Joystick API (/dev/input/js*) in Linux. It now only uses the Event API (/dev/input/event*) for joysticks. In many cases, these event device files are not readable by unprivileged users, and so your joystick won't work."

Steps for making joystick devices work then include: "Download the following file and move it to /etc/udev/rules.d/ "

There's a link on that forum page to a readme as well.

Kallan Reed (who I've seen posts by on this forum) mentioned in a 2021 blog post: "it turns out that SDL2 no longer supports the joystick devices, but instead looks at event devices."

The rest of the blog post might be worth a skim: https://kallanreed.com/tag/udev/

However, I've no knowledge in this area; this was the result of a websearch. On the basis that not all websearches return the same result, I've opted to post it in spite of lack of personal knowledge.
1

@remcode

Thank you for the links, its shedding a lot of light on potential issues. I haven't found if SDL2 implemented an actual fix for the issues they discussed in 2013 though. The fixes in that thread don't seem to work for issues that seem unique to android and proot environments... (namely that I don't have much ability to probe hardware calls from a virtualized linux install, nor do I have true device root to probe it from the android side)

I have a cheap phone arriving in a little bit that I can assuredly root and I'm going to try all this again when it arrives.

Past that, short of a post from lord and master Lexaloffle himself... if this doesn't work then its pretty much out of my hands.

Thank you though, for real. Any issues I find when the rooted phone arrives might be solvable from that.
3

Lordy lordy.

Bought a Motorola Photon Q because AFAIK it's the only slider keyboard phone that can flash android 6 or newer and still be found for under $100.

Unlocking it was easy, rooting was easy... Finding a build of LOS that would actually flash and not boot loop was a pain and took me all of Sunday and part of Saturday. Once it was actually running, I grabbed andronix for easy mode proot install, fdroid for termux, did a ton of waiting... And after getting Pico-8-rasp into the right spot and figuring out how best to use root to talk to proot...

It worked.

http://imgur.com/gallery/Nhlsng8

That, my friends, is the full Pico-8 engine running on a dual core snapdragon S4. FPS is limited probably because it's running through VNC but everything works.
1

Wow. A Photon Q running PICO-8. That's an amazing result. I wish those weren't unobtanium in this side of the pond.

How did you get around the UDEV problem? I had some luck running PICO-8 on an Asus tablet (https://twitter.com/MacarioMorenoUK/status/1154521770277216258) by disabling UDEV in the build, but that was an atom processor; the same approach on ARM didn't work for me.
1

@Maca
Ultimately the only solution I could find was to root the device and then launch the proot-distro with tsudo. I also used the Raspbian builds obviously since I didn't feel like chancing box86 on a dual core phone.

I'm still not sure what exactly Pico is calling from UDEV and if I can figure that out then a custom UDEV ruleset for it could bypass the need for true root. Or it could make no difference at all if UDEV can't initialize at all without tsudo proot. Unfortunately though I have to learn different ways to get logs to figure that out since I can't tail a messages file on termux.

I wonder though, did you try the raspbian or the x86/64 builds with the UDEV disabled LibSDL2 build? Also, with UDEV disabled, did anything stop working like joysticks or sound or something?
1

@FlaxWombat
Thank you for your reply. I tried running PICO-8 on two android machines:

  • a x86-based tablet, where I found this problem with the x86 32 bit build and succeeded by just rebuilding LibSDL2 without UDEV
  • a rooted armhf-based phone (Snapdragon S2) where I tried running the raspbian build and the "disable UDEV" approach failed
    The second device is probably using chroot, so I will try proot as you suggest.
    I didn't try joysticks with any of the devices, in the 1st case the I used a BT keyboard which worked through the VNC client without problems.
2

Actually after revisiting this I realised I had been making a mistake all along: in the more recent versions of SDL2, the setting to configure the build to run without UDEV is no longer --disable-udev but --disable-libudev. With this setting I was able to run pico8_64 on a chroot installation of Ubuntu 20.04.

@FlaxWombat: you may want to try this for ease of use, as well as avoiding the overhead of hijacking ptrace.

It serves me well for not reading the build logs.
6

So that this can serve as a reference for anyone who comes across this thread and would like to run PICO-8 from a chroot installation by disabling UDEV in their SDL2 build:

  • getting the SDL2 sources:
    • uncomment the deb-src lines in your /etc/apt/sources.list, either manually or by running sudo sed -i 's/"# deb-src"/deb-src/g' /etc/apt/sources.list
    • update your repository data: sudo apt-get update
    • install libsdl2-dev as a proxy for the build dependencies: sudo apt-get install libsdl2-dev
    • install the sources for SDL2: sudo apt-get source libsdl2
  • building SDL2 withtout UDEV support:
    • cd libsdl2-2.0.10+dfsg1 (or whichever path the sources were unpacked to)
    • mkdir build; cd build
    • ../configure --disable-libudev (you can also disable support for pulseaudio or wayland)
    • make
    • sudo make install
  • running PICO-8 with the rebuilt SDL2:
    • LD_PRELOAD=/usr/local/lib/libSDL2.so ./pico8_64 -windowed 1

These instructions are for Debian-like distros (tested with Ubuntu 20.04 arm64)

I've compiled SDL without udev but now it fails and says "no available video device".

I can't figure out what video devices the precompiled libsdl2 binaries use
2

Sorry for the delay in replying. Somehow I missed the notification email.

I presume from what you have said before that you are using VNC (I haven't been able to get PICO-8 working with XSDL, even though I don't get that message - I use VNC viewer with default settings). In that case you should be using the X11 driver. You can force it with 

SDL_VIDEODRIVER=x11 LD_PRELOAD=/usr/local/lib/libSDL2.so pico8_64 -windowed 1

In that case I expect it would tell you if when rebuilding SDL2 you missed x11. This is not necessarily because of explicitly using an option, but because the x11 headers were not present at the time you run configure. If that is the case, please install libsdl2-dev; that should bring in all the dependencies you need to rebuild it. Then re-run the build process and the new .so should have the driver.

Also it may be worth checking that you have libXrand installed (I guess libSDL2-dev also installs this)

Please let me know if any of this helps and I will update the instructions.
1

@FlaxWombat: I repeated the process from scratch, installing just libsdl2-dev and dpkg-dev prior to building the sources, and this is the summary of configure on that installation:

 
Building Shared Libraries
Building Static Libraries
Enabled modules : atomic audio video render events joystick haptic sensor power filesystem threads timers file loadso cpuinfo assembly
imers file loadso cpuinfo assembly
Assembly Math   :
Audio drivers   : disk dummy oss alsa(dynamic) pulse(dynamic) sndio(dynamic)
Video drivers   : dummy x11(dynamic) opengl opengl_es1 opengl_es2 vulkan
X11 libraries   : xcursor xdbe xinerama xinput2 xinput2_multitouch xrandr xscrnsaver xshape xvidmode
Input drivers   : linuxev linuxkd
Using libsamplerate : NO
Using libudev       : NO
Using dbus          : YES
Using ime           : YES
Using ibus          : YES
Using fcitx         : NO

Does yours display any Video drivers?

@Maca

Sorry for the delay, i'm rebuilding libsdl2 with libsdl2-dev installed. I do know that X11 was a video device that got compiled so I'll try your new commands to see what happens.
1

@FlaxWombat

Not a problem, whenever you have the time. It may be relevant to know that UserLAnd uses tightvncserver for Ubuntu.



1

@Maca
IT WORKED.
I installed libsdl2-dev and compiled with --disable-libudev and --disable-video-wayland (wayland was breaking make for some reason)

I'm going to do it again on my daily driver phone since that one isn't rooted at all just to be sure but I have high hopes that this should work, meaning there is actually a method of running Pico 8 on an unrooted android device. Is it practical? Nope, but this is great news either way.

Thank you so much for your work on that, it would have taken me weeks extra minimum to even start figuring this out.

Console is constantly spitting out 

shared memfd open() failed: Function not implemented

but it so far doesn't seem to affect functionality

EDIT:

Well, Splore doesn't seem to want to connect to BBS and I confirmed that wget is installed... which AFAIK was its only prerequisite. I don't seem to be the only one with the issue though as of today so I guess we'll see.
1

It is fantastic news that it worked. Thanks for your perseverance, it is great to have someone else follow the same process and pinpoint the steps I had missed. I will update the earlier post, hopefully it may serve as guide for more PICO enthusiasts.

This should definitely work on a non-rooted phone. I have it running on a stock Samsung S7 with UserLAnd and VNC viewer. Splore works for me but audio does not (probably would if I configured PulseAudio). Because of the libc version statically linked in pico8_64 only Ubuntu 20.04 can be used. Hopefully UserLAnd will get updated to support bullseye which is also built around a compatible version.

As for practicality, well, it is awkward using a phone but things can be done as long as you mostly use the code view. IIRC the great @freds72 used an IPhone vnc'ing to a PocketCHIP, so this cannot be worse. Having a physical keyboard also helps, I have one for my S7 that mounts on top of the bottom of the screen and it is quite reasonable (typing from it ATM).

As for the shared memory fd (file descriptor I presume) it is not an error I had seen in any of my installations. This sounds like a form of IPC the usermode part of a driver would use with the application. I wonder whether it has anything to do with the splore failure.
3

This is awesome!

I followed guide here by @Maca and been using PICO-8 in my Termux setup for some time.

My favourite thing to do with it is projecting the screen to my homebrewed 3DS (with TinyVNC) and using PICO-8 through that as a portable setup (take that, FAKE-08!). It's good for playing games, slightly less for making them. Latter doesn't really work with touchscreen keyboards in my opinion.

One of the only cons right now is that the sound comes out of the phone: I couldn't get audio to stream over HTTP to VNC. I'm okay with using it as is though.

I also found -pixel_perfect option set to 0 not working. I wonder why that's the case...



[Please log in to post a comment]