Could someone please help build https://github.com/BlitterStudio/amiberry for SFOS? It only has a few dependencies (SDL2, flac mpg123 libmpeg2-4) and I’ve successfully built it on “normal” Linux systems (raspberry os, ubuntu, etc) where a simple make command did it all, but I just don’t know how to build it in Sailfish SDK…
Could someone please be kind enough to post a step-by-step guide for such a Salfish OS newbie as myself to go though this SDK maze and build this kind of project? It would also be a great tutorial helping to build such stuff myself in the future…
Amiberry is a great Amiga emulator, very fast and highly optimized for ARM. There are no other emulators available for SFOS and the Android ones all are more or less flawed…
Just a note in advance: SDL apps usually do run and display something on SFOS, but generally require modifications to deal with the Lipstick/Wayland situation, and the way UI/input is done on SFOS.
I am not equipped to do anything but maybe getting it to compile, someone else will need to pick up from there.
Speaking of which: in case anyone is in the mood, I have built two other nice things successfully, both run fine but they are not really usable on SFOS without SDL-related tweaks (mainly reolution/scaling and fullscreen/orientation for wayland), and perhaps an UI:
Dune Legacy, remake of the original TBS game (careful when trying that one, if you close it it will happily continue to run in the background, even outputing sound, and eat your battery. kill it with kill -9.)
Wow, amazing! I am a former long-time Amiga user, so I’ll love to have this on my SFOS phones, even just to watch from time to time some of those fantastic Amiga demos
I’ve just installed it (for this I needed to find and manually install some other libmpeg2 version containing mpeg2convert.so that the amiberry binary was demanding) and it does start, but unfortunately the GUI opens in portrait (and apparently with a hardcoded 800x600 resolution) which makes it so tiny that it is completely illegible even on the XA2 Ultra’s huge screen, and also there seems to be a problem with touch recognition (maybe resulting from that wrong hardcoded screen mode) as the GUI reacts to touch in a different place than tapped (few of the upper menu options can be selected by tapping half of the window lower, and the lower ones as well as the buttons on the bottom are not reachable at all).
If started without GUI by feeding the necessary options (model and kickstart 1.3 location) from the command line, it only opens a black screen whereas there should be a white “hand with disk” screen shown… But maybe it takes giving it the correct screen mode to use via the -O command line option.
So it needs some tweaking when it comes to screen modes it uses. Sadly, I know absolutely nothing about SDL. Hopefully someone will be able to do it as it would be really neat to have Amiberry on SFOS!
I’m tinkering a bit with the packaging, trying to set some of the options so you may see updated RPMs you might want to check out.
The newer RPMs install all the data into /usr/share/amiberry, but will be configured to use $XDG_CONFIG_HOME/amiberry ( $HOME/.config/amiberry) for config and $XDG_DATA_HOME/amiberry ($HOME/.local/share/amiberry) for the other files, with recordings and screenshotes in ~/Music and ~/Pictures.
But all this is not finalized, things will change around a bit.
Just a quick note, take a look at input handling in the code. It’s very likely not going to deal with touch input in a reliable way, if at all. @sashikknox has some experience in this domain.
That’s the link to the example from jolla that I posted above. It’s not trivial though since you have to use custom build/clean/run steps. I’ve also just tried it (it did work in 4.3) and the opengl example doesn’t render.
I’ve just installed some Amiga emulators for Android from Google Play store and at least two of them (Uae4All2 and Uae4Arm) are also SDL2-based. Both have an SDL2-based GUI (and Uae4Arm GUI is identical as in Amiberry) and their SDL GUIs are working OK, i.e. good screen mode, autorotating and can be normally controlled with touch.
The emulation itself also has the right screen mode (autorotates, fills the display in landscape) and even touch works ALMOST fine - i.e. the pointer on Amiga Workbench can be controlled via touch screen, it’s just that there is a large discrepancy when it comes to coordinates - the pointer moves much faster than the finger, so I guess it needs some tweaking. But other than that, even click and double click work OK to the point that even in Workbench you can click icons, open folders, etc.
The following are screenshots from Uae4All and Uae4Arm for Android running on the 10 III.
Ah, thanks, that’s great to know. I just noted some odd behaviour in the sdk example I posted about (really delayed input handling) and @nephros appears to have patches, but I’m pretty sure that godot uses SDL2 for input and, albeit odd, I’ve gotten accurate (well, finger dependant!) position info in godot. I’ll go have a look at those android ports. Thanks!
Having played with both those Android Amiga emulators some more, I’d say that when it comes to screen mode and touch control they are ALMOST OK, the only problem being the inaccurate touch coordinates (the distance of the finger movement is translated into a much bigger distance of pointer movement). Other than that they’re OK if we don’t count some Android-related glitches like for example no access to folders outside of android_storage (I guess that Android permission to access external storage is missing) and things like that.
When it comes to speed, I launched SysInfo in Android’s Uae4All2 running on 10 III with 030 CPU, JIT and “fastest possible” options and I got 26 times the speed of Amiga 4000
However, when it comes to actual performance under load (e.g. when running demos fully utilizing the Amiga chipset - simultaneous graphics, music, etc.) while on the 10 III it is sufficient (relatively smooth), on the XA2 Ultra in horizontal mode (when the screen fills the entire display) it’s jerky and sound stutters a lot and only gets OK if switched to portrait where the emulated display is small.
So I guess that native Amiberry might deliver a much better performance given its advanced ARM optimizations.
I had to jump through quite some hoops to translate coordinate reading from mouse to touch based input in godot. I’m going to do some tests with Decker and the old sdk sdl example to see if I can find a good method in ‘plain’ sdl.
I’m so old now, I can barely keep up with my mac classic Sadly, I’m going to have to fix it first (was working the beginning of last year!). So, for now, being slow is not a disadvantage
These things can be fixed but it’s quite a bit of tweaking. off to debug.
produces (some code in the sdltest.cpp iteself) accurate touch input feedback. BUT, it uses opengl so that’s not really appropriate for the general case. Sadlly, it no longer renders any thing.
I do have a xrick sound theme though 
