CLI: Key Slots and path to the file

[kudomarkos]

Hello, i was trying the CLI version and I found two problems.

first problem:
If i have jgenesis-cli_0.8.3_x86_64.AppImage and Sonic.md in the same folder and i run
./jgenesis-cli_0.8.3_x86_64.AppImage --file-path Sonic.md
or
./jgenesis-cli_0.8.3_x86_64.AppImage --file-path ./Sonic.md
or
./jgenesis-cli_0.8.3_x86_64.AppImage --file-path "Sonic.md"
or
./jgenesis-cli_0.8.3_x86_64.AppImage --file-path "./Sonic.md"
or with ' instead of ", the program answers:

Error: Failed to read ROM file at 'Sonic.md': No such file or directory (os error 2)

Caused by:
    No such file or directory (os error 2)
    

It only works if i write ALL the route:
./jgenesis-cli_0.8.3_x86_64.AppImage --file-path "/home/kudomarkos/AppImagenes/Sonic.md"

second problem:
About mapping and saving or loading states
SaveState -> 'Key: F5', LoadState -> 'Key: F6', NextSaveStateSlot -> 'Key: ]', PrevSaveStateSlot -> 'Key: ['
If i press F5, ok it saves the game in slot 0 in the folder of.... QUESTION: the AppImage's folder or the ROM's folder?
[2025-01-06T10:44:09Z INFO jgenesis_native_driver::mainloop] Saved state to slot 0 in '/home/kudomarkos/AppImagenes/Sonic_0.jst'
If i press F6, ok it loads slot 0
But, if I press [ (ctrl + alt gr + [ ) in Spanish Keyboard and later I press F5 to save it... presumely in slot 1:
[2025-01-06T11:22:19Z INFO jgenesis_native_driver::mainloop] Saved state to slot 0 in '/home/kudomarkos/AppImagenes/Sonic_0.jst'
Tadaaaa!!!!! It has overwritten my Slot 0 state !!!!!!

I wonder if we need more keys.. or if you can ... overlay a context menu like the MAME CLI used to do
When you press F5 a overlayed menu appears with the options (save slot 0, slot 1..... slot whatever.. and BACK TO GAME for those they really dont want to save anything, only testing)
and when you press F6 a overlayed menu appears with the options (load slot 0, slot 1..... slot whatever... and BACK TO GAME for those they really dont want to load anything, only testing)

I had no idea about rust, sorry... maybe it is impossible
MAME version:

Thanks so much for this amazing app.

[jsgroth]

Relative File Paths (AppImage)

The relative file path issue is specifically with the AppImage builds, because the AppImage runner chdirs to a directory inside the AppImage package rather than running the executable from your shell's current working directory. Absolute file paths work as you noted.

I agree that this is extremely unintuitive and I'd like to fix it. In the context of a user-supplied CLI arg, I don't think there's any good reason to assume that a relative path is relative to the AppImage run directory rather than the shell CWD.

The AppImage runner exposes the original working directory through an env var (OWD) so I can use that if it's available and the input file path is relative.

Key Config

It sounds like the emulator is not recognizing the [ or ] key, otherwise it would show some text like "Selected save state slot N", like this:

I'll need to do some testing to figure out exactly what is happening but it looks like probably an issue with some non-US keyboard layouts - I see that the Spanish keyboard layout has ` and + in the positions where US layouts have [ and ]. I'll need to experiment to see what makes the most sense in terms of improving this behavior.

There's a related issue which is that there's currently no way to customize input mappings using the CLI. The CLI will read and use any input settings that are configured using the GUI (they share the same config file), but there's no way to change input mappings in the CLI without manually editing the config file. I'm not really sure the best way to improve this - right now I would say to use the GUI if you want to customize input mappings, even if you plan to only launch games using the CLI.

There are hotkeys for saving & loading individual save state slots but none of them are mapped by default. Implementing some sort of overlay for saving/loading states is definitely possible, but it might be a decent amount of work to get something working in a way that it's possible to navigate using the keyboard or a gamepad.

[jsgroth]

I can confirm that the default next/previous slot mappings of [ and ] do not work at all with a Spanish keyboard layout. The ' key doesn't work either.

There's also a problem where if you map the ` or ´ key in the GUI (locations of [ and ' on a US keyboard), the mapping will work temporarily, but it will stop working after you close and re-exit.

I think the problem is that internally the input mapping code is using SDL keycodes (what key was pressed in the current layout) where it should be using SDL scancodes (physical location of the pressed key), and maybe converting to a keycode for display in the GUI and in the config printout.

[kudomarkos]

Thanks so much for confirming.
I can't imagine how many diferent country keyboard layouts exist...
" it should be using SDL scancodes (physical location of the pressed key)"

or maybe the problem is I need to press 3 keys to write [ while you only 1... So jgenesis doesn't understand what key i am pressing... crtl , alt or `

By the way, thanks so much for spending your time with this problem.
I appreciate a lot this app.
Thanks

[jsgroth]

fyi the relative file path issue is fixed and will go into the next release.

or maybe the problem is I need to press 3 keys to write [ while you only 1... So jgenesis doesn't understand what key i am pressing... crtl , alt or `

Well, it sees that all three keys are pressed, but it reads this as Ctrl and Alt and ` each being pressed separately so it doesn't trigger the [ input mapping. This is because the emulator is watching individual key press/release events rather than trying to determine what character that key combination would produce in a text input. From what I could tell there is no key in the Spanish layout that will match a [ input mapping or a ] mapping.

I tested using SDL scancodes for input mapping instead of SDL keycodes, and that does fix all of these issues with the Spanish layout, but I was seeing some odd behavior with the Ctrl/Alt/Shift modifier keys when using custom layouts that change the positions of those keys (e.g. swapping Left Ctrl and Caps Lock). It might work to do a hybrid approach where modifier keys use SDL keycode for input mapping and all other keys use SDL scancode, but I'm going to need to do a lot of testing to make sure that doesn't have any unexpected effects for customized layouts.