@edmaul69 you make me want to install some dos games now if you can configure keyboard to controller. Never even bothered to look.
I found a "bug" in the theme thus far. I put the psp logo into the master system folder. I'll upload a fix later today with some new systems as well. I need to learn how to get GitHub up and running so I can easily just upload new changes. Any one want to help me with this?
@hex I think I'm done with this project. It's just not going to happen.
I gave up porting MicroEmulator. It's ridiculously over-complicated. I figured it would be easier to just write the thing from scratch, so I did.
MicroEmulator, for all its absurdity, works very simply. It implements javax.microedition.* and uses the reflection API to read the manifest, load the application, and call the startApp method.
Simple, right? So that's exactly what I did. Granted, while my implementation of javax.microedition was minimal, it was good enough to get a few games to run for a while. Happy with my progress, and the significantly simpler code base, I added a JavaFx UI and some code to handle all the image drawing. That's when everything fell apart.
See, JavaFx doesn't like when you try to modify things from outside a JavaFx thread. Naturally, games will want to do this very thing. Short of a lot of very slow pixel-by-pixel image operations (yes, really) and some tricky message passing, a pure JavaFx solution was out.
Big deal, right? Just re-implement all the graphics stuff in AWT and use SwingFXUtils. It's simple and mostly solves the problem.
A test shows that the AWT works on the pi, you just can't display anything. So I gave it a try with a sample application. Unfortunately, SwingFXUtils is not available to us on the pi. It's like we're a niche market that Oracle doesn't care about.
So I'm out. It was an interesting distraction, but it's looking like a fool's errand.
All is not lost, however. For anyone interested in playing a few games that didn't previously work in MicroEmulator due to one problem or another, I have the last MicroEmulator build I made.
@pjft GPU memory and textures are handled by the Qt library -- which I've recently updated on the build server to 5.9.1. It's supposed to be a minor maintenance/bugfix release to 5.9, but as it turned out it was the cause of the bug. So for now I'll revert to 5.9, and try to report the bug to the Qt devs.
Can I just ask (considering that my images folder is different for 'Arcade' and all other platforms - Arcade is in arcade/images, other platforms in platform/boxart or marquee etc), will I have to update each gamelist separately, altering the image path each time? All will the software only overwrite the XML where changes have been made?
I'm also guessing I'm going to run into issues where the boxart, marquee and video are saved in different folders?
So the reason I'm not having rumble is because I didn't install the ps3controller driver and I'm using the (for lack of better terms) built in one that doesn't support it? So the quick and easy solution is to install that driver. Otherwise, wait and get the new kernel update when RaspberryPi Foundation pushes out the update with a new version of Raspbian (or whatever they use).
I'm trying to remember what conflict I had when I last did a kernel update. I know there was one update I had to get, to patch in the Raphnet "northwest drift" fix on my NES build. After that, I did a kernel update and it broke something. I think it was when the branch of ES came out that brought in video preview art support. But I can't remember what part actually broke. It might have been skin related, or something to do with it locking up. I'll have to go back through my post history over the last few months to find it. :(
I'm pretty sure that the ps3controller is only a userspace wrapper, which means it doesn't need any special kernel version or driver module to be built. You can most likely install it without updating the underlying OS/kernel; just make sure to update the RetroPie script so that it fetches the latest driver and includes the Bluetooth compatibility fix.
I'm not 100% certain if the ps3controller will override the Sony HID driver on the USB connection and I can't really test that for you (my Pi is powering a 2.5" drive & plugging in the PS3 controller causes the drive to disconnect due to lack of power).
You can see what version is used from the dmesg log (this is a Bluetooth log, but USB would be similar):
sony 0005:054C:0268.0007: input,hidraw1: BLUETOOTH HID v1.00 Joystick [PLAYSTATION(R)3 Controller] on xx:xx:xx:xx:xx:xx
Wrapped driver using generic HID:
input: PLAYSTATION(R)3 Controller as /devices/virtual/input/input1
I did spend some time getting the inputs right but so far without success.
To get it right the sdl input should have to be rewritten to use a event driven model instead of a polling model.
The polling it now uses has timing issues causing the misfiring experienced in roms like choplifter.
The input crosstalk is another thing requiring a lot of work.
The original 5200 used multiplexers to select which joystick port places keypad (row/column) data on the bus, as far as i can tell the core does not have this implemented so all incoming data appears to come from all joystickports.
I thought about the game specific but then it would show the mega man launch image if I launch it from the NES system....I guess it isn't the end of the world, but I would like to get it so that mega man.zip shows the mega man lunch when launched from the mega man system and mega man.zip has the nes launch when launched from the nes system.
This is not a bid deal at all, so no worries. Thanks
The old standby that everyone always recommends for the Pi is this one. I've used it myself in the past and it always seemed to work well. Currently, I use an iPazzPort model that eliminates the trackpad for an airmouse, making it even more compact, but currently it doesn't appear to be available anywhere.
Looks like your connection to RetroPie Forum was lost, please wait while we try to reconnect.