search

stella-emu / stella

A multi-platform Atari 2600 Emulator
https://stella-emu.github.io
GNU General Public License v2.0
611 stars 112 forks source link

(libretro) lightgun/analog support #865

Closed StormedBubbles closed 2 years ago

StormedBubbles commented 2 years ago

Hello again,

I recently became aware of the libretro port of Stella, and I have it up and running on my Raspberry Pi. RetroArch's built-in ability to apply overlays allows me to easily apply a border to the game area and use my Sinden lightguns in emulators that have lightgun support.

I browsed through stella/src/libretro/libretro.cxx and noticed that the lightgun appears to not be mapped to any control input in lr-stella.

RetroArch has a lightgun API (as mentioned in stella/src/libretro/libretro.h) that can grab a mouse cursor and allow mouse devices to act as a lightgun. I am curious if the lightgun feature could be brought over to the libretro port from standalone Stella.

thrust26 commented 2 years ago

We would need support for testing. Can you provide that?

StormedBubbles commented 2 years ago

Absolutely! I have already aided with testing lightgun support / reporting bugs with a few other emulators and am happy to help.

thrust26 commented 2 years ago

Cool. Though it may take quite a while until we come back to this. Real lightgun support is probably too much for a start. First I would like to aim for mouse support for lightgun games in Libretro. There I have multiple open questions and no one of the Stella team can answer these. We need some support from the Libretro team here too.

StormedBubbles commented 2 years ago

Thanks! I am subscribed to this discussion and will get notifications of new messages.

My experience with Libretro lightgun support is that it grabs the mouse cursor of the mouse you identify as your lightgun and uses a transparent cursor or optional emulator-specific stylized cursor/crosshair to aim. Using a regular mouse is fine in this mode, but there are more technical details with respect to absolute vs relative coordinates (that I do not have a handle on) that allow lightgun-like mouse devices to function better than they would in a raw mouse mode.

thrust26 commented 2 years ago

Unfortunately I go no feedback from the Libretro team yet. Maybe you have some contacts you can activate?

StormedBubbles commented 2 years ago

I have had interactions with devs of other Libretro emulators who definitely have the know-how to look into this. I brought this up to my friends in the Sinden community to see if there's anyone we know willing to take a look. I can ping a helper into the conversation if we locate someone 😃

StormedBubbles commented 2 years ago

Summary of some info I received about connecting the standalone emulator's gun support to the Libretro port:

Need to have an absolute-coordinate function in the lightgun code which overrides the incremental code used by mouse/gamepad/other for an emulated lightgun, and that is somehow hooked into RetroArch from the Libretro side.

I am in the process of contacting people to see if they are interested in helping.

barbudreadmon commented 2 years ago

Hi,

FBNeo dev here, i was asked for help :). Here is a libretro api call to query inputs : 

input_state_cb(port, devive_type, index, id);

If you got other questions, i can probably answer them.

thrust26 commented 2 years ago

@barbudreadmon Thanks for offering support! 👍

Yes, I have many more questions: For a start, we want to play the games using a computer mouse. So you are aiming with the mouse cursor (assuming it is displayed in Libretro). I suppose we do not use lightgun IDs then?

And also what's up with bitmaps, like someone added to libretro.cxx last year? Maybe you can have a look at that file? AFAIK that's the whole interface between Stella and Libretro.

barbudreadmon commented 2 years ago

assuming it is displayed in Libretro.

Afaik, libretro doesn't have any feature to draw a cursor over the video framebuffer, you'll have to implement this feature backend-side if you want it. if you are using an OS with a windowing system you should still be able to see your mouse cursor over the emulation app though.

I suppose we do not use lightgun IDs then?

On most platforms the lightgun id will cover both lightguns and mouses, but as said above you can implement RETRO_DEVICE_POINTER as an alternative for the few platforms that don't.

And also what's up with bitmaps, like someone added to libretro.cxx last year?

You mean the bitmasks from https://github.com/stella-emu/stella/commit/87bbf20c114f0ac58851e162c2d5af9363be8c1d ? Originally, you had to query libretro for each input, meaning you'd have to execute input_state_cb for querying button A, then use input_state_cb again to query button B, ... The bitmask was implemented some time ago to query all inputs at once, however i believe its usage is still restricted to RETRO_DEVICE_JOYPAD so you aren't gonna use it for lightguns, basically you use it like this : 

# retrieve the bitmask once
int bitmask = input_cb(port, RETRO_DEVICE_JOYPAD, index, RETRO_DEVICE_ID_JOYPAD_MASK);

# use the retrieved bitmask afterward instead of doing multiple queries
if (bitmask & (1 << RETRO_DEVICE_ID_JOYPAD_START))
  echo("start is pressed, do something\n");
if (bitmask & (1 << RETRO_DEVICE_ID_JOYPAD_UP))
  echo("up is pressed, do something\n");
...
thrust26 commented 2 years ago

Thanks! Yup, that was the bitmap update I meant.

I have no plans to implement a cursor just for the very few light gun games. So either the OS displays it, or it won't work.

Regarding the IDs, which one should I use? Lightgun?

Also, how can I test my code myself? (I only have a Windows system)

thrust26 commented 2 years ago

BTW: There seems to be no real paddle support. Or which type should I use for paddles?

thrust26 commented 2 years ago

OK, I went with LightGun as ID and committed. Let's see if it builds. And then I am hoping for feedback.

thrust26 commented 2 years ago

2nd try... Built!

StormedBubbles commented 2 years ago

Thank you so much! The emulator compiled for me.

The emulator does indeed attempt to auto-set the first RetroArch "controller port" to mouse when in Sentinel. However, the Device Type returns "Unknown" to me by default. I believe you need to add to that list on your end. Currently, it shows "RetroPad" (SNES-type controller) and "RetroPad with Analog" (same plus analog sticks) as the valid choices. Other emulators populate that list with custom devices that have IDs tied to the generic RetroArch ones (i.e., for NES, "Zapper" may appear in the list, but it is identified as a lightgun in the code). You would be allowed to have "Atari XG-1 light gun" in that list if you wanted. I suppose that also affects the paddles, which appear to be currently mapped to the digital D-pad of typical controllers. I believe you can just map those to the analog stick of a typical controller and create a device type "Paddle" that is identified as an analog controller, but I am not sure how RA would deal with the dual paddles in a single port. I suppose there would also need to be an option to adjust analog sensitivity, but that is another can of worms.

That may be contributing to a few things I notice:

thrust26 commented 2 years ago

The emulator does indeed attempt to auto-set the first RetroArch "controller port" to mouse when in Sentinel. However, the Device Type returns "Unknown" to me by default. I believe you need to add to that list on your end.

Which list are if referring to? Where can I find it if I use RetroArch?

Stella autodetects the light gun, there it works. I have added the light gun to the input description list, maybe that helps.

Other emulators populate that list with custom devices that have IDs tied to the generic RetroArch ones (i.e., for NES, "Zapper" may appear in the list, but it is identified as a lightgun in the code). You would be allowed to have "Atari XG-1 light gun" in that list if you wanted.

Here I have no clue how to do that. I would need support again.

I suppose that also affects the paddles, which appear to be currently mapped to the digital D-pad of typical controllers. I believe you can just map those to the analog stick of a typical controller and create a device type "Paddle" that is identified as an analog controller, but I am not sure how RA would deal with the dual paddles in a single port.

Yes, paddles are only mapped to digital input. For analog input I would need support too,

I can't seem to tell where I'm shooting. The RetroArch "Core Options" menu could potentially hold an option to toggle the mouse cursor on/off for testing purposes.

What do you mean with "could potentially"? Is that a feature request? Or do you just don't know? (I don't know either).

StormedBubbles commented 2 years ago

Sorry, I will clarify everything from a user's perspective 😊. @barbudreadmon would be the one to ask about the corresponding coding syntax.

A huge benefit of the RetroArch ecosystem is being able to access all menus with a controller only. With a controller, the RetroArch menu is accessible in game by holding the "hotkey" (typically assigned to a controller's "Select" button) and pressing the top face button ("X" on a Super Nintendo controller).

That will drop you into the "Quick Menu." While there are tons and tons of choices here, "Options" and "Controls" contain the vast majority of emulator-specific stuff.

For example, "Options" contains a selection of settings from the standalone Stella emulator's menu that you'd normally access by pressing TAB. As such, Options is typically used as a replacement for settings menus from standalone emulators.

If you were to load up the game "Zero Point 2" in lr-fbneo, you would see many useful things in the Options subsection of the Quick Menu. There are DIP switches, CPU clock adjustments, lightgun crosshair enable/disable, and more. In the PlayStation emulator lr-pcsx-rearmed, you will see the option to enable a multitap in either or both of the controller ports.

The "Controls" menu lists individual "Ports." Those usually correspond to the physical controller port on the real device. For example, with the same Zero Point 2 in lr-fbneo example, you can go to Port 1 and see that the "Device Type" list displays a variety of controller types. As this is a gun game, something controlling the crosshairs is necessary:

Emulators get creative with a combination of the two menus. You may wish to set this up similarly to how lr-vice handles Commodore 64. Instead of messing with the "Controls" menu at all, that emulator handles all of that in the "Options" menu. In that emulator, if you go to Quick Menu -> Options -> Input -> Joystick Port Type, you'll see a full variety of what the C64 offered.

This is just a suggestion, but it may be best to tackle the 2600 inputs in a way similar to lr-vice. In Quick Menu -> Options, you could have a "Port 1 device type" and "Port 2 device type" just in case of the odd homebrew game here and there that isn't recognized and needs manual adjustment. I believe some games even allowed a choice between the driving controller and the paddles. Anyway, a selection there could say "Port 1 device type -> Paddles" and then have the RetroArch input system grab the first controller's analog controls for Paddle A and controller 2's analog controls for Paddle B. This is a direct substitute for the equivalent options in standalone Stella's menu.

That Options menu can also contain options to swap the paddles and various granular settings like analog adjustments. These things are all possible, but I am unaware of the exact syntax.

I hope that that helps to clarify things (at least from a user's perspective!). All of the things I mentioned as "maybe you could do this" are definitely possible within the RetroArch framework, but that is also easy for me to say. 😆

thrust26 commented 2 years ago

This is just a suggestion, but it may be best to tackle the 2600 inputs in a way similar to lr-vice. In Quick Menu -> Options, you could have a "Port 1 device type" and "Port 2 device type" just in case of the odd homebrew game here and there that isn't recognized and needs manual adjustment. I believe some games even allowed a choice between the driving controller and the paddles. Anyway, a selection there could say "Port 1 device type -> Paddles" and then have the RetroArch input system grab the first controller's analog controls for Paddle A and controller 2's analog controls for Paddle B. This is a direct substitute for the equivalent options in standalone Stella's menu.

That's not under my influence, as far as I can tell. I can only provide so much. No clue how this gets translated into what you describe.

Emulators get creative with a combination of the two menus. You may wish to set this up similarly to how lr-vice handles Commodore 64. Instead of messing with the "Controls" menu at all, that emulator handles all of that in the "Options" menu. In that emulator, if you go to Quick Menu -> Options -> Input -> Joystick Port Type, you'll see a full variety of what the C64 offered.

Before I can get creative, I need to understand. 😄 And even then, I am lacking the resources to do anything beyond the minimum required.

That Options menu can also contain options to swap the paddles and various granular settings like analog adjustments. These things are all possible, but I am unaware of the exact syntax.

I think these I can add. But I can only guess a lot of stuff here. @barbudreadmon Is there some documentation? If found e.g.: "stella_phosphor_blend", "Phosphor blend %; 60|65|70|75|80|85|90|95|100|0|5|10|15|20|25|30|35|40|45|50|55"

I suppose I mostly understand this. But I wonder about the odd number order.

StormedBubbles commented 2 years ago

Before I can get creative, I need to understand. 😄 And even then, I am lacking the resources to do anything beyond the minimum required.

I understand 😃. I've got a couple of 2600daptors + paddles + joysticks as well as some modern analog controllers to help with testing if/when any of that gets integrated into the libretro port.

StormedBubbles commented 2 years ago

Also, I tested your latest commit. I don't notice a difference from before while playing. I can fire but can't seem to hit anything. I'm not sure if it's because there's an offset from where I'm aiming or if the cursor is just stuck in some corner and is not moving. The RetroArch menu still displays an unknown device in its controls menu.

Was there maybe a search-and-replace error in the /src/libretro/libretro.h file? I noticed that one of the disclaimers now reads "IN NO MASK_EVENT SHALL..."

thrust26 commented 2 years ago

Also, I tested your latest commit. I don't notice a difference from before while playing. I can fire but can't seem to hit anything. I'm not sure if it's because there's an offset from where I'm aiming or if the cursor is just stuck in some corner and is not moving.

I suppose without a cursor, this won't get any better.

The RetroArch menu still displays an unknown device in its controls menu.

That's what I tried to fix with my latest commit following what I found implemented for the joypad. Obvisously this did not work. So I am lost again.

Was there maybe a search-and-replace error in the /src/libretro/libretro.h file? I noticed that one of the disclaimers now reads "IN NO MASK_EVENT SHALL..."

No, there was a refactoring. But Visual Studio is stupid enough to refactor comments. 😒

barbudreadmon commented 2 years ago

BTW: There seems to be no real paddle support. Or which type should I use for paddles?

You use RETRO_DEVICE_ANALOG and index to query retropad's analog controls, some examples : 

# Query X axis on left analog
input_state_cb(port, RETRO_DEVICE_ANALOG, RETRO_DEVICE_INDEX_ANALOG_LEFT, RETRO_DEVICE_ID_ANALOG_X);

# Query Y axis on right analog
input_state_cb(port, RETRO_DEVICE_ANALOG, RETRO_DEVICE_INDEX_ANALOG_RIGHT, RETRO_DEVICE_ID_ANALOG_Y);

# Query analog L2 trigger
input_state_cb(port, RETRO_DEVICE_ANALOG, RETRO_DEVICE_INDEX_ANALOG_BUTTON, RETRO_DEVICE_ID_JOYPAD_L2);

They will return values between -0x7fff and 0x7fff

Which list are if referring to? Where can I find it if I use RetroArch?

It seems you don't tell what kind of devices you support through the libretro api, here is an example of how to do this : 

# Tell libretro we allow those 4 different types of devices
static const struct retro_controller_description player1_controller_description[] = {
    { "None", RETRO_DEVICE_NONE },
    { "Joystick", RETRO_DEVICE_JOYPAD },
    { "Paddle", RETRO_DEVICE_ANALOG },
    { "Lightgun", RETRO_DEVICE_LIGHTGUN }
};

# Tell libretro we allow those 2 different types of devices
static const struct retro_controller_description other_player_controller_description[] = {
    { "None", RETRO_DEVICE_NONE },
    { "Joystick", RETRO_DEVICE_JOYPAD },
};

# Tell libretro we allow those types for 4 players
static const struct retro_controller_info controller_infos[5] = {
    { player1_controller_description, 4 },
    { other_player_controller_description, 2 },
    { other_player_controller_description, 2 },
    { other_player_controller_description, 2 },
    { NULL, 0 }
};

# Send to libretro
environ_cb(RETRO_ENVIRONMENT_SET_CONTROLLER_INFO, (void*)controller_infos);

You call this once, it can be in either retro_init, retro_set_environment, or retro_load_game. You'll also want to update https://github.com/stella-emu/stella/blob/8875e04faa6239da53ccc0c450bbbc8af0cd2653/src/libretro/libretro.cxx#L481-L500 accordingly

thrust26 commented 2 years ago

@barbudreadmon Thanks a lot, I am finally starting to see some forest for the trees 😄

Nevertheless a few more questions for paddles:

You call this once, it can be in either retro_init, retro_set_environment, or retro_load_game.

The retro_input_descriptor was set in retro_load_game. Therefore I now set retro_controller_info there too (for now). And always for all controller types. Now I wonder if this (or part of it) should be moved, e.g. to retro_init. And if it remains in retro_load_game, wouldn't it make more sense to only set controller info and descriptors used by the current game? Also this might allow supporting Atari 2600 quirks like swapped ports or swapped paddles. There are quite a few settings, especially for paddles: options_gameinfo_controller

But for doing so, Stella must have already loaded the ROM (which e.g. executes controller auto detection) and the code would have to be able to communicate with Stella here. Do you know if this is feasible?

barbudreadmon commented 2 years ago

Atari 2600 paddles only have one axis, I now have added the same analog axis event to RETRO_DEVICE_ID_ANALOG_X and Y. I am not sure if that makes sense.

As long as you handle conflicting values between the 2 axis you poll properly, i don't see any problem.

Also what do RETRO_DEVICE_INDEX_ANALOG_LEFT and RIGHT define here? Different physical controller hats?

They define left and right analog sticks you see on modern controllers (think about sony dualshock)

wouldn't it make more sense to only set controller info and descriptors used by the current game?

Yes you can set retro_input_descriptor and retro_controller_info after loading game and it makes sense. This is actually what i do on FBNeo since available controls are different from an emulated arcade machine to another.

thrust26 commented 2 years ago

As long as you handle conflicting values between the 2 axis you poll properly, i don't see any problem.

I don't. Probably someone has to test here first if this is a problem. Or I will decide for one axis only, maybe depending on the game, e.g. y-axis for Pong and x-axis for Breakout).

They define left and right analog sticks you see on modern controllers (think about sony dualshock)

I am not into modern gaming at all, so bare with me here, please. But after searching the web, I get you.

Yes you can set retro_input_descriptor and retro_controller_info after loading game and it makes sense. This is actually what i do on FBNeo since available controls are different from an emulated arcade machine to another.

I suppose my question was not well formulated. Is the emulator core already started at this point? And if it is, how can I access it to query the results of controller detection?

barbudreadmon commented 2 years ago

I don't.

Hmm imho you might want some min/max based algorithm to select a "preference" from the 2 conflicting polled values, otherwise the second one will probably always override the first one from your backend's perspective, and polling the first one becomes useless.

I suppose my question was not well formulated. Is the emulator core already started at this point? And if it is, how can I access it to query the results of controller detection?

You don't access it, libretro is the one who will tell you the user choices afterward, through retro_set_controller_port_device, and it won't happen before the end of retro_load_game execution if that's your question.

thrust26 commented 2 years ago

Hmm imho you might want some min/max based algorithm to select a "preference" from the 2 conflicting polled values, otherwise the second one will probably always override the first one from your backend's perspective, and polling the first one becomes useless.

Makes sense. @StormedBubbles Can you also test paddle games?

You don't access it, libretro is the one who will tell you the user choices afterward, through retro_set_controller_port_device, and it won't happen before the end of retro_load_game execution if that's your question.

OK, then the question is, how does Libretro know which is the right controller for the game? Until now everything was joypad, so there was no choice required. If we start supporting more controller types, there has to be something which supports choosing the correct controller. Either by the user or automatically.

barbudreadmon commented 2 years ago

The user set Quick Menu > Controls > Port X Controls > Device Type (where X is the player number) and that's what libretro will send you through retro_set_controller_port_device.

thrust26 commented 2 years ago

Ah, so there is no database or controller auto detection? Each game has to be set one by one?

StormedBubbles commented 2 years ago

Typically, you do have to manually select the control type for each game in RetroArch. Users will be aware of this going in.

Great work! I first tried this latest commit with 4 modern controllers with dual analog sticks similar to the PlayStation DualShock. The analog movement is mapped to the right stick's y-axis on all four controllers. The four controllers are correctly recognized independently of each other and control 4 unique players. I just tried it out with Warlords and was able to control all 4 players independently. I got some movement when using the x-axis on the right stick, but that may have just been me accidentally getting some y-axis movement too.

Analog sticks on modern controllers automatically move back to center when you let go of them. That is reflected in game with the character moving back to center position.

My four controllers exhibited different sensitivities, so an eventual analog-sensitivity-adjustment setting will be very helpful.

The experience is the same whether I set the control type to "Joystick," "Paddle," or "Lightgun" (those are all visible now), so that selection doesn't currently seem to have a bearing on what you're allowed to do, control-wise. It seems that Stella's auto-detection is still taking precedence.

I will need to check out the actual physical Atari paddles + 2600daptor a bit later. The (normally) easy way to map controllers in RetroArch is a bit cumbersome when using paddles since it's difficult to find the center point. Standalone Stella just recognizes them. My system does recognize the 2600daptor by name, but I will need to double check that my system actually recognizes the paddles as separate controllers. I just need to research a little on how to get that going properly.

I will also change the name of this issue to include analog.

thrust26 commented 2 years ago

Great work! I first tried this latest commit with 4 modern controllers with dual analog sticks similar to the PlayStation DualShock. The analog movement is mapped to the right stick's y-axis on all four controllers. The four controllers are correctly recognized independently of each other and control 4 unique players.

Cool! Thanks for testing!

The analog movement is mapped to the right stick's y-axis on all four controllers. The four controllers are correctly recognized independently of each other and control 4 unique players. I just tried it out with Warlords and was able to control all 4 players independently. I got some movement when using the x-axis on the right stick, but that may have just been me accidentally getting some y-axis movement too.

Does the x-axis conflict here? If so, I wonder which axis would be preferred. Then I would remove the mapping of the other axis. Or should this be adjusted per game?

Analog sticks on modern controllers automatically move back to center when you let go of them. That is reflected in game with the character moving back to center position.

For that we have settings for center offset in Stella (see screenshot above), different for each game.

My four controllers exhibited different sensitivities, so an eventual analog-sensitivity-adjustment setting will be very helpful.

You mean per controller? That's nothing Stella currently supports and maybe its a bit of overkill (you are the first asking for this). We only have a global analog controller sensitivity setting.

I will need to check out the actual physical Atari paddles + 2600daptor a bit later. The (normally) easy way to map controllers in RetroArch is a bit cumbersome when using paddles since it's difficult to find the center point.

How does RetroArch define the center point? The problem with Atari 2600 games is, that paddles have no real center. Where the center is, solely depends on how and where a game polls the paddles during its display kernel. That's why we have that dedicated setting per game.

BTW: I suppose the Lightgun hasn't improved?

barbudreadmon commented 2 years ago

Ah, so there is no database or controller auto detection? Each game has to be set one by one?

No, the device type is a user choice, because ultimately the user might choose something different, and that's not something i'll cover here but you can offer several choice for the same kind of device, for example if you want to provide different layouts.

StormedBubbles commented 2 years ago

For that we have settings for center offset in Stella (see screenshot above), different for each game.

Oops, I meant to point out that the centering is working properly.

You mean per controller? That's nothing Stella currently supports and maybe its a bit of overkill (you are the first asking for this). We only have a global analog controller sensitivity setting.

Ah, I see. The sensitivity isn't really a problem anyway. You get used to the range of motion for each controller pretty quickly.

RetroArch treats the 2600daptor paired with a paddle set as a single entity that has two buttons and analog movement along 2 independent axes.

Now that I have a handle on that, I'll do some testing with the paddles to see how they work. Suddenly, one of my 2600daptors is giving me some issues. It's always something 😆

thrust26 commented 2 years ago

Great. I will wait for your testing results and then we can decide how to proceed.

thrust26 commented 2 years ago

@StormedBubbles I got stella_libretro.dll compiled (yay!) and replaced the version that came with RetroArch with this one. Seems to work.

But the RetroArch interface is pretty complex and hard to understand (probably due to its flexibility). After some fiddling (I cannot set a start directory), I started Breakout. And after finding the Controls option, Device Type "Paddle" was already selected. Huh?

Anyway, I did not manage to get the input mapping right. The paddle in Breakout only reacts to the D-pad on my controller, but not to my analog input. How do I have to setup the Port 1 Controls?

Note: The RetroArch doc https://docs.libretro.com/guides/file-browser/ says:

Navigate your file system until you are inside your content folder then select \<Use this directory>.

Well, how do you do the latter?

StormedBubbles commented 2 years ago

It looks like it's going to work! There's just a caveat with how RetroArch reads a paddle set.

I have one paddle easily working perfectly. Getting the second one in a paddle set to be mapped to a different player currently would require some RetroArch gymnastics by the user.

The issue is that one 2600daptor + one set of paddles is recognized as a single device. The inputs are all separate (2 independent buttons and 2 independent axes), but I'm having trouble figuring out how to divide those between two separate players.

The way regular controllers behave now is great. Each individual controller controls an independent player. The only thing people might want changed is which stick (L/R) or axis (X/Y) is the one to use.

I know that we're probably not here yet in terms of this sort of granular setting, but I think this is where the different input choices in RetroArch will be a benefit. Perhaps what would solve this is a "Core Option" of "Paddle Mode" that would work like this:

StormedBubbles commented 2 years ago

Ah, just saw your next comment. I will take a look at the latest commit. I was on the one before that.

thrust26 commented 2 years ago

I know that we're probably not here yet in terms of this sort of granular setting, but I think this is where the different input choices in RetroArch will be a benefit. Perhaps what would solve this is a "Core Option" of "Paddle Mode" that would work like this:

What is a "Core Option"?

thrust26 commented 2 years ago

BTW: Can you somehow disable the wraparound in the menus? This sucks when using a mouse scroll wheel.

StormedBubbles commented 2 years ago

From the RetroArch menu, "Core Options" is in Quick Menu -> Options. Those are settings specific to the emulator you're currently using. That menu currently houses some of the settings from standalone Stella's menu.

The RetroArch Main Menu -> Settings -> User Interface section has a lot of settings related to appearance. I haven't messed with those and stick with the simple text menu that came pre-configured for Raspberry Pi use.

thrust26 commented 2 years ago

Where is Quick Menu? I only have Main Menu. Edit: I found Desktop Menu. At first glance this seems much better accessible for a PC. Edit 2: Core Options is empty. Is there more than one?

Are there other UIs for Windows? The RetroArch one is stylish for sure, but the usability doesn't work for me at all.

thrust26 commented 2 years ago

@barbudreadmon Any idea why the original stella_libretro.dll is 4.4 MB while the one I did build is only 3.0 MB?

sa666666 commented 2 years ago

Windows binaries built with MinGW tend to be larger than those from Visual Studio. And not always as fast. At least that's been my experience. Might be part of the issue??

barbudreadmon commented 2 years ago

@thrust26 because of different compilers & cflags, that's pretty normal

StormedBubbles commented 2 years ago

Edit 2: Core Options is empty. Is there more than one?

The options only appear when you have an emulator loaded. You probably have RetroArch alone open

Are there other UIs for Windows?

Yes: If you go to Main Menu -> Settings -> Drivers -> Menu, you'll see a list. I use "rgui." You may need to save, quit, and restart in order to see a change take effect.

RetroArch has seen about 10 years' worth of contributions that have changed this, changed that, moved this here, forgotten about that, etc. That's why the menu system is a bit overwhelming. There has been more effort lately in trying to organize that better, but doing so may also break configuration files people already have from older versions. The RA menu is sort of between a rock and a hard place.

thrust26 commented 2 years ago

Yes: If you go to Main Menu -> Settings -> Drivers -> Menu, you'll see a list. I use "rgui." You may need to save, quit, and restart in order to see a change take effect.

I have briefly tried them all. It seems like each one was developed with a different design idea. Maybe I can find one which works well for me. Currently I am stuck in that animated blue one and cannot find how to change back the menu drivers. 😒 (there are some icons, but they do not work)

RetroArch has seen about 10 years' worth of contributions that have changed this, changed that, moved this here, forgotten about that, etc. That's why the menu system is a bit overwhelming. There has been more effort lately in trying to organize that better, but doing so may also break configuration files people already have from older versions. The RA menu is sort of between a rock and a hard place.

Yes, that shows. Stella has it much easier, we only support one core and I am the only one responsible for the UI. That helps a lot with consistency. RA seems to lack this. Of course I am saying this from a complete noob perspective. But it shows that the initial learning curve is pretty steep. Which will deter new users. Maybe there should be a simple mode?

thrust26 commented 2 years ago

I looked into the descriptions of RETRO_DEVICE_LIGHTGUN and RETRO_DEVICE_POINTER. Both scale to -0x7fff..0x8000. This doesn't fit to what the mouse events of SDL deliver. I think I have to scale the values provided by Libretro.

StormedBubbles commented 2 years ago

Thanks! I saw the commit but ran out of time for the day to test. I will take a look sometime over the next day and let you know how it is for me.

thrust26 commented 2 years ago

I am still having problems with the control mappings. Analog paddles do not work at all, console switches (Select, Reset) too. I cannot even start Kaboom!. Help!

StormedBubbles commented 2 years ago

I'm still going to be away from my testing computer for a while, but here's an outline on mapping. I might have the exact names of the menu items slightly wrong.

If the paddles are already connected to your computer when you start up the emulator in RetroArch, they should appear as a single device in

Main Menu -> Settings -> Input -> Port 1

In the Port 1 menu, there should be a device/joypad list as well as a long list of things you can map. The 2600daptor also appears as a mouse for some reason, but that doesn't appear to be relevant for paddle usage. I assume there is another compatible Atari peripheral that behaves as a mouse.

Anyway, here you'll probably want a keyboard to navigate the menus because you'll take menu control away from your first controller. This is one of the issues I'm trying to iron out to present a good solution.

You'll want to make sure that the device for port 1 is the 2600daptor and that neither paddle is turned to an extreme direction. Then, find the Right Analog Y+ and Y- selections below the button list. Select one and turn the paddle you wish to use in the appropriate extreme direction. It should register. Then turn back away to a more neutral position and do the same for the other direction. Do the same for the fire button.

This is something that I'm not sure works properly. It's going to be in my next round of testing. In order to get a second player working on the same set of paddles, you can try moving to port 2 in the menu, setting the device type to the same 2600daptor, and mapping the similar functions for player 2.

I definitely had one paddle working great in Warlords, but I didn't try Kaboom! yet. I believe the libretro Stella does have some issues with specific games crashing, but I would need to test out to see if I get similar results.

Normally, you can use an external tool to configure whatever you want as a controller and have RetroArch automatically interpret it, but any Atari device makes that difficult due to the limited number of buttons.