Idea for the Android port

[BlisterB]

Hi guys !

I open this issue to centralize suggestions about how improve the Android port, don't hesitate to give me job :) !

Idea :

• [x] Multiple game directory
• [ ] Hi res splash screen while game browser parses the directories (I think this one is not possible has it depend from the C++ code)
• [x] Thumbnail support in GameBrowser (ask to find a quick way to store title screenshot)
• [ ] Key mapping for gamepads
• [x] Better configuration file for projects
• [x] Re do the settings activity
• [x] Different game displaying system depending on device screen
• [ ] A setting button in "select game layout"
• [ ] Ask for permission to add .nomedia in new game folder.

[Ghabry]

• Support for multiply game directories (configurable in the settings)
  • The Game Browser itself should just merge all directories
  • Problem: How to deal with duplicates (same game in multiple directories)
  • Problem: On some Android devices (Android 4.4) the SD card is without rooting only writable by system apps (= only google)
  • Workaround: New command line option --save-path to overwrite the save directory (and save in the data directory of the apk instead). This should be transparent for the user, no interaction required.
• Button mapping for individual games
  • Reasonable defaults for RPG2k and RPG2k3 and some popular games, e.g. Yume Nikki preset
  • Moving buttons around while ingame (with running game rendered semi-transparent in the background)
  • Resizing of buttons
• A shiny, high-res "Easy RPG Player" splashscreen while the game browser parses the directories ;)
• Some users asked for Thumbnail support, but that would require some LDB parsing to get the title image

I don't think that file management (delete game e.g.) is required, but maybe "open game directory" and "open save directory", which launches ES File Explorer or whatever is installed.

[BlisterB]

Thanks for the ideas :) ! I'll start to improve the button mapping system (the easiest xp). I think I'll switch to an xml format, that will be way more flexible for the futur.

I thought of this :

• Use tabs to switch 2k/2k3/all game
  • https://www.google.com/design/spec/components/tabs.html#tabs-usage
  • Require to find how to know the Rm version of a game x))).

I also thought of displaying a thumbnail, that would be a big UX improvement BUT there are those .LDB parsing and folder's name thing (different depending on version/location). If I find which function are involved in the C++ code I maybe will be able to use them with JNI (after learning how to use it hahaha).

[Ghabry]

The problem here is that liblcf is not optimized for quickly extracting a single information out of the LDB-database. It always parses all of it, which is a waste of time here. The only feasible approach when using liblcf here is to cache the result... or to write a very simple parser in Java, only extracting title image and version code is simple.

[Zegeri]

It could create the thumbnail the first time you open the game.

[fdelapena]

• Fix allow horizontal screen flip preventing activity reset. Having vertical might also be worth, with relative virtual buttons positioning. This is useful for larger screens and buttons are not covering the game screen.
• Joystick custom key mapping support, e.g. for Xperia Play, Ouya and bluetooth pads. I'd prefer this being cross platform but it's OK for now.

[BlisterB]

Haha I was the guy who annoyed you for Xperia Play support, but it's dead snif RIP gaming in train ;'(. Okay so I'll deeply remake the button mapping system !

Is it a problem if I use JDOM .jar to parse xml ? It use an Apache licence, which is GPL3 compatible. https://en.wikipedia.org/wiki/JDOM https://en.wikipedia.org/wiki/Apache_License

[fdelapena]

According with the license is an Apache-like license but not Apache. Apache 2.0 license is GPLv3 compatible but JDOM license clause 4 is GPL incompatible, according with a related question in debian-legal mailing list.

[BlisterB]

Pff those licences stuff break my balls. Thanks for the explanation ! I'll use a basic format.

[Ghabry]

Doesn't Java include a XML parser? Did you consider using json? ;)

[BlisterB]

Oh nice, I didn't even known about that format, thanks Ghabry !

[Zegeri]

If it used INI, the per-game setting could be loaded/saved from the RPG_RT.ini file. That way, if you want to distribute your game using easyrpg, you could set a recommended default buttons setting.

[fdelapena]

+1 for .ini, you can use ini4j and eventually it could be reused later for a non-Android implementation without losing existing stored settings.

[BlisterB]

That's a good idea but the problem is that EasyRPG will have its own button preset list, if the user modifies one, it has to be applied to all game involved. But I can implement a way for a developper to suggest a predefined button mapping in the .ini, EasyRPG would ask the first time to the user if he want to use it.

[BlisterB]

Hi guys. Some news, I'm working on proportional input layout (between landscape and portrait mode)... And as I thought it's not good. To keep approximatively proportions in portrait I only consider half of the screen. But buttons become too short.

I don't really know what to do, here are some clues :

• Use fixed sized button in portrait (with adjustment in position, aka the present situation in master branch), and resizable button only in landscape
• Resizable buttons in portrait and landscape mode, but 200% of normal size in portrait

In both configuration there is the risk of buttons on others buttons. But I think the first one is better.

[BlisterB]

• Use resizable buttons in both orientation (based on fixed proportion and not screen resolution), but cheating in portrait with proportion and an horizontal gap seems to be a good choice.

[fdelapena]

Nice, some users asked for resizable buttons for several devices, they were looking too small. What about another slider to adjust the size by the user if possible?

[BlisterB]

:o I was wondering how to display the resizing function for days and you unlocked it in my mind.

Sooooo. 2 options :

• In ButtonMapping system, display a slider under the last moved button, to resize it in real time (I'll learn one or more thing hihi).
• In Settings Activity, displaying a resize option for every button of every inputLayout (one slider to rule them all) OR
• Doing the 2 things, BUT with a checkbox in settings, to bypass inputLayout resize configuration (look the best to me).

[Ghabry]

How about activating a button by touching it (color changes) and then you can resize it by making a zoom gesture (moving two fingers)

[BlisterB]

API 10 my friend :p But there will be a thing to show that the button is selected and a another to show the possibility to resize it, which is not the case for two fingered movements.

[BlisterB]

Soooo. Here are the Adventures of BlisterB in an Android World™.

To have a clean and an understandable GUI, use discrete sliders is a good idea (better than implement an ugly thing with a textfield actualized in real time). Good news, Android Visual GuideLine are talking of discrete sliders, they looks awesome : https://www.google.com/design/spec/components/sliders.html#sliders-discrete-slider

That's wonderful, this will provide us a wonderful GUI. Guess what, those slider doesn't exist.. Nowhere, not in a single API's version. (That's not a joke XD).

The only solution (like everytime in android) is to use a library that solve the problem: https://github.com/AnderWeb/discreteSeekBar

By chance, this one use a true Apache V2 licence. So we can include it in EasyRPG : http://www.apache.org/licenses/GPL-compatibility.html

Does it poses a problem if I use it ?

[BlisterB]

(Of course I can do the textfield thing)

[Ghabry]

Sure if you think that external libs are useful add them. What is the problem with your current slider solution? For me it works fine ^^

[BlisterB]

Yep I finally did the other solution and it's not so bad. Sometimes you just go nuts when you see the difference between what they say you can do and what you really can do lol. I'll remember the libs thing for later, thanks Ghabry !

Btw the Android port really starts to being cool ^^. But the Google Play (in french) highlights just comments talking about past problems.. What a shame ! Is there a way to hide them ? (As they are solved for a long time).

[BlisterB]

Another thing to do : Fix the standalone mode.

[Ghabry]

The standalone mode has one gigantic problem: It wastes twice the space because the game must be extracted out of the assets. Maybe it should be considered to download the game over the internet on startup instead. Any other suggestions?

The more complex solution would be to work with Streams in the FileFinder API and not with Filenames... then we could open streams to the files in the asset part of the APK.

And no we can't hide anything in the Store. Imo it is really stupid, that all rating are weighted the same way. Older ratings should be downweighted to make it possible to get a better rating over time.

[BlisterB]

Yeah that sucks ! Some bad comments from frenchies comes from people which seems to have no idea of what is RPG Maker ^^".

I fixed the standalone mode, I saw the problem of copy folders. Why is there a copy ? Because application cannot write file in asset folder ? For the moment it's not a big deal, but we can find solution such as copying file in external storage or use a different folder for save/log/etc. A good thing to implement is the possibility for the maker to indicate preferences (button mapping, screen filter etc.) in a file. It would be loaded in standalone (in game browser mode, a dialog box would ask the first time if the user wants to use the maker's preferences, or user's preferences).

[Ghabry]

The problem is that the Assets are in in an archive, so you can't get a handle to them from the native code.

This could be worked around by adding extra code to the following FileFinder functions (native code):

fopenUTF8 
IsDirectory 
Exists
GetDirectoryMembers

Then it should be possible to use the asset dir directly.

https://stackoverflow.com/questions/13317387/how-to-get-file-in-assets-from-android-ndk

Should be easily possible to get a FILE* handle by using AAsset_openFileDescriptor and then open this descriptor using fdopen. Will check this during the weekend :)

[Ghabry]

The first review already complained, why the new version only occupies half of the screen. :D

[BlisterB]

Wtf are they stupid or something ? The screen occupy the totality of the screen in one dimension

[BlisterB]

I can only access to french review, does the person complain about the actuel system (which would be stupid) or is it a bug ? Can you copy/past it ?

[fdelapena]

Add &hl=en or &hl=de or &hl=es from the google play website for other reviews

[Ghabry]

Of course they are stupid. You can never think as stupid as the worst user :D

Why open the game becomes vertical screen, and only half of the screen is displayed on the previous version ....... not so .....

Original review
为什么打开游戏变成竖屏的了，只显示在屏幕上半部分.......以前的版本不是这样的.....

[BlisterB]

Thanks @fdelapena !

@Ghabry , is there a way to ask google his location ? I want to piss on his door. Don't tell me he've put a bad rate x). No joking, some comments make me wonder if every user understand they are using a RPG Maker Emulator.

Guys you should look the PR relative to changing directory, I will have less and less time to change it if someone bothers you :/.

[Ghabry]

He gave 4 Stars. There are more and more users who ask for an ESC key. But B is the same as ESC... m(

[carstene1ns]

Time to implement an in-app FAQ. :grinning:

[fdelapena]

Because some games are documenting "Esc or X" and "B" is unrelated may be confusing, that's why I was suggesting to change it to "X" and then put something in the key mapping like "X (Esc)" and also "Z (Enter)", and show "Z" instead of "A" in the button. I guess most users won't understand the meaning of "B" and "A" and default RPG Maker mappings.

[BlisterB]

@fdelapena , B key in a keyboard really does the same thing than ESC button, as A does the same than Enter

[BlisterB]

I don't know why you proposed X and Y buttons, do you really use those buttons when you use a keyboard ? Because A and B have the advantage to be a "convention" for everyone since the NES pad. Seriously, just one or two guy don't know this. If we change theses buttons, more and more people will be confused.

[Ghabry]

Maybe this could be clarified by changing the text in the "Add button" dialog (the user should see this dialog because he searches ESC). And changing the text of "B" to: "B (Equal to keys ESC and X)" (and while doing this "A (Equal to keys ENTER/RETURN and Y)")

[BlisterB]

It sounds to be an excellent compromise Le 5 oct. 2015 10:53 AM, "Ghabry" notifications@github.com a écrit :

Maybe this could be clarified by changing the text in the "Add button" dialog (the user should see this dialog because he searches ESC). And changing the text of "B" to: "B (Equal to keys ESC and X)" (and while doing this "A (Equal to keys ENTER/RETURN and Y)")

— Reply to this email directly or view it on GitHub https://github.com/EasyRPG/Player/issues/575#issuecomment-145466584.

[Ghabry]

There are 3 minor (?) (well it's Android, maybe they are tricky :D) improvements that would be useful: [ ] Force Orientation (*) Landscape ( ) Orientation in settings [ Edit ] Button in the "Choose Layout" dialog because the users are too stupid to open the settings

In Game: [ Settings ] to open the settings [ Edit Layout ] to edit the current used layout

[BlisterB]

[ ] Force Orientation (*) Landscape ( ) Orientation in settings [ Edit ] Button in the "Choose Layout" dialog because the users are too stupid to open the settings

Good ideas, my 2 friends will be available for working on the port in few weeks, this will be a great start for them to understand the project ! Also the Settings Activity start to be quite bulky, dividing option by section will be nice.

[ Settings ] to open the settings

We can use a "menu" button in game, the app "My Boy!" use this features and I find it usefull.

[ Edit Layout ] to edit the current used layout

Edit the layout in game would be a good improvement but, Android lolilol => will probably kill the game session while the user edit the layout in another activity x).

[Ghabry]

I wanted to write the "Force Orientation" on my own. But I gave up after 30min. because I had no idea how to do this. Not even breakpoints worked, the breakpoint is triggered but the activity rotates and native code continues m( Yeah so I will forward it to your friends :D

[BlisterB]

Haha don't worry this is their problem now xp. Screen orientation is a classic exemple of problems with Android : instead of providing a function doing it, we have to overwrite the function onConfigurationChanged(Configuration newConfig) and call it manually (and praying to not have complains from Samsung's users). This is counter the logic of the architecture, but well...

Even the SettingsActivity itself. Android provide an Activity helping changing preferences, but it's so limited that I was forced to code it like a normal activity x) (this is why the SettingsActivity is so bulky).

[Ghabry]

Maybe we should consider switching to API14 (4.0.4).

The amount of people running under 2.3.3 is currently less then 2% (200 devices) and the daily install rate of people with 2.3.3 is 1% (~3 devices).

[BlisterB]

How do we do the thumb up icon, I need a lot of them

EDIT : :+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1:

[BlisterB]

But more seriously, we should try to use the Android Support Library before switching to another API. The problem is always the same : a lot of thing are not supported by native older api, even the API 14 and 15.

[BlisterB]

(But Android Studio propose some really nice and intuitive Activity with API >= 15)

[Ghabry]

And have to correct myself: API 15 is 4.0.3 :+1:

[BlisterB]

What do you think about keeping the minimum API to 10, but changing the target to 15? Of course, only when somebody will have to implement something using the target 15.