Emulator(Native Android)

[nicksen782]

I must have missed the bootloader support. It would be neat if you could pick either version for Iros (regular and GM) right from CUzeBox. Of course, the Emscripten filesystem would need to have a download of both roms for that to work. Perhaps this could be useful for development/debugging. Outside of testing new bootloaders, where would this feature be used?

Android? It's available on Android? ???

[Artcfox]

Yes, it works with:

Code: Select all

cuzebox Bootloader_0_4_5.hex

What I did was do a git clone of your online repository, and then extracted the games folder telling the extraction program to ignore directories (so it extracted all the games to a single folder), dropped the Bootloader_0_4_5.hex in there, and Poof! I now have 7 pages of Uzebox games that I can select from. I did notice that some of the games in your database only have a .hex file, rather than a .uze file, so the bootloader method of selecting them does not work, so for this to be viable, I think everything should be in a .uze format.

A rudimentary version has been available on Android for quite a while now (downloads available in the last post of the first page of this thread). I don't know much about Android programming, so if you rotate the device, it half-kills the emulator, and you'll need to force quit it, and for now you have to compile each game into it, because I did this at a time when CUzeBox didn't have bootloader support. Just plug a USB On-The-Go adapter into your phone, and then plug a USB keyboard into it to play. I tried getting a wired XBox360 controller working, but I don't think that CUzeBox supports "joysticks" yet.

I did this port a while ago (back in February), and on my Pixel XL it runs perfectly (it can even run at 230% CPU if I turn off the frame limiter!). Hell, even the Emscripten version almost always runs at full speed in Firefox on the Pixel XL, which is why I think the person who did screen recordings from the web version was using a really slow computer.

Someone who knows more about Android programming could probably put some polish on this so it runs well, and maybe supports wireless joysticks (or even invisible on-screen touch controls for people w/o joysticks).

I envisioned this feature being used in lieu of having to create multiple native file selection mechanisms for each emulator port. So any platform the emulator is ported to it would automatically have native game-selection built into it, exactly the way it would run on real-hardware. I figure an Android app would be able to automatically keep the list of games current, and download them into a folder on the sdcard, where the application could find them when running the bootloader.

[nicksen782]

I did notice that some of the games in your database only have a .hex file, rather than a .uze file, so the bootloader method of selecting them does not work, so for this to be viable, I think everything should be in a .uze format.

I figure an Android app would be able to automatically keep the list of games current, and download them into a folder on the sdcard, where the application could find them when running the bootloader.

In some cases I only found the .hex file. I imagine that the could be converted to .uze. In a couple of cases I actually included both files although only one of the files is set as the game.

A simple sort of rsync or folder hashing could be used to determine if there are updates. Seems like a cool idea for the future.

[Jubatian]

Someone who knows more about Android programming could probably put some polish on this so it runs well, and maybe supports wireless joysticks (or even invisible on-screen touch controls for people w/o joysticks).

Now that I added a proper game input module, I could go on to include touch events trying to cook up some interaction method for phones. However I have no smartphone, I never had one, neither any touch sensitive screen, so I really don't know how a typical user interface should look like. Does anyone have such experience (could tell how other emulators react on phones? Particularly NES / SNES which have the same controllers like Uzebox?)

[Artcfox]

I think that most people who game on their portable devices have game controllers, so I wouldn't worry about adding on-screen controls just yet. I looked up some SNES emulators in Google Play, and it looks like in landscape mode they put the D-pad to the left of the screen, and the buttons to the right, and the shoulder buttons on the top of the screen. In portrait mode, the game window is on top, and the controls are all on the bottom half, like so:

unnamed.jpg (29.11 KiB) Viewed 9258 times

I also re-compiled the latest version of CUzeBox (with my patches for the Buffalo game controllers) for Android, and while the Android OS can see and use the game controller, the Android version of CUzeBox can't. I believe that hot plugging support is required in order for Android to pass it along to an SDL game.

I also discovered how to force it into landscape mode, so it no longer crashes, just because you accidentally rotated the device.

In the AndroidManifest.xml file, make sure it says:

Code: Select all

        <activity android:name="SDLActivity"
                  android:label="@string/app_name"
                  android:configChanges="keyboardHidden|orientation"
                  android:screenOrientation="userLandscape"
                  android:alwaysRetainTaskState="true"
                  android:launchMode="singleTask"

Attached is the latest .apk if anyone wants to plug a keyboard into their Android device and try it. I still haven't figured out how to make it quit gracefully, so you'll still have to Force Quit it. (Sorry)

[Artcfox]

I'm just gonna leave this here...



(CUzeBox compiled for Android with bootloader support that can read games from /storage/emulated/0/cuzebox)

After installing, you must go to App Info, click on Permissions, and then slide the slider over so it has permissions to read and write to external storage, otherwise the app will just crash when you try to run it.

[L4rry]

I'd suggest testing tilt based controls as an input option for directional movement as well. Could be interesting. Maybe action buttons can be configurable per game on where you press on the screen. Maybe top half could be jump, maybe fast paced tapping could be shooting. Dunno. Maybe using the strengths of smartphone capability to do something interesting? Never liked the onscreen controls for retro gaming on a smart phone. No tactile feedback and it takes away graphical real estate. Not sure if there is a real solution for that really.

[Artcfox]

I'd suggest testing tilt based controls as an input option for directional movement as well. Could be interesting. Maybe action buttons can be configurable per game on where you press on the screen. Maybe top half could be jump, maybe fast paced tapping could be shooting. Dunno. Maybe using the strengths of smartphone capability to do something interesting? Never liked the onscreen controls for retro gaming on a smart phone. No tactile feedback and it takes away graphical real estate. Not sure if there is a real solution for that really.

That could be pretty interesting for games that don't require every button on the controllers to function. Your post did get me thinking about the other forms of input that the Uzebox supports that not so many people have, the SNES mouse. I am not sure if CUzeBox has mouse support, but if it does, I wonder if the touch screen could be used in place of a SNES mouse?

I'm thinking touch even could be registered as Moved to this (X, Y) in the same way that a SNES mouse move event would register, and then the top half of the dead space on one side of the screen might be left-click while the bottom half of that dead space registers as a right-click. Maybe even allow different pre-configured button layouts in the dead space for the other buttons?

Those are just ideas, really my main goal for this port is to get it to a point where Bluetooth/USB game controllers and Bluetooth/USB keyboards can function. I know that USB keyboards function, but since I can't get my old Apple BT keyboard to pair with any phone I have, I can't test if BT keyboards function with this port.

Can anyone with a Bluetooth keyboard on Android test to see if it works for this port? Thanks!

[Artcfox]

I figured out how to get the Java wrapper to cleanly exit when pressing Esc, so you aren't required to Force Stop it on Android.

All I had to do was add an:

Code: Select all

exit(0);

at the end of the native code, right before the:

Code: Select all

return 0;

I also tweaked the name and icons, but for some reason if I try to change the package name from org.libsdl.app, the application keeps crashing. I tried to change it everywhere, but that doesn't seem to work. If anyone knows the proper way to rename this on Android, please let me know.

I also changed some of the properties in the manifest file, so Android doesn't kill the Activity when you do certain things like plugging in and unplugging a keyboard (seriously, WTF Android!?):

Code: Select all

        <activity android:name="SDLActivity"
                  android:label="@string/app_name"
                  android:configChanges="mcc|mnc|locale|touchscreen|keyboard|keyboardHidden|navigation|screenLayout|fontScale|uiMode|orientation|screenSize|smallestScreenSize|layoutDirection"
                  android:screenOrientation="userLandscape"
                  android:alwaysRetainTaskState="true"
                  android:launchMode="singleTask"
                  android:finishOnTaskLaunch="true"
            >

If you've installed the .apk from the above .7z file, all you should need to do is reinstall it from the attached .zip file. If you uninstall the old one first, you'll need to grant this new one the storage permissions, but if you install it as an update to the existing one, you shouldn't have to do that. Since all of the game files are separate, installing and uninstalling won't affect those.

[Jubatian]

I figured out how to get the Java wrapper to cleanly exit when pressing Esc, so you aren't required to Force Stop it on Android.

All I had to do was add an:

Code: Select all

exit(0);

at the end of the native code, right before the:

Code: Select all

return 0;

I found a relevant topic in SDL's development forum:

https://forums.libsdl.org/viewtopic.php?p=40812

It seems like it is more complex than that, it just works. Reading that however I am unsure whether the emulator would behave correctly upon restarting.