Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Android Bug Thread  (Read 7379 times)

0 Members and 1 Guest are viewing this topic.

AlexAUT

  • Sr. Member
  • ****
  • Posts: 396
    • View Profile
Android Bug Thread
« 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)


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


AlexAUT
« Last Edit: June 21, 2014, 12:21:11 pm by AlexAUT »

Sonkun

  • Full Member
  • ***
  • Posts: 241
    • View Profile
Re: Android Bug Thread
« Reply #1 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.
Interested in using SFML with Python ? Try out its Python binding!

AlexAUT

  • Sr. Member
  • ****
  • Posts: 396
    • View Profile
Re: Android Bug Thread
« Reply #2 on: June 21, 2014, 12:20:42 pm »
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.

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

Sonkun

  • Full Member
  • ***
  • Posts: 241
    • View Profile
Re: Android Bug Thread
« Reply #3 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
Interested in using SFML with Python ? Try out its Python binding!

AlexAUT

  • Sr. Member
  • ****
  • Posts: 396
    • View Profile
Re: Android Bug Thread
« Reply #4 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