solarus-1.6: request for comments and testing

hhromic

Hi all, I just sent now a PR to add the new Solarus version to RetroPie: https://github.com/RetroPie/RetroPie-Setup/pull/2813

I've been testing it a lot myself and all seems to be working fine. We also now added the official theme assets from the Solarus Team to the Carbon and Simple themes, so you just need to update these themes normally from your RetroPie packages menu to obtain them.

The above means that the section "INSTALLING OFFICIAL THEME ASSETS FOR EMULATIONSTATION" is obsolete now and is no longer necessary.

cyperghost

@hhromic Thanks for this one!

EDIT:
About the question from Shakes(pie)r : To ports or not to ports

I think you can consider a simple shell script like I've done several times for OpenBOR, ecWOLF or Commander Genius.
A selection menu for this specific game ... For example like here: Commander Genius

It needs just slight modification with find command and the dialog listing (keep aware of the --no-items switch!). What do you think?

hhromic

@cyperghost thanks for the thanks!

I just read your post and I already merged the Solarus PR by now :)

I had a long struggle with the "ports or not ports" dilemma indeed. However I decided the best is to be consistent, and other game-engines in RetroPie already work like a system, for example: Löve, AGS and ScummVM. Solarus deserves the same level of citizenship!

At some point I also thought of a game selection menu but then EmulationStation is designed precisely for this function already, so why not use it for what it is? Besides, Solarus is designed to run many kinds of quests, not just Zelda-type games after all. Also, the Solarus Team guys made official EmulationStation assets too (on my request).

I think Solarus as a system is the perfect fit, specially considering that Solarus quests are now distributed as single standalone .solarus files.

hhromic

Update

Solarus is now officially updated to the latest version. This brings OpenGL ES acceleration and support for newer games from the Solarus Games website.

You can find Solarus in "Manage Packages -> Optional -> Solarus".
Don't forget to update Carbon and/or Simple themes if you are using them to get the new Solarus theme assets.

cyperghost

@hhromic said in solarus-1.6: request for comments and testing:

@cyperghost thanks for the thanks!

I just read your post and I already merged the Solarus PR by now :)

I see ;)

I had a long struggle with the "ports or not ports" dilemma indeed. However I decided the best is to be consistent, and other game-engines in RetroPie already work like a system, for example: Löve, AGS and ScummVM. Solarus deserves the same level of citizenship!

Yes indeed I think this is the best solution for this nice game-engine

At some point I also thought of a game selection menu but then EmulationStation is designed precisely for this function already, so why not use it for what it is? Besides, Solarus is designed to run many kinds of quests, not just Zelda-type games after all. Also, the Solarus Team guys made official EmulationStation assets too (on my request).

Of course but unfortunately there are other game engines that deserves the same status. OpenBOR for example but this seems a bit underestimated game-engine. And annother fact is that official development team simply gots zero interest for an official port for Raspberry. I think that's the biggest issue...

I think Solarus as a system is the perfect fit, specially considering that Solarus quests are now distributed as single standalone .solarus files.

Furthermore it's the task of every scripter/coder/developer here to make the ports ready for usage as own system. It's really easy because most game-engines offers command line inputs together with the insane ability of RetroPie for adding own "emulators" with own "ROM" variable it's very easy to add new systems inside ES.

To close the loop ;)
Yes I read the comments on github whereas the question of port locations was still open. I personlly don't like overgrown entries in ports menus (maybe 5 or 6 entries per game engine is okay) so these selections menus are a good way to save space and to give back overview.

So I've established these selection menus for Commander Genuies, ecWolf (not announed here) and OpenBOR. This will otherwise result in a total plus of 50 entries ;)

Furthermore I don't like to hack "in" own game systems, because my skill in design lacks a bit and so own badges of a new system will look ugly.

Your newesr PR pushes all these askings aside. Well done! Thank you again

cyperghost

@hhromic
One small suggestion for setup.
~~Cancel Button unsets~~
~~Blank sets default 9+10~~

Edit better: default value is "9+10", inputbox supports defaults
Please test as I'm on vacation and can't try --- it should work ;)
and you should still use cancel for abort and nothing happens
Because if you need a keyboard to set the correct value you can delete the default values and set the new ones... I assume that 9+10 is very common :)

  Q)
                cmd=(dialog --backtitle "$__backtitle" --inputbox "Please enter joypad button numbers to use for quitting separated by '+' signs (leave BLANK to unset)\n\nTip: use 'jstest' to find button numbers for your joypad" 12 65 "9+10")
                choice=$("${cmd[@]}" 2>&1 >/dev/tty)
                if [[ $? -eq 0 ]]; then
                    if [[ -n "$choice" ]]; then
                        iniSet "QUIT_COMBO" "$choice"
                    else
                        iniDel "QUIT_COMBO"
                    fi
                    chown $user:$user "$(_options_cfg_file_solarus)"
                fi
                ;;

ellohir

I tried it today and it works beautifully! I played a bit of Tunics, the idea of doing a Zelda roguelike is something I had in mind from a while and it's so cool to have it on my system now :)

I had one problem with the installation though. At first it seemed like Emulation Station didn't see the system, but I remembered that I'm using the systems.cfg from my home directory (I have been toying around with adding Pico-8 as a system and not a port). I just copied the system definition from /etc/emulationstation/es_systems.cfg to ~/.emulationstation/es_systems.cfg and it worked.

Looking forward to trying the other Solarus games!

hhromic

@cyperghost said in solarus-1.6: request for comments and testing:

@hhromic
One small suggestion for setup.
~~Cancel Button unsets~~
~~Blank sets default 9+10~~

Edit better: default value is "9+10", inputbox supports defaults
Please test as I'm on vacation and can't try --- it should work ;)
and you should still use cancel for abort and nothing happens
Because if you need a keyboard to set the correct value you can delete the default values and set the new ones... I assume that 9+10 is very common :)

I thought about that as well (providing a default). However until we have symbolic button names in Solarus (which is coming soon actually) I don't want to assume any raw button numbers without good testing. I understand is unconvenient :/

Which gamepad you used to obtain 9+10 for quitting? is that HOTKEY + START for you as well? I have an original PS3 controller and 9+10 are the PS button + START. But I'm not sure if we can assume these numbers for most controllers? can we?

If that is the case, then maybe I will consider defaulting to these numbers indeed.

Thanks for the feedback, appreciated!

hhromic

@ellohir said in solarus-1.6: request for comments and testing:

I tried it today and it works beautifully! I played a bit of Tunics, the idea of doing a Zelda roguelike is something I had in mind from a while and it's so cool to have it on my system now :)

I'm really glad it's working fine for you! Thanks for the feedback!
I also found Tunics! a very interesting experimental game.. procedurally generated zelda dungeons!
Beware that some Solarus games are a bit too beefy for the Raspberry Pi, at least for the 3B+. I will be testing Solarus on a RPI4 as well, should work much faster!

I had one problem with the installation though. At first it seemed like Emulation Station didn't see the system, but I remembered that I'm using the systems.cfg from my home directory (I have been toying around with adding Pico-8 as a system and not a port). I just copied the system definition from /etc/emulationstation/es_systems.cfg to ~/.emulationstation/es_systems.cfg and it worked.

Ah yes, unfortunately RetroPie doesn't cover automatic system adding to custom setups. But good you sorted it out !

Looking forward to trying the other Solarus games!

Have fun! and report any problems if you find them, so we can improve the engine and/or the integration. Thanks!

ellohir

@hhromic said in solarus-1.6: request for comments and testing:

Which gamepad you used to obtain 9+10 for quitting? is that HOTKEY + START for you as well? I have an original PS3 controller and 9+10 are the PS button + START. But I'm not sure if we can assume these numbers for most controllers? can we?

Just FYI I have a 8bitdo SN30 (the SNES bluetooth one) and my keys were 10+11.

cyperghost

@hhromic I have an idroid:con and a 8bitdo Zero - for both 10+11 for Select+Start

I've a list of lots of controllers provided by older versions of Batocera - here in this link.
And it seems that PS3, XBOX360 use dedicated Hotkey+Start as 9+10
Seveal controllers using 10+11
But all in all it seems like a mess

Did you consider the usage of es_temporaryinput.cfg?
This will show the last configured PAD as input.
And everything can be read out from this file ;)
So a grep search for hotkeyenable and start should do the job.
And you can say: I've found hotkey combo value+value for PAD deviceName
If the file is not present then plugin Keyboard and make your own config.

For example in this thread

Example config

ts-x

Is there a way to install v1.6 on a RetroPie 4.3 build? I've tried a couple of different approaches with no success. I had previously installed and been using the old version (v1.4.5?). The best path so far has been to uninstall the old version, replace the setup script with the latest, and then install fresh. Run this way the process seems to download the necessary files, creates a solarus ROM directory, adds to es_systems.cfg, but then stops without an error message. I believe it's right before it begins building the files, based on a test installation I did on a dummy 4.5.1 image.

Any thoughts? Thanks for the help!

cyperghost

@ts-x What error are you receiving?
There was not much change in dependecy tree (add of libogg-dev) only

Try to upgrade your package lists with sudo apt-get update

ts-x

@cyperghost I'm not actually receiving an error message, it begins installing and returns to the install menu like the process has successfully completed. I updated the package list per your instructions, but the process still does the exact same thing. Based on my observation of a 4.5.1 install, I believe it's running into some sort of problem right before the file builds. The only file the script places under /opt/retropie/ports/solarus is solarus.sh, so attempting to open a game file yields this runcommand.log ...

Parameters: 
Executing: /opt/retropie/ports/solarus/solarus.sh "/home/pi/RetroPie/roms/solarus/zelda-roth-se-1.2.1.solarus"
/opt/retropie/ports/solarus/solarus.sh: line 7: /opt/retropie/ports/solarus/bin/solarus-run: No such file or directory

ts-x

@cyperghost Caught the error message via a cell phone video...it's an issue with SDL2. I have version 2.0.5 and it's looking for 2.0.6 (RetroPie v4.4 went from 2.0.5 to 2.0.8). Is it possible to upgrade?

cyperghost

@ts-x imho yes it's possible to upgrade. If it's not a default package then you need to compile on your own. But I'm not sure if Open GLES will do its work then.

hhromic

Sorry guys for the delay replying, been a bit busy :)

@cyperghost thanks for the feedback on the controller buttons. Indeed I thought about extracting them from retroarch.cfg or EmulationStation but in the end is too much trouble considering that we are working on bringing proper gamepad support natively on Solarus anyway so I prefer to spend my efforts on that instead.

@ts-x indeed as you discovered yourself Solarus 1.6 requires SDL 2.0.6 or better which comes with Debian Stretch or better.

What you can try to do to upgrade is to backport the sdl2.sh scriptmodule from newer RetroPie (like you did for the solarus scriptmodule) and reinstall the RetroPie SDL2 package doing: sudo ./retropie_packages.sh sdl2. However I would make a backup before attempting this as I'm not sure it's gonna work reliably.

Good Luck and let us know how it went.

cyperghost

@hhromic Thanks for feedback

One question how are these buttons working? HOTKEY(START)+SELECT terminates Solarus, like the libretro-cores? Or will a menu pop up if you press HOTKEY(START) or SELECT and then you can select a menu entry to quit. If this will happen I would strongly suggest to use 9+10 as default. This will cover 90% of usecase

Sorry I can test this WE only? Currently using Windows builds but this engine is amazing!

~~Yes and as you suggested SDL2.0.8 is available as~~
Hmm I see SDL2.0.2 DEBIAN jessie build only.

@ts-x
Maybe it works with sudo apt-get update && sudo apt-get upgrade to get SDL working

hhromic

@cyperghost said in solarus-1.6: request for comments and testing:

@hhromic Thanks for feedback
One question how are these buttons working? HOTKEY(START)+SELECT terminates Solarus, like the libretro-cores? Or will a menu pop up if you press HOTKEY(START) or SELECT and then you can select a menu entry to quit. If this will happen I would strongly suggest to use 9+10 as default. This will cover 90% of usecase

I implemented it like in RetroArch, once the combination is detected it simply calls the shutdown routine of the engine immediately. Nothing fancy as the engine relies 99% on the Quests for user interaction therefore asking all quest makers to implement such a menu is not feasible.

Hmm I see SDL2.0.2 DEBIAN jessie build only.
@ts-x
Maybe it works with sudo apt-get update && sudo apt-get upgrade to get SDL working

Please note that the solution I proposed on my previous post uses RetroPie's version of SDL2 (which you should use) which is built independently of any packages in Debian.

ts-x

@hhromic + @cyperghost Thanks again for the assistance. I upgraded SDL2 on a test image per @hhromic's instructions - Solarus 1.6 does install and the 1.6 compatible versions of the two games I tried seem to operate normally. I haven't thoroughly tested, but at a minimum the SDL2 upgrade breaks N64 emulation. Given that, I'm hesitant to apply the same upgrade to my main, almost 2 years in the making 99.9% complete image.

As a fall back, I was thinking of modifying the original 4.3 script to install Solarus 1.5.3 (instead of 1.4.5) and then using the latest pre-1.6 versions of all games (dx 1.11.1, roth 1.1.0, xd 1.11.0 + xd2 1.0.5). @hhromic given what you know about the source, any reason that approach might not work? Is it worth the pre-1.6 version upgrade for all?