Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feature request] Star Raiders Video Touch Pad Control #963

Open
Cibomatto2002 opened this issue Mar 19, 2023 · 17 comments
Open

[feature request] Star Raiders Video Touch Pad Control #963

Cibomatto2002 opened this issue Mar 19, 2023 · 17 comments

Comments

@Cibomatto2002
Copy link

Is there any plans for this game to ever be fully playable on Retroarch?

@thrust26
Copy link
Member

The touchpad is identical to a keyboard controller. Both have 12 buttons. How should we map them?

A joypad has 16 buttons, 8 are used for console switches. That only leaves 8 buttons. We might optimize a bit here by using toggle events for color and difficulties, which would free 3 button. But that's still one button to few.

@Cibomatto2002
Copy link
Author

I don't see the keyboard controller in RetroArch all I see is Joystick, Analog, None. This game only needs 5 buttons on the Video Touch Control.
Atari

@thrust26
Copy link
Member

I don't see the keyboard controller in RetroArch all I see is Joystick, Analog, None.

The Touchpad technical is identical to a keyboard controller. It just looks a bit different.

This game only needs 5 buttons on the Video Touch Control.

Yes, but it has 12 buttons and I don't like the idea of implementing an incomplete solution. Does the RetroArch support a keyboard? This would fit best here.

@Cibomatto2002
Copy link
Author

I greatly appreciate the time you spent working on this.

@thrust26
Copy link
Member

Maybe someone with good RetroArch/Libretro knowledge could give us some hints here, how we should map the keyboard controller?

@sa666666
Copy link
Member

I wonder, is there an onscreen keyboard available for libretro? Maybe that can be used instead of a real keyboard (which many users of libretro wouldn't be using anyway). Libretro is available on many systems, and emulates many systems that have a similar requirement. I would think that this problem has already been solved, so someone should probably look to that to see what can be done.

@thrust26
Copy link
Member

I found that libretro.h also contains constants for the keyboard. However, I am not sure if it is the best way, to map the 2600 keyboard controllers to a real keyboard.

I have a lot of questions, maybe someone from the Libretro/RetroArch team can answer them:

  • How flexible is the mapping is. E.g. if I should map the 5 used Touch Pad buttons to a joypad and this doesn't support that many buttons, can the user remap these buttons to a different controller?
  • Can the code or the user map events for port2 on a controller in port1?
  • Is it correct that ConsoleLeftDiffA etc. are always mapped to the 2nd controller? The code seems to indicate this?
  • Would it be OK to use toggle events for the console switches? E.g. ConsoleLeftDiffToggle instead of ConsoleLeftDiffA and ConsoleLeftDiffB? This would free two buttons.

@thrust26
Copy link
Member

Today I tried, but the UI of RetroArch and my mindset are totally incompatible. Gave up completely frustrated. :(

@sa666666
Copy link
Member

sa666666 commented Mar 24, 2023

Yeah, we really need someone who is familiar with libretro internals. I don't think the task is impossible, but libretro is sometimes 'strange' in the way it interacts with emulators. We are not the first ones to notice this; I've seen other developers say similar things.

@Cibomatto2002
Copy link
Author

Could someone just make a hotkey you could hold down and press another button to active the Video Touch Pad Control?

@thrust26
Copy link
Member

The problem is, that I failed trying to implement the controller for the touch pad. The current code we use, is very much tailored to joypads and not from us. We really need support from the libretro team here.

@hizzlekizzle
Copy link

hizzlekizzle commented Mar 30, 2023

Hey guys, sorry for the radio silence. Thanks for looking into it on your end, and no worries, it's always tough digging around in foreign codebases/APIs/GUIs. :)

I took a quick look at this a few days back and didn't make a whole lot of progress, but I had some questions and answers that might help us all make more sense of the situation:

While Video Touch Pad is in use, am I correct in thinking it occupies the P1 controller slot? That is, so we we don't need a bunch of other functions while it's active? Does it need 12 buttons? If both of these things is true, we shouldn't have any trouble mapping it as another joystick-style input device (e.g., 4 of the buttons on the dpad, 4 on the ABXY buttons and 4 on the R1/R2/L1/L2). We could also potentially map stuff to the analog sticks to free up buttons that aren't used very often (and users can always move them around in the remapping menu).

to answer some of your questions, there are some cores that require putting specialized input devices into port 2 (lightguns are commonly handled like this), but you can't make input devices span >1 controller port. That is, you couldn't put some of the buttons on port 1 and some on port 2.

@thrust26
Copy link
Member

thrust26 commented Mar 30, 2023

@hizzlekizzle Thanks for the feedback. And no worries about the delay, after all we all have our real lives.

You count players and slots from 1, right? Then, for Star Raiders, the Video Touch Pad is in the P2 slot. And it only needs 5 buttons.

BUT: The Video Touch Pad just a differently designed (but technically identical) keyboard controller. These come in pairs, one for each port. And they have 12 buttons each. So I am looking for a solution to make use of them.

to answer some of your questions, there are some cores that require putting specialized input devices into port 2 (lightguns are commonly handled like this), but you can't make input devices span >1 controller port. That is, you couldn't put some of the buttons on port 1 and some on port 2.

And vice versa? Can port 1 and 2 buttons be (partially) merged into one port?

I would prefer, if the user has alternatives for the mapping. E.g. in case of Star Raiders, it might make sense to map the first 5 buttons of the Video Touch Pad on port 2 to the controller in port 1. And for games which make use of all 2*12 buttons, it might be best to map them to something else, e.g. a keyboard.

BTW: I tried freeing some joypad buttons, by merging the difficulty and color/B&W events into toggle events (e.g. ConsoleLeftDiffA, ConsoleLeftDiffB -> ConsoleLeftDiffToggle). The problem is, that for whatever reason, these events happen repeatedly. They should happen only once, else toggling the switches becomes random. Do you have any idea what I am doing wrong here? E.g. the select and reset events are not repeated.

@hizzlekizzle
Copy link

hizzlekizzle commented Mar 30, 2023

Ahhh, so basically 24 buttons are needed, but the fact that it occupies port 2 is nice, since it doesn't look like we have too much going on there currently (i.e., we don't need to shuffle around the stuff that's already going with port 1). Well, the retrokeyboard model might be your best bet in that case. Or else setting up a "shift" button, like "default to keypad 1 but hold select [or whatever] to switch to the second one". That's certainly doable, but might be confusingly obscure for users, dunno. Then again, that's what docs are for :)

The problem is, that for whatever reason, these events happen repeatedly

My wild guess there would be that it has to do with the functions that are calling them happening repeatedly (every frame, perhaps?). If that's the case, they might be able to move somewhere else that's called less often (though I'm assuming it's not enough to call them once on init and then expect them to stay the same until deinit?), or else add a check for "changes" in the button state instead of the button state itself (if that makes sense; that is, store the value and at the start of the frame check whether the current state is different from the stored value and, if so, update the stored value to match and trigger the event)

How do you guys handle these devices in your own GUI? Do you map them to the user's keyboard?

@thrust26
Copy link
Member

thrust26 commented Mar 30, 2023

Ahhh, so basically 24 buttons are needed, but the fact that it occupies port 2.

Yes and no. On the real Atari you can have two keyboard controllers, with 12 buttons each. One is in port 1 and one in port 2. Star Raiders is an exception, as it uses only one controller in port 2 (and joystick in port 1).

is nice, since it doesn't look like we have too much going on there currently (i.e., we don't need to shuffle around the stuff that's already going with port 1). Well, the retrokeyboard model might be your best bet in that case. Or else setting up a "shift" button, like "default to keypad 1 but hold select [or whatever] to switch to the second one". That's certainly doable, but might be confusingly obscure for users, dunno. Then again, that's what docs are for :)

How would I implement that in Stella's libretro.cxx file? It was originally written by someone (@sa666666 do you remember?) to support joypads only (see GET_BITMASK and MASK_EVEN macros). I somehow managed to add the lightgun support. But I have no clue how to modify the code for the "retrokeyboard".

The problem is, that for whatever reason, these events happen repeatedly

Not in Stella. There for such events, each key or button press causes two events (pressed, released). And if you hold the key for a while, it will repeat the two events. The toggle code only reacts to (pressed && !repeated).

My wild guess there would be that it has to do with the functions that are calling them happening repeatedly (every frame, perhaps?).

Which functions? Ours or yours? And why do the Select and Start buttons work without repeating, but the shoulder buttons do not?

If that's the case, they might be able to move somewhere else that's called less often (though I'm assuming it's not enough to call them once on init and then expect them to stay the same until deinit?),

No, you can (and sometimes have to) change while playing the game.

or else add a check for "changes" in the button state instead of the button state itself (if that makes sense; that is, store the value and at the start of the frame check whether the current state is different from the stored value and, if so, update the stored value to match and trigger the event)

Not sure what you mean. Stella runs with evens here, not states. The event is already a state change.

How do you guys handle these devices in your own GUI? Do you map them to the user's keyboard?

By default, yes. But you can map them to controller buttons as well. Or both. Stella has become quite flexible here.

@hizzlekizzle
Copy link

Which functions? Ours or yours? And why do the Select and Start buttons work without repeating, but the shoulder buttons do not?

It looks like it's happening in update_input(), which is being called in retro_run, which happens on every frame.

That's a good question about start/select. Are all of these handled the same in Stella? https://github.com/stella-emu/stella/blob/master/src/os/libretro/libretro.cxx#L182 That is, is it correct for all of these to be using the same "MASK_EVENT" macro? Or should the toggles be using the EVENT macro instead (possibly with the aforementioned *Toggle change)?

@thrust26
Copy link
Member

It looks like it's happening in update_input(), which is being called in retro_run, which happens on every frame.

Yup.

That's a good question about start/select. Are all of these handled the same in Stella? https://github.com/stella-emu/stella/blob/master/src/os/libretro/libretro.cxx#L182

I thought they are. But now I found that this is not true. I have to analyze why these are handled differently. And maybe we can make use of that difference. Anyway, that's a minor problem.

That is, is it correct for all of these to be using the same "MASK_EVENT" macro? Or should the toggles be using the EVENT macro instead (possibly with the aforementioned *Toggle change)?

No clue. I never really tried to understand what exactly the macro does. Some comments would have helped for sure.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants