SFML community forums

General => General discussions => Topic started by: AlexAUT on June 21, 2014, 09:42:15 am

Title: Android Bug Thread
Post by: AlexAUT on June 21, 2014, 09:42:15 am

I decided to make a new thread about the Android-port because I don't think mixing Android and iOS is a good idea.

As you may know I released my first game on the play store, and maybe I'm the first guy who used the Android port for a game. First of all, it was quite a pain in the a**. There are still many problems with the port and I will publish my Buglist below (I fixed every problem in my private fork so I could help to fix every single on):
 

• The android port won't even compile. The fix is already posted by Mario in April... (http://en.sfml-dev.org/forums/index.php?topic=13716.msg105423#msg105423)
• Without changing the src of SFML you can't use sf::Text and transparent sprites because transparency will be  rendered as white  ??? . So you have to use the fix written by Jonathan in December last year... (http://en.sfml-dev.org/forums/index.php?topic=13716.msg97191#msg97191)
• Audio files have to be normalized, (Edit: found that this is a limitation of a third party lib)
• You can't access hardware keys like "Back, Home, Edit, VolumeKeys, PowerSwitch". Why do we have implemented advanced stuff like sensors but we cant access these very important buttons? Fixing this is a matter for minutes just add sf::Keyboard::VolumeDown etc and chage the switch in Android/windowimpl .
  
• You can't tell SFML to give the events for the volume keys back to the OS, I know that you maybe want to use the volume keys in an multimedia app for example scrolling. But for games with Music it's a must that you can change the Volume of the Device.
  
  Two Options:
  
  • Insert a function to the renderWindow like changeDeviceVolume(int offset), but this function is very hard to implement in native code
  • Like I fixed it in my private fork add a member "mUsingVolumeKeys" and the change in src/window/Android/WindowImplAndroid.cpp the keyEvent handling (Code is written below the list

Event handling code

(click to show/hide)

if (action == AKEY_EVENT_ACTION_DOWN || action == AKEY_EVENT_ACTION_UP || action == AKEY_EVENT_ACTION_MULTIPLE)
{
      processKeyEvent(_event, states);
      //New part
      int32_t key = AKeyEvent_getKeyCode(_event);
      if(mUsingVolumeKeys && (key == 24 || key == 25)) //24, 25 are the values for the volume keys
      {
            handled = 0;
            AInputQueue_finishEvent(states->inputQueue, _event, handled);
            return 1;
      }
}

So my question is, are you guys still working on the port? Because some bugs are known since 6months!


AlexAUT

Title: Re: Android Bug Thread
Post by: Sonkun on June 21, 2014, 11:12:01 am

What's the point in listing bugs/issues already fixed :p

1. Fixed.
2. https://github.com/SFML/SFML/commit/ce1037118c043bec33d6c1d36ab368b9f8e609b2
3. Isn't related to the Android port (AFAIK)
4. Yeah.. I haven't yet taken the time to think about to which key code I have to bind them but I intended to work on that this week-end (since now I need them for my own game :D).
5. Won't happen. But if key events are generated for Volume UP/DOWN, we might consider adding new key code to SFML.

Quote

So my question is, are you guys still working on the port? Because some bugs are known since 6months!

Yes... Sorry but implementing the Android port isn't as trivial as writing Kroniax.

Title: Re: Android Bug Thread
Post by: AlexAUT on June 21, 2014, 12:20:42 pm

Quote from: Sonkun on June 21, 2014, 11:12:01 am

What's the point in listing bugs/issues already fixed :p

Looks like I messed something up when testing the current source of sfml-master (maybe used an old master), because #1 and #2 still occured, so sry.

Quote from: Sonkun on June 21, 2014, 11:12:01 am

But if key events are generated for Volume UP/DOWN, we might consider adding new key code to SFML.

Events are generated for VolumeUP/DOWN, but currently you say to the OS that you are using them but as a user of SFML we can't access them  :-[. And if we can access them we can't change the volume of the device anyway (I didn't found a way to do it from native code), so I think something like my "implementation" has to be done.



AlexAUT

Title: Re: Android Bug Thread
Post by: Sonkun on June 21, 2014, 01:04:34 pm

I may have misunderstood you on point 5. I though you asked us to map these volume up/down events to all sf::Sound and sf::Music objects. Would mapping volume up/down events to key codes solve your problem ? I can easily imagine the need to be in the know about the sound volume value, to keep the volume slider in your app updated, or to know when the volume is off/on. I'll investigate this issue shortly and will get back to you. :)

I'd be glad if you show me the code about volume events too :p

Title: Re: Android Bug Thread
Post by: AlexAUT on June 21, 2014, 01:24:11 pm

Ok, now I think you missunderstood me ;)

The VolumeKeys trigger an KeyPressed/Released, but the keyvalues aren't mapped to sf::Keyboard:: .So you can't check if the keys are pressed. This is one problem.

The other is that you can't change the "master"-volume of your device except with my little code addition postet in my first post. Currently when you are pressing the volume keys nothing is happening except a KeyPressed/Released event with key.code = sf::Keyboard::Unknown  :)



AlexAUT