wizzomafizzo / tapto

Launch games using physical objects
GNU General Public License v3.0
64 stars 9 forks source link

Support for tty2rpi #68

Open ojaksch opened 5 days ago

ojaksch commented 5 days ago

I'm the author of tty2rpi (and co-author of tty2oled) and got a user's request to add TapTo support. While TapTo already supports tty2oled it would be logical to add support for tty2rpi into TapTo than vice versa.

If that request is acceptable to you I would add the needed info here what variables, files and strings to use and to send... no russian rocket sience there and only a few lines of code.

wizzomafizzo commented 5 days ago

Hey! Absolutely, love to add support. Let me know what needs to happen

asturur commented 5 days ago

Consider that if you want to add something else cool to tty2rpi, there is also a different possible integration, mrext supports a websocket endpoint that informs you of current game loaded but also current game highlighted in the menu. With a dedicated rasbperry project like yours, the RPI could listen to the websocket and reflect changes on game load and menu navigation

ojaksch commented 5 days ago

Great! The process is simple. The device is defined in the file /media/fat/tty2rpi/tty2rpi-user.ini (MiSTer) as a variable, similar as in tty2oled: TTYDEV="/dev/tcp/IP-ADDRESS-OF-RPI/6666"

There are two functions in tty2rpi (on the RPi side), one simply displays the loaded Core (for example NEOGEO), the other is doing the same plus the loaded game as set in MiSTer's /tmp/CURRENTPATH if log_file_entry=1 is set in mister.ini

That said, the logic is

NEOGEO here is an example of the active Core as stated in MiSTer's /tmp/CORENAME. 1945kiii here is an example of the loaded game as stated in MiSTer's /tmp/CURRENTPATH.

I think it's up to you to decide whether to respect log_file_entry or to just use your own setting of "USETTY2RPI=true" or something like this.

ojaksch commented 5 days ago

@asturur Thanks for that hint! I'm using my own socket but will keep mrext in my mind. For now I won't force my user to use mrext as a dependency to keep the setup as simple as possible. I think some or most of them or Linux beginners and are already challenged ;)

wizzomafizzo commented 4 days ago

Having a think about this, maybe there is a simpler way to get this working. Are you aware that both Remote and TapTo write the launched game to /tmp/ACTIVEGAME? Everything in the mrext repo should write to this file when it launches something.

You can test this file exists to see if either is running (they create an empty one on startup), and then monitor it like CORENAME to get the full file path to the game that was launched.

A couple of notes with it:

If you can support this method, you'll actually have automatic support for everything I've made rather than just TapTo.

ojaksch commented 4 days ago

Thanks for the headup! I'll have a deeper look at it the next days (very busy over weekend :disappointed: ) and report.

EDIT1: Did a quick test with the Remote, /tmp/ACTIVEGAME is created and the Remote UI is available and working. But no matter what game I choose in MiSTer's menu or in the Remote UI, /tmp/ACTIVEGAME remains empty and never got touched/updated (timestamp still at date of creation).

EDIT2: Ah, just explored that /tmp/ACTIVEGAME seems to be be updated only when starting a game in Remote's "Games" section...

ojaksch commented 4 days ago

So far so good and working, but what I'm missing is that "under some circumstances" (ie while running Remote but starting something per MiSTer menu or starting an arcade core) /tmp/ACTIVEGAME doesn't get touched. It would be easier to "inotifywait" for it to get touched even if it remained empty.

wizzomafizzo commented 4 days ago

Do you have the recents feature enabled in your ini? This is necessary for the game tracking service to work and update for all games. Otherwise yeah it'll only update the file when Remote or TapTo itself are the ones launching

ojaksch commented 3 days ago

It's getting better and better after enabling recents, but there are still sometimes situations where /tmp/ACTIVEGAME isn't getting updated. While most Computers, Consoles and games are working and displayed, I was jumping to /Games/_Arcade/ in Remote and selected one and another there but ACTIVEGAME isn't getting touched.

wizzomafizzo commented 2 days ago

In the case of Arcade games specifically they won't be populated in this file because they're cores rather than loaded files. It's intentional. You'd have to still rely on the CORENAME file like usual.

I've thought about it but just decided it complicates things too much. It's actually not possible to see what .rbf file is loaded in memory, and a core can set the "corename" to anything it likes. You also can't inspect an rbf file and see what corename it would set. So it's just impossible to reliably resolve either way.

If you need a unified way to get this information where Arcade counts as a "game", you could send an HTTP request to the Remote REST API to get this information. But you won't be able to wait for it to change like with inotifywait, you'd have to poll it repeatedly (which is ok too, it's not resource heavy)

wizzomafizzo commented 2 days ago

Personally I would recommend using a combination of CORENAME and ACTIVEGAME to cover all the cases.

ojaksch commented 2 days ago

I see and understand, but wouldn't it be enough just to touch the ACTIVEGAME and/or to write nothing to it (leaving it empty). I'm already watching CORENAME and ACTIVEGAME (and others) but the actual situation (with Remote) requires several ifs and thens to compare which of these files has changed and what happened to the remaining ones.

Sure, I can write some lines of code/logic to address this, but imho the not-touched ACTIVEGAME is an exception that leaves the usual process how MiSTer handles it's files in /tmp ...

wizzomafizzo commented 2 days ago

Fair enough! I've made a change to TapTo's game tracker that will write the corename to ACTIVEGAME if the game is an Arcade core. It'll be in the 1.5 release. A copy of it is attached.

tapto-1.5-activegame.zip

I'll make the same change to Remote. I'll try get a new release of that out soon.

ojaksch commented 2 days ago

Great, thanks! Will continue tomorrow when weather changes from today's 25°C to 19°C :sun_behind_rain_cloud: