Squarepusher are you guys gonna update today? Will test if you add the arcade stick i put o the other thread, because today i´ve been trying to play with 2 joysticks on a tablet binding manually the inputs but 30 seconds or so after i load the game the app does not respond (not even any of both pads)
Im gonna look again this with other usb hub and joysticks, not sure what happened today, maybe with 2 usb pads automatically configured this would not happen.
I dont get tired of saying thank you to all of you making this possible, keep the hard work
Yes, it has a bug with XP gamepad.
When RetroArch loads games, it assign the input devices order by which keys pressed first. It takes first pressed key’s gamepad as 1P gamepad.
This makes XP’s game pad not working properly.
For XP, direction keys, X, triangle, square, menu and serach key are of same device code:HID 163310: keypad-zeus
Start, Select and Volume keys are of another same device code: HID 0: Keypad-game-zeus
Touch screen is HID 65541: cy8ctma300_touch
Touch pad is HID 65539: synaptics_touchp
So if we want it to work, We have to follow following steps.
1.RetroArch Settings—>Input Settings–>Configuration Autodetect ,disable
2.RetroArch Settings—>Input Settings–>Player 1 Custom Binds
Direction keys and ABXY,L1,R1 are mapped here. Start is mapped to Menu, while Select mapped to Search.
3.Touchscreen Overlay Enable
When game is loaded, NEVER press Start or Select and NEVER use touch pad or touch screen. Make sure that any button among Direction keys and ABXY,L1,R1 is firstly pressed.
If you do above steps, you can use XP game pad properly. But, you can not quit game with Return. To quit game, press Home to back to desktop, launch RetroArch, and press press Start or Select ,or use touch pad or touch screen. This makes direction keys disabled, and you can quit game now.
Yes, it has a bug with XP gamepad.
When RetroArch loads games, it assign the input devices order by which keys pressed first. It takes first pressed key’s gamepad as 1P gamepad.
This makes XP’s game pad not working properly.
For XP, direction keys, X, triangle, square, menu and serach key are of same device code:HID 163310: keypad-zeus
Start, Select and Volume keys are of another same device code: HID 0: Keypad-game-zeus
Touch screen is HID 65541: cy8ctma300_touch
Touch pad is HID 65539: synaptics_touchp
So if we want it to work, We have to follow following steps.
1.RetroArch Settings—>Input Settings–>Configuration Autodetect ,disable
2.RetroArch Settings—>Input Settings–>Player 1 Custom Binds
Direction keys and ABXY,L1,R1 are mapped here. Start is mapped to Menu, while Select mapped to Search.
3.Touchscreen Overlay Enable
When game is loaded, NEVER press Start or Select and NEVER use touch pad or touch screen. Make sure that any button among Direction keys and ABXY,L1,R1 is firstly pressed.
If you do below steps, you can sue XP game pad properly. But, you can not quit game with Return. To quit game, press Home to back to desktop, launch RetroArch, and press press Start or Select ,or use touch pad or touch screen. This makes direction keys disabled, and you can quit game now.[/quote]
Thanks to a user called kiri87, we managed to fix this today.
So the next update (r9) will have fully working Xperia Play controls (except for the Synaptics touchpad ‘touch analog’ thingies - but there is no real analog stick support in RetroArch Android anyway so we’ll return to that later).
The latest release is now working well on my Xperia Pro (possibly benefitting from the Xperia Play fixes), thanks!
However with the shaders bundled the app now consumes a lot of internal storage. Would it be possible to allow install to sd or does that come with significant technical hurdles?
You could just delete them all from your device - you don’t need those shaders at least and on Xperia Play it’s going to be way too slow to be useful anyway - you need a Tegra 4/Exynos5-class GPU for fullspeed results on most of them.
Anyway, the shader files shouldn’t consume much memory - 2MB at most.
False positive - you can not take anything for granted when it comes to Android performance - it’s a sucky non-realtime OS and it will run better or worse depending on the number of services that are running in the background. Best thing to do when you get performance issues is to restart your phone/tablet, turn off wifi, turn off some services or something along that nature.
Really, the problem lies elsewhere - and this is the big problem with Android - you can’t guarantee a stable runtime performance - it’s all dependent on what you have running in the background as a user and how your OS was configured. Making an OS based on Java with ‘native code’ running in a jail was a TERRIBLE, TERRIBLE IDEA from a performance standpoint.
Another thing that will boost performance is to ‘disable’ overlays entirely. People want them ever more elaborate, so that means that system requirements will go up. After ‘adjustable scaling’ of overlays we are going to call it a day though - if people are still not satisfied by then, then they’re just going to have to learn how to make custom overlays - it isn’t hard, we tried making it as easy as possible, and if it’s still not easy enough, a user (kamui) is working on an overlay maker Android app which could hopefully fill the void.
I spoke to one of you guys in the Reddit thread a while ago and finally got around to trying to document a controller after I asked about having it being supported in RetroArch. I was told to make a post in here by TheToadKing with the info, so hopefully I’ve been able to provide you with everything needed.
It is the ThinkGeek 8-bitty and is a bit of an oddity as far as controllers go. It doesn’t reply on single code or character button mapping.
It sends two different characters per button. One when the button is pressed and a different character when the button is released. Some bluetooth controllers support the iCade scheme that the 8-bitty follows so it would allow for supporting a small handful of controllers in implementation and not just the 8-bitty. Unfortunately, success in using this controller largely depends on app support.
There is an open source SDK for the iCade but it’s mainly for iOS and doesn’t seem to mention the 8-bitty at all. Dunno if it is complete. It’s what is linked on the 8-bitty page, though.
Device Name in Bluetooth Settings when connected to my phone: ThinkGeek 8-bitty Game Controller
If I pressed the left shoulder button repeatedly, it would be sent as: hrhrhrhrhrhrhrhrhr
No spaces between characters sent, only the characters mentioned below.
Left Shoulder pressed: h
Left Shoulder released: r
Right Shoulder pressed: j
Right Shoulder released: n
Up pressed: w
Up released: e
down pressed: x
down released: z
left pressed: a
left released: q
right pressed: d
right released: c
middle left (aka select) pressed: y
middle left (aka select) released: t
middle right (aka start) pressed: u
middle right (aka start) released: f
top left (aka Y) pressed: i
top left (aka Y) released: m
top right (aka X) pressed: o
top right (aka X) released: g
bottom left (aka B) pressed: k
bottom left (aka B) released: p
bottom right (aka A) pressed: l
bottom right (aka A) released: v
The problem with these 8-bitty pads is that they report a ‘generic’ Bluetooth HID name - there will probably be a lot of other devices under the sun that use the exact same HID name with different buton layouts - so this is one case where autodetecting these pads will either be difficult or not possible and it might be best to just use custom mapping instead.
Actually, I’m not sure of this yet - perhaps we just need an extra unique identifier for pad detection so that we can differentiate these pads in some way.
Perhaps I need an additional option in the Input Settings menu for iCade in general - so you can select a ‘profile’ for a specific implementation of iCade. Selecting the ‘8-bitty’ profile for instance would set up an iCade pad with an 8-bitty layout. I could also make this option configurable for each of the 8 pads that RetroArch Android supports - so that you can setup autodetection for different ICade pads that way.
Sounds great, actually. It’d also serve as a nice reminder and way to look up what other controllers are already supported by the app if someone is looking to shop for one.
Perhaps you can include a dropdown selection list under configuration autodetect that becomes selectable if you uncheck “Enable”… Allowing someone to choose a profile and make it a permanent setting instead of having it redetected each time the app starts. That would help for people who may have controller and/or keyboard conflicts.
It’s a shame that what ended up being the most simple, adaptable and portable bluetooth controller out there had to be the biggest pain in the butt when it comes to being able to use it. Very few (if any) can come close to how easy it is to keep the 8Bitty around since it’ll easily go in my pocket with my phone.
False positive - you can not take anything for granted when it comes to Android performance - it’s a sucky non-realtime OS and it will run better or worse depending on the number of services that are running in the background. Best thing to do when you get performance issues is to restart your phone/tablet, turn off wifi, turn off some services or something along that nature.
Really, the problem lies elsewhere - and this is the big problem with Android - you can’t guarantee a stable runtime performance - it’s all dependent on what you have running in the background as a user and how your OS was configured. Making an OS based on Java with ‘native code’ running in a jail was a TERRIBLE, TERRIBLE IDEA from a performance standpoint.
Another thing that will boost performance is to ‘disable’ overlays entirely. People want them ever more elaborate, so that means that system requirements will go up. After ‘adjustable scaling’ of overlays we are going to call it a day though - if people are still not satisfied by then, then they’re just going to have to learn how to make custom overlays - it isn’t hard, we tried making it as easy as possible, and if it’s still not easy enough, a user (kamui) is working on an overlay maker Android app which could hopefully fill the void.[/quote]
I disable overlays both iN R8 and R9, so I think the speed slowing down is not about overlays.
False positive - you can not take anything for granted when it comes to Android performance - it’s a sucky non-realtime OS and it will run better or worse depending on the number of services that are running in the background. Best thing to do when you get performance issues is to restart your phone/tablet, turn off wifi, turn off some services or something along that nature.
Really, the problem lies elsewhere - and this is the big problem with Android - you can’t guarantee a stable runtime performance - it’s all dependent on what you have running in the background as a user and how your OS was configured. Making an OS based on Java with ‘native code’ running in a jail was a TERRIBLE, TERRIBLE IDEA from a performance standpoint.
Another thing that will boost performance is to ‘disable’ overlays entirely. People want them ever more elaborate, so that means that system requirements will go up. After ‘adjustable scaling’ of overlays we are going to call it a day though - if people are still not satisfied by then, then they’re just going to have to learn how to make custom overlays - it isn’t hard, we tried making it as easy as possible, and if it’s still not easy enough, a user (kamui) is working on an overlay maker Android app which could hopefully fill the void.[/quote]
I disable overlays both iN R8 and R9, so I think the speed slowing down is not about overlays.[/quote]
There is nothing that got changed that should have made it slower.
EDIT: Are you using an Xperia Play? Because I’ve seen in a debug log that it uses a really bad refresh rate value that it reports to the OS - try to turn off ‘Sync refreshrate to screen’ and set ‘Custom refresh rate’ instead - set it to something like 59.95. See if that works better.
Same thing applies here right now as what I told the Galaxy S3 guys:
Yes - I explain it in the ‘RetroArch Manual’ PDF - your Galaxy S3 reports a ‘wrong’ refreshrate - it says that the screen is 60Hz but that’s not true - so you need to disable ‘Sync refreshrate to screen’ and start experimenting with the refresh rate - start at 59.95Hz and then go lower until you hit the sweet spot.
We’ll need to sort out the refresh rate problems with certain devices because vendors cannot be trusted to report the ‘real refresh rate’ of the screen to the Android OS. Xperia Play and Galaxy S3 are both examples of that where the manufacturer either ‘lies’ about the refresh rate of the screen or just plain gets it wrong. Note 2 gets it right though.
