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

Author Topic: SFML android port  (Read 16963 times)

0 Members and 2 Guests are viewing this topic.

greeniekin

  • Jr. Member
  • **
  • Posts: 66
    • View Profile
SFML android port
« on: October 16, 2012, 04:50:43 am »
Thought i would give a quick demo of my progress.

The goal is to have all the gui_apps in the examples projects folder in sfmls cmake folder run. Preferably with as little or no changes if possible.

Below is a quick example of sfml system and sfml window parts. It simply makes the entire screen a color.
The green color is controlled by a timer and reset every second and can be reset when your finger touches the screen. The red color is controlled by your fingers last x position and blue by your fingers last y position.

all the same as normal sfml except using gles. There is one part at the top which is driving me nuts. If i have that function where I wanted in sfml window then when it is statically linked the compiler optimizes it out ><. If you have any ideas. I would appreciate it.


/*
stupid peice of code here. The android activity handling stuff would be completely unnoticed.
Though because it is adding a static library and if the ANativeActivity_onCreate entry point is in it. it seems to get Optimised out. >< joy.
*/


#include <android/native_activity.h>
extern void ANativeActivity_onCreate2(ANativeActivity* activity, void* savedState, size_t savedStateSize);

void ANativeActivity_onCreate(ANativeActivity* activity, void* savedState, size_t savedStateSize)
{
        ANativeActivity_onCreate2(activity, savedState, savedStateSize);
}



////////////////////////////////////////////////////////////
// Headers
////////////////////////////////////////////////////////////
#include <SFML/Window.hpp>
#include <GLES/gl.h>





////////////////////////////////////////////////////////////
/// Entry point of application
///
/// \return Application exit code
///
////////////////////////////////////////////////////////////
int main()
{
    // Create the main window
    sf::Window window(sf::VideoMode(640, 480, 32), "SFML Window", sf::Style::Default, sf::ContextSettings(32));

    // Create a clock for measuring the time elapsed
    sf::Clock clock;

    sf::Vector2u size=window.getSize();

    // Start the game loop
    while (window.isOpen())
    {
        // Process events
        sf::Event event;
        while (window.pollEvent(event))
        {
            // Close window : exit
            if (event.type == sf::Event::Closed)
                window.close();

            if (event.type == sf::Event::MouseButtonPressed)
                clock.restart();

            // Resize event : adjust viewport
            if (event.type == sf::Event::Resized)
            glViewport(0, 0, event.size.width, event.size.height);
       }
           
        float x =  sf::Mouse::getPosition(window).x;
        float y = sf::Mouse::getPosition(window).y;

               
        x /=size.x;
        y /=size.y;

        float val=clock.getElapsedTime().asSeconds();

        if(val>1)
            val=clock.restart().asSeconds();
           
        glClearColor(x, val, y , 1);
        glClear(GL_COLOR_BUFFER_BIT);

        // Finally, display the rendered frame on screen
        window.display();
    }

    return EXIT_SUCCESS;
}
 

below is a video. unfortunately it is not very clear on when i am clicking which is mean to represent my finger on the screen.



I also use extra stuff not shown. Like threads, mutex's and locks. It was required to get the main thread working.

Also any experienced OpenGL ES 2 users around? I suppose this is really not the place where they would be.  Having worked on mobiles which are not really related to SFML. Restructuring the graphics library will be hardest. plus compiling it's libs for android. Hopefully I can offload that work onto you guys :P
« Last Edit: October 16, 2012, 06:03:06 am by greeniekin »

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Re: SFML android port
« Reply #1 on: October 16, 2012, 08:06:01 am »
Quote
There is one part at the top which is driving me nuts. If i have that function where I wanted in sfml window then when it is statically linked the compiler optimizes it out ><. If you have any ideas. I would appreciate it.
I faced a similar problem recently, and couldn't find a better solution :(
However for me it was not an optimization problem, the function was there but somehow it couldn't be found by the linker when it was in the static library.

Quote
Restructuring the graphics library will be hardest. plus compiling it's libs for android. Hopefully I can offload that work onto you guys
I plan to work on it soon after SFML 2.0 is released.
You should share your work so that I can use it when doing the official port :)
Laurent Gomila - SFML developer

budsan

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: SFML android port
« Reply #2 on: October 16, 2012, 08:55:23 am »
Hi All,

I'm developing a framework as a hobby for mobile devices and desktop computers. During the development sometimes I've faced problems like sharing context resources through threads and more. Looking for a solution I realised SFML solves most of this problems but it main problem is SFML isn't OpenGL ES 2.0 compatible. For a long time I was rethinking how SFML can internally works for support glES2 without any API break. IMHO, it's hard to archive that.

Later I also faced with the lack of any multitouch event in SFML. I mean, Android 4.0 have mice and multitouch API separately, also does Blackberry OS 10. Even in Windows 8 or Wayland have multitouch devices support. Should they exist? I think they should.

I offer my time and my skill if there is any attempt in the future to port SFML to glES 2.0 :)

greeniekin

  • Jr. Member
  • **
  • Posts: 66
    • View Profile
Re: SFML android port
« Reply #3 on: October 16, 2012, 09:09:38 am »
I would be happy and honored if it even slightly helped with the official port.

It needs a little cleaning up and my cmake cross compile script is very window targeted. It has the windows ndk in the folder and generates a build cmd to make building it easy.

Yah I was thinking that multi-touch would be needed. I think your first touch could just be considered a mouse click as it makes less work when cross compiling an app. Plus I have a multi-touch  laptop and there is never a time when I would need to use the touch screen and mouse simultaneously.

Though second touch needs to be added. That could just be a new event type.

The naming of the first one will be misleading as mouse.

We could use the name pointer as that is what android seems to use to represent it's input. It would still represent mouse and touches.
like sf::pointer::getPosition().x and  sf::pointer2::getPosition().x

Though it starts to get a little confusing.
« Last Edit: October 16, 2012, 09:19:00 am by greeniekin »

Mario

  • SFML Team
  • Hero Member
  • *****
  • Posts: 879
    • View Profile
Re: SFML android port
« Reply #4 on: October 25, 2012, 03:08:50 pm »
Regarding your issue with the optimized native activity: You don't have to use it or create it on your own - at least I've never done so so far. The NDK provides premade code you can link.

The AndroidManifest.xml:
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
   package="my.unique.package.name"
   android:versionCode="1"
   android:versionName="1.0" >
    <uses-sdk android:minSdkVersion="12" />
    <application
       android:label="@string/app_name"
                android:hasCode="false" >
        <activity
           android:name="android.app.NativeActivity"
           android:label="@string/app_name" >
                        <meta-data android:name="android.app.lib_name"
                                android:value="mylibraryname" />
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
    </application>
</manifest>

The main entry point in main.cpp looks like this:
#include <android_native_app_glue.h>

int main(int argc, char **argv) {
        // stuff happening...
        return 0;
}
 

In your Android.mk make sure to link the following static library:
Code: [Select]
LOCAL_STATIC_LIBRARIES := android_native_app_glue
I plan to work on it soon after SFML 2.0 is released.
You should share your work so that I can use it when doing the official port :)
Let me know if/when you start doing so and could need some help. Would love helping you getting it written, tested, etc. and to get some prototype games stuff finally ported to Android (and finished).
« Last Edit: October 25, 2012, 03:11:32 pm by Mario »

greeniekin

  • Jr. Member
  • **
  • Posts: 66
    • View Profile
Re: SFML android port
« Reply #5 on: November 02, 2012, 09:56:52 pm »
Regarding your issue with the optimized native activity: You don't have to use it or create it on your own - at least I've never done so so far. The NDK provides premade code you can link.

I do use the premade native-activity provided by android. Which is just a premade java front end which calls ANativeActivity_onCreate from shared library you provide.  That's all the glue really does except convoluted thread stuff. Which is simpler with sfml.

I actually produce a native library used in native activity from sfml cmake build with examples.
Just like you currently can build sfml with examples on windows mac and linux.

I do not use the glue code as that is not the problem. It is some how related to having the function in a static library linked to the main shared library if not referenced. The glue code gets around this through the header I think.

Unless the android mk file has an invisible flag that stops this stuff. I have found other stuff like that.


Also the glue code will not call the main thread it will call
void android_main(struct android_app* app)

my code does call main()

The idea being that you do not need to make any changes to your source and just compile for all 4 of the operating systems.
« Last Edit: November 03, 2012, 05:15:18 am by greeniekin »

Mario

  • SFML Team
  • Hero Member
  • *****
  • Posts: 879
    • View Profile
Re: SFML android port
« Reply #6 on: November 05, 2012, 01:14:12 am »
Ah, okay - sounds nice and reasonable.

I'd actually move the custom glue code to SFML-main (similar to the WinMain/main redirect) and then try to link it as described here. But this sounds like something interesting to have a look at. Definitely some screwing with GCC somewhere - just linking the library would be a lot more awesome.

Edit:
Just had a quick look; it's not even in the headers (only in android_native_app_glue.c). Custom toolchain magic I guess?
How about providing an inline wrapper mapping android_main() to main()? If there are other calls you'd like to do, do them there? Or is it the whole threading stuff for the main thread you'd like to avoid?
« Last Edit: November 05, 2012, 01:26:19 am by Mario »

greeniekin

  • Jr. Member
  • **
  • Posts: 66
    • View Profile
Re: SFML android port
« Reply #7 on: November 05, 2012, 01:28:11 pm »
I originally had it in sfml main. Though it manages all window management events. So it seems more natural to put it in sfml windows. as the on event calls can directly be converted to sfml window events. Linking sfml window should in theory automatically set up everything for main thread and window management.

The only way to have a main function is to create a thread for it. as all on call events must return or the activity will be considered frozen. Plus choosing on what event the main thread will be created means we can assure everything is ready for the window creation things like to set up opengl.

I have not worked on it any more yet. So i need to do more experiments.
« Last Edit: November 05, 2012, 01:43:56 pm by greeniekin »

Mario

  • SFML Team
  • Hero Member
  • *****
  • Posts: 879
    • View Profile
Re: SFML android port
« Reply #8 on: November 05, 2012, 02:24:08 pm »
Yes, I've read about that. Overall, it probably really depends on whether it's really feasible to use SFML without SFML's window lib.

But in the end I'd still tend to keep it in the main library, considering it's really just another "if you don't want to implement it yourself" entry point stuff (i.e. not that different to WinMain). Just adding the wrapper from android_main() to main() (excluding the native glue part) inside SFML's main sounds like exactly the same thing the Windows version does. You don't have to use it (e.g. write it yourself), but you can.

greeniekin

  • Jr. Member
  • **
  • Posts: 66
    • View Profile
Re: SFML android port
« Reply #9 on: November 05, 2012, 03:55:20 pm »
I do not see any benefit from having a standard main function without using sfml window. As it means the main method runs and  the native activity still exists.Yet there is no way to get access to anything to do with the native activity or handle it's events.

also if you provide a way for the user to implement the handling of the activity startup then it creates problems for event management stuff and opengl stuff. They would not be able to use the window class. They would essentially be handling all windows events and drawing.

The only way I can think of this working is making public methods to push events and pass information needed. Which starts to get confusing cross platform wise and breaks the idea where as little public modifications as possible are made.

I doubt anyone would implement their own. The main benefit of using sfml on android would it being portable to other os's.
As if you are developing specifically for android using java would be simpler and feature full.
« Last Edit: November 05, 2012, 03:58:23 pm by greeniekin »

greeniekin

  • Jr. Member
  • **
  • Posts: 66
    • View Profile
Re: SFML android port
« Reply #10 on: February 28, 2013, 10:58:38 am »
Decided to do a little more work on this past couple of nights. fleshed out event handling quite a bit. Better support for buttons and even keyboards. Also I have ouya controllers working. With the controllers being sfml joysticks. x and y are the left thumb stick, z and r are the right thumbstick,u is the left trigger and v the right trigger.
Which turned out quite nice.

I mapped the android back button to keyboard escape. Dpad to keyboard arrow keys. Select button to keyboard enter. That is it so far. Means you can write a simple single player game for a pc and it will work on ouya and android. Though if you have multiple controllers on the ouya they will send the keyboard events. You need to use joystick to distinguish them. Which I kind of like the idea of anyway.

I have kind of started on the graphics part. I am looking to use GLES 2. Which is a bit of a pain as it lacks matrix modes and  fixed functions and seems to require shaders for everything. Which does not really match the current design. I thought I read somewhere opengl 3 is much the same. Anyway Unsure exactly what my solution will be. I do not want to have 2 code bases. Especially since I think a fair amount will be similar.
« Last Edit: February 28, 2013, 11:08:30 am by greeniekin »

Mario

  • SFML Team
  • Hero Member
  • *****
  • Posts: 879
    • View Profile
Re: SFML android port
« Reply #11 on: March 02, 2013, 03:41:35 pm »
Very nice, although I'm not sure about mapping softkeys like the back button to existing keyboard keys. I'd probably add custom enum members.

Anything new on the main/entry point front?

greeniekin

  • Jr. Member
  • **
  • Posts: 66
    • View Profile
Re: SFML android port
« Reply #12 on: March 28, 2013, 03:41:31 pm »
*Imagin mad scientist from space voice...that's also a space pirate....and awesome with jectpacks*

They called me mad for not using the android glue code. Mad they said. I called them mad and damn them, they outvoted me.
Now I have shown them. I shall rain fire and brimstone upon those that doubt me.
Well if I can work that into really poor budget. Otherwise it will be more of cursing you from my share house...

http://forums.ouya.tv/discussion/846/opengl-performance-with-touch-events#latest

On a side note I have done a bit more. Got shaders(mandatory for GLES 2) and some rendering working.
So currently graphics works much like SFML window src works with sub folders representing the os specific part. Except the subfolders are "opengl" and "gles2"

Not much is done here and I am tempted to not make graphics 2d specific. Have features that accept matrix and then have a graphics 2d specific stuff that is specific to 2d and inherits from normal matrix stuff and there there is the potential to use the same code for personal 3d stuff or a seperate 3d library. This way code can be shared as opposed to the current model.

As to the main entry point. I have implemented a hack. When building the examples I include a c++ file with the top part of code. Making it unnoticeable..... in the examples built in cmake. Though outside you would have to include it your self. ><
« Last Edit: March 28, 2013, 03:44:34 pm by greeniekin »

Mario

  • SFML Team
  • Hero Member
  • *****
  • Posts: 879
    • View Profile
Re: SFML android port
« Reply #13 on: March 30, 2013, 10:18:42 am »
Still sounds rather mad... :P No, great. :)

Probably wouldn't worry too much about the glue code for now, although I'm really a bit surprised the event handling is so time critical.