cool, good to know this works, I will use it as a template for any future mobile repositories.
Ok, got ya.
I’m just cleaning up the rest (duplicate names in desktop) and it should be testable in a couple of minutes.
Hi, I’ve been uploading some löve ports recently to openrepos and I would like to receive some feedback which would allow me to make improvements.
Some of the submitted games have not touch controls completely implemented, this is due to complexity and lack of time but I still though they are worth submitting so that people could eventually contribute if interested or at least play with a keyboard (I know it’s not the best way but at least you can play the games on your mobile which was not possible before I ported them).
Feel free to give me feedback even if it is negative, is there any of the Apps I submitted not good enough or too early to submit in your opinion? All of them are available on releases in my codeberg repository so I don’t mind removing any if you don’t think they pass quality filters.
Feel free also to submit technical questions or request but I suggest to use codeberg instead so that they can be translated into solutions / fixes.
Thanks for any feedback and I hope you enjoy them!
1 Like
I found that many of them (but not all) do not start at all in SFOS < 4.5.
That is (likely) due to a bug combination in SDL and wayland and can AFAICS not be fixed in the love engine.
The message is this:
love: gralloc.c:133: hybris_gralloc_initialize: Assertion `NULL' failed.
Aborted
This issue has also affected the Qt5.15 effort and is the reason it’s not available on older SFOS versions.
Thread 1 "love" received signal SIGABRT, Aborted.
0x0000007ff78c6384 in raise () from /lib64/libc.so.6
(gdb) backtrace
#0 0x0000007ff78c6384 in raise () from /lib64/libc.so.6
#1 0x0000007ff78abce8 in abort () from /lib64/libc.so.6
#2 0x0000007ff78babd8 in ?? () from /lib64/libc.so.6
#3 0x0000007ff78bac40 in __assert_fail () from /lib64/libc.so.6
#4 0x0000007ff5ae22c8 in hybris_gralloc_initialize () from /usr/lib64/libgralloc.so.1
#5 0x0000007ff5b58518 in waylandws_init_module () from /usr/lib64/libhybris//eglplatform_wayland.so
#6 0x0000007ff56ed8bc in ws_init () from /usr/lib64/libEGL.so.1
#7 0x0000007ff56ec31c in ?? () from /usr/lib64/libEGL.so.1
#8 0x0000007ff777be7c in ?? () from /usr/lib64/libSDL2-2.0.so.0
#9 0x0000007ff77a3c2c in ?? () from /usr/lib64/libSDL2-2.0.so.0
#10 0x0000007ff7787664 in ?? () from /usr/lib64/libSDL2-2.0.so.0
#11 0x0000007ff7789118 in ?? () from /usr/lib64/libSDL2-2.0.so.0
#12 0x0000007ff7cd4a6c in love::window::sdl::Window::createWindowAndContext(int, int, int, int, unsigned
int, int, bool, int) () from /usr/lib64/liblove-11.3.so
#13 0x0000007ff7cd5a84 in love::window::sdl::Window::setWindow(int, int, love::window::WindowSettings*)
() from /usr/lib64/liblove-11.3.so
#14 0x0000007ff7cd7ee0 in love::window::w_setMode(lua_State*) () from /usr/lib64/liblove-11.3.so
#15 0x0000007ff7a3168c in ?? () from /usr/lib64/liblua-5.3.so
I changed phone and I currently have SFOS 4.5 and I discovered some of them (like boxclip) do not work on 4.5 but do work on old versions and also the opposite. Maybe a list stating which game work on which version would help?
All I can say is that all game starts but not in the same version…
Let me know which one do not start in your phone and will see if there’s anything I can do.
I’ve never experience that error you just posted, could you tell me which game causes it? is it at start or triggered by any specific event? also which SFOS version? I only have 3.4 and 4.5 to test.
As said above, if anyone wants the feedback to be eventually turned into solutions feel free to open issues on the repositories of any game and leave your SFOS Version, errors and events so that I can check and try to figure out how to solve them.
A very small nitpick about the .spec files:
Uninstalling a game leaves its dir in /usr/share/games/love.
Change the spec to ‘own’ the dir and that will not happen. So instead of
%files
%{_datadir}/games/love/Foo/Foo-mobile-x-y.love
...
do
%files
%{_datadir}/games/love/Foo/
Not very important though.
1 Like
so if I understand right
`%files
/usr/share/applications/sienna.desktop
/usr/share/games/love/sienna/sienna-mobile-v0.2-7.love
/usr/share/games/love/sienna/sienna.png`
should be:
%files
%{_datadir}/applications/sienna.desktop
%{_datadir}/games/love/sienna/
%{_datadir}/games/love/sienna/sienna.png
Due to the amount of games I ported and submitted I would test those changes on future releases and leave current releases as they are.
In case you think automating builds for any game would be useful I could add the spec files to the repositories.
I’ve been looking here and there at the games to try to pick which ones to put to chum first, since love is now in chum. But there numerous issues with haptic input handling which have stalled my efforts. For instance, trying the tetris game, I was unable to turn tiles, although I could move them left and right. Am I just missing something?
1 Like
which ones have you tried that are only > 4.5 ? I haven’t that much time at the moment, but would try to do some haptics debugging and chum packaging in the next weeks. Perhaps with the ‘best performers’ first?
The only one that gets stucked and crash on start on my 4.5 Sailfish phone is boxclip.
You are completely right, I confirm the same problems, I think pressing the button is rotating the pieces twice which causes to only turn it 180°, but you can indeed turn the tiles, the problem is that buttons are too small and tricky to press, I will fix that in the future.
My touch controls are very far from perfect, but no one has done anything better so far (I mean with thumbstick emulation) and they should be considered a first step towards porting the games to mobiles. I hope I manage to improve them a lot more in the future.
The touch controls used on the games are my first gamepad designs, I’m experimenting with making the buttons with different sizes and space between them and with thresholds and other parameters.
There are no flawless game, I’m improving them but it will take a lot of time to have them flawless (if ever happen).
The games that currently have 5 stars from users are: gravitonik, space engine and culator4 (which is a calculator).
The last one I added called sienna have in my opinion one of the best touch controls already, this is due the fact that they were already there and that they make use of swipe gestures to navigate menus and tap to control the player (you can only jump so no need for thumbstick emulation).
Whatever game you are interested to automate the packaging (since there’s nothing to compile) just let me know and I will add the missing spec files to the repositories.
3 Likes
I’ve made changes to the touch layouts and implemented the changes on gravitonik. I will test the new Touch layouts on gravitonik first since is the first game to have a good rating and depending on the received feedback I would eventually translate those changes to other games. Anyone interested on checking the new touch layout iterations and provide feedback feel free to test last versions of the game.
The changes are made only for landscape mode so make sure you rotate the phone before reviewing it. Thanks!
2 Likes
The layout, design and parameters used on the touch controls of gravitonik are now translated to Mr.Rescue, the design is exclusively made for landscape mode so you have to rotate the phone in order to play those games (orientation is automatically detected).
Two games which play in portrait mode have now a new input layout with new parameters that affects sensitivity for the virtual thumbstick and they should be fully playable now: Block Drop and love tetris.
To save time ( a lot of testing work is needed to test and edit all the parameters and layouts any time I change them) I will use both the portrait and landscapes designs as a template for any future game that requires them and simply slightly modify them to meet any specific needs. So basically any feedback regarding the touch inputs on those games would eventually be used and transferred to other games that need them based on the phone orientation.
Feel free to provide feedback and I hope you find them comfortable.
I’ve recently implemented framerate measuring tools on boxclip which is currently the most demanding love2d game I submitted (and that I know so far) and I think it would be interesting to know how every device performs.
The instructions are on the game’s repository but it is very straightforward for anyone interested to try it:
-
Click on Menu on top of the screen during the initial menu state and select “FPS Button” → From version 0.2-2 you also have that option on the pull menu and you can pull it anytime even during gameplay.
-
Click the red touch button to start the game
You can add to the steps testing the performance mode: On the same menu where the FPS button is, there is a so called “performance mode”. The performance mode reduces parallax complexity and boost FPS a little bit.
Since most of the devices would not hit 60fps and the program automatically detects fps and turns performance mode when the device does not hit 60fps, it is very likely that you already are in performance mode and selecting performance mode will toggle it (also turn performance mode off). You will be able to distinguish both modes by the background: on performance mode there is only one layer and looks gray and on normal mode the background looks green (due to the seasons based coloring mechanism the game has which assigns different colors to each of the layer based on a theme based on so called “seasons”).
I think it would be interesting to know the performance of other devices. I wonder if there is any device yet in the market that really hit 60fps which is the limit to not automatically enable the performance mode.
Any question on how to follow the steps above or issues following them feel free to ask.
1 Like
I’ve recently added a new version of boxclip, I will make a pause with the game and it could probably be the last one, at least on the short term. Feel free to contribute or report any bug to the repository.
As explained on the log on open repos, the new version improves the parallax in performance mode by mirroring and shading the lower part of the parallax filling that way the screen with a kind of lake effect.
The second add on that new version is the network controls which now can be pulled from the pull menu.
The network feature purpose is to allow game control from an instance of my other app called “Virtual-gamepad” and it is in beta phase (it works partially but intended for developers and betatesters not for regular users).
I succesfully tested the feature from a pc and from another mobile. Basically you can move the character (jumping is not implemented) with a gamepad conected to a pc or with the touch controls on another mobile and the controls will be received by the game provided that:
The sending ip of the virtual gamepad and the boxclip ip match (both programs have by default sending ip 192.168.178.37 on port 1024 and 192.168.178.34 port 1025 for listening.
The network menu is not fully working and there’s no way to set up the ip without hardcoding for now, but you can enable remote control on boxclip network’s menu and start testing provided that the client and server have the right ip.
Do not have big expectations, you can only move the player to the left and right and is laggy and buggy but it reacts.
I’ve added to boxclip recently online multiplayer with split screen, zoom and a lot of extra features many of which are work in progress and touch some parts of love’s api which are an uncharted territory to me such as networks, that’s why things like that are unfinished but eventually contributors could finish them or build upon them and complete the features.
Some of the features really pushes the hardware but they are optional, if your mobile can’t handle them smoothly you can simply not use them.
For now I’m not adding anything else, if you want to see more content I would suggest to open an issue on the original developer’s project (Issues · Jigoku/boxclip · GitHub) so that contributors and the original developer are aware of my fork. Since the project has no update in the last two years people may think the project is dead and they could eventually be interested in what I added lately and maybe merge the two repositories or contribute to my fork? just wondering… I don’t have a github account so I can not open an issue linked to my project.
The project has a lot of potential for growing since is much more than a game: it’s a full engine with which you can create full platform games and levels without writing a single line of code.
Feel free to add your wishes, bugs reports or feedback to issues on my repository on codeberg or the original repository.
I hope you enjoy the game!
1 Like
I did not find the reason for the performance penalty that happens on sailfish os, anyway it only affects one game: “boxclip” which is too demanding due to the ammount of parallax and shaders that happens simultaneously through the game.
I found a plausible reason and maybe someone could confirm that is the case: encryption. From what I’ve read from other users encryption in sailfish os consume a considerable amount of resources and could be the reason for the performance penalty… I though that would only affects performance during read / writting task but apparently it also happens while games are already loaded and on ram?
If anyone installed sailfish without encryption it would be helpful to know if “boxclip” performs better there.
No idea, again in case anyone has a hint I’ll be glad to know… I don’t even know if there’s a solution to that problem.