Fba core still not playing neogeo… Used mame 147 rom but no luck. Roms working perfectly on fba 1.6.
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?
R9 runs slower than R8 does 
And once again, you have outdated ROMs and (very likely) a very incomplete romset. Nothing I can do about it.
Most probably your NeoGeo BIOS zip file is outdated or missing a file.
PS: Can somebody make a SHA1 or MD5 sum of their neogeo.zip file that works?
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.
Product Page for the 8-bitty: http://www.thinkgeek.com/product/ecea/
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
/proc/bus/input/devices
I: Bus=0005 Vendor=0000 Product=0000 Version=0000 N: Name=“BT HID” P: Phys= S: Sysfs=/devices/virtual/input/input11 U: Uniq= H: Handlers=sysrq event6 keyreset keychord B: PROP=0 B: EV=12001b B: KEY=400000 0 0 0 10000 2000007 ff9f387a c94057ff febeffdf ffefffff ffffffff fffffffe B: ABS=f00 0 B: MSC=10 B: LED=1f
Button mapping:
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.
Found a PDF with the iCade Developer’s Resource…
Shows the button mapping for the iCade arcade cabinet for the iPad… but Android tablets can use this controller and cabinet, too.
Same button mapping for the 8-bitty, just the buttons are laid out in a slightly different order.
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.
How does that sound to you?
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.
@Squarepusher:
neogeo.zip (latest FBA)
SHA1: E627605D17A8EF6423BBC0CFFF7563D141DDCB43
MD5: 356BE30C5E37F749A604A5E3CBFB4F72
CRC32: 959451DF
<game name="neogeo">
<description>neogeo</description>
<rom name="000-lo.lo" size="131072" crc="5a86cff2" md5="fc7599f3f871578fe9a0453662d1c966" sha1="5992277debadeb64d1c1c64b0a92d9293eaf7e4a"/>
<rom name="asia-s3.rom" size="131072" crc="91b64be3" md5="ff453315c5ddacc0f3bf4ca994c13adc" sha1="720a3e20d26818632aedf2c2fd16c54f213543e1"/>
<rom name="japan-j3.bin" size="131072" crc="dff6d41f" md5="5b2d6f653ba4cf36e7fe237e4acb2f50" sha1="e92910e20092577a4523a6b39d578a71d4de7085"/>
<rom name="neo-epo.bin" size="131072" crc="d27a71f1" md5="b11751ad42879c461d64ad2b7b2b0129" sha1="1b3b22092f30c4d1b2c15f04d1670eb1e9fbea07"/>
<rom name="neo-po.bin" size="131072" crc="16d0c132" md5="1ec68104095d4b7236e8c18c77ea501b" sha1="4e4a440cae46f3889d20234aebd7f8d5f522e22c"/>
<rom name="neodebug.bin" size="131072" crc="698ebb7d" md5="3089166a89d9735d038e8e7da36e5bc2" sha1="081c49aa8cc7dad5939833dc1b18338321ea0a07"/>
<rom name="neopen.sp1" size="131072" crc="cb915e76" md5="fb5070239588630de48838e0d92ce526" sha1="11f95ee6c73b1bcc11d03d5b3127ba5948920c76"/>
<rom name="sfix.sfix" size="131072" crc="c2ea0cfd" md5="aa2b5d0eae4158ffc0d7d63481c7830b" sha1="fd4a618cdcdbf849374f0a50dd8efe9dbab706c3"/>
<rom name="sm1.sm1" size="131072" crc="94416d67" md5="8c26241f9f5beb3a55c8d6ab638d250e" sha1="42f9d7ddd6c0931fd64226a60dc73602b2819dcf"/>
<rom name="sp-1v1_3db8c.bin" size="131072" crc="162f0ebe" md5="629e6beaa277e039eae2f96ff237f8e6" sha1="fe1c6dd3dfcf97d960065b1bb46c1e11cb7bf271"/>
<rom name="sp-45.sp1" size="524288" crc="03cc9f6a" md5="0396470c1ed8b1a7d5cce754924246bb" sha1="cdf1f49e3ff2bac528c21ed28449cf35b7957dc1"/>
<rom name="sp-e.sp1" size="131072" crc="2723a5b5" md5="a7b798c9cafb1aba49090bca34e1d4ec" sha1="5dbff7531cf04886cde3ef022fb5ca687573dcb8"/>
<rom name="sp-j2.sp1" size="131072" crc="acede59c" md5="a51ad226535ff862c1f54120e4298f79" sha1="b6f97acd282fd7e94d9426078a90f059b5e9dd91"/>
<rom name="sp-s.sp1" size="131072" crc="c7f2fa45" md5="908b5a0026b2b10f2a7c01ccd98a1236" sha1="09576ff20b4d6b365e78e6a5698ea450262697cd"/>
<rom name="sp-s2.sp1" size="131072" crc="9036d879" md5="2968f59f44bf328639aa79391aeeeab4" sha1="4f5ed7105b7128794654ce82b51723e16e389543"/>
<rom name="sp-u2.sp1" size="131072" crc="e72943de" md5="b60fb8ea07e8a64772ab717afba3706d" sha1="5c6bba07d2ec8ac95776aa3511109f5e1e2e92eb"/>
<rom name="sp1.jipan.1024" size="131072" crc="9fb0abe4" md5="a80fffe27bf8e615171ce728e43d2f6c" sha1="18a987ce2229df79a8cf6a84f968f0e42ce4e59d"/>
<rom name="uni-bios_1_0.rom" size="131072" crc="0ce453a0" md5="6293999bbc32e594aa0ae1da2113dc4d" sha1="3b4c0cd26c176fc6b26c3a2f95143dd478f6abf9"/>
<rom name="uni-bios_1_1.rom" size="131072" crc="5dda0d84" md5="cafa6c274b271c769b8246c8f87473a1" sha1="4153d533c02926a2577e49c32657214781ff29b7"/>
<rom name="uni-bios_1_2.rom" size="131072" crc="4fa698e9" md5="206fb0d9b5d01a0375d2d3ecab2401b1" sha1="682e13ec1c42beaa2d04473967840c88fd52c75a"/>
<rom name="uni-bios_1_2o.rom" size="131072" crc="e19d3ce9" md5="6b2f2d8507be4d1feb14fdfbab0bf22e" sha1="af88ef837f44a3af2d7144bb46a37c8512b67770"/>
<rom name="uni-bios_1_3.rom" size="131072" crc="b24b44a0" md5="856d122ee5fc473d7d1dd99dbf42c25b" sha1="eca8851d30557b97c309a0d9f4a9d20e5b14af4e"/>
<rom name="uni-bios_2_0.rom" size="131072" crc="0c12c2ad" md5="1b9724d1b9d41a1a9b733007b2033fb5" sha1="37bcd4d30f3892078b46841d895a6eff16dc921e"/>
<rom name="uni-bios_2_1.rom" size="131072" crc="8dabf76b" md5="0377c32f69a28f23d9281c448aafb391" sha1="c23732c4491d966cf0373c65c83c7a4e88f0082c"/>
<rom name="uni-bios_2_2.rom" size="131072" crc="2d50996a" md5="5b9079a81d84137d8b6f221659d777c5" sha1="5241a4fb0c63b1a23fd1da8efa9c9a9bd3b4279c"/>
<rom name="uni-bios_2_3.rom" size="131072" crc="27664eb5" md5="74c4bb6a945f7284350036b40f0a0d9d" sha1="5b02900a3ccf3df168bdcfc98458136fd2b92ac0"/>
<rom name="uni-bios_2_3o.rom" size="131072" crc="601720ae" md5="d9f0ed2e0eeab813c9692d7e8d037fd8" sha1="1b8a72c720cdb5ee3f1d735bbcf447b09204b8d9"/>
<rom name="uni-bios_3_0.rom" size="131072" crc="a97c89a9" md5="727b731c1f4bd643094574ebaa3814b4" sha1="97a5eff3b119062f10e31ad6f04fe4b90d366e7f"/>
<rom name="vs-bios.rom" size="131072" crc="f0e8f27d" md5="530fb9761957e59aeb47f2e8782df288" sha1="ecf01eda815909f1facec62abf3594eaa8d11075"/>
</game>
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.
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.
How does that sound to you?[/quote]
As an 8-Bitty owner, I’ll interject here and say I would LOVE this. Thank you again for all your hard work here.
In r9 the onscreen buttons seem to stop responding after a gamepad is detected, so there is no way to access the quick menu.
The touchscreen is now always used for player 1 - and doesn’t take up a slot for the gamepads.
What kind of device do you have so we can troubleshoot this?
The touchscreen is now always used for player 1 - and doesn’t take up a slot for the gamepads.
What kind of device do you have so we can troubleshoot this?[/quote]
My device is a Nexus 7
Not sure if it helps, but here is the full logcat output of me launching retroarch, starting a sega genesis game, and pressing a button on my ps3 controller (at which point the touch buttons become unresponsive) http://pastebin.com/aezjBQtV
The touchscreen is now always used for player 1 - and doesn’t take up a slot for the gamepads.
What kind of device do you have so we can troubleshoot this?[/quote]
My device is a Nexus 7
Not sure if it helps, but here is the full logcat output of me launching retroarch, starting a sega genesis game, and pressing a button on my ps3 controller (at which point the touch buttons become unresponsive) http://pastebin.com/aezjBQtV[/quote] Unfotunately, the log doesn’t explain a whole lot.
Just to make sure: you can use the touch controls before using the controller? Also, what app are you using for PS3 controllers, or are you just connecting them via USB? Also, does the back button still work after using the controller?
New version posted (r10) - see OP.
r10 (Feb 5, 2013)
- [NXEngine / Cave Story] Fixed bug where moving blocks would not move in Labyrinth levels
- Add new psx and GBA overlays by user boxs.
- Should fix some touchscreen control issues.
Download
APK (r10) - https://anonfiles.com/file/a341ba50b135121318fdcb342c1992af
Google Play Store -https://play.google.com/store/apps/details?id=org.retroarch
Grab it here in advance - should be on Google Play store later.