sdl2 guid, remove the CRC bytes (4 first characters) and replace with 0000 when creating guid #753
@ -57,16 +57,19 @@ namespace Ryujinx.Input.SDL2
|
||||
|
|
||||
return null;
|
||||
}
|
||||
|
||||
// Remove the first 4 char of the guid (CRC part) to make it stable
|
||||
It seems that this does not affect compatibility with other gamepads, the only thing is that you need to reconfigure all previously connected gamepads. You can instead of zeros write a unique identifier for the emulator, for example RYUX and this also works It seems that this does not affect compatibility with other gamepads, the only thing is that you need to reconfigure all previously connected gamepads.
You can instead of zeros write a unique identifier for the emulator, for example RYUX and this also works
Why use this when sdl2 guid is with 0000, that would make it specific while 0000 keeps standard sdl Why use this when sdl2 guid is with 0000, that would make it specific while 0000 keeps standard sdl
These bytes after their replacement turn out to be meaningless, of course you can leave zeros, but they will not affect anything in the future, including compatibility, except perhaps visual. Your gamepad will still connect without problems, At least I tested it in my assembly and it works great These bytes after their replacement turn out to be meaningless, of course you can leave zeros, but they will not affect anything in the future, including compatibility, except perhaps visual.
For the emulator, this number becomes just a string variable, and then it is simply placed in the list for display in the menu. At least I am currently working on the controller menu and it seems to work exactly like that.
Your gamepad will still connect without problems,
At least I tested it in my assembly and it works great
My recommandation is usually to stick to the standard provided by the library, but i agree that here whatever will work, as it's part of the object... This is an extract of SDL database commonly used : Also native methods used in SDL2 library can return the sdl string without CRC16 (0000 instead). So usually i stick more to the use of what is commonly used, just look at other emulators: My recommandation is usually to stick to the standard provided by the library, but i agree that here whatever will work, as it's part of the object...
This is an extract of SDL database commonly used :
Also native methods used in SDL2 library can return the sdl string without CRC16 (0000 instead).
So usually i stick more to the use of what is commonly used, just look at other emulators:
All in all it works, of course people having saved profiles would need to recreate them once, but that's really not an issue versus the issues that XBOX controllers not saving represent. I've tested with approx 16 controller models (from PS4, dualsense, switch pro, many 8BitDo and Xbox models), and as you already noticed, there is no impact in compatibility of these. All in all it works, of course people having saved profiles would need to recreate them once, but that's really not an issue versus the issues that XBOX controllers not saving represent.
We could even provide a tool that would automatically go through the profile files and edit the guids to fix this and make profiles compatible without having to recreate them, i highly doubt a huge lot of people actually use profiles in an extensive way.
I've tested with approx 16 controller models (from PS4, dualsense, switch pro, many 8BitDo and Xbox models), and as you already noticed, there is no impact in compatibility of these.
I understand everything. I definitely like that it works and the solution turned out to be simpler than I thought. I understand everything. I definitely like that it works and the solution turned out to be simpler than I thought.
Basically, when working with sdl and controllers, first hint will always be the guid, these guys change the way to calculate these crc bytes so often amd with each version that it became a mess, to cover each cases one would need a folder with 8 dll and dynamically retrieve each guid from each version... But originally we should blame the manufacturers that build controllers and use vid/pid from standard manufacturers instead of their own, especially when they use different button layout than the controller they "copy". I did not look yet at sdl3, that will be a whole new story (for better or worse but I hope for better). Basically, when working with sdl and controllers, first hint will always be the guid, these guys change the way to calculate these crc bytes so often amd with each version that it became a mess, to cover each cases one would need a folder with 8 dll and dynamically retrieve each guid from each version...
But originally we should blame the manufacturers that build controllers and use vid/pid from standard manufacturers instead of their own, especially when they use different button layout than the controller they "copy".
I did not look yet at sdl3, that will be a whole new story (for better or worse but I hope for better).
your solution is good, but there is another problem that unfortunately neither sdl2 nor sdl3 will solve, it is the confusion of two absolutely identical controllers. For the correct detection of such devices, the port number to which they are connected is needed. I looked at sdl3, It is impossible to get the USB port number through these libraries. But this is a completely different problem your solution is good, but there is another problem that unfortunately neither sdl2 nor sdl3 will solve, it is the confusion of two absolutely identical controllers. For the correct detection of such devices, the port number to which they are connected is needed. I looked at sdl3, It is impossible to get the USB port number through these libraries. But this is a completely different problem
I don't think this is a problem, ryujinx adds an index before the guid that increments for identical controllers. And worst case scenario, someone has 2 identical controllers connected, there would be no issues just picking up the correct one... I don't think this is a problem, ryujinx adds an index before the guid that increments for identical controllers.
Normally the enumeration order of controllers is the same, as it's based on the device path...
And worst case scenario, someone has 2 identical controllers connected, there would be no issues just picking up the correct one...
|
||||
string guidString = "0000" + guid.ToString().Substring(4);
|
||||
|
It seems that this does not affect compatibility with other gamepads, the only thing is that you need to reconfigure all previously connected gamepads. You can instead of zeros write a unique identifier for the emulator, for example RYUX and this also works It seems that this does not affect compatibility with other gamepads, the only thing is that you need to reconfigure all previously connected gamepads.
You can instead of zeros write a unique identifier for the emulator, for example RYUX and this also works
Why use this when sdl2 guid is with 0000, that would make it specific while 0000 keeps standard sdl Why use this when sdl2 guid is with 0000, that would make it specific while 0000 keeps standard sdl
These bytes after their replacement turn out to be meaningless, of course you can leave zeros, but they will not affect anything in the future, including compatibility, except perhaps visual. Your gamepad will still connect without problems, At least I tested it in my assembly and it works great These bytes after their replacement turn out to be meaningless, of course you can leave zeros, but they will not affect anything in the future, including compatibility, except perhaps visual.
For the emulator, this number becomes just a string variable, and then it is simply placed in the list for display in the menu. At least I am currently working on the controller menu and it seems to work exactly like that.
Your gamepad will still connect without problems,
At least I tested it in my assembly and it works great
My recommandation is usually to stick to the standard provided by the library, but i agree that here whatever will work, as it's part of the object... This is an extract of SDL database commonly used : Also native methods used in SDL2 library can return the sdl string without CRC16 (0000 instead). So usually i stick more to the use of what is commonly used, just look at other emulators: My recommandation is usually to stick to the standard provided by the library, but i agree that here whatever will work, as it's part of the object...
This is an extract of SDL database commonly used :
Also native methods used in SDL2 library can return the sdl string without CRC16 (0000 instead).
So usually i stick more to the use of what is commonly used, just look at other emulators:
All in all it works, of course people having saved profiles would need to recreate them once, but that's really not an issue versus the issues that XBOX controllers not saving represent. I've tested with approx 16 controller models (from PS4, dualsense, switch pro, many 8BitDo and Xbox models), and as you already noticed, there is no impact in compatibility of these. All in all it works, of course people having saved profiles would need to recreate them once, but that's really not an issue versus the issues that XBOX controllers not saving represent.
We could even provide a tool that would automatically go through the profile files and edit the guids to fix this and make profiles compatible without having to recreate them, i highly doubt a huge lot of people actually use profiles in an extensive way.
I've tested with approx 16 controller models (from PS4, dualsense, switch pro, many 8BitDo and Xbox models), and as you already noticed, there is no impact in compatibility of these.
I understand everything. I definitely like that it works and the solution turned out to be simpler than I thought. I understand everything. I definitely like that it works and the solution turned out to be simpler than I thought.
Basically, when working with sdl and controllers, first hint will always be the guid, these guys change the way to calculate these crc bytes so often amd with each version that it became a mess, to cover each cases one would need a folder with 8 dll and dynamically retrieve each guid from each version... But originally we should blame the manufacturers that build controllers and use vid/pid from standard manufacturers instead of their own, especially when they use different button layout than the controller they "copy". I did not look yet at sdl3, that will be a whole new story (for better or worse but I hope for better). Basically, when working with sdl and controllers, first hint will always be the guid, these guys change the way to calculate these crc bytes so often amd with each version that it became a mess, to cover each cases one would need a folder with 8 dll and dynamically retrieve each guid from each version...
But originally we should blame the manufacturers that build controllers and use vid/pid from standard manufacturers instead of their own, especially when they use different button layout than the controller they "copy".
I did not look yet at sdl3, that will be a whole new story (for better or worse but I hope for better).
your solution is good, but there is another problem that unfortunately neither sdl2 nor sdl3 will solve, it is the confusion of two absolutely identical controllers. For the correct detection of such devices, the port number to which they are connected is needed. I looked at sdl3, It is impossible to get the USB port number through these libraries. But this is a completely different problem your solution is good, but there is another problem that unfortunately neither sdl2 nor sdl3 will solve, it is the confusion of two absolutely identical controllers. For the correct detection of such devices, the port number to which they are connected is needed. I looked at sdl3, It is impossible to get the USB port number through these libraries. But this is a completely different problem
I don't think this is a problem, ryujinx adds an index before the guid that increments for identical controllers. And worst case scenario, someone has 2 identical controllers connected, there would be no issues just picking up the correct one... I don't think this is a problem, ryujinx adds an index before the guid that increments for identical controllers.
Normally the enumeration order of controllers is the same, as it's based on the device path...
And worst case scenario, someone has 2 identical controllers connected, there would be no issues just picking up the correct one...
|
||||
|
||||
|
It seems that this does not affect compatibility with other gamepads, the only thing is that you need to reconfigure all previously connected gamepads. You can instead of zeros write a unique identifier for the emulator, for example RYUX and this also works It seems that this does not affect compatibility with other gamepads, the only thing is that you need to reconfigure all previously connected gamepads.
You can instead of zeros write a unique identifier for the emulator, for example RYUX and this also works
Why use this when sdl2 guid is with 0000, that would make it specific while 0000 keeps standard sdl Why use this when sdl2 guid is with 0000, that would make it specific while 0000 keeps standard sdl
These bytes after their replacement turn out to be meaningless, of course you can leave zeros, but they will not affect anything in the future, including compatibility, except perhaps visual. Your gamepad will still connect without problems, At least I tested it in my assembly and it works great These bytes after their replacement turn out to be meaningless, of course you can leave zeros, but they will not affect anything in the future, including compatibility, except perhaps visual.
For the emulator, this number becomes just a string variable, and then it is simply placed in the list for display in the menu. At least I am currently working on the controller menu and it seems to work exactly like that.
Your gamepad will still connect without problems,
At least I tested it in my assembly and it works great
My recommandation is usually to stick to the standard provided by the library, but i agree that here whatever will work, as it's part of the object... This is an extract of SDL database commonly used : Also native methods used in SDL2 library can return the sdl string without CRC16 (0000 instead). So usually i stick more to the use of what is commonly used, just look at other emulators: My recommandation is usually to stick to the standard provided by the library, but i agree that here whatever will work, as it's part of the object...
This is an extract of SDL database commonly used :
Also native methods used in SDL2 library can return the sdl string without CRC16 (0000 instead).
So usually i stick more to the use of what is commonly used, just look at other emulators:
All in all it works, of course people having saved profiles would need to recreate them once, but that's really not an issue versus the issues that XBOX controllers not saving represent. I've tested with approx 16 controller models (from PS4, dualsense, switch pro, many 8BitDo and Xbox models), and as you already noticed, there is no impact in compatibility of these. All in all it works, of course people having saved profiles would need to recreate them once, but that's really not an issue versus the issues that XBOX controllers not saving represent.
We could even provide a tool that would automatically go through the profile files and edit the guids to fix this and make profiles compatible without having to recreate them, i highly doubt a huge lot of people actually use profiles in an extensive way.
I've tested with approx 16 controller models (from PS4, dualsense, switch pro, many 8BitDo and Xbox models), and as you already noticed, there is no impact in compatibility of these.
I understand everything. I definitely like that it works and the solution turned out to be simpler than I thought. I understand everything. I definitely like that it works and the solution turned out to be simpler than I thought.
Basically, when working with sdl and controllers, first hint will always be the guid, these guys change the way to calculate these crc bytes so often amd with each version that it became a mess, to cover each cases one would need a folder with 8 dll and dynamically retrieve each guid from each version... But originally we should blame the manufacturers that build controllers and use vid/pid from standard manufacturers instead of their own, especially when they use different button layout than the controller they "copy". I did not look yet at sdl3, that will be a whole new story (for better or worse but I hope for better). Basically, when working with sdl and controllers, first hint will always be the guid, these guys change the way to calculate these crc bytes so often amd with each version that it became a mess, to cover each cases one would need a folder with 8 dll and dynamically retrieve each guid from each version...
But originally we should blame the manufacturers that build controllers and use vid/pid from standard manufacturers instead of their own, especially when they use different button layout than the controller they "copy".
I did not look yet at sdl3, that will be a whole new story (for better or worse but I hope for better).
your solution is good, but there is another problem that unfortunately neither sdl2 nor sdl3 will solve, it is the confusion of two absolutely identical controllers. For the correct detection of such devices, the port number to which they are connected is needed. I looked at sdl3, It is impossible to get the USB port number through these libraries. But this is a completely different problem your solution is good, but there is another problem that unfortunately neither sdl2 nor sdl3 will solve, it is the confusion of two absolutely identical controllers. For the correct detection of such devices, the port number to which they are connected is needed. I looked at sdl3, It is impossible to get the USB port number through these libraries. But this is a completely different problem
I don't think this is a problem, ryujinx adds an index before the guid that increments for identical controllers. And worst case scenario, someone has 2 identical controllers connected, there would be no issues just picking up the correct one... I don't think this is a problem, ryujinx adds an index before the guid that increments for identical controllers.
Normally the enumeration order of controllers is the same, as it's based on the device path...
And worst case scenario, someone has 2 identical controllers connected, there would be no issues just picking up the correct one...
|
||||
string id;
|
||||
|
||||
lock (_lock)
|
||||
{
|
||||
int guidIndex = 0;
|
||||
id = guidIndex + "-" + guid;
|
||||
|
It seems that this does not affect compatibility with other gamepads, the only thing is that you need to reconfigure all previously connected gamepads. You can instead of zeros write a unique identifier for the emulator, for example RYUX and this also works It seems that this does not affect compatibility with other gamepads, the only thing is that you need to reconfigure all previously connected gamepads.
You can instead of zeros write a unique identifier for the emulator, for example RYUX and this also works
Why use this when sdl2 guid is with 0000, that would make it specific while 0000 keeps standard sdl Why use this when sdl2 guid is with 0000, that would make it specific while 0000 keeps standard sdl
These bytes after their replacement turn out to be meaningless, of course you can leave zeros, but they will not affect anything in the future, including compatibility, except perhaps visual. Your gamepad will still connect without problems, At least I tested it in my assembly and it works great These bytes after their replacement turn out to be meaningless, of course you can leave zeros, but they will not affect anything in the future, including compatibility, except perhaps visual.
For the emulator, this number becomes just a string variable, and then it is simply placed in the list for display in the menu. At least I am currently working on the controller menu and it seems to work exactly like that.
Your gamepad will still connect without problems,
At least I tested it in my assembly and it works great
My recommandation is usually to stick to the standard provided by the library, but i agree that here whatever will work, as it's part of the object... This is an extract of SDL database commonly used : Also native methods used in SDL2 library can return the sdl string without CRC16 (0000 instead). So usually i stick more to the use of what is commonly used, just look at other emulators: My recommandation is usually to stick to the standard provided by the library, but i agree that here whatever will work, as it's part of the object...
This is an extract of SDL database commonly used :
Also native methods used in SDL2 library can return the sdl string without CRC16 (0000 instead).
So usually i stick more to the use of what is commonly used, just look at other emulators:
All in all it works, of course people having saved profiles would need to recreate them once, but that's really not an issue versus the issues that XBOX controllers not saving represent. I've tested with approx 16 controller models (from PS4, dualsense, switch pro, many 8BitDo and Xbox models), and as you already noticed, there is no impact in compatibility of these. All in all it works, of course people having saved profiles would need to recreate them once, but that's really not an issue versus the issues that XBOX controllers not saving represent.
We could even provide a tool that would automatically go through the profile files and edit the guids to fix this and make profiles compatible without having to recreate them, i highly doubt a huge lot of people actually use profiles in an extensive way.
I've tested with approx 16 controller models (from PS4, dualsense, switch pro, many 8BitDo and Xbox models), and as you already noticed, there is no impact in compatibility of these.
I understand everything. I definitely like that it works and the solution turned out to be simpler than I thought. I understand everything. I definitely like that it works and the solution turned out to be simpler than I thought.
Basically, when working with sdl and controllers, first hint will always be the guid, these guys change the way to calculate these crc bytes so often amd with each version that it became a mess, to cover each cases one would need a folder with 8 dll and dynamically retrieve each guid from each version... But originally we should blame the manufacturers that build controllers and use vid/pid from standard manufacturers instead of their own, especially when they use different button layout than the controller they "copy". I did not look yet at sdl3, that will be a whole new story (for better or worse but I hope for better). Basically, when working with sdl and controllers, first hint will always be the guid, these guys change the way to calculate these crc bytes so often amd with each version that it became a mess, to cover each cases one would need a folder with 8 dll and dynamically retrieve each guid from each version...
But originally we should blame the manufacturers that build controllers and use vid/pid from standard manufacturers instead of their own, especially when they use different button layout than the controller they "copy".
I did not look yet at sdl3, that will be a whole new story (for better or worse but I hope for better).
your solution is good, but there is another problem that unfortunately neither sdl2 nor sdl3 will solve, it is the confusion of two absolutely identical controllers. For the correct detection of such devices, the port number to which they are connected is needed. I looked at sdl3, It is impossible to get the USB port number through these libraries. But this is a completely different problem your solution is good, but there is another problem that unfortunately neither sdl2 nor sdl3 will solve, it is the confusion of two absolutely identical controllers. For the correct detection of such devices, the port number to which they are connected is needed. I looked at sdl3, It is impossible to get the USB port number through these libraries. But this is a completely different problem
I don't think this is a problem, ryujinx adds an index before the guid that increments for identical controllers. And worst case scenario, someone has 2 identical controllers connected, there would be no issues just picking up the correct one... I don't think this is a problem, ryujinx adds an index before the guid that increments for identical controllers.
Normally the enumeration order of controllers is the same, as it's based on the device path...
And worst case scenario, someone has 2 identical controllers connected, there would be no issues just picking up the correct one...
|
||||
id = guidIndex + "-" + guidString;
|
||||
|
It seems that this does not affect compatibility with other gamepads, the only thing is that you need to reconfigure all previously connected gamepads. You can instead of zeros write a unique identifier for the emulator, for example RYUX and this also works It seems that this does not affect compatibility with other gamepads, the only thing is that you need to reconfigure all previously connected gamepads.
You can instead of zeros write a unique identifier for the emulator, for example RYUX and this also works
Why use this when sdl2 guid is with 0000, that would make it specific while 0000 keeps standard sdl Why use this when sdl2 guid is with 0000, that would make it specific while 0000 keeps standard sdl
These bytes after their replacement turn out to be meaningless, of course you can leave zeros, but they will not affect anything in the future, including compatibility, except perhaps visual. Your gamepad will still connect without problems, At least I tested it in my assembly and it works great These bytes after their replacement turn out to be meaningless, of course you can leave zeros, but they will not affect anything in the future, including compatibility, except perhaps visual.
For the emulator, this number becomes just a string variable, and then it is simply placed in the list for display in the menu. At least I am currently working on the controller menu and it seems to work exactly like that.
Your gamepad will still connect without problems,
At least I tested it in my assembly and it works great
My recommandation is usually to stick to the standard provided by the library, but i agree that here whatever will work, as it's part of the object... This is an extract of SDL database commonly used : Also native methods used in SDL2 library can return the sdl string without CRC16 (0000 instead). So usually i stick more to the use of what is commonly used, just look at other emulators: My recommandation is usually to stick to the standard provided by the library, but i agree that here whatever will work, as it's part of the object...
This is an extract of SDL database commonly used :
Also native methods used in SDL2 library can return the sdl string without CRC16 (0000 instead).
So usually i stick more to the use of what is commonly used, just look at other emulators:
All in all it works, of course people having saved profiles would need to recreate them once, but that's really not an issue versus the issues that XBOX controllers not saving represent. I've tested with approx 16 controller models (from PS4, dualsense, switch pro, many 8BitDo and Xbox models), and as you already noticed, there is no impact in compatibility of these. All in all it works, of course people having saved profiles would need to recreate them once, but that's really not an issue versus the issues that XBOX controllers not saving represent.
We could even provide a tool that would automatically go through the profile files and edit the guids to fix this and make profiles compatible without having to recreate them, i highly doubt a huge lot of people actually use profiles in an extensive way.
I've tested with approx 16 controller models (from PS4, dualsense, switch pro, many 8BitDo and Xbox models), and as you already noticed, there is no impact in compatibility of these.
I understand everything. I definitely like that it works and the solution turned out to be simpler than I thought. I understand everything. I definitely like that it works and the solution turned out to be simpler than I thought.
Basically, when working with sdl and controllers, first hint will always be the guid, these guys change the way to calculate these crc bytes so often amd with each version that it became a mess, to cover each cases one would need a folder with 8 dll and dynamically retrieve each guid from each version... But originally we should blame the manufacturers that build controllers and use vid/pid from standard manufacturers instead of their own, especially when they use different button layout than the controller they "copy". I did not look yet at sdl3, that will be a whole new story (for better or worse but I hope for better). Basically, when working with sdl and controllers, first hint will always be the guid, these guys change the way to calculate these crc bytes so often amd with each version that it became a mess, to cover each cases one would need a folder with 8 dll and dynamically retrieve each guid from each version...
But originally we should blame the manufacturers that build controllers and use vid/pid from standard manufacturers instead of their own, especially when they use different button layout than the controller they "copy".
I did not look yet at sdl3, that will be a whole new story (for better or worse but I hope for better).
your solution is good, but there is another problem that unfortunately neither sdl2 nor sdl3 will solve, it is the confusion of two absolutely identical controllers. For the correct detection of such devices, the port number to which they are connected is needed. I looked at sdl3, It is impossible to get the USB port number through these libraries. But this is a completely different problem your solution is good, but there is another problem that unfortunately neither sdl2 nor sdl3 will solve, it is the confusion of two absolutely identical controllers. For the correct detection of such devices, the port number to which they are connected is needed. I looked at sdl3, It is impossible to get the USB port number through these libraries. But this is a completely different problem
I don't think this is a problem, ryujinx adds an index before the guid that increments for identical controllers. And worst case scenario, someone has 2 identical controllers connected, there would be no issues just picking up the correct one... I don't think this is a problem, ryujinx adds an index before the guid that increments for identical controllers.
Normally the enumeration order of controllers is the same, as it's based on the device path...
And worst case scenario, someone has 2 identical controllers connected, there would be no issues just picking up the correct one...
|
||||
|
||||
while (_gamepadsIds.Contains(id))
|
||||
{
|
||||
id = (++guidIndex) + "-" + guid;
|
||||
|
It seems that this does not affect compatibility with other gamepads, the only thing is that you need to reconfigure all previously connected gamepads. You can instead of zeros write a unique identifier for the emulator, for example RYUX and this also works It seems that this does not affect compatibility with other gamepads, the only thing is that you need to reconfigure all previously connected gamepads.
You can instead of zeros write a unique identifier for the emulator, for example RYUX and this also works
Why use this when sdl2 guid is with 0000, that would make it specific while 0000 keeps standard sdl Why use this when sdl2 guid is with 0000, that would make it specific while 0000 keeps standard sdl
These bytes after their replacement turn out to be meaningless, of course you can leave zeros, but they will not affect anything in the future, including compatibility, except perhaps visual. Your gamepad will still connect without problems, At least I tested it in my assembly and it works great These bytes after their replacement turn out to be meaningless, of course you can leave zeros, but they will not affect anything in the future, including compatibility, except perhaps visual.
For the emulator, this number becomes just a string variable, and then it is simply placed in the list for display in the menu. At least I am currently working on the controller menu and it seems to work exactly like that.
Your gamepad will still connect without problems,
At least I tested it in my assembly and it works great
My recommandation is usually to stick to the standard provided by the library, but i agree that here whatever will work, as it's part of the object... This is an extract of SDL database commonly used : Also native methods used in SDL2 library can return the sdl string without CRC16 (0000 instead). So usually i stick more to the use of what is commonly used, just look at other emulators: My recommandation is usually to stick to the standard provided by the library, but i agree that here whatever will work, as it's part of the object...
This is an extract of SDL database commonly used :
Also native methods used in SDL2 library can return the sdl string without CRC16 (0000 instead).
So usually i stick more to the use of what is commonly used, just look at other emulators:
All in all it works, of course people having saved profiles would need to recreate them once, but that's really not an issue versus the issues that XBOX controllers not saving represent. I've tested with approx 16 controller models (from PS4, dualsense, switch pro, many 8BitDo and Xbox models), and as you already noticed, there is no impact in compatibility of these. All in all it works, of course people having saved profiles would need to recreate them once, but that's really not an issue versus the issues that XBOX controllers not saving represent.
We could even provide a tool that would automatically go through the profile files and edit the guids to fix this and make profiles compatible without having to recreate them, i highly doubt a huge lot of people actually use profiles in an extensive way.
I've tested with approx 16 controller models (from PS4, dualsense, switch pro, many 8BitDo and Xbox models), and as you already noticed, there is no impact in compatibility of these.
I understand everything. I definitely like that it works and the solution turned out to be simpler than I thought. I understand everything. I definitely like that it works and the solution turned out to be simpler than I thought.
Basically, when working with sdl and controllers, first hint will always be the guid, these guys change the way to calculate these crc bytes so often amd with each version that it became a mess, to cover each cases one would need a folder with 8 dll and dynamically retrieve each guid from each version... But originally we should blame the manufacturers that build controllers and use vid/pid from standard manufacturers instead of their own, especially when they use different button layout than the controller they "copy". I did not look yet at sdl3, that will be a whole new story (for better or worse but I hope for better). Basically, when working with sdl and controllers, first hint will always be the guid, these guys change the way to calculate these crc bytes so often amd with each version that it became a mess, to cover each cases one would need a folder with 8 dll and dynamically retrieve each guid from each version...
But originally we should blame the manufacturers that build controllers and use vid/pid from standard manufacturers instead of their own, especially when they use different button layout than the controller they "copy".
I did not look yet at sdl3, that will be a whole new story (for better or worse but I hope for better).
your solution is good, but there is another problem that unfortunately neither sdl2 nor sdl3 will solve, it is the confusion of two absolutely identical controllers. For the correct detection of such devices, the port number to which they are connected is needed. I looked at sdl3, It is impossible to get the USB port number through these libraries. But this is a completely different problem your solution is good, but there is another problem that unfortunately neither sdl2 nor sdl3 will solve, it is the confusion of two absolutely identical controllers. For the correct detection of such devices, the port number to which they are connected is needed. I looked at sdl3, It is impossible to get the USB port number through these libraries. But this is a completely different problem
I don't think this is a problem, ryujinx adds an index before the guid that increments for identical controllers. And worst case scenario, someone has 2 identical controllers connected, there would be no issues just picking up the correct one... I don't think this is a problem, ryujinx adds an index before the guid that increments for identical controllers.
Normally the enumeration order of controllers is the same, as it's based on the device path...
And worst case scenario, someone has 2 identical controllers connected, there would be no issues just picking up the correct one...
|
||||
id = (++guidIndex) + "-" + guidString;
|
||||
|
It seems that this does not affect compatibility with other gamepads, the only thing is that you need to reconfigure all previously connected gamepads. You can instead of zeros write a unique identifier for the emulator, for example RYUX and this also works It seems that this does not affect compatibility with other gamepads, the only thing is that you need to reconfigure all previously connected gamepads.
You can instead of zeros write a unique identifier for the emulator, for example RYUX and this also works
Why use this when sdl2 guid is with 0000, that would make it specific while 0000 keeps standard sdl Why use this when sdl2 guid is with 0000, that would make it specific while 0000 keeps standard sdl
These bytes after their replacement turn out to be meaningless, of course you can leave zeros, but they will not affect anything in the future, including compatibility, except perhaps visual. Your gamepad will still connect without problems, At least I tested it in my assembly and it works great These bytes after their replacement turn out to be meaningless, of course you can leave zeros, but they will not affect anything in the future, including compatibility, except perhaps visual.
For the emulator, this number becomes just a string variable, and then it is simply placed in the list for display in the menu. At least I am currently working on the controller menu and it seems to work exactly like that.
Your gamepad will still connect without problems,
At least I tested it in my assembly and it works great
My recommandation is usually to stick to the standard provided by the library, but i agree that here whatever will work, as it's part of the object... This is an extract of SDL database commonly used : Also native methods used in SDL2 library can return the sdl string without CRC16 (0000 instead). So usually i stick more to the use of what is commonly used, just look at other emulators: My recommandation is usually to stick to the standard provided by the library, but i agree that here whatever will work, as it's part of the object...
This is an extract of SDL database commonly used :
Also native methods used in SDL2 library can return the sdl string without CRC16 (0000 instead).
So usually i stick more to the use of what is commonly used, just look at other emulators:
All in all it works, of course people having saved profiles would need to recreate them once, but that's really not an issue versus the issues that XBOX controllers not saving represent. I've tested with approx 16 controller models (from PS4, dualsense, switch pro, many 8BitDo and Xbox models), and as you already noticed, there is no impact in compatibility of these. All in all it works, of course people having saved profiles would need to recreate them once, but that's really not an issue versus the issues that XBOX controllers not saving represent.
We could even provide a tool that would automatically go through the profile files and edit the guids to fix this and make profiles compatible without having to recreate them, i highly doubt a huge lot of people actually use profiles in an extensive way.
I've tested with approx 16 controller models (from PS4, dualsense, switch pro, many 8BitDo and Xbox models), and as you already noticed, there is no impact in compatibility of these.
I understand everything. I definitely like that it works and the solution turned out to be simpler than I thought. I understand everything. I definitely like that it works and the solution turned out to be simpler than I thought.
Basically, when working with sdl and controllers, first hint will always be the guid, these guys change the way to calculate these crc bytes so often amd with each version that it became a mess, to cover each cases one would need a folder with 8 dll and dynamically retrieve each guid from each version... But originally we should blame the manufacturers that build controllers and use vid/pid from standard manufacturers instead of their own, especially when they use different button layout than the controller they "copy". I did not look yet at sdl3, that will be a whole new story (for better or worse but I hope for better). Basically, when working with sdl and controllers, first hint will always be the guid, these guys change the way to calculate these crc bytes so often amd with each version that it became a mess, to cover each cases one would need a folder with 8 dll and dynamically retrieve each guid from each version...
But originally we should blame the manufacturers that build controllers and use vid/pid from standard manufacturers instead of their own, especially when they use different button layout than the controller they "copy".
I did not look yet at sdl3, that will be a whole new story (for better or worse but I hope for better).
your solution is good, but there is another problem that unfortunately neither sdl2 nor sdl3 will solve, it is the confusion of two absolutely identical controllers. For the correct detection of such devices, the port number to which they are connected is needed. I looked at sdl3, It is impossible to get the USB port number through these libraries. But this is a completely different problem your solution is good, but there is another problem that unfortunately neither sdl2 nor sdl3 will solve, it is the confusion of two absolutely identical controllers. For the correct detection of such devices, the port number to which they are connected is needed. I looked at sdl3, It is impossible to get the USB port number through these libraries. But this is a completely different problem
I don't think this is a problem, ryujinx adds an index before the guid that increments for identical controllers. And worst case scenario, someone has 2 identical controllers connected, there would be no issues just picking up the correct one... I don't think this is a problem, ryujinx adds an index before the guid that increments for identical controllers.
Normally the enumeration order of controllers is the same, as it's based on the device path...
And worst case scenario, someone has 2 identical controllers connected, there would be no issues just picking up the correct one...
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
|
It seems that this does not affect compatibility with other gamepads, the only thing is that you need to reconfigure all previously connected gamepads. You can instead of zeros write a unique identifier for the emulator, for example RYUX and this also works It seems that this does not affect compatibility with other gamepads, the only thing is that you need to reconfigure all previously connected gamepads.
You can instead of zeros write a unique identifier for the emulator, for example RYUX and this also works
It seems that this does not affect compatibility with other gamepads, the only thing is that you need to reconfigure all previously connected gamepads. You can instead of zeros write a unique identifier for the emulator, for example RYUX and this also works It seems that this does not affect compatibility with other gamepads, the only thing is that you need to reconfigure all previously connected gamepads.
You can instead of zeros write a unique identifier for the emulator, for example RYUX and this also works
Why use this when sdl2 guid is with 0000, that would make it specific while 0000 keeps standard sdl Why use this when sdl2 guid is with 0000, that would make it specific while 0000 keeps standard sdl
Why use this when sdl2 guid is with 0000, that would make it specific while 0000 keeps standard sdl Why use this when sdl2 guid is with 0000, that would make it specific while 0000 keeps standard sdl
These bytes after their replacement turn out to be meaningless, of course you can leave zeros, but they will not affect anything in the future, including compatibility, except perhaps visual. Your gamepad will still connect without problems, At least I tested it in my assembly and it works great These bytes after their replacement turn out to be meaningless, of course you can leave zeros, but they will not affect anything in the future, including compatibility, except perhaps visual.
For the emulator, this number becomes just a string variable, and then it is simply placed in the list for display in the menu. At least I am currently working on the controller menu and it seems to work exactly like that.
Your gamepad will still connect without problems,
At least I tested it in my assembly and it works great
These bytes after their replacement turn out to be meaningless, of course you can leave zeros, but they will not affect anything in the future, including compatibility, except perhaps visual. Your gamepad will still connect without problems, At least I tested it in my assembly and it works great These bytes after their replacement turn out to be meaningless, of course you can leave zeros, but they will not affect anything in the future, including compatibility, except perhaps visual.
For the emulator, this number becomes just a string variable, and then it is simply placed in the list for display in the menu. At least I am currently working on the controller menu and it seems to work exactly like that.
Your gamepad will still connect without problems,
At least I tested it in my assembly and it works great
My recommandation is usually to stick to the standard provided by the library, but i agree that here whatever will work, as it's part of the object... This is an extract of SDL database commonly used : Also native methods used in SDL2 library can return the sdl string without CRC16 (0000 instead). So usually i stick more to the use of what is commonly used, just look at other emulators: My recommandation is usually to stick to the standard provided by the library, but i agree that here whatever will work, as it's part of the object...
This is an extract of SDL database commonly used :
Also native methods used in SDL2 library can return the sdl string without CRC16 (0000 instead).
So usually i stick more to the use of what is commonly used, just look at other emulators:
My recommandation is usually to stick to the standard provided by the library, but i agree that here whatever will work, as it's part of the object... This is an extract of SDL database commonly used : Also native methods used in SDL2 library can return the sdl string without CRC16 (0000 instead). So usually i stick more to the use of what is commonly used, just look at other emulators: My recommandation is usually to stick to the standard provided by the library, but i agree that here whatever will work, as it's part of the object...
This is an extract of SDL database commonly used :
Also native methods used in SDL2 library can return the sdl string without CRC16 (0000 instead).
So usually i stick more to the use of what is commonly used, just look at other emulators:
All in all it works, of course people having saved profiles would need to recreate them once, but that's really not an issue versus the issues that XBOX controllers not saving represent. I've tested with approx 16 controller models (from PS4, dualsense, switch pro, many 8BitDo and Xbox models), and as you already noticed, there is no impact in compatibility of these. All in all it works, of course people having saved profiles would need to recreate them once, but that's really not an issue versus the issues that XBOX controllers not saving represent.
We could even provide a tool that would automatically go through the profile files and edit the guids to fix this and make profiles compatible without having to recreate them, i highly doubt a huge lot of people actually use profiles in an extensive way.
I've tested with approx 16 controller models (from PS4, dualsense, switch pro, many 8BitDo and Xbox models), and as you already noticed, there is no impact in compatibility of these.
All in all it works, of course people having saved profiles would need to recreate them once, but that's really not an issue versus the issues that XBOX controllers not saving represent. I've tested with approx 16 controller models (from PS4, dualsense, switch pro, many 8BitDo and Xbox models), and as you already noticed, there is no impact in compatibility of these. All in all it works, of course people having saved profiles would need to recreate them once, but that's really not an issue versus the issues that XBOX controllers not saving represent.
We could even provide a tool that would automatically go through the profile files and edit the guids to fix this and make profiles compatible without having to recreate them, i highly doubt a huge lot of people actually use profiles in an extensive way.
I've tested with approx 16 controller models (from PS4, dualsense, switch pro, many 8BitDo and Xbox models), and as you already noticed, there is no impact in compatibility of these.
I understand everything. I definitely like that it works and the solution turned out to be simpler than I thought. I understand everything. I definitely like that it works and the solution turned out to be simpler than I thought.
I understand everything. I definitely like that it works and the solution turned out to be simpler than I thought. I understand everything. I definitely like that it works and the solution turned out to be simpler than I thought.
Basically, when working with sdl and controllers, first hint will always be the guid, these guys change the way to calculate these crc bytes so often amd with each version that it became a mess, to cover each cases one would need a folder with 8 dll and dynamically retrieve each guid from each version... But originally we should blame the manufacturers that build controllers and use vid/pid from standard manufacturers instead of their own, especially when they use different button layout than the controller they "copy". I did not look yet at sdl3, that will be a whole new story (for better or worse but I hope for better). Basically, when working with sdl and controllers, first hint will always be the guid, these guys change the way to calculate these crc bytes so often amd with each version that it became a mess, to cover each cases one would need a folder with 8 dll and dynamically retrieve each guid from each version...
But originally we should blame the manufacturers that build controllers and use vid/pid from standard manufacturers instead of their own, especially when they use different button layout than the controller they "copy".
I did not look yet at sdl3, that will be a whole new story (for better or worse but I hope for better).
Basically, when working with sdl and controllers, first hint will always be the guid, these guys change the way to calculate these crc bytes so often amd with each version that it became a mess, to cover each cases one would need a folder with 8 dll and dynamically retrieve each guid from each version... But originally we should blame the manufacturers that build controllers and use vid/pid from standard manufacturers instead of their own, especially when they use different button layout than the controller they "copy". I did not look yet at sdl3, that will be a whole new story (for better or worse but I hope for better). Basically, when working with sdl and controllers, first hint will always be the guid, these guys change the way to calculate these crc bytes so often amd with each version that it became a mess, to cover each cases one would need a folder with 8 dll and dynamically retrieve each guid from each version...
But originally we should blame the manufacturers that build controllers and use vid/pid from standard manufacturers instead of their own, especially when they use different button layout than the controller they "copy".
I did not look yet at sdl3, that will be a whole new story (for better or worse but I hope for better).
your solution is good, but there is another problem that unfortunately neither sdl2 nor sdl3 will solve, it is the confusion of two absolutely identical controllers. For the correct detection of such devices, the port number to which they are connected is needed. I looked at sdl3, It is impossible to get the USB port number through these libraries. But this is a completely different problem your solution is good, but there is another problem that unfortunately neither sdl2 nor sdl3 will solve, it is the confusion of two absolutely identical controllers. For the correct detection of such devices, the port number to which they are connected is needed. I looked at sdl3, It is impossible to get the USB port number through these libraries. But this is a completely different problem
your solution is good, but there is another problem that unfortunately neither sdl2 nor sdl3 will solve, it is the confusion of two absolutely identical controllers. For the correct detection of such devices, the port number to which they are connected is needed. I looked at sdl3, It is impossible to get the USB port number through these libraries. But this is a completely different problem your solution is good, but there is another problem that unfortunately neither sdl2 nor sdl3 will solve, it is the confusion of two absolutely identical controllers. For the correct detection of such devices, the port number to which they are connected is needed. I looked at sdl3, It is impossible to get the USB port number through these libraries. But this is a completely different problem
I don't think this is a problem, ryujinx adds an index before the guid that increments for identical controllers. And worst case scenario, someone has 2 identical controllers connected, there would be no issues just picking up the correct one... I don't think this is a problem, ryujinx adds an index before the guid that increments for identical controllers.
Normally the enumeration order of controllers is the same, as it's based on the device path...
And worst case scenario, someone has 2 identical controllers connected, there would be no issues just picking up the correct one...
I don't think this is a problem, ryujinx adds an index before the guid that increments for identical controllers. And worst case scenario, someone has 2 identical controllers connected, there would be no issues just picking up the correct one... I don't think this is a problem, ryujinx adds an index before the guid that increments for identical controllers.
Normally the enumeration order of controllers is the same, as it's based on the device path...
And worst case scenario, someone has 2 identical controllers connected, there would be no issues just picking up the correct one...
|
||||
It seems that this does not affect compatibility with other gamepads, the only thing is that you need to reconfigure all previously connected gamepads.
You can instead of zeros write a unique identifier for the emulator, for example RYUX and this also works
It seems that this does not affect compatibility with other gamepads, the only thing is that you need to reconfigure all previously connected gamepads.
You can instead of zeros write a unique identifier for the emulator, for example RYUX and this also works
Why use this when sdl2 guid is with 0000, that would make it specific while 0000 keeps standard sdl
Why use this when sdl2 guid is with 0000, that would make it specific while 0000 keeps standard sdl
These bytes after their replacement turn out to be meaningless, of course you can leave zeros, but they will not affect anything in the future, including compatibility, except perhaps visual.
For the emulator, this number becomes just a string variable, and then it is simply placed in the list for display in the menu. At least I am currently working on the controller menu and it seems to work exactly like that.
Your gamepad will still connect without problems,
At least I tested it in my assembly and it works great
These bytes after their replacement turn out to be meaningless, of course you can leave zeros, but they will not affect anything in the future, including compatibility, except perhaps visual.
For the emulator, this number becomes just a string variable, and then it is simply placed in the list for display in the menu. At least I am currently working on the controller menu and it seems to work exactly like that.
Your gamepad will still connect without problems,
At least I tested it in my assembly and it works great
My recommandation is usually to stick to the standard provided by the library, but i agree that here whatever will work, as it's part of the object...
This is an extract of SDL database commonly used :
Also native methods used in SDL2 library can return the sdl string without CRC16 (0000 instead).
So usually i stick more to the use of what is commonly used, just look at other emulators:
My recommandation is usually to stick to the standard provided by the library, but i agree that here whatever will work, as it's part of the object...
This is an extract of SDL database commonly used :
Also native methods used in SDL2 library can return the sdl string without CRC16 (0000 instead).
So usually i stick more to the use of what is commonly used, just look at other emulators:
All in all it works, of course people having saved profiles would need to recreate them once, but that's really not an issue versus the issues that XBOX controllers not saving represent.
We could even provide a tool that would automatically go through the profile files and edit the guids to fix this and make profiles compatible without having to recreate them, i highly doubt a huge lot of people actually use profiles in an extensive way.
I've tested with approx 16 controller models (from PS4, dualsense, switch pro, many 8BitDo and Xbox models), and as you already noticed, there is no impact in compatibility of these.
All in all it works, of course people having saved profiles would need to recreate them once, but that's really not an issue versus the issues that XBOX controllers not saving represent.
We could even provide a tool that would automatically go through the profile files and edit the guids to fix this and make profiles compatible without having to recreate them, i highly doubt a huge lot of people actually use profiles in an extensive way.
I've tested with approx 16 controller models (from PS4, dualsense, switch pro, many 8BitDo and Xbox models), and as you already noticed, there is no impact in compatibility of these.
I understand everything. I definitely like that it works and the solution turned out to be simpler than I thought.
I understand everything. I definitely like that it works and the solution turned out to be simpler than I thought.
Basically, when working with sdl and controllers, first hint will always be the guid, these guys change the way to calculate these crc bytes so often amd with each version that it became a mess, to cover each cases one would need a folder with 8 dll and dynamically retrieve each guid from each version...
But originally we should blame the manufacturers that build controllers and use vid/pid from standard manufacturers instead of their own, especially when they use different button layout than the controller they "copy".
I did not look yet at sdl3, that will be a whole new story (for better or worse but I hope for better).
Basically, when working with sdl and controllers, first hint will always be the guid, these guys change the way to calculate these crc bytes so often amd with each version that it became a mess, to cover each cases one would need a folder with 8 dll and dynamically retrieve each guid from each version...
But originally we should blame the manufacturers that build controllers and use vid/pid from standard manufacturers instead of their own, especially when they use different button layout than the controller they "copy".
I did not look yet at sdl3, that will be a whole new story (for better or worse but I hope for better).
your solution is good, but there is another problem that unfortunately neither sdl2 nor sdl3 will solve, it is the confusion of two absolutely identical controllers. For the correct detection of such devices, the port number to which they are connected is needed. I looked at sdl3, It is impossible to get the USB port number through these libraries. But this is a completely different problem
your solution is good, but there is another problem that unfortunately neither sdl2 nor sdl3 will solve, it is the confusion of two absolutely identical controllers. For the correct detection of such devices, the port number to which they are connected is needed. I looked at sdl3, It is impossible to get the USB port number through these libraries. But this is a completely different problem
I don't think this is a problem, ryujinx adds an index before the guid that increments for identical controllers.
Normally the enumeration order of controllers is the same, as it's based on the device path...
And worst case scenario, someone has 2 identical controllers connected, there would be no issues just picking up the correct one...
I don't think this is a problem, ryujinx adds an index before the guid that increments for identical controllers.
Normally the enumeration order of controllers is the same, as it's based on the device path...
And worst case scenario, someone has 2 identical controllers connected, there would be no issues just picking up the correct one...